@@ -38,7 +38,7 @@ To test the servers:
38
38
crossbario/autobahn-testsuite \
39
39
wstest --mode fuzzingclient --spec /config/fuzzingclient.json
40
40
41
- $ open reports/servers/index.html
41
+ $ open compliance/ reports/servers/index.html
42
42
43
43
To test the clients:
44
44
@@ -54,7 +54,7 @@ To test the clients:
54
54
$ PYTHONPATH=src python compliance/asyncio/client.py
55
55
$ PYTHONPATH=src python compliance/sync/client.py
56
56
57
- $ open reports/clients/index.html
57
+ $ open compliance/ reports/clients/index.html
58
58
59
59
Conformance notes
60
60
-----------------
@@ -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
67
67
protocol error and closes the connection at the library level before the
68
68
application gets a chance to echo the previous frame.
69
69
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