- 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