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).
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com