WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
206652
[GTK] imported/w3c/web-platform-tests/websockets/constructor/011.html has been failing since
r252429
https://bugs.webkit.org/show_bug.cgi?id=206652
Summary
[GTK] imported/w3c/web-platform-tests/websockets/constructor/011.html has bee...
Diego Pino
Reported
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. Diff: --- /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
Attachments
Add attachment
proposed patch, testcase, etc.
Diego Pino
Comment 1
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 ].
Diego Pino
Comment 2
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
.
Diego Pino
Comment 3
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug