On Sat, Jul 17, 2010 at 5:57 AM, Armin Ronacher <armin.ronac...@active-4.com > wrote:
> On 7/17/10 9:15 AM, Ian Bicking wrote: > >> This is an Apache-specific issue. It definitely doesn't apply to >> paste.httpserver, I doubt CherryPy or wsgiref. I don't really know how >> Nginx or other servers work. >> > > This will be an issue for every server that... > > * supports unicode filesystems > * decides to do internal mapping based on URIs and not IRIs > I think specifically it's hard to go back and forth between URL-encoded and decoded paths, so if a system parses the decoded path then it's difficult to go back to a raw form. For example Paste includes several URL mappers, and they would require (minor) rewriting; but then they can be rewritten so it's not as concerning. Apache cannot be rewritten to parse the encoded URL. I think working on the encoded URLs is a better representation of HTTP, and HTTP URLs, and of browser behavior... but there is a legacy concern. I don't think IRI or URI matters in this case; by decoding you *could* transcode URLs from UTF-8 to some local encoding, but that's not the issue I see us encountering here, it's really the more simple issue of URL encoding. (I should say I appreciate this concrete concern; it keeps us grounded when we discuss HTTP *specifically*, not bytes-v-unicode generally) -- Ian Bicking | http://blog.ianbicking.org
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
