[Web-SIG] WSGI - alternative ideas

[Mark Nottingham]

On Aug 14, 2004, at 12:05 PM, Phillip J. Eby wrote:

> Well, the only one that doesn't have an explicit name is the 'write' 
> callable, and I can fix that by calling it "the 'write' callable".  
> Some editing should ensure that all callables are referred to with 
> some kind of name nearby.

Great. Maybe something more descriptive, like writeResponseBody?

>> - could you talk a bit about the choice of using an environment 
>> dictionary for requests? In particular, I understand that CGI-style 
>> environment variables makes things easy for CGI implementations, 
>> potentially at the expense of others; why not do a list of tuples -- 
>> in the style that you describe for response headers?
>
> 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.

This isn't to say that the entire environment should be in this style; 
I'm just concerned about the HTTP headers.


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.

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?

Keep up the good work!

--
Mark Nottingham     http://www.mnot.net/