Bug 57139 – Websocket cookies should be locked in when creating websocket

• Component: WebCore JavaScript
• Status: RESOLVED WONTFIX

[Joe Mason]

Conceptually a websocket is opened when the WebSocket object is created in Javascript.  However, behind the scenes the handshake data is not actually sent until the socket has been set up, asynchronously.  So if a document creates a websocket and then immediately updates the cookie, the cookie that is sent is the one that is current at the point the handshake is sent.  This is a race condition.  The cookie should be saved when the WebSocket constructor is executed, and the saved cookie sent with the handshake.

(I noticed this when running the cookie-001 test from the Opera test suite: http://testsuites.opera.com/websockets/)

[Joe Mason]

Created attachment 87008 [details]
patch

[Alexey Proskuryakov]

Note that the cookie storage can be changed by other applications concurrently, so a race condition in JS code that relies on cookies being immutable is pretty much unavoidable.

[Joe Mason]

This patch cuts down on it a lot, though.

[Antonio Gomes]

Comment on attachment 87008 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=87008&action=review

> Source/WebCore/websockets/WebSocketHandshake.cpp:177
> +    // read the document cookie at creation, in case it is updated before the handshake is sent

Capital letter in the beginning and period in the end, please.

[Alexey Proskuryakov]

I still think that this is WONTFIX, but I could be convinced by specific examples of how the current code causes practical trouble.

[Eric Seidel (no email)]

Closing per ap's comment.