[Web-SIG] Reading of input after headers sent and 100-continue.

[Graham Dumpleton]

For those on the Python web sig who might be thinking they missed part
of the conversation, you have. This is the second half of a
conversation started on Apache modules-dev list about Apache
100-continue processing. If interested, you can see the first half of
the conversation at:

  http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/200801.mbox/browser

Graham

On 31/01/2008, Brian Smith <brian at briansmith.org> wrote:
> Graham Dumpleton wrote:
> > Effectively, if a 200 response came back, it seems to suggest
> > that the client still should send the request body, just that
> > it 'SHOULD NOT wait for an indefinite period'. It doesn't say
> > explicitly for the client that it shouldn't still send the
> > request body if another response code comes back.
>
> This behavior is to support servers that don't understand the Expect:
> header.
>
> Basically, if the server responds with a 100, the client must send the
> request body. If the server responds with a 4xx or 5xx, the client must
> not send the request body. If the server responds with a 2xx or a 3xx,
> then the client should must send (the rest of) the request body, on the
> assumption that the server doesn't understand "Expect:". To be
> completely compliant, a server should always respond with a 100 in front
> of a 2xx or 3xx, I guess. Thanks for clarifying that for me. I guess the
> rules make sense after all.
>
> > So technically, if the client has to still send the request
> > content, something could still read it. It would not be ideal
> > that there is a delay depending on what the client does, but
> > would still be possible from what I read of this section.
>
> You are right. To avoid confusion, you should probably force mod_wsgi to
> send a 100-continue in front of any 2xx or 3xx response.
>
> > It MUST NOT perform the requested method if it returns a final status
> code.
>
> The implication is that the only time it will avoid sending a 100 is
> when it is sending a 4xx, and it should never perform the requested
> method if it already said the method failed. The only excuse for not
> sending a 100 is that you don't know about "Expect: 100-continue". But,
> that can't be true if you are reading this part of the spec!
>
> >        """If it responds with a final status
> >         code, it MAY close the transport connection or it MAY continue
> >         to read and discard the rest of the request."""
>
> If the client receives a 2xx or 3xx without a 100 first, it has to send
> the request body (well, depending on which 3xx it is, that is not true).
> But, the server doesn't have to read it! But, again, the assumption is
> that the server will only send a response without a 100 if it is a 4xx
> or 5xx.
>
> > It seems by what you are saying that if 100-continue is
> > present this wouldn't be allowed, and that to ensure correct
> > behaviour the handler would have to read at least some of the
> > request body before sending back the response headers.
>
> You are right, I was wrong.
>
> > > Since ap_http_filter is an input filter only, it should be
> > enough to
> > > just avoid reading from the input brigade. (AFAICT, anyway.)
> >
> > In other words block the handler from reading, potentially
> > raise an error in the process. Except to be fair and
> > consistent, you would have to apply the same rule even if
> > 100-continue isn't present. Whether that would break some
> > existing code in doing that is the concern I have, even if it
> > is some simple test program that just echos back the request
> > body as the response body.
>
> Technically, even if the server returns a 4xx, it can still read the
> request body, but it might not get anything or it might only get part of
> it. I guess, the change to the WSGI spec that is needed is to say that
> the gateway must not send the "100 continue" if it has already sent some
> headers, and that it should send a "100 continue" before any 2xx or 3xx
> code, which is basically what James Knight suggested (sorry James). The
> gateway must indicate EOF if only a partial request body was received. I
> don't think the gateway should be required to provide any of the partial
> request content on a 4xx, though.
>
> - Brian
>
>