[hybi] Proxies | Re: Extending HTTP/2 | Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Sun, 12 November 2017 07:47 UTC

Return-Path: <hurtta@siilo.fmi.fi>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DF22E12762F for <hybi@ietfa.amsl.com>; Sat, 11 Nov 2017 23:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rQCkAYGZv2eW for <hybi@ietfa.amsl.com>; Sat, 11 Nov 2017 23:47:14 -0800 (PST)
Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03DC12751F for <hybi@ietf.org>; Sat, 11 Nov 2017 23:47:13 -0800 (PST)
Received: from souk.fmi.fi (souk.fmi.fi []) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vAC7l7P7002782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <hybi@ietf.org>; Sun, 12 Nov 2017 09:47:07 +0200
Received: from shell.siilo.fmi.fi by souk.fmi.fi with ESMTP id vAC7l79S007660 for <hybi@ietf.org>; Sun, 12 Nov 2017 09:47:07 +0200
Received: from shell.siilo.fmi.fi ([]) by shell.siilo.fmi.fi with ESMTP id vAC7l6U9019211 for <hybi@ietf.org>; Sun, 12 Nov 2017 09:47:06 +0200
Received: by shell.siilo.fmi.fi id vAC7l67g019210 for hybi@ietf.org; Sun, 12 Nov 2017 09:47:06 +0200
Message-Id: <201711120747.vAC7l67g019210@shell.siilo.fmi.fi>
Sender: hurtta@siilo.fmi.fi
In-Reply-To: <CANatvzxJ4qyvT6e2qwTS7jPw3fUeBCTg3CVgqJ69rm0qyRAtqw@mail.gmail.com>
References: <CAOdDvNrTeZkeYybjcCmQnAK4zEmRSbL=7kBRxjPSo+ODsdVJyA@mail.gmail.com> <20171111210725.4A2D553719@welho-filter1.welho.com> <MWHPR08MB34720F4DE0B015DC46301636DA550@MWHPR08MB3472.namprd08.prod.outlook.com> <CAOdDvNp8Hqr+4vb+meojUVPpFHNky-4aesD0DArsNKHLr9QXeA@mail.gmail.com> <CANatvzxJ4qyvT6e2qwTS7jPw3fUeBCTg3CVgqJ69rm0qyRAtqw@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Date: Sun, 12 Nov 2017 09:44:20 +0200 (EET)
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
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>
X-Mailer: ELM [version ME+ 2.5 PLalpha46]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171112/00983/01
X-Filter: smtpVgate.fmi.fi: ID 0983/01, 1 parts scanned for known viruses
X-Filter: souk.fmi.fi: ID 126317/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi []); Sun, 12 Nov 2017 09:47:07 +0200 (EET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/WLNnpBdKWg9P4v72lSKB2uSnrK0>
X-Mailman-Approved-At: Sat, 18 Nov 2017 08:09:20 -0800
Subject: [hybi] Proxies | Re: Extending HTTP/2 | Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2017 07:47:17 -0000

Kazuho Oku <kazuhooku@gmail.com>om>: (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>om>:
  "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.


"   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

"   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