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