On Dec 28, 2005, at 1:14 PM, Ian Bicking wrote: >> Surely that's a bug in the server, not the spec? Indeterminate >> length uploads (with transfer-encoding chunked) are allowed by >> HTTP, after all. The CGI spec explicitly rejects such requests, >> but WSGI doesn't seem to. >> > > But while it is possible, if an application uses this then it won't > be portable, right? I think chunking has been explicitly excluded > from WSGI too, as something that should be handled/isolated in the > server. Not that I really know much about chunking, except that it > was discussed at one point.
The server handles the unchunking, but the unchunked stream it passes to the client has no content-length. The only way to indicate when the stream is done is via EOF. It doesn't seem a good idea to me for the WSGI spec to disallow chunked uploads. The reason it's disallowed in the CGI spec is that it was added to HTTP after CGI was defined. There's no similar excuse for WSGI. However, I see that in the spec, indeterminate length uploads have already been disallowed implicitly, by not requiring the server to return EOF from reads at the end of the stream: "The server is not required to read past the client's specified Content-Length, and is allowed to simulate an end-of-file condition if the application attempts to read past that point. The application SHOULD NOT attempt to read more data than is specified by the CONTENT_LENGTH variable." If the client cannot depend on an EOF at the end of the stream, it cannot read a stream without a length. I'd much rather it say something like: "The server MUST NOT read past the end of the request, and MUST simulate an end-of-file condition if the application attempts to read past that point. Attempting to read from an input stream when no data has been provided MUST result in an end-of-file result (the empty string)." but it doesn't. At least the spec does allow the server to implement read correctly. 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
