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 [EMAIL PROTECTED] 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
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
