Re: p2: Expect: 100-continue and "final" status codes

["Adrien W. de Croy" <[e-mail]>]

------ Original Message ------
From: "Mark Nottingham" <[e-mail]>
>
>On 24/04/2013, at 12:41 PM, Amos Jeffries <[e-mail]> wrote:
>>>>
>>>>  I think we can give better advice than that. If a server responds 
>>>>with a final status code instead of 100 (Continue)
>>>>
>>>>  1. The response must be the last response on the connection. The 
>>>>response should contain "Connection: close" header. After the 
>>>>response is written, the server must initiate a lingering close of 
>>>>the connection (p1#6.6).
>>>  That seems too restrictive; as long as the server reads the rest of 
>>>the request properly (discarding it), it should be able to recover 
>>>and reuse the connection.
>>
>>  The problem comes with intermediaries. How are they to know the bytes 
>>following were the original advertised payload or not? the status from 
>>server has no guarantee of arriving after the client payload starts 
>>arriving.
>>  The only way to guarantee safety on the connection is to close it or 
>>always send payload.


I'm really struggling to see what benefit can be derived by a client in 
knowing whether a server supports 100 continue or not.  So to me 
Expects: 100-continue is a complete waste of space.  I've never seen one 
so I guess implementors by and large agree.

Regardless of 100 continue being transmitted, the client has to send the 
payload if it wants to reuse the connection.  The only early-out options 
involve closing the connection.

There was quite a lot of discussion about this in the past, and my 
understanding was that 100 continue couldn't be used to negotiate 
whether or not the payload would be sent.  The outcome of this 
discussion was not satisfactory IMO, since the "answer" was for the 
client to send request bodies always chunked, and send a 0 chunk if it 
needed to abort early.

This IMO is unsatisfactory because it does not indicate that the client 
didn't send the payload, and a whole heap of intermediary agents may act 
on that as if it were complete.

So for me therefore there's still a hole in the spec around this - 
chunking doesn't have a way to indicate aborting the body.  And there's 
no way to pre-authorization transmission of a request body.

I don't see how a server can return a success status code to a message 
it didn't even receive yet.  Returning a 417 due to expectation not met 
is just extra noise and RTT, and the connection needs to be closed 
anyway or the payload sent.

So, what would we really lose if 100-continue were deprecated?  and what 
would we gain.

Some servers send it on every POST, regardless.  This has some 
significant cost.  What's the real benefit?

Adrien

>
>
>True.
>
>--
>Mark Nottingham http://www.mnot.net/
>
>
>
>