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