- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sun, 12 Nov 2017 09:44:20 +0200 (EET)
- To: Kazuho Oku <kazuhooku@gmail.com>
- CC: Patrick McManus <mcmanus@ducksong.com>, Mike Bishop <mbishop@evequefou.be>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Cory Benfield <cory@lukasa.co.uk>
Kazuho Oku <kazuhooku@gmail.com>: (Sun Nov 12 02:27:25 2017) > I now do not think that "upgrade" needs to be a pseudo header. > > The reason I proposed having :upgrade: pseudo header was due to my > understanding that HTTP/2 prohibited hop-by-hop headers, and that we ( on here I aggreed with Patrick McManus <mcmanus@ducksong.com>: "a colon header is a transport specific (i.e. hop to hop) header. … it changes the dynamics of the transaction into a fully bidirectional channel and that's transport specific." https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0241.html ) > are trying to revive the "upgrade" hop-by-hop header of HTTP/1 by > trying to implement Websocket (or a generic upgrade) on HTTP/2. It > seemed to me that defining it as an extraordinary header (i.e. pseudo > header) seemed to make sense. > > But reconsidering this, I now believe that what we are trying to > define is an end-to-end upgrade of a stream. In H2WS, we use a > SETTINGS parameter for hop-by-hop negotiation. 1) forward proxyes (which are configured to browser) still use regular CONNECT -method. https://github.com/mcmanus/draft-h2ws/blob/master/draft-mcmanus-httpbis-h2-websockets-02.txt " This document does not change how WebSockets interacts with HTTP " proxies. If a client wishing to speak WebSockets connects via HTTP/2 " to a HTTP proxy it should continue to use a traditional (i.e. not " with a :protocol pseudo-header) CONNECT to tunnel through that proxy " to the WebSocket server via HTTP. 4.1. Client Requirements https://tools.ietf.org/html/rfc6455#section-4.1 " 3. _Proxy Usage_: If the client is configured to use a proxy when " using the WebSocket Protocol to connect to host /host/ and port " /port/, then the client SHOULD connect to that proxy and ask it " to open a TCP connection to the host given by /host/ and the port " given by /port/. " " EXAMPLE: For example, if the client uses an HTTP proxy for all " traffic, then if it was to try to connect to port 80 on server " example.com, it might send the following lines to the proxy " server: " " CONNECT example.com:80 HTTP/1.1 " Host: example.com 2) It is reverse proxies which see Upgrade: on HTTP/1.1 and :method = CONNECT :protocol = websocket on HTTP/2. These reverse proxies listen IP address which resolves from name given on Host -header or :authority pseudo header. I often also refer situation where reverse proxy does TLS offloading — TLS is terminated on reverse proxy. ( Often reverse proxy ↔ backend server connection is not encrypted — sometimes it is re-encrypted — there is another TLS connection to backend server. ) / Kari Hurtta
Received on Sunday, 12 November 2017 07:45:02 UTC