- From: Andy Green <andy@warmcat.com>
- Date: Wed, 15 Nov 2017 18:40:52 +0800
- To: Takeshi Yoshino <tyoshino@google.com>, Patrick McManus <mcmanus@ducksong.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 11/15/2017 06:14 PM, Takeshi Yoshino wrote:
> "due to its multiplexing nature" in the introduction section looks
> redundant.
>
> Given that we drop the Sec-WebSocket-Key/Sec-WebSocket-Accept header
> considering that SETTINGS+:protocol is sufficient to ensure everyone on
> the path understands WebSockets (tunneling), I suggest that we also drop
> the client-server frame masking while also allowing masking as optional
> for LBs that don't want to parse/rebuild frames but forward everything
> after upgrading.
I think you are right and no point for this expensive, pointless,
masking when it goes through this tunnel, but it's open to the client,
ie, typically the browser to either still follow the requirement from
RFC6455:
5.2
...
Mask: 1 bit
Defines whether the "Payload data" is masked. If set to 1, a
masking key is present in masking-key, and this is used to unmask
the "Payload data" as per Section 5.3. **All frames sent from
client to server have this bit set to 1. **
...or, the client can just decide to disregard the requirement due to
its understanding of the tunnel and not set the frame-masked bit on
outgoing traffic that goes through the h2 CONNECT tunnel and save 4
bytes per ws frame.
All this tunnel spec can do is make a recommendation the masking is not
needed, with :protocol websocket it is supposed to be being an *RFC6455*
tunnel, so it should certainly be able to handle masking if that's what
the client side decided (not very well) that it wanted to send.
-Andy
Received on Wednesday, 15 November 2017 10:41:28 UTC