On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote:
> The WebDAV spec, on the other hand, says
> (http://www.webdav.org/specs/rfc2518.html#STATUS_102):
>
> The 102 (Processing) status code is an interim response used to inform the
> client that the server has accepted the complete request, but has not yet
> completed it. This status code SHOULD only be sent when the server has a
> reasonable expectation that the request will take significant time to
> complete. As guidance, if a method is taking longer than 20 seconds (a
> reasonable, but arbitrary value) to process the serverSHOULD return a 102
> (Processing) response. The server MUST send a final response after the
> request has been completed.
>
> Again, I don't care how this is done as long as it's possible.
This pretty much has to be generated by the server implementation. One thing
that could be done in WSGI is a callback function inserted into the environ to
suggest to the server that it generate a certain 1xx response. That is,
something like:
if 'wsgi.intermediate_response' in environ:
environ['wsgi.intermediate_response'](102, {'Random-Header': 'Whatever'})
If a server implements this, it should probably ignore any requests from the
app to send a 100 or 101 response. The server should be free to ignore the
request, or not implement it. Given that the only actual use case (WebDAV) is
rather rare and marks it as a SHOULD, I don't see any real practical issues
with it being optional.
The other thing that could be done is simply have a server-side configuration
to allow sending 102 after *any* request takes > 20 seconds to process. That
wouldn't require any changes to WSGI.
I'd note that HTTP/1.1 clients are *required* to be able to handle any number
of 1xx responses followed by a final response, so it's supposed to be perfectly
safe for a server to always send a 102 as a response to any request, no matter
what the app is, or what client user-agent is (so long as it advertised
HTTP/1.1), or even whether the resource has anything to do with WebDAV. Of
course, I'm willing to bet that's patently false back here in the Real World --
no doubt plenty of "HTTP/1.1" clients incorrectly barf on 1xx responses.
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
