I've never proposed that WSGI make choices for people. I'm simply saying that a configurable server, with a sane, perfectly-reversible default, is the simplest thing that could possibly work.
Robert Brewer fuman...@aminus.org > -----Original Message----- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Monday, September 21, 2009 6:28 PM > To: P.J. Eby > Cc: Robert Brewer; René Dudfield; Web SIG > Subject: Re: [Web-SIG] Request for Comments on upcoming WSGI Changes > > +1. There is no one answer for these issues (e.g., URI->IRI conversion > can lose information), so low-level infrastructure like WSGI shouldn't > be making choices for people. > > > On 22/09/2009, at 5:31 AM, P.J. Eby wrote: > > > At 11:23 AM 9/21/2009 -0700, Robert Brewer wrote: > >> I still don't see why the environ should have multiple versions of > >> anything. It's not as if the HTTP request gives us multiple Request- > >> URI's. There's a single processing step that has to happen > >> somewhere: decoding the bytes of the Request-URI to unicode. For > >> the vast majority of apps, it should only happen once. Twice is > >> acceptable to me for some apps. As I pointed out in the linked > >> email, doing that as soon as possible (i.e. in the WSGI origin > >> server) allows URI's to be compared as character strings more > >> easily. If you deploy a piece of middleware that transcodes (based > >> on more information than servers want to deal with), it had better > >> be nearly first in the stack so routing works reliably. > > > > The problem with this whole approach is that it's not composable. > > You can't stick in an application under a router that uses a > > different method for grokking its subtree of the URI space, unless > > it knows what's been done to the URI and can un-do it. > > > > Maybe I'm missing something here, but the only way I see to preserve > > composability here is to use latin-1 or bytes. > > > > The fundamental problem is that, like it or not, HTTP headers are > > actually byte strings. The *only* reason we ever supported unicode > > in WSGI was to handle platforms where there's no such thing as a non- > > unicode string, and there we made it explicit that it's just a way > > of manipulating *bytes*, not unicode. > > > > ISTM that very few (if any) of the proposals floating around for > > modifying WSGI are taking this concept into account. Most of them > > sound to me like people saying, "yeah, but this particular hack will > > work for *my* apps... so everybody else must be doing something > > stupid." > > > > But WSGI was built on the principle of *equally inconveniencing > > everyone*, specifically to avoid an impossible attempt at consensus > > between incompatible ways of doing things. (E.g., nine million > > request/response APIs.) > > > > So, if the only problem we're going to cause by using bytes > > everywhere is to make everyone need to change their routing code on > > Python 3, I vote +1000. ;-) > > > > _______________________________________________ > > 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/mnot%40mnot.net > > > -- > Mark Nottingham http://www.mnot.net/ _______________________________________________ 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
