@@ -38,7 +38,7 @@ To test the servers:
3838 crossbario/autobahn-testsuite \
3939 wstest --mode fuzzingclient --spec /config/fuzzingclient.json
4040
41- $ open reports/servers/index.html
41+ $ open compliance/ reports/servers/index.html
4242
4343 To test the clients:
4444
@@ -54,7 +54,7 @@ To test the clients:
5454 $ PYTHONPATH=src python compliance/asyncio/client.py
5555 $ PYTHONPATH=src python compliance/sync/client.py
5656
57- $ open reports/clients/index.html
57+ $ open compliance/ reports/clients/index.html
5858
5959 Conformance notes
6060-----------------
@@ -67,6 +67,13 @@ In 3.2, 3.3, 4.1.3, 4.1.4, 4.2.3, 4.2.4, and 5.15 websockets notices the
6767protocol error and closes the connection at the library level before the
6868application gets a chance to echo the previous frame.
6969
70- In 6.4.3 and 6.4.4, even though it uses an incremental decoder, websockets
71- doesn't notice the invalid utf-8 fast enough to get a "Strict" pass. These tests
72- are more strict than the RFC.
70+ In 6.4.1, 6.4.2, 6.4.3, and 6.4.4, even though it uses an incremental decoder,
71+ websockets doesn't notice the invalid utf-8 fast enough to get a "Strict" pass.
72+ These tests are more strict than the RFC.
73+
74+ Test case 7.1.5 fails because websockets treats closing the connection in the
75+ middle of a fragmented message as a protocol error. As a consequence, it sends
76+ a close frame with code 1002. The test suite expects a close frame with code
77+ 1000, echoing the close code that it sent. This isn't required. RFC 6455 states
78+ that "the endpoint typically echos the status code it received", which leaves
79+ the possibility to send a close frame with a different status code.
0 commit comments