[Web-SIG] HTTP 1.1 Expect/Continue handling

[Brian Smith]

Graham Dumpleton wrote:
> On 29/01/2008, James Y Knight <foom at fuhm.net> wrote:
> a) One is to clarify this as a requirement upon the WSGI gateway.
> > Something like the following:
> > "If the client requests Expect: 100-continue, and the application 
> > yields data before reading from the input, and the response 
> > code is a success (2xx) code, then the gateway MUST send a
> > 100 continue response, before writing any other response headers
> > in order to comply with RFC 2616 §8.2.3 and to allow the WSGI
> > application to read from the input stream later on in request
> > processing".

This requirement is goes too far. I think the part of the specification
that says the server most not perform the requested operation is
over-reaching. It fails to consider the case where the server can
successfully perform the operation without reading the request body. For
example, consider a TOUCH method that updates the ETag and Last-Modified
date of a resource. Or, a DELETE (a DELETE request shouldn't have a
request body, but should the server really be required to check for one
and refuse to delete the resource if it finds one?).

The WSGI gateway MAY send a 100 continue response in this situation, but
it shouldn't be required to. If the application wants the stricter
semantics then it should be coded to handle it.

> > This should handle most real-world cases. Now, only sending 
> > 100 when the response code is 2xx may be potentially a bit
> > fragile, and won't help e.g. your dummy app above.
> > (maybe some real app really did want the input data even
> > for an error response too?). But, on the other hand, you
> > really *don't* want to force the transmission of a 100 
> > continue when the server is sending e.g. a "400 Bad 
> > Request" response and likely won't ever read input data.

Exactly, if you always send 100 continue then you defeat the purpose of
it entirely. I would like to see the specification revised so that it is
obvious that my example program is invalid when a "Expect: 100 continue"
response header is present.

> > b) Alternatively, the WSGI gateway could raise an exception 
> > when you attempt to respond with a success code without having
> > read the input.

For the same reasons I mentioned above, this is too strict. 

> > c) Another option is to clarify this as a requirement for a WSGI
> > application: "An application must not read from wsgi.input after 
> > yielding its first non-empty string unless it has already read from 
> > wsgi.input before having yielded its first non-empty string.

This is the requirement that I want to see. But, I prefer to have it
qualified with "when environ['HTTP_EXPECT'] contains the '100-continue'
token".

> > (environ["wsgi.input"].read(0) may be used to indicate the 
> > desire to read the input in the future and satisfy this
> > requirement, without actually reading any data.)"

Nice in theory, but if the specification is going to change to support
this, I would rather see the specification change to allow the
application to generate its own "100 continue" response.

> A clarification in the specification may be required to the 
> extent of saying that where a zero length read is done, that 
> no WSGI middleware which wraps wsgi.input, nor even the WSGI 
> adapter itself may optimise it away. In other words a zero 
> length read must always be passed through unless specifically 
> not appropriate for what the WSGI middleware is doing.
>
> This would be required to ensure that zero length read always 
> propagates down to the web server layer itself such that it 
> may trigger the 100-continue.

The statement "An application must not read from wsgi.input after..."
would already apply to middleware, because middleware are applications.
If the middleware causes no response data to be read, it should not be
required to cause a "100 continue" to be sent.

- Brian