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. I don't consider WSGI's CGI compatibility on this point to be an error, in other words. An application that expects to receive encoded URLs is going to be *very* limited in its deployment choices, and needs to find its own way of dealing with this. 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. _______________________________________________ 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