Re: #467: Expect: 100-continue and "final" status codes

On 05/17/2013 05:28 AM, Ken Murchison wrote:
> On 05/16/2013 10:47 PM, Mark Nottingham wrote:
>> Note that this mechanism does not change the request message parsing
>> algorithm; in particular, whether or not a final response status code
>> is sent, the client still needs to send a complete request message. As
>> such, if a final status code is received, clients will often choose to
>> close the connection, rather than send a complete request (e.g., if it
>> is length-delimited). 

"the client needs to send a complete message" is perhaps too strong.
"the client needs to send a complete message if the client wants to keep
the connection open and the server response allows for a persistent
connection" may be more appropriate.


> This is an important point that I completely missed from any reading of
> 2616 and the current httpbis.  I assumed that if the server responded
> with a final status code before sending 100-continue, that the client
> would not send the body.

Keep in mind that by the time the origin server sends a response (any
status code), the client may have already started sending the request.
And intermediaries may see a different order of those two events.


> If I read your proposed text properly, the only way for a client to
> avoid sending the body of a failed conditional request while maintaining
> a persistent connection is to send the request using e/c and te/chunked,
> and just send a zero-length chunk after receiving the final response
> code.  Correct?

I do not think sending last-chunk prematurely is a good idea because
there will be no way for the intermediaries (and the origin server) to
distinguish an incomplete request from a complete one. The origin server
MUST NOT perform the requested method after sending 417, but
intermediaries may not know that the server has sent the final status
code and, hence, may "perform" the requested method. Misrepresenting the
end of the request body may have nasty side effects in real world.

Terminating the connection is probably the only safe course of action
for the client that does not want to send the whole body.


Cheers,

Alex.

Received on Monday, 20 May 2013 16:44:55 UTC