W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-02.txt

From: Takeshi Yoshino <tyoshino@google.com>
Date: Wed, 15 Nov 2017 20:17:40 +0900
Message-ID: <CAH9hSJbvMVq03Js7Y6FeUNkvuzn8OgSLwAj-pSt1BhpcuUKVsA@mail.gmail.com>
To: Andy Green <andy@warmcat.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Nov 15, 2017 at 7:40 PM, Andy Green <andy@warmcat.com> wrote:

> 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.
After I sent this mail, I noticed that a proxy can skip parsing the
tunneled traffic for the direction from WS/(TLS)/TCP w/ masking to WS/H2
(allowed to be w/o masking), but for the other direction it cannot since
when masking is not made, it needs to apply masking before forwarding to

> 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.

Yeah, maybe.
Received on Wednesday, 15 November 2017 11:18:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 15 November 2017 11:18:30 UTC