RFC 6455, "The WebSocket Protocol", December 2011

Note: This RFC has been updated by RFC 7936, RFC 8307, RFC 8441

Errata ID: 7262
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Demi Y
Date Reported: 2022-12-09

Section 5.5.1 says:

Following the 2-byte integer, the body MAY contain UTF-8-encoded data
with value /reason/, the interpretation of which is not defined by
this specification.  This data is not necessarily human readable but
may be useful for debugging or passing information relevant to the
script that opened the connection.  As the data is not guaranteed to
be human readable, clients MUST NOT show it to end users.

It should say:

> Following the 2-byte integer, the body MAY contain data which MUST
be UTF-8-encoded with value /reason/, the interpretation of which is
not defined by this specification.

> As the interpretation is not defined here, clients MAY show it to
end users.

----- OR -----

> Following the 2-byte integer, the body MAY contain arbitrary data,
the interpretation of which is not defined by this specification.

> As the interpretation is not defined here, clients MAY hide it
from end users.

Notes:

The RFC is unclear on whether or not close-frames can contain binary data for the /reason/.

In section 5.2, "Application data" is defined as "arbitrary".

Section 5.5.1 also says about the /reason/:
> This data is not necessarily human readable ...
> As the data is not guaranteed to be human readable ...

Ok, but what if it is?

As per RFC 2119, The "MUST NOT show it to end users" here is not a mere suggestion.
It implies some sort of inherent danger or contract breaking that would occur if the data were "shown" (undefined term), as if passing along UTF-8 text in a controlled manner could cause harm to their application.

Due to the "MUST NOT", the "MAY contain UTF-8-encoded data" here is ambiguous. It implies it could be something other than UTF-8, like binary data, which would be unsafe to blindly "show" to the "end user" (undefined term). There is no clear reason as to why it (emphatically) "MUST NOT" be shown to "end users".

Who is the client and who is the "end user"? This is the only occurrence of "end user" in the RFC. Is the "client" the browser, and the "end user" the developer trying to debug their application, but "MUST NOT" see close /reason/s? In practice, the close reason is of course exposed by browsers. But then is the end user the non-developer who triggers an unexpected error on the server, and has no way to report a bug since the server's error /reason/ MUST NOT be shown to them? Why MUSTN'T it be shown? Is it because it MAY contain binary data?

Clarification is needed on whether or not the /reason/ can contain arbitrary binary data. And the imperative restriction on what the undefined "end user" can be "shown" should be loosened.

Report New Errata