[Web-SIG] Request for Comments on upcoming WSGI Changes

[Robert Brewer]

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
fumanchu at aminus.org

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot at 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 at 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/