Subject: [hybi] -05: Overly restrictive with "Connection"

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Fri, 11 Feb 2011 12:03:41 -0500

In client requirements (5.1), under handshake requirement #6: 
"The request MUST contain a "Connection" header whose value is equal to
"Upgrade"."

I believe that should be changed to "whose value contains the Upgrade
token" instead of the "equal" language. As currently written it
prohibits the client from concurrently using the Connection header for
other valid HTTP/1.1 purposes too, and we want to make this HTTP/1.1
compatible.

Similarly:

 "If the response lacks a Connection header or the Connection header
contains a value that is not an ASCII case-insensitive match for the
value "Upgrade", the client MUST fail the WebSocket connection." 

Again, we require an upgrade token but its ok to have other values in
there too.. in order to be http compatible we must loosen this receive
condition, and we ought to loosen the send one too.

-- 
http://www.getfirefox.com/

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 22 Feb 2011 09:41:27 +0200

> other valid HTTP/1.1 purposes too, and we want to make this HTTP/1.1
Hi Pat,

I agree we should be HTTP/1.1 compatible,
however I don't see what other "valid" HTTP/1.1 purpose would be in this 
context.
do you have any scenario in mind?

anyway what about changing from

OLD

    6.   The request MUST contain a "Connection" header whose value is
         equal to "Upgrade".

NEW

    6.   The request MUST contain a "Connection" header whose value
         SHOULD contain the "Upgrade" token.

in this way we are compatible to HTTP/1.1, we mandate the Upgrade toke
unless there is a valid reason for a different toke

> there too..
can you explain how it is OK have other values?
> in order to be http compatible we must loosen this receive
cheers
/Sa

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Tue, 22 Feb 2011 10:07:18 -0500

> do you have any scenario in mind?

one possibility for the request header:

Connection: Upgrade, keep-alive

(yes, k-a is redundant with http/1.1 but if recvd by a non 1.1 aware
server this allows recycling of the connection after the http error).. 

> unless there is a valid reason for a different toke

I was thinking

    6.   The request MUST contain a "Connection" header whose value
          MUST include the "Upgrade" token.

> can you explain how it is OK have other values?

X-Defined-In-2012: Bar
Connection: Upgrade, X-Defined-In-2012

That's just how connection is defined - it is a list of other header
values that need to be stripped hop to hop. There is nothing gained by
breaking and saying it must equal one particular token; we can mandate
that it includes a particular token instead. Does that make sense?

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 22 Feb 2011 16:26:18 +0100

Hi Pat,

> On Tue, 2011-02-22 at 09:41 +0200, Salvatore Loreto wrote:
(...)
> that it includes a particular token instead. Does that make sense?

I too agree that this is very important, especially when we don't yet know
what will be done for pipelining nor for the proxy-connection headers. It's
very possible that these issues will finally lead to additional tokens in
the Connection header.

Regards,
Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 22 Feb 2011 17:32:39 +0200

>            MUST include the "Upgrade" token.

ahh... now I see!!!
sorry I didn't get  you were talking of the possibility to have 
"additional" tokens

> that it includes a particular token instead. Does that make sense?

it make a lot of sense.
thanks a lot for the clarification

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 22 Feb 2011 20:14:03 +0100

> that it includes a particular token instead. Does that make sense?

I strongly agree. In some fragments the WebSocket draft still seems to
be written with the aim of describring a "new" protocol rather than a
extension to HTTP, but in fact WebSocket uses "Connection: upgrade"
and 101 response which are defined by RFC 2616.

Please, focus the WebSocket handshake as an extension to HTTP rather
than as a new protocol. An implementor of WebSocket must know HTTP
(IMHO).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 22 Feb 2011 20:29:25 +0100

On Tue, Feb 22, 2011 at 08:14:03PM +0100, Iñaki Baz Castillo wrote:
> than as a new protocol.

I may be wrong, but I'm sure that both Ian as the editor and the Chairs
would appreciate that such requests come with proposed changes instead
of remaining just requests. Touching the draft seems to be a tough work
and it could probably be much less with more contributions.

Regards,
Willy