Remove case 7.7.8 (close code 1010 may not be used by server)

[JoakimCh]

Case description: Send close with valid close code 1010

The problem is that code 1010 may NOT be used by the server.

From RFC6455:

1010 indicates that an endpoint (client) is terminating the
connection because it has expected the server to negotiate one or
more extension, but the server didn't return them in the response
message of the WebSocket handshake.  The list of extensions that
are needed SHOULD appear in the /reason/ part of the Close frame.
Note that this status code is not used by the server, because it
can fail the WebSocket handshake instead.

[oberstet]

The spec text indeed seems pretty clear (not sure, was that added late in a revision? anyways): a test for this close code should only be run when testing clients, not servers.

[JoakimCh]

a test for this close code should only be run when testing clients, not servers.

I'm sorry but this statement doesn't make any sense to me since I was testing a client implementation when getting this code from the Autobahn test server.

The code COULD be tested against the client, but then as an INVALID code from the server, meaning the test must change.

But a second test for clients could be the actually described situation in the quote from RFC6455. Also servers could be testet to accept the code in such situations. If these tests are feasible to do I don't know though.

[oberstet]

ok, so since Autobahn supports the per-message deflate compession WebSocket extension, what could be added is testing a client

• testee client requesting per-message deflate
• fuzzing server not replying with (any) per-message deflate
• testee client closes with 1010 <= good case tested for

---

realistically, I won't have time to add such stuff .. I'd rather simply remove 1010 from the list here

autobahn-testsuite/autobahntestsuite/autobahntestsuite/case/case7_7_X.py

Line 22 in 55339e7

tests = [1000,1001,1002,1003,1007,1008,1009,1010,1011,3000,3999,4000,4999]

in the end, just testing for close 1010 without being in the context of extension negotiation is bogus anyways ...

[JoakimCh]

Sounds good to me! Such tests can be added at a later time.