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

Ian Bicking ianb at colorstudy.com
Tue Sep 22 10:26:46 CEST 2009


On Tue, Sep 22, 2009 at 3:16 AM, Armin Ronacher <armin.ronacher at active-4.com
> wrote:

> Hi,
>
> Ian Bicking schrieb:
> > Request headers, which you didn't split out... those I'm not sure.  I'd
> > *like* them to be native.  But damn, I'm just not sure quite how.
> > surrogateescape?  Latin1?  Latin1 as a kind of poor man's surrogateescape
> > isn't so bad.  And the headers *should* be ASCII for sane requests, so
> it's
> > not a horrible compromise.
> Except for cookie headers.  Thanks to advertising and all the other
> system putting headers on your page you can't even properly control that
> one.
>

Yes, but it'd be relatively easy to handle this, especially since the raw
header isn't very useful.  So you just do
environ['HTTP_COOKIE'].encode('latin1').decode('utf8', 'replace') before
parsing.

Another thing to consider: in Python 3.1, the HTTP server internally
> decodes to latin1 and there is no simple way to change that, unless you
> replace the implementation.
>
> > Ugh.  wsgi.input could remain.  I think at least it should become a
> > file-like interface (i.e., giving an empty string when the content is
> > exausted) and I might even ask that it implement .tell() (.seek() would
> be
> > nice of course, but optional).  If there was some other idea, I think
> > there's room for improvement on wsgi.input and the file interface.
> -1 on seek and tell.  This could be impossible to implement and what we
> really want to do is to not have the data in memory but on disk or
> whereever you put big-ass uploads.  Also it will be hard to test for an
> avaiable seek or not, because even if it's a noop, the method could be
> there.
>

Tell doesn't have particular overhead except to keep track of how many bytes
have been read.  That would allow libraries to at least detect contention
for wsgi.input.  I wish seek were detectable, though I agree it shouldn't be
required at all.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20090922/a30e2c18/attachment-0001.htm>


More information about the Web-SIG mailing list