Subject: #300: Define non-final responses

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 11:58:18 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/300>

1xx responses are non-final; i.e., the underlying model is that for each request, there are 0 to many non-final responses, and exactly one final response.

This should be made explicit at a high level; it's implied by the definition of 1xx, but never really spelled out anywhere.

(this is almost editorial; I'm assigning for -16)

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Jul 2011 06:32:01 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:
>1xx responses are non-final; i.e., the underlying model is that for each =
>request, there are 0 to many non-final responses, and exactly one final =
>response.

But with the footnote that 101 is final as far as HTTP goes, and that
it is up to the new protocol to define who sends something next.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 17:16:12 +1000

> it is up to the new protocol to define who sends something next.

Works for me.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jul 2011 14:09:11 -0700

On Jul 16, 2011, at 11:32 PM, Poul-Henning Kamp wrote:

> But with the footnote that 101 is final as far as HTTP goes,

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.

....Roy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Jul 2011 21:15:27 +0000

In message <[email-masked]>, "Roy T. Fielding" w

>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.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 17 Jul 2011 23:39:24 +0200

> What happens next is simply not part of the HTTPbis standard any

I agree with this statement. The fact that it can be mis-interpreted as
an interim response from an HTTP point of view has already caused some
trouble to get it correctly implemented in intermediaries. Without
explicit processing of 101, an intermediary will get stuck waiting for
the next response which might never come.

Regards,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jul 2011 14:39:29 -0700

> What happens next is simply not part of the HTTPbis standard any

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

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 17 Jul 2011 23:48:36 +0200

> does not define is how, not if, that final response is sent.

Roy, this is not how I read RFC2616 :

  10.1.2 101 Switching Protocols
  The server understands and is willing to comply with the client's request,
  via the Upgrade message header field (section 14.42), for a change in the
  application protocol being used on this connection. The server will switch
  protocols to those defined by the response's Upgrade header field immediately
  after the empty line which terminates the 101 response.

  The protocol SHOULD be switched only when it is advantageous to do so. For
  example, switching to a newer version of HTTP is advantageous over older
  versions, and switching to a real-time, synchronous protocol might be
  advantageous when delivering resources that use such features.

The term "immediately after the empty line which terminates the 101 response"
is pretty clear to me : HTTP ends after the 101 response, and immediately
after it, it is the next protocol. So there clearly is not any other HTTP
response after 101. It may not be how you designed it 12 years ago, but it
is how it's documented and how people have been using it. WebSocket is even
relying on this in the handshake.

Regards,
Willy

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Jul 2011 00:12:21 +0200

>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".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Jul 2011 22:18:01 +0000

In message <[email-masked]>, "Roy T. Fielding" w

>initial request after the switch is complete.  There are NO EXCEPTIONS.

We have three bits of relevant text in 14.42:

]   The server
]   MUST use the Upgrade header field within a 101 (Switching Protocols)
]   response to indicate which protocol(s) are being switched.

So the server has to send a HTTP reponse with 101 to say that it
is changing protocol, obviously, this happens before the protocol
is changed.

Next:

]   The capabilities and nature of the
]   application-layer communication after the protocol change is entirely
]   dependent upon the new protocol chosen

Notice:  "after the protocol change"

]   [...] although the first action
]   after changing the protocol MUST be a response to the initial HTTP
]   request containing the Upgrade header field.

Notice again: "after changing protocol"

The only way to read these two bits consistently, is to read it as

	"a response in the new protocol to the initial HTTP
	request which contained the Upgade header field"

The "final" reponse comes after the protocol switch and the semantics
of it is "entirely dependent upon the new protocol chosen"

There is absolutely no support in the text for the notion that
the server should send a 200 reponse between the 101 and the
switch of protocol.

Likewise, it is specifically nailed down, that the format of
(final) reponse to the request comes from the new protocol, in
whatever shape it feels like.

Therefore, when upgrading protocols, the 101 is final as far
as HTTP/1.1 is concerned.

---

From: Brian Pane <[email-masked]>
Date: Sun, 17 Jul 2011 15:26:02 -0700

Looking at section 10.1 of RFC 2616, I see two issues that could
benefit from clarification:

1. After a 101, is the server required to send a response to the
original HTTP request in the new protocol?

By my reading of Section 10.1.2, the answer is "no."  Roy's
description, though, suggests that the intended answer was "yes."  And
there's at least one strong argument in favor of requiring the server
to send a final response in the new protocol after the 101: doing so,
rather than requiring the client to retransmit the request in the new
protocol, saves a network round trip.

2. After the server sends a 101, can it send other 1xx responses on
the same connection?

Section 10.1 says "yes," but that seems like a bad idea; once the
server has committed to supporting a different protocol, requiring the
client to accept additional HTTP/1.1 response headers on that
connection would make the client implementation much more complex.

-Brian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Jul 2011 00:49:58 +0200

>the server should send a 200 reponse between the 101 and the

My impression is that the issue is whether you can have a HTTP
request that goes unanswered and then have meaningful exchanges
on the same connection. Is HTTP a "request-response" protocol, or
a "request and then either response or protocol switch" protocol?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Jul 2011 22:59:39 +0000

In message <[email-masked]>, Bjoer
>a "request and then either response or protocol switch" protocol?

The 101 _is_ your HTTP reponse, but it is not the reponse to
your request.

The reason for this little dance is to avoid an extra round-trip:

Instead of:
	> GET / HTTP/1.1
	> Upgrade: Wiz-Bang

	< HTTP/1.1 101 Protocol switch
	< Upgrade: Wiz-Bang

	> [wiz-bang GET /]
	< [wiz-bang index.html]

We can:
	> GET / HTTP/1.1
	> Upgrade: Wiz-Bang

	< HTTP/1.1 101 Protocol switch
	< Upgrade: Wiz-Bang

	< [wiz-bang OK index.html]

However, if the protocol is not for delivering web-objects it may
instead look like:

	> GET / HTTP/1.1
	> Upgrade: TN3270

	< HTTP/1.1 101 Protocol switch
	< Upgrade: TN3270

	< [TELNET option negotiation]

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 18 Jul 2011 12:03:40 +1200

On Sun, 17 Jul 2011 22:59:39 +0000, Poul-Henning Kamp wrote:
> In message
> <[email-masked]>, Bjoer
> n Hoehrmann writes:

 Or we can do this safely:

   > Content-Length: NNN
   > Connection: keep-alive

   < Connection: keep-alive
   <
   < [wiz-bang index.html]

 or we can even do this safely:

   > Content-Length: NNN
   > Connection: keep-alive

   < HTTP/1.1 400 Oops.
   > Content-Length: 0
   < Connection: keep-alive
   <

   > GET /next HTTP/1.1

 Now, tell me how that 101 is not final?

 AYJ

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jul 2011 10:53:46 +1000

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,

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jul 2011 17:55:16 -0700

> 	request which contained the Upgade header field"

Yes.

> of it is "entirely dependent upon the new protocol chosen"

No.  The request was received via HTTP.  It has HTTP semantics.  How the
new protocol acts on HTTP semantics is unknown, but that doesn't change
the fact that the recipient did understand the request and is capable
of responding to the sender of that request according to the semantics
of the received request method.

> the server should send a 200 reponse between the 101 and the

No, there wouldn't be.  The response is in the new protocol format
and we don't even know if that format has status codes.  What we
do know is that the client requested the Upgrade and presumably
knows what to expect in return, whether or not the connection is
upgraded by the recipient.

> ikewise, it is specifically nailed down, that the format of

Your logic is flawed.  A protocol is more than just bits on
the wire -- it is also a set of behavioral requirements that are
expected by a client and required of the server (and sometimes
vice versa).  It is an HTTP requirement that, after the 101 is sent,
the server MUST respond to the original request (that contained the
Upgrade header).  The HTTP semantics still govern that request even
after the connection protocol is switched, and therefore the 101 is
not final as far as HTTP/1.1 is concerned.

If an HTTP GET message is received with an Upgrade, then the initial
message sent after the 101 is a response from the server to the
client regarding the final status of that GET.  It doesn't matter
what the new protocol might be -- if it defines Upgrade as a suitable
mechanism for establishing a connection, then it must define a way
to respond to that GET request in the new protocol or it can't be
used.  The client, in turn, will expect the response and the entire
connection will likely be terminated by the client if nothing
is received.  For some methods the response is almost inherent, like
using CONNECT with "Upgrade: TLS" might result in a TLS exchange
that does establish a connection.  For GET, it will be a response as
if the semantic-equivalent of GET were received on a new connection
with that new protocol.

Since the primary design goal of Upgrade was to support HTTPng and
waka (and whatever else like them might come along), the requirement
is very specific and motivated.  This is how we can gradually deploy
a new protocol by offering to upgrade a normal connection on-the-fly
without requiring an extra round-trip.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jul 2011 18:07:43 -0700

> 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…

Yes, that is the requirement in HTTP.

> Other folks are saying that what happens after an upgrade is a complete black box, which HTTP cannot say anything about.

Perhaps they are unfamiliar with STD 3.

> 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).

No, it isn't true.  Upgrade is a hop-by-hop field and the intermediary
will only upgrade the connection if they are capable of doing so.
Part of being capable is knowing how to fulfill the request.

> 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 pro…

Other protocols that do not want GET semantics, or some other such
semantically significant method, should use something like OPTIONS
for the request and specify how to respond to it.  That is what I
told the hybi WG.

> What we need to do is find a way to communicate this so it's clear in both contexts.

The requirement already exists.  Maybe we just need to move it up.

....Roy

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 18 Jul 2011 13:19:59 +1200

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 
Upgrade.

Adrien

On 18/07/2011 12:53 p.m., Mark Nottingham wrote:
>>> In message<[email-masked]>, "Roy T. Fielding" w
>>> rites:
>>>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 beta out now - http://www.wingate.com/getlatest/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jul 2011 19:51:45 -0700

On Jul 17, 2011, at 6:19 PM, Adrien de Croy wrote:

> For an intermediary, Upgrade + 101 needs to be handled like CONNECT + 200.

No.  Look, I don't know how any of you got the impression that Upgrade
is a request to turn into a tunnel, but that simply is not the case.
It cannot be implemented that way.  Please don't try.  You are not supposed
to upgrade the connection if you don't know how to upgrade the connection.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jul 2011 19:57:19 -0700

> Roy, this is not how I read RFC2616 :

Please read the section on Upgrade.

> relying on this in the handshake.

If WebSocket relies on broken behavior, in spite of the many times that I have
posted the correct handshake, then someone should fix WebSockets.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jul 2011 20:01:58 -0700

> 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

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 18 Jul 2011 17:18:48 +1200

> is a request to turn into a tunnel, but that simply is not the case.

Not all middleware tunnels CONNECT. Some switch to a new protocol and 
process the internal CONNECT octets in accordance with that protocol 
spec. But only if they support and implement that protocol.

Given that implementing each new protocol takes time, and people are 
_already_ using Upgrade to switch to random other non-HTTP protocols. 
Telnet, SSH, WebSockets already happening. The alternative is to 
terminate with 4xx any request containing Upgrade: and a protocol not 
supported by that middleware.

You may like that, but the reality is a needless burden on support 
helpdesks when a blind end-to-end packet relay is already in the toolkit 
and will work.

> to upgrade the connection if you don't know how to upgrade the connection.

I'm not talking about implementing Upgrade. The client and origin may be 
the only places where that is possible (as is the case for WebSockets). 
Merely transiting requests which use it.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Jul 2011 07:28:44 +0200

> to upgrade the connection if you don't know how to upgrade the connection.

Roy, the example in RFC2616 says "switching to a real-time, synchronous
protocol", which clearly suggests so. Once again, it is possible that people
have been using 101 for the wrong thing, but we should admit that the wording
used in the spec makes it obviously valid.

We can't write specs by playing with words and waiting for users to get
trapped. The spec was written in a way that unambiguously pretends to
upgrade to whatever protocol and which does not suggest at all that another
final HTTP response is coming, quite the opposite instead. Now we must admit
that it's being used how it has been understood.

Concerning the use of OPTIONS vs GET to establish a tunnel with the server,
it was mentionned nowhere either, and more precisely, nowhere it is said
that 101's semantics vary depending on the method. The earliest example of
OPTIONS we can find is in RFC2817.

At least if such specific semantics exist, we must now document them, and
it is even more urgent because WebSocket is close to be released, it's not
too late to adjust some things there.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Jul 2011 07:40:00 +0200

> Please read the section on Upgrade.

OK I found the point you mention :

  "the first action after changing the protocol MUST be a response to
   the initial HTTP request containing the Upgrade header field."

So this should be repeated in the 101 section, and we should probably
suggest that depending on the upgraded protocol, either the response
might be empty, or the server might need more info from the client in
order to respond.

One example is TLS : if we want the server to respond to the client,
it is necessary that the client can send a bit of information to the
server such as the session ID or a list of supported ciphers.

> posted the correct handshake, then someone should fix WebSockets.

At that point it relies on *documented* HTTP behaviour. However there was a
discussion on using GET vs OPTIONS, and the rough consensus was that since
there was no perceivable benefit in switching to OPTIONS, it would remain
on GET unless some new element was brought in to change it. While I was more
in favor of using OPTIONS so that we can more easily get rid of the dumbest
transparent proxies, I really do not see any incompatibility with *documented*
requirements.

Willy

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 18 Jul 2011 17:46:20 +1200

Ok, I re-read the sections in RFC2616.

It's pretty clearly marked as a hop-by-hop header.

This has some serious negative implications for usefulness.

If a proxy cannot pass the upgrade header through, and get out of the 
way then any new protocol to be upgraded to needs to be supported by all 
proxies in any chain.

Compared to (what appears to be common) current understanding, this 
means the problem is not one of just getting a client and server working 
which is do-able, it also means getting your proxy vendor, or any vendor 
of any proxy used by any client to also implement the protocol.  A 
non-starter.

This makes it basically impractical, and a show stopper for any deployment.

Maybe we need to extend CONNECT to enable it to be used against an 
origin server, and deprecate Upgrade.  This at least is fairly well 
understood by intermediaries.  AFAIK this is what Websockets was doing 
originally?

---

From: Brian Pane <[email-masked]>
Date: Sun, 17 Jul 2011 22:57:10 -0700

>   the initial HTTP request containing the Upgrade header field."

I don't see anything in 2616 (or STD 3) that would require this
response in the new protocol to have a nonzero length, though,
regardless of the HTTP method in the request.

-Brian

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Jul 2011 08:01:39 +0200

> way then any new protocol to be upgraded to needs to be supported by all 

It depends, if the proxy understands the Upgrade header and what it
means, it's allowed to emit it on the other side. For instance, the
proxy might know that the header holds a list of protocols that it
can become transparent to because it's switching to a tunnel once
it sees 101+Upgrade. In my opinion, it does not necessarily have to
understand all of the header's values.

> This makes it basically impractical, and a show stopper for any deployment.

Indeed, if it is as you're saying, it will never be usable that way.

> understood by intermediaries.  AFAIK this is what Websockets was doing 

No, I introduced the suggestion of using CONNECT when I joined the WG 2
years ago when I was a bit shoked to see an HTTP-incompatible handshake
(some bytes had to be sent from the client to the server for the Upgrade
to be possible). But along the discussions, it appeared that CONNECT was
not a good idea with origin servers, because it was never meant for that
use, the destination address would not make much sense either, and it
would present a risk of misbehaviour when the request would pass through
intermediaries : since by definition CONNECT is for proxies, intermediaries
in the chain would have no way to know if the request has to be processed
as a proxy or as a gateway. So we dropped that idea.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jul 2011 16:05:42 +1000

I think we're hitting diminishing returns here, and possibly approaching the angels dancing on the pins.

If someone has a proposal for a text change that they think will represent consensus, great.

In the meantime, I don't see any pushback on the proposed resolution, as it affects p1.

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 18 Jul 2011 16:48:39 +1000

> for the request and specify how to respond to it.  That is what I

Roy,

Unfortunately your postings to the hybi list did not clearly express
your concerns with the use of Upgrade.     You have expressed them
much better here and I finally get it that you are concerned about an
outstanding semantic request.

However, I don't understand why an OPTIONS method is any better, as it
too is a semantic request for information (about the communication
options available on the request/response chain).   So even after a
101, there is a semantic response outstanding.

So at the very least, protocols like websockets need to deal with the
outstanding response.  However, as the wire protocol is entirely up to
the new protocol, surely it is an option for the protocol to use zero
bytes to "send" and implicit response to the user-agent.      Perhaps
it would be sufficient for the websockets spec to say that after a
successful upgrade, the user-agent that issued the upgrade request
should receive an implicit 204 response.

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Mon, 18 Jul 2011 08:19:35 +0000

For the original discussion for which this thread was started, I completely agree that the initial HTTP request is significant when used with an Upgrade request but once you are outside the HTTP wire-protocol a response can take any number of shapes involving N "successful" messages fulfilling the request where N can be 0, 1, or more. The notion of "successful" is in this context is of course defined by the upgraded protocol.

I would like to clarify, however, that the initial WebSockets handshake semantically is a GET request and not an OPTIONS request. It has been discussed quite a bit but there are important reasons for why GET is appropriate:

First, the request URI is used to interact with the WebSockets resource, not the server, and not "about" the resource. That is, the request URI identifies the resource with which you are initiating the WebSockets communication. 

Second, the initial interaction is a GET in the sense that you do get some representation of the resource you are communicating with. Just like for HTTP itself, the range of how such representations can be manifested is of course very broad but in addition it is not limited to a request/response interaction. At [1] there are several examples of this:

1) The stock ticker is an example where the server sends an upgrade GET request where the URI contains a query for the stocks for which ticks are requested. After that the resource simply starts sending back ticks which is very much the representation of that resource.

2) The chat example illustrates a case where the chat room is identified by the request URI and the "response" is the state of that chat room.

3) The game example provides the state of the game, etc.

Same thing goes for the other samples. In neither of these cases are there any additional "GET" request defined by the WebSockets communication -- the HTTP upgrade request indeed semantically signifies the interaction with the resource. Once you have established the WebSocket you obviously no longer are bound to a request/response interaction pattern and so can evolve into any message exchange pattern desired but then you clearly are beyond HTTP semantics.

Third, it is important that the initial handshake is safe and idempotent and entirely described by HTTP; otherwise the scenarios above would all fall apart. As OPTIONS can contain a request entity making it impossible to know what the semantics would be.

All of these in my opinion are consistent with GET and inconsistent with OPTIONS.

I hope this clarified things a bit.

Henrik

[1] http://html5labs.interoperabilitybridges.com/prototypes/websockets/websockets/info

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Greg Wilkins
> Sent: Sunday, July 17, 2011 23:49
> To: Roy T. Fielding
> Cc: Mark Nottingham; Poul-Henning Kamp; HTTP Working Group
> Subject: Re: #300: Define non-final responses
> 
> > semantically significant method, should use something like OPTIONS for
> > the request and specify how to respond to it.  That is what I told the
> > hybi WG.
> 
> Roy,
> 
> However, I don't understand why an OPTIONS method is any better, as it too is
> a semantic request for information (about the communication
> So at the very least, protocols like websockets need to deal with the outstanding
> response.  However, as the wire protocol is entirely up to the new protocol,
> surely it is an option for the protocol to use zero
> it would be sufficient for the websockets spec to say that after a successful
> upgrade, the user-agent that issued the upgrade request should receive an
> implicit 204 response.
>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Jul 2011 10:55:46 +0200

> In the meantime, I don't see any pushback on the proposed resolution, as it affects p1.

Before we rush into writing anything, we should try to think about some use
cases to ensure they can rely on a very clear understanding of the spec.
Among the things that were discussed in this thread :

  - Upgrade is mostly being used end-to-end despite being hop-by-hop, and
    contents are generally exchanged as tunnelled data between both ends
    over intermediaries which support it without specific handling of the
    upgraded protocol ;

  - In order to be usable through intermediaries, those who don't know the
    upgraded protocol are simply blind and do already work that way ; thus
    they don't care about semantics at this point as they don't participate
    to the upgraded protocol ;

  - Upgrade might be used to upgrade to next generation protocols such as
    SPDY without affecting the method's semantics ;

  - a server might need more information from the client before responding
    to an upgrade request (eg: session ID or cipher suite)

What I'm wondering is how would an HTTP-to-SPDY gateway work. Let's imagine
that we have a caching proxy which always adds an "Upgrade: SPDY/1.0" header
into all outgoing requests so that compliant servers may tentatively upgrade.

I think I get Roy's point about the GET semantics : if this caching proxy
gets a 101, it should still assume that it gets a response to the GET request
with whatever it can imply in terms of caching, origin, etc... Still, doing
so does not prevent the proxy from sending some required protocol data to the
server so that it can provide the adequate response.

It may also have implications about idempotence of the request when the
connection is unexpectedly aborted and the request retried.

With that said, I think we should wait for Roy's feedback and comments on
the subject. He certainly has precise ideas of how he expects Upgrade+101
to be used, and we should consider his ideas and better document the spec
accordingly.

Cheers,
Willy

---

From: Brian Pane <[email-masked]>
Date: Mon, 18 Jul 2011 02:43:06 -0700

> into all outgoing requests so that compliant servers may tentatively upgrade.

I think what would need to happen in this scenario is:

1. The server generates a SPDY stream ID.  The simplest correct
implementation, if I've read the latest SPDY draft correctly, is to
use a stream ID of 2.
2. The server sends an HTTP 101 response.
3. The server sends a SPDY SYN_STREAM frame to create a unidirectional stream.
4. The server sends the response headers as a SPDY HEADERS frame.
5. The server sends the response body, packaged into one or more SPDY
data frames.  The last of these frames contains a SPDY (not TCP) FIN.

This looks similar to SPDY's server-push mechanism, but it's not quite
the same thing.

If I got the mapping right, the server would be able to send the
entire response (steps 2-5) without waiting for any more HTTP or SPDY
messages from its immediate client (the caching proxy in this
example).

The caching proxy would be allowed to start sending additional SPDY
requests to the server upon receipt of the SYN_STREAM in step 3.

-Brian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 18 Jul 2011 11:38:12 -0700

> For the original discussion for which this thread was started, I completely agree that the initial HTTP request is significant when used with an Upgrade request but once you are outside the HTTP wi…

and the semantics of the request in HTTP.

> First, the request URI is used to interact with the WebSockets resource, not the server, and not "about" the resource. That is, the request URI identifies the resource with which you are initiating…

That was not the case the last time I read the spec, but it is good news.

> Same thing goes for the other samples. In neither of these cases are there any additional "GET" request defined by the WebSockets communication -- the HTTP upgrade request indeed semantically signi…

Well, no, we are still bound by the semantics of HTTP.  We are not bound
by the interaction limitations of HTTP, its specific syntax, or even
the nature of its messages.  That's what you mean above, and I agree.

> Third, it is important that the initial handshake is safe and idempotent and entirely described by HTTP; otherwise the scenarios above would all fall apart. As OPTIONS can contain a request entity…

The protocol being upgraded to can require that the OPTIONS request be
sent with an empty body merely by refusing to upgrade the connection if
that isn't so.

> All of these in my opinion are consistent with GET and inconsistent with OPTIONS.

Certainly, if the WebSockets server is using the request target to initiate a
response to that HTTP request, then the mechanism of that response doesn't matter.
What matters is that the client doesn't need to repeat its request inside the
WebSockets protocol after the connection is established.  So, if that is true
of the WebSockets handshake, then it is indeed using Upgrade correctly.

Cheers,

....Roy

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Tue, 19 Jul 2011 14:54:28 +0000

> > Same thing goes for the other samples. In neither of these cases are there any
> additional "GET" request defined by the WebSockets communication -- the HTTP
> upgrade request indeed semantically signifies the interaction with the resource.
> Once you have established the WebSocket you obviously no longer are bound
> to a request/response interaction pattern and so can evolve into any message
> exchange pattern desired but then you clearly are beyond HTTP semantics.
> 
> Well, no, we are still bound by the semantics of HTTP.  We are not bound by the
> interaction limitations of HTTP, its specific syntax, or even the nature of its
> messages.  That's what you mean above, and I agree.

Yes, I meant on subsequent interactions beyond the first one.
 
> WebSockets protocol after the connection is established.  So, if that is true of the
> WebSockets handshake, then it is indeed using Upgrade correctly.

Yup, no need to reinvent GET :)
 
Henrik