[Web-SIG] PEP 444 Goals

[Graham Dumpleton]

2011/1/7 James Y Knight <foom at fuhm.net>:
>
> 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.

FWIW, Apache provides ap_send_interim_response() to allow interim status.

This is used by mod_proxy, but no where else in Apache core code. So,
you would be fine if proxying to a pure Python HTTP/WSGI server which
could generate interim responses, but would be out of luck with
FASTCGI, SCGI, AJP, CGI and any modules which do custom proxying using
own protocol such as uWSGI or mod_wsgi daemon mode.

In all the latter, the wire protocols for proxy connection would
themselves need to be modified as well as module implementation, which
isn't going to happen for any of those which are generic protocols.

Graham