W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #300: Define non-final responses

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 18 Jul 2011 13:19:59 +1200
Message-ID: <4E238A3F.9050401@qbik.com>
To: Mark Nottingham <mnot@mnot.net>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>

For an intermediary, Upgrade + 101 needs to be handled like CONNECT + 
200.  the intermediary steps out of the way.

for an O-S, CONNECT makes no sense.

Maybe that's the thing, we need to be more explicit about when one 
should be used over the other.

Depending on the nature of the upgrade, the rest of the request is 
either significant or not.

Seems to me that Upgrade is very dangerous anyway.  If you have any 
HTTP/1.0 intermediary in the path (or anything that doesn't understand 
Upgrade), then using it results only in pain.  I would speculate that 
many more intermediaries support CONNECT than support Upgrade.  So even 
if the target of the Upgrade is an O-S, using it is risky.  Intercepting 
proxies make it even worse.

I've never even seen an application or request that requires or uses 


On 18/07/2011 12:53 p.m., Mark Nottingham wrote:
> Roy, if I understand correctly, you're saying that the server is still responsible for responding to the request, whatever wire protocol that it chooses to use. That is, when you say "response" you're speaking in a general, semantic way, not response-message-serialised-as-HTTP.
> Other folks are saying that what happens after an upgrade is a complete black box, which HTTP cannot say anything about.
>  From the standpoint of (for example) a HTTP/1.1 intermediary, the latter view is true (and I note that a lot of people participating in this discussion are intermediary implementers).
> However, I agree that from the user-agent and origin server's perspective, the request is still outstanding until the server satisfies it -- however it chooses to do so.
> Roy's view makes a lot of sense when you consider Upgrade as a way to transition to a protocol like SPDY, which closely mirrors HTTP's semantics. It doesn't fit as obviously with less HTTP-like protocols (e.g., WebSockets), but conceptually, the request is either fulfilled or not.
> What we need to do is find a way to communicate this so it's clear in both contexts.
> Cheers,
> On 18/07/2011, at 7:39 AM, Roy T. Fielding wrote:
>> On Jul 17, 2011, at 2:15 PM, Poul-Henning Kamp wrote:
>>> In message<7D5E6715-1377-45EC-A00E-F3FB6D392AAC@gbiv.com>, "Roy T. Fielding" w
>>> rites:
>>>> As mentioned before, that statement is false.  101 is never the final
>>>> response to the request.  Whether or not a later response is in the same
>>>> syntax of HTTP is irrelevant to the semantics being described here.
>>> Actually 101 can be the final response, it all depends on which
>>> protocol you switch to, and since that is outside the scope of HTTPbis
>>> there are no absolute answers to this.
>>> People use UPGRADE to switch to all sorts of protocols, including,
>>> to my horror, TN3270.
>>> That is why I wrote that "101 is final as far as HTTP goes."
>>> What happens next is simply not part of the HTTPbis standard any
>>> more.
>> It is part of the HTTP standard, and it is not our problem if some
>> people who implemented 101 cannot read and obey that standard.
>> 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.
>> ....Roy
> --
> Mark Nottingham   http://www.mnot.net/

Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 beta out now - http://www.wingate.com/getlatest/
Received on Monday, 18 July 2011 01:20:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC