On Fri, Nov 27, 2009 at 12:20 PM, P.J. Eby <p...@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
_______________________________________________ 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