[Web-SIG] WSGI - alternative ideas

[Phillip J. Eby]

At 01:21 PM 8/14/04 -0700, Mark Nottingham wrote:
>On Aug 14, 2004, at 12:05 PM, Phillip J. Eby wrote:
>>Because CGI variables aren't ordered.  If the request input were required 
>>to be HTTP headers, this would make it impossible for CGI, FastCGI and 
>>other gateways defined in terms of CGI to serve as valid WSGI implementations.
>
>Sorry, I don't follow. HTTP headers aren't ordered, except within a 
>particular header field-name. It's trivial to map from a dictionary like 
>{"HTTP_REFERER": "http://www.example.com/", "HTTP_HOST": 
>"www.example.org"} to [("referer", "http://www.example.com/"), ("host", 
>"www.example.org")]. No information is lost, and it's easier for non-CGI 
>implementations to work with.

Hm.  How many such frameworks are there?  I'm making the implicit 
assumption that web servers that know how to create CGI variables are more 
common than frameworks that don't use CGI variables.  If that's not a valid 
assumption, then perhaps the decision should be revisited.


>One other thing -- as far as I can tell, this interface can't accommodate 
>Expect/100-Continue interactions, as specified in RFC2616 section 8.2.3. 
>I.e., to support this, the application needs to be given access to the 
>request headers before reading the request body, so that it can send a 100 
>Continue, then read the request body, then send a normal response.

Actually, this *could* work under the current spec, so long as the 
application manages the second response.  However, there are pieces that 
need to be better defined, such as what happens if the application writes 
more data than is present in the outgoing 'Content-Length' header.


>I think it would be possible to support this feature without unduly 
>burdening implementations by saying that start_response() can be called a 
>second time, IF there is an expect: 100-continue header in the request. 
>Server implementations which don't support this behaviour, or 
>automatically handle it themselves, can filter out that header.
>
>E.g., if the request environment contains the expect: 100-continue header, 
>the application can do one of three things;
>
>1) respond as normal; i.e., call start_response() and send a successful, 
>redirect, or error response (possibly blocking until the request body is 
>received)
>
>2) respond with a 417 Expectation Failed status code
>
>3) respond with a 100 Continue in the first call to start_response(), and 
>then call start_response() again to make the actual response.
>
>Thoughts?

Unfortunately, I have no experience with this aspect of HTTP/1.1.  I fear I 
shall end up having to study the RFC extensively before drawing a 
conclusion on this.  :(

It seems to me that another approach is possible, though...  couldn't the 
web server just send a 100 Continue response if there's an "expect: 
100-continue"  header in the request, and you attempt to read from the 
input stream before you've called the 'start_response' callable?  At first 
glance, this sounds like a reasonable way to handle it, that wouldn't 
require any explicit handling by the application code.  Then, WSGI could 
also require that such an "expect" header must NOT appear in the request 
passed to an application.