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. > 1. The 'readline()' function of 'wsgi.input' may optionally take a size hint. Already de-facto required. Leaving it out helps no-one. KEEP. > 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 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. KEEP. > 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. > 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? > 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. James _______________________________________________ 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
