Bug 206652 - [GTK] imported/w3c/web-platform-tests/websockets/constructor/011.html has been failing since r252429
Summary: [GTK] imported/w3c/web-platform-tests/websockets/constructor/011.html has bee...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2020-01-23 05:10 PST by Diego Pino
Modified: 2022-01-11 23:53 PST (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Diego Pino 2020-01-23 05:10:28 PST
* imported/w3c/web-platform-tests/websockets/constructor/011.html  [ Failure ]

r252429 changed the TestExpectations of this tests, marked as Failure, to DumpJSConsoleLogInStdErr. The test wasn't passing in GTK, it went unnoticed until then.


--- /layout-test-results/imported/w3c/web-platform-tests/websockets/constructor/011-expected.txt
+++ /layout-test-results/imported/w3c/web-platform-tests/websockets/constructor/011-actual.txt
@@ -1,3 +1,3 @@

-PASS WebSockets: protocol mismatch 
+FAIL WebSockets: protocol mismatch assert_false: got open expected false got true
Comment 1 Diego Pino 2020-01-23 08:52:50 PST
After some investigation we learned this test was passing before r248099, and started to report FAIL after that. However since the expected results at that time for the test were [ PASS FAILURE ], there was no regression.

There's another test that is in a similar situation, that is:

  * imported/w3c/web-platform-tests/websockets/interfaces/WebSocket/bufferedAmount/bufferedAmount-getting.html

This test started to report a Failure after r252429, because expectations for the test changed. This test was as well passing before r248099 and started to fail afterwards (however expectations at that time were [ PASS FAILURE ].
Comment 2 Diego Pino 2022-01-11 23:10:35 PST
Test imported/w3c/web-platform-tests/websockets/interfaces/WebSocket/bufferedAmount/bufferedAmount-getting.html was fixed by https://bugs.webkit.org/show_bug.cgi?id=235098.
Comment 3 Diego Pino 2022-01-11 23:53:31 PST
I've been investigating 'imported/w3c/web-platform-tests/websockets/constructor/011.html'.

The test checks whether subprotocol matching is case-sensitive. The string used as subprotocol is "FOOBAR".

Quoting https://html.spec.whatwg.org/multipage/web-sockets.html (Section 9.3.2):

"protocols is either a string or an array of strings. If it is a string, it is equivalent to an array consisting of just that string; if it is omitted, it is equivalent to the empty array. Each string in the array is a subprotocol name. The connection will only be established if the server reports that it has selected one of these subprotocols. The subprotocol names have to match the requirements for elements that comprise the value of Sec-WebSocket-Protocol fields as defined by The WebSocket protocol."

My understanding is that a valid subprotocol must be a registered value in https://www.iana.org/assignments/websocket/websocket.xml.

The test is only failing when value "FOOBAR" is used. If, for instance, I use a subprotocol from https://www.iana.org/assignments/websocket/websocket.xml, like "soup", the test passes. If I use "SOUP", the test passes too. If I use a subprotocol not in the list (other than "FOOBAR"), like "BARFOO", the test passes too.