Subject: [hybi] Are "Sec-WebSocket-XXXXX" headers case sensitive? WS handshake is still HTTP !

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Jan 2011 00:49:29 +0100

Hi, version 76 of the draft states that WS related headers are case sensitive:

---------------------------------------------
 The leading line from the client follows the Request-Line format.
 The leading line from the server follows the Status-Line format.  The
 Request-Line and Status-Line productions are defined in the HTTP
 specification.

 After the leading line in both cases come an unordered ASCII case-
 insensitive set of fields, one per line, that each match the
 following non-normative ABNF: [RFC5234]
---------------------------------------------

Fortunatelly latest draft 04 corrects it:

---------------------------------------------
 The leading line from the client follows the Request-Line format.
 The leading line from the server follows the Status-Line format.  The
 Request-Line and Status-Line productions are defined in [RFC2616].

 After the leading line in both cases come an unordered set of
 headers.  The meaning of these headers is specified in Section 5 of
 this document.  Additional headers may also be present, such as
 cookies required to identify the user.  The format and parsing of
 headers is as defined in [RFC2616].
---------------------------------------------

By reading some versions of the draft I've realized that the author(s)
has tried to make the WS handshake something non related to HTTP (non
normative rules for header matching, 8 bytes of body without
Content-Length header and so on).
IMHO this vision is totally wrong as WS is based on a feature
*already* described in RFC 2616, in which "Upgrade" header and 101
response are already defined. So if such feature is used it must be
done by respecting core HTTP rules (i.e: headers are always case
insensitive).

Also, until version 75 of the draft, the 101 response parsing by the
client is explained as if it had nothing to do with normal HTTP
parsing ("expect CRLF after each field value" and such stuf). It's
like if WS was designed for developers without HTTP knowledge (which
makes no sense as WS will be mainly implemented in web browsers, whose
authors do know the HTTP protocol very well).

Anyhow is nice to see that all these "issues" have been "fixed" in
latest versions of the draft but, can we be sure that they won't come
back in future versions? This is, IMHO the websocket protocol MUST be
valid HTTP until the 101 response has been sent by the server. After
it the protocol has been "switched" and new rules are accepted, but
not before.

Just my opinion, thanks a lot.

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

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 28 Jan 2011 11:56:35 +1100

On 28 January 2011 10:49, Iñaki Baz Castillo <[email-masked]> wrote:
> IMHO this vision is totally wrong [...]

> back in future versions?

There was a long debate about in the WG of  "must be HTTP compliant"
vs "it just looks like HTTP".
This was eventually put to a consensus call which came down on the
side of MUST be HTTP compliant before the 101 response (or 200 if
CONNECT is used etc.).
So I hope you need not fear the return of the "it's so like HTTP that
I can't believe it's not HTTP" handshake.

cheers

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Jan 2011 01:58:19 +0100

> I can't believe it's not HTTP" handshake.

Great, thanks for the information.

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