Re: #300: Define non-final responses

On Jul 17, 2011, at 3:12 PM, Bjoern Hoehrmann wrote:

> * Roy T. Fielding wrote:
>> I repeat:  101 is never the final response.  In order for the HTTP
>> request to be completed, the upgraded protocol MUST respond to the
>> initial request after the switch is complete.  There are NO EXCEPTIONS.
>> If the final response is not received, an HTTP error has occurred
>> even if the connection is no longer being run in HTTP.  What HTTP
>> does not define is how, not if, that final response is sent.
> 
> How would a tool like Wireshark tell whether there was a response to the
> initial request? It might be able to if the response was more than zero
> bytes long, but I am not aware of a requirement to respond with at least
> one byte. I might agree with you semantically that the "upgraded-to"
> protocol is supposed to offer a response to the request that lead to the
> upgrade, but I do not see how that translates to "bits on the wire".

The response might be zero bytes long -- it depends on the method,
resource, and new protocol.

It is easy to satisfy a request once the semantics are known.  It is
hard to guess what the bits will look like until the protocol is known,
nor is it necessary to know what the bits look like in order to define
a future extensibility mechanism like Upgrade.  What is necessary is
to define the semantics of the request so that the people who write the
future protocol can know what they are supposed to define.

....Roy

Received on Monday, 18 July 2011 03:02:22 UTC