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

[P.J. Eby]

At 12:34 PM 11/27/2009 -0500, James Y Knight wrote:
>On Nov 27, 2009, at 10:20 AM, P.J. Eby wrote:
> > Second, I do not think that the "additional 
> guarantees/requirements" can be safely added to a 1.x version, as 
> they make it impossible for an app to tell whether it's *really* 
> running under 1.1 or under a broken piece of middleware that's 
> passing through wsgi.version but not actually providing 1.1-level 
> guarantees.  I would therefore suggest that these additional 
> guarantees and requirements be deferred to WSGI 2.0.
>
>Okay, let's look at these additional requirements in more detail. I 
>see 4 that should be kept, 1 that can be dispensed with, and 1 I'm 
>not sure about.

I agree with 2 of your keeps, and remain -0.5 to -1 on the 
others.  See below...


> > 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.


> > 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.


>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.


> > 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.


> > 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).