websockets/cookies/007.html doesn't match spec #5213

Activity

1. annevk

   added

   websockets

   on Mar 24, 2017
2. annevk commented on Mar 24, 2017

   

   annevk

   on Mar 24, 2017

   Member

   More actions

   Firefox and Safari TP pass this test, Chrome fails it.

   So currently for all fetches cookies are just set when the response is received. We could change that somehow maybe to synchronize them with the main thread as part of the task queued for the response (headers) coming in. We'd then make Fetch queue a task for establishing a connection as well (which matches the task of the response coming in) and HTML would use that to dispatch the open event.

   I guess I wonder what happens for normal fetches.

   @zcorpan
3. zcorpan commented on Mar 24, 2017

   

   zcorpan

   on Mar 24, 2017

   Last edited by zcorpan

   Member

   More actions

   whatwg/html@43156d2

   https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Jul/0309.html

   On Fri, 7 May 2010, Simon Pieters wrote:

   establish a WebSocket connection

   [[
   41. ...

   If the entry's name is "set-cookie" or "set-cookie2" or another cookie-related
   field name
   If the relevant specification is supported by the user agent, handle the
   cookie as defined by the appropriate specification, with the resource being
   the one with the host host, the port port, the path (and possibly query
   parameters) resource name, and the scheme http if secure is false and https if
   secure is true. [COOKIES]

   If the relevant specification is not supported by the user agent, then the
   field must be ignored.
   ]]

   At this point, the handshake can still fail. It seems bad to set cookies
   if the handshake fails. We want to process set-cookie when the handshake
   has succeeded (but before changing readyState and firing 'open').

   Fixed.
4. annevk commented on Mar 24, 2017

   

   annevk

   on Mar 24, 2017

   Member

   More actions

   Interesting point. I guess that only applies to cookies and would require abstracting cookies somehow in Fetch. That still doesn't address the overall point of synchronizing state across threads, but gets somewhat closer.
5. nox commented on Mar 24, 2017

   

   nox

   on Mar 24, 2017

   Contributor

   More actions

   Firefox and Safari TP pass this test, Chrome fails it.

   Note that Firefox and Safari both fail on the wss variant of the test.
6. annevk commented on Mar 24, 2017

   

   annevk

   on Mar 24, 2017

   Member

   More actions

   I think wss is not supported by WPT.
7. ricea commented on Nov 7, 2022

   

   ricea

   on Nov 7, 2022

   Contributor

   More actions

   In Chrome the update of document.cookie and the firing of the open event are not synchronised in any way, so there's no way for us to make the test pass without major restructuring.

   The wss version of the test fails due to Schemeful Same-Site cookies.
8. zcorpan commented on Nov 8, 2022

   

   zcorpan

   on Nov 8, 2022

   Member

   More actions

   I think the point is not necessarily that they are updated in perfect lockstep, but that

   • if the handshake can still fail, set-cookie should not be processed yet
   • if the handshake succeeds, set-cookie should be processed before the open event is fired (so that the event handler for open can reliably check the cookies).

   I'm happy to review a PR to fix the Schemeful Same-Site cookies aspect.
9. ricea commented on Nov 10, 2022

   

   ricea

   on Nov 10, 2022

   Contributor

   More actions

   • if the handshake can still fail, set-cookie should not be processed yet

   This part is easy in Chrome; cookie setting happens way after handshake validation.

   • if the handshake succeeds, set-cookie should be processed before the open event is fired (so that the event handler for open can reliably check the cookies).

   This is tricky with Chrome's architecture as we asynchronously ask any extensions if they'd like to change the response headers before we apply cookies. This happens after the WebSocket handshake is validated.