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

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