Phillip J. Eby wrote: > At 09:15 AM 1/23/2008 -0800, Robert Brewer wrote: >> I consider it a bug in both, and the difficulty level of changing the >> CGI behavior really has no bearing on our decision to do better with >> WSGI. I think it's important that we allow the full range of URI's to be >> accepted. If you go and stick Apache in front of your WSGI app, it will >> still 404, sure; but that's your choice to use Apache or not. There's no >> sense making WSGI a least common denominator, inheriting all the >> limitations of all the existing web servers. > > Uh, actually, that's sort of the whole point of WSGI - to allow > portable applications. If the spec allows you to do something in > theory that's almost never allowed in practice, that's not very helpful.
It could probably work in a good number of implementations, but because some gateways could lose or reject the encoding, the deployment becomes kind of fragile. Of course you could argue the same thing about SCRIPT_NAME -- it's constantly getting lost and makes deployments seem fragile at times. But in contrast to this issue, it's actually quite useful; distinguishing %2f and / is more of a corner case. > MoinMoin, for example, has its own encoding scheme for handling > pseudo-slashes in paths, and IMO it's a better way to handle it than > trying to rely on finding a server that supports *not* decoding URLs. We encountered it with GData too, as it uses URLs like /{http:%2f%2fexample.com}term/. But if you balance the {}'s you can parse it out. Ian _______________________________________________ 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