Ambiguous response / case 7.3.1: Send a close frame with payload length 0 (no close code, no close reason)

#1

Just a question about autobahn server testcase 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.

Should the response status also contain no close code, no close reason?

Or is the status code 1000 (normal) the way the spec wants?

Reading the spec at

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13#section-5.5.1

" If there is a body, the first two

bytes of the body MUST be a 2-byte unsigned integer (in network byte

order) representing a status code with value /code/ defined in

Section 7.4. "

That tells me that receiving a frame with no status code is acceptable.

Fair enough.

And then section

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13#section-7.1.5

says …

" If this Close control frame contains no status code, _The WebSocket

Connection Close Code_ is considered to be 1005. "

So internally in our server impl we take the lack of status code in the close frame to mean 1005 internally (no status code specified), treating the incoming frame as having no status code [1], then we respond with status code 1000 and no reason indicating a normal close.

However a point was raised that if the close frame has no status or message then the response should also contain no status and message.

Is this the behavior?

Or is responding with status code 1000 and no message the appropriate way?

[1] This is treated differently than if we receive a code 1005 from the endpoint as per autobahn server testcase 7.9.4

  • Joakim
0 Likes

#2

My view:

Upon receiving a close with no code/reason, an impl. should eventually
signal the close to the app using 1005 (in onClose() or whatever).

The 1005 must never be used on the wire. A MUST in the spec.

The close reply should either be 1000 or no code/reason. Which one is
left undefined by the spec.

With Autobahn, this can be controlled via echoCloseCodeReason parameter.

When False (the default), AB will answer 1000 in this case.
With True, AB would reply with empty code/reason (which is the "echo" close
code/reason in this case).

···

2011/11/4 Joakim Erdfelt <joakim....@gmail.com>:

Just a question about autobahn server testcase 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.
Should the response status also contain no close code, no close reason?
Or is the status code 1000 (normal) the way the spec wants?
Reading the spec at
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13#section-5.5.1

" If there is a body, the first two
bytes of the body MUST be a 2-byte unsigned integer (in network byte
order) representing a status code with value /code/ defined in
Section 7.4. "
That tells me that receiving a frame with no status code is acceptable.
Fair enough.
And then section
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13#section-7.1.5
says ...
" If this Close control frame contains no status code, _The WebSocket
Connection Close Code_ is considered to be 1005. "
So internally in our server impl we take the lack of status code in the
close frame to mean 1005 internally (no status code specified), treating the
incoming frame as having no status code [1], then we respond with status
code 1000 and no reason indicating a normal close.
However a point was raised that if the close frame has no status or message
then the response should also contain no status and message.
Is this the behavior?
Or is responding with status code 1000 and no message the appropriate way?
[1] This is treated differently than if we receive a code 1005 from the
endpoint as per autobahn server testcase 7.9.4
- Joakim

0 Likes