W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Working Group Last Call: Bootstrapping WebSockets with HTTP/2

From: Andy Green <andy@warmcat.com>
Date: Wed, 04 Apr 2018 01:32:26 +0800
To: ietf-http-wg@w3.org,Alessandro Ghedini <alessandro@ghedini.me>,Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>,Patrick McManus <mcmanus@ducksong.com>
Message-ID: <A048F0A5-8ED4-4576-BF0D-C1EA039E5DB5@warmcat.com>


On April 4, 2018 1:17:10 AM GMT+08:00, Alessandro Ghedini <alessandro@ghedini.me> wrote:
>On Thu, Mar 29, 2018 at 08:48:28AM +1100, Mark Nottingham wrote:
>> Hi everyone,
>> 
>> Patrick (as editor) has incorporated the discussion from London and
>believes this is ready for WGLC; there are no open issues.
>> 
>> Please have a look at:
>>   https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01
>> 
>> ... and bring up any issues on-list or on its issues list; likewise
>statements of support (or otherwise) for publication on-list would be
>appreciated.
>
>Hello,
>
>Need a clarification regarding section 5. It says:
>
>   Implementations using this extended CONNECT to bootstrap WebSockets
>   do not do the processing of the [RFC6455] Sec-WebSocket-Key and Sec-
>  WebSocket-Accept headers as that functionality has been superseded by
>   the :protocol pseudo-header.
>
>does that mean that a transparent proxy (say, a CDN, as opposed to a
>traditional HTTP CONNECT proxy) that proxies WS connections and speaks
>HTTP/2
>with the client but HTTP/1 with the origin server, is expected to
>generate
>-Key and validate -Accept itself? Might be worth mentioning this in
>section 7
>as well.

Yes it means that's solely a problem for the h1-speaking side to fake up.  The h2-speaking side doesn't have that ws upgrade handshake concept and no state from it is used on that side.

-Andy

>Cheers
Received on Tuesday, 3 April 2018 17:33:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC