[hybi] Re: Questions about RFC6455 (implementing websockets)

[Adam Rice <[e-mail]>]

Good analysis. You can see existing errata at
https://www.rfc-editor.org/errata_search.php?rfc=6455 and report new errata
using the link at the bottom of the page.

You should be aware that since the IETF hybi working group was closed, it
is unclear who is responsible for updates to RFC6455, and in practice
updates haven't been happening.

I was not involved in the standardisation of RFC6455, but I've been working
with WebSockets for a long time and I'm one of the maintainers of
pywebsocket, a server that is used in browser testing. I will comment from
the point-of-view of what pywebsocket does.

On Thu, 5 Sept 2024 at 02:31, A. Rothman <[e-mail]> wrote:

> 1: 1.8
>
>    "At the time of writing of this
>    specification, it should be noted that connections on ports 80 and
>    443 have significantly different success rates, with connections on
>    port 443 being significantly more likely to succeed, though this may
>    change with time."
>
>    I could neither understand what this is trying to say (Is this a
> general statistic about port-scanning? Or a fun fact specific to websocket
> deployments?) nor why "it should be noted" - how is it relevant to the
> websocket spec? Would removing this sentence entirely make any difference
> in understanding, implementing or using websockets? I'm not sure if I'm
> missing an important point or this is really redundant.
>

Safe to ignore.


> 2: 4.2.1.3
>
>    "An |Upgrade| header field containing the value "websocket""
>
>    Does "containing" imply it can have other elements as well (as the
> Upgrade field is normally defined), or does it mean the entire value must
> exactly equal "websocket"? The former makes more sense, being standard, but
> I've seen interpretations both ways, and mention of clients that reject
> anything but the single exact value. Perhaps this can be clarified in the
> spec.
>

pywebsocket requires an exact case-insensitive match for "websocket", so if
you only have browser clients it's safe to do the same.


> 4: 4.2.2.4 (regarding /key/)
>
>   "It is not necessary for the server to base64-decode the
> |Sec-WebSocket-Key| value."
>
>   Although technically correct, this is somewhere between a half-truth and
> misleading: section 4.2.1 states that
>
>   "If the server, while reading the handshake, finds that the client did
>    not send a handshake that matches the description below [...]
>    the server MUST stop processing the client's handshake and return an
> HTTP
>    response with an appropriate error code"
>
>    and the "description below" of the key field is:
>
>    "A |Sec-WebSocket-Key| header field with a base64-encoded (see
>    Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in
>    length."
>

In practice, pywebsocket checks that the string looks like base64 using the
regular expression /^[+/0-9A-Za-z]{21}[AQgw]==$/ and then decodes it to
check the length. I think the first step is probably sufficient by itself,
but performance isn't a priority for pywebsocket.


> 6: 5.1
>
>   "a client MUST mask all frames that it sends to the server" and
>   "A server MUST NOT mask any frames that it sends to the client"
>
>   However in 5.2, referring to the Mask field definition, it only says:
>
>   "All frames sent from client to server have this bit set to 1."
>
>   I think it should also say "All frames sent from server to client have
> this bit set to 0". It's strange to mention the requirement in one
> direction and not the other here, even though both are MUST (NOT) earlier.
> It would make sense to mention either both directions or none, not just one.
>
My understanding is that there was an open question of whether masking
would be required in both directions, so the standard left it easy to
change.

7.1.5
>   "_The WebSocket Connection Close Code_ is defined as the status code (Section
> 7.4 <https://datatracker.ietf.org/doc/html/rfc6455#section-7.4>)
> contained in
>   the first Close control frame received by the application implementing
> this protocol."
>
>   "the first Close control frame received" implies there can be more than
> one (also in 7.1.6)? What scenario is this? Why not explicitly disallow
> sending more than one? How is the receiver supposed to react to the second
> one?
>
My interpretation is that this is just protection against a badly-behaved
peer that sends multiple close codes.

Chrome ignores an unexpected Close frame. pywebsocket always closes the
connection immediately after receiving a Close frame, so the issue cannot
arise.


> 9: 6.1.1
>
>   "If at any point the state of the WebSocket connection changes, the
> endpoint MUST abort the following steps."
>
>   It isn't entirely clear what "at any point" means here - in between the
> listed steps? within a step? more specifically, in step 7 it transmits
> potentially multiple frames - is that an atomic operation? or MUST it abort
> also in between frames/fragments? or MUST it abort in the middle of a
> single (possibly very long) frame? This has significant implications to
> what happens next e.g. if aborted in the middle of a frame, or even in
> between frames in a multi-frame message, the framing protocol is then
> broken and no close frame can be sent, etc., whereas if step 7 is
> all-or-nothing with regards to the MUST abort, then the closing can
> continue gracefully and no data is lost). This should really be clarified,
> as this is a MUST that can be interpreted in significantly different ways.
>

My philosophy is that frames are atomic, but messages are not. In practice,
many implementations avoid the question completely by sending every message
in a single frame. Obviously if the underlying connection goes down in the
middle of sending a frame we can't continue anyway, so the question is moot.

Chrome's implementation may be slightly wrong here, as we have an internal
queue of frames to be written to the OS's socket buffer, and we don't have
a way for a Close frame to jump the queue.


>   2 - More generally, it's not entirely clear why it would be required to
> close the socket in any case if the handshake fails, whether according to
> this section or other sections. To my understanding the handshake is still
> using the HTTP protocol, so sending an error status code should be enough,
> and the client should be free to reuse the connection to try again, or to
> send unrelated non-websocket requests for other HTTP resources on the same
> TCP connection. Specifically, section 4.4 describes such a scenario for
> protocol version negotiations - why should it be necessary to close the
> connection in the middle before the second request with the corrected
> version number is sent? (section 4.2.2, under /version/, requires aborting
> the handshake).
>

As a practical matter, in order for NTLM or Negotiate HTTP authentication
to work it's necessary for the client to be able to receive a 401 response
and send another request with updated credentials on the same connection. I
was never sure whether RFC6455 permits this, but I implemented it for
Chrome anyway as it was required for interoperability.

Thanks,
Adam Rice
Chromium Networking