- From: Takeshi Yoshino <tyoshino@google.com>
- Date: Wed, 15 Nov 2017 20:17:40 +0900
- To: Andy Green <andy@warmcat.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH9hSJbvMVq03Js7Y6FeUNkvuzn8OgSLwAj-pSt1BhpcuUKVsA@mail.gmail.com>
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 WS/(TLS)/TCP. > 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