Autobahn|Testsuite

#1

Hi,

First of all, thanks a lot for the great test suite you guys made!

I have a few questions on test cases for Close messages.

Case 7.3.1
Case Description
Send a close frame with payload length 0 (no close code, no close reason)
Case Expectation
Clean close with normal code.

I wonder if it can be relaxed? Is there anything in the RFC 6455 that precludes the test from expecting an empty close message in return? (The test expectation becomes: Clean close with normal code or an empty close)

  1. Test cases 7.9.6-7.9.7

It looks like these codes have been finally defined and adopted by several APIs out there:

https://www.iana.org/assignments/websocket/websocket.xml#close-code-number

So I wonder if it can be relaxed to “Clean close with protocol error or with normal or echoed code or drop TCP”. So the test cases can stay compatible with the old clients.

Thanks.

And several typos if I may:

Case 7.1.5
Case Description
Send message fragment1 followed by close then fragment2
Case Expectation
Clean close with normal code.

Detail view of test case refers to fragment1 and fragment2.

Case 7.7.1
Case Description
Send close with valid close code 1000
Case Expectation
Clean close with normal or echoed code

Isn’t it the same here?

Case 7.1.6
Case Description
Send 256K message followed by close then a ping
Case Expectation
Case outcome depends on implementation defined close behavior. Message and close frame are sent back to back. If the close frame is processed before the text message write is complete (as can happen in asynchronous processing models) the close frame is processed first and the text message may not be received or may only be partially received.

Case 7.13.2
Case Description
Send close with close code 65536
Case Expectation
Actual events are undefined by the spec.

The maximum status code available 0xffff is 65535.

0 Likes

#2

One more:

Case 7.7.8
Case Description
Send close with valid close code 1010
Case Expectation
Clean close with normal or echoed code

Well, given the description from the RFC:

1010
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.

I wouldn’t say this code should be sent by the server. So, I wonder if the expectation is valid.

···

On Monday, June 27, 2016 at 12:21:52 PM UTC+1, pave...@gmail.com wrote:

Hi,

First of all, thanks a lot for the great test suite you guys made!

I have a few questions on test cases for Close messages.

Case 7.3.1
Case Description
Send a close frame with payload length 0 (no close code, no close reason)
Case Expectation
Clean close with normal code.

I wonder if it can be relaxed? Is there anything in the RFC 6455 that precludes the test from expecting an empty close message in return? (The test expectation becomes: Clean close with normal code or an empty close)

  1. Test cases 7.9.6-7.9.7

It looks like these codes have been finally defined and adopted by several APIs out there:

https://www.iana.org/assignments/websocket/websocket.xml#close-code-number

So I wonder if it can be relaxed to “Clean close with protocol error or with normal or echoed code or drop TCP”. So the test cases can stay compatible with the old clients.

Thanks.

And several typos if I may:

Case 7.1.5
Case Description
Send message fragment1 followed by close then fragment2
Case Expectation
Clean close with normal code.

Detail view of test case refers to fragment1 and fragment2.

Case 7.7.1
Case Description
Send close with valid close code 1000
Case Expectation
Clean close with normal or echoed code

Isn’t it the same here?

Case 7.1.6
Case Description
Send 256K message followed by close then a ping
Case Expectation
Case outcome depends on implementation defined close behavior. Message and close frame are sent back to back. If the close frame is processed before the text message write is complete (as can happen in asynchronous processing models) the close frame is processed first and the text message may not be received or may only be partially received.

Case 7.13.2
Case Description
Send close with close code 65536
Case Expectation
Actual events are undefined by the spec.

The maximum status code available 0xffff is 65535.

0 Likes