Close frames with binary data & Case 7.5.1

[kiler129]

Testing my own WebSocket implementation in fuzzing client mode I noticed "Fail" on Case 7.5.1 - I assumed that closing frame body if it's present can be ANYTHING and MAY be UTF-8 encoded text (but can also be just regular binary blob - application decides what's expected).
I looked through RFC 6455 and I'm puzzled.

Section 1.2 specified only text frames as UTF-8 encoded, binary frames interpretation are left to applications, there's no information about interpretation of control frames payloads.

(...)there are
types for textual data (which is interpreted as UTF-8 [RFC3629]
text), binary data (whose interpretation is left up to the
application), and control frames (which are not intended to carry
data for the application but instead for protocol-level signaling,
such as to signal that the connection should be closed).

Section 5.5 clearly defines close frame as control frame:

Currently defined opcodes for control frames
include 0x8 (Close),(...)

Section 5.5.1. states close frames payload after 2B integer, body may or may not be present. Body itself may be UTF-8 encoded but it's interpretation is not defined.

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.

In addition the same section warns later on close frame payload cannot be considered human-readable:

data is not guaranteed to
be human readable, clients MUST NOT show it to end users.

In my opinion close frames payload could contain UTF-8 text but it's not mandatory - it could also contain binary data.
Maybe my misunderstanding came from fact that I'm not native english speaker?

[kolorafa]

After consulting with @kiler129 we came to conclusion that RFC forcing client to send "valid text" as a reason of disconnect for logging purpose.
Is there a different reason to check the body?
If "data is not guaranteed to be human readable", can it be a binary data? Does it need to be "machine/server readable"?

[oberstet]

Essentially, RFC6455 allows 3 forms of close frames:

• no payload at all
• only 2 bytes containing close code
• more than 2 bytes, and everything after the first 2 is valid UTF8

Not every byte sequence is valid UTF8, and not every UTF8 string is human readable. E.g. close reason could be JSON (which is machine readable, but valid UTF8).

[kiler129]

@oberstet Honestly I don't know why you closed this issue, because it's not resolved from my point of view. There's still a place for discussion about that behaviour.

I can agree with you about first two points, but not with 3rd. Where RFC states that it MUST be UTF-8 encoded data? There's only information that the body MAY contain UTF-8-encoded data.

[essen]

The test is correct.

You MAY have no body.
You MAY have a body that is only the close code.
You MAY have a body that is the close code followed by UTF-8 encoded data.

It's not "You MAY have a body that MAY be UTF-8 encoded data", it's "You MAY have a UTF-8 encoded body".

[oberstet]

Yep, @essen is right. If you think the RFC is ambiguous (I don't), you can take this question to the IETF Hybi mailing list and ask around among implementors and the RFC authors.

Apart from that (as a practical issue): this test has been in the testsuite basically since it exists - and I guess most implementations will pass this test.

[kiler129]

After reading once again I also agree with @essen & @oberstet. Despite from that I'll post question on IETF mailing list - I think it's little ambiguous, it should be clearly described close packet body caries textual data.