[Web-SIG] Move to bless Graham's WSGI 1.1 as official spec

[Ian Bicking]

On Fri, Nov 27, 2009 at 12:20 PM, P.J. Eby <pje at telecommunity.com> wrote:

>
>> > 1. The 'readline()' function of 'wsgi.input' may optionally take a size
>> hint.
>>
>> Already de-facto required. Leaving it out helps no-one. KEEP.
>>
>
> Fair enough, since it's a MAY.  On the other hand, because it's a MAY, it
> actually *helps* no-one, from a spec compatibility POV.  (That is, you have
> to test whether it's available, so it's no different than it not being in
> the spec to begin with.)
>
> So, putting it in doesn't *hurt*, but neither does it *help*...  so I lean
> towards leaving it to 2.x, where it can actually help.


I think it was meant to be a must.  The *caller* MAY pass in a size hint,
the implementor MUST implement this optional argument.  This is the de-facto
requirement.


>  > 2. The 'wsgi.input' must provide an empty string as end of input stream
>> marker.
>>
>> I don't think this will be a problem. What would WSGI middleware do to
>> break this requirement?
>>
>
> It could be reading the original input stream, and replacing it with
> another one.  Not very common I would guess, but it's still possible for a
> piece of perfectly valid 1.0 middleware to fail this requirement for 1.1,
> leading to the condition where you really can't tell if you're running valid
> 1.1 or not.


Middleware sometimes does this, but any time it does this it always replaces
the input stream with something truly file-like, e.g., StringIO or a temp
file.  Nothing but servers really hands sockets around, and sockets are the
only objects I'm aware of that don't act quite like a file.


 It was only put in in the first place so that CGI adapters could pass
>> through their input stream (which may not ever provide an EOF) without
>> having to wrap it. I agree that was a mistake, and should be corrected.
>>
>
> I agree...  but only in 2.x.
>
>
>
>  > 3. The size argument to 'read()' function of 'wsgi.input' would be
>> optional and if not supplied the function would return all available request
>> content. Thus would make 'wsgi.input' more file like as the WSGI
>> specification suggests it is, but isn't really per original definition.
>>
>> This one could be a problem with middleware, and that feature shouldn't
>> ever be used, in any case: reading into memory an arbitrary amount of data
>> from a client is not a good thing to encourage. OMIT.
>>
>
> Agreed -- even in 2.x it's questionable if not harmful.


Well, we need a way to handle content of unknown length, but if the file
terminates with '' then this isn't that important.

 > 4. The 'wsgi.file_wrapper' supplied by the WSGI adapter must honour the
>> Content-Length response header and must only return from the file that
>> amount of content. This would guarantee that using wsgi.file_wrapper to
>> return part of a file for byte range requests would work.
>>
>> Given item #6, I suppose this is actually just a matter of efficiency, in
>> case the file wrapper is sent to a middleware rather than directly to the
>> wsgi gateway? If it goes directly to the gateway, that can of course stop
>> reading by itself. ?undecided?
>>
>
> I don't really see how this one helps anything in 1.x, and so lean towards
> leaving it out.


I don't really understand this either, unless it was handling range
responses as well.  Content-Length alone isn't very interesting in this
case.

 > 5. Any WSGI application or middleware should not return more data than
>> specified by the Content-Length response header if defined.
>>
>> As long as this is meant as "SHOULD", that's fine. It's not actually a
>> requirement, but rather a suggestion of best practices. KEEP.
>>
>> > 6. The WSGI adapter must not pass on to the server any data above what
>> the Content-Length response header defines if supplied.
>>
>> This is already required by HTTP. If the WSGI gateway doesn't make this
>> happen somehow, it's generating invalid HTTP and that's a bug. Okay to
>> clarify in the spec to ensure people don't miss the requirement when
>> implementing. KEEP.
>>
>
> Good points - I agree with these two, and they can be considered 1.0
> clarifications as well.  After the first four (which I see no reason to
> include) I was probably a little over-inclined to throw these two out
> (especially since I was reading the "should" above as a "must", per your
> proposal).


In this context, maybe 4 is just an extension of these?  Put 4 after 6 and
maybe it'll seem more obvious...?

-- 
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/20091127/c323418e/attachment-0001.htm>