Subject: [hybi] "Establish a WebSocket Connection" does not allow for cookies

From: Anne van Kesteren <[email-masked]>
Date: Sat, 5 Sep 2015 19:25:22 +0200

After the tenth protocol draft this algorithm broke a hook the API
standard was using and those authoring the WebSocket API were never
notified.

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=27869 for details.

How do you suggest this gets fixed?

-- 
https://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 5 Sep 2015 20:09:03 +0200

> How do you suggest this gets fixed?

The subject line is misleading. 
<https://tools.ietf.org/html/rfc6455#section-4.1>, item 12 in the second 
list is:

>    12.  The request MAY include any other header fields, for example,
>         cookies [RFC6265] and/or authentication-related header fields
>         such as the |Authorization| header field [RFC2616], which are
>         processed according to documents that define them.

Best regards, Julian

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 6 Sep 2015 17:12:26 +0200

> The subject line is misleading.

It's the name of the algorithm defined in the RFC that takes a set
number of arguments of which headers and/or cookies are not an
acceptable argument.

>>         processed according to documents that define them.

This step cannot be influenced from the API. The "request" is
constructed by this algorithm and the influence the API has over it is
carefully defined.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 16 Sep 2015 17:20:31 +0900

> number of arguments of which headers and/or cookies are not an
Yes, what to do is described in the step, but the identifier of the
algorithm is gone.

> constructed by this algorithm and the influence the API has over it is

It's not expecting any argument explicitly, but given the history of the
spec, I think we should just proceed to influence this by e.g.:

Replace the second sentence of the step 9 of
https://html.spec.whatwg.org/multipage/comms.html#dom-websocket with

When processing the step 12 of the requirements for an opening handshake
from a client described in the <a href="
https://tools.ietf.org/html/rfc6455#section-4.1">"Client Requirements"
section of  the WebSocket protocol specification</a>, include a Cookie
header whose value is the cookie-string computed from the user's cookie
store and the URL url; for these purposes this is not a "non-HTTP" API.
[WSP] [COOKIES]

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Anne van Kesteren <[email-masked]>
Date: Wed, 16 Sep 2015 10:43:59 +0200

On Wed, Sep 16, 2015 at 10:20 AM, Takeshi Yoshino <[email-masked]> wrote:
> from a client described in the <a
> href="https://tools.ietf.org/html/rfc6455#section-4.1">"Client Requirements"

By "given the history of the spec" do you mean that we should not
expect a clean fix to appear anytime soon on the IETF side and instead
just use this monkey patch? I guess that's fine, it just seems far
from ideal, especially given that it was done properly until draft
eleven.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 16 Sep 2015 17:48:16 +0900

> just use this monkey patch? I guess that's fine, it just seems far

I meant that we can see this as expecting an argument though it's not
explicitly expecting. In response to your comment "we cannot influence this
sentence".

> from ideal, especially given that it was done properly until draft
Ideally. Julian, do you think we can revive the identifier with a little
work? What's your thoughts after Anne's recent reply.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 17 Sep 2015 12:54:47 +0000

Not completely sure, but maybe we can worn on an Errata to clarify this

br
Salvatore

-----Original Message-----
From: hybi [mailto:[email-masked]] On Behalf Of Anne van Kesteren
Sent: den 6 september 2015 17:12
To: Julian Reschke
Cc: [email-masked]
Subject: Re: [hybi] "Establish a WebSocket Connection" does not allow for cookies

> The subject line is misleading.

It's the name of the algorithm defined in the RFC that takes a set number of arguments of which headers and/or cookies are not an acceptable argument.

> <https://tools.ietf.org/html/rfc6455#section-4.1>, item 12 in the 
> second list is:
>

This step cannot be influenced from the API. The "request" is constructed by this algorithm and the influence the API has over it is carefully defined.