[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