Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

["Richard L. Barnes" <[e-mail]>]

[trimmed for brevity]

On Sep 7, 2011, at 10:17 AM, John Tamplin wrote:

> On Wed, Sep 7, 2011 at 8:32 AM, Takeshi Yoshino <[e-mail]> wrote:
> Yes. That's unexpected side-effect of addition of MASK bit. Without the flag, there was no information in a frame if it's masked or not so client just had to follow what the spec says. So, client never encountered such situation.

It should also be noted that if the MASK bit is eliminated, then the recipient of a frame can't even parse it in the current format, since it doesn't know whether the first four octets are a masking key or not.


> I expect it will get used as a WS-variant when dealing with non-browser clients -- ie, between a frontend which handles masking/aggregation/deaggregation/SSL and the ultimate backend, I would not be surprised if there were unmasked client->server frames.  As long as all the browser clients all enforce masking on their connections, the problem masking was added for is averted.

This seems to argue against Gabriel's proposed "c2s MUST / s2c MUST NOT".  Proposed alternative:

OLD: "All frames sent from the server to the client are not masked."
NEW: "Frames sent from the server to the client MAY be masked."

OLD: "All frames sent from the client to the server are masked to avoid ..."
NEW: "Frames sent from the client to the server SHOULD be to avoid ..."

NEW: "Servers MUST NOT reject un-masked frames, unless masking is required by local policy."

--Richard