Subject: [hybi] proxy & ENABLE_UPGRADE SETTINGS | Re: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

From: Kari Hurtta <[email-masked]>
Date: Sat, 11 Nov 2017 11:19:41 +0200 (EET)

>     SETTINGS   ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server
>     end of connection to client end of connection tells on that case
> 
>     that server end of connection understand
>              :upgrade
>     pseudo header.
> 
>     It tells nothing about that what is behind of that server end of
>     connection.
> 
>     Only after request is sent, http response tells if that authority
>     and path supporting that upgrade. Error is reported as http status code.
> 
>     I see that reverse proxy can send SETTINGS   ENABLE_UPGRADE (or
>     ENABLE_CONNECT_PROTOCOL)
>     even when it does not konw if next hop supports that. Support
>     of next hop or origin server is reported by when that protocol
>     is triedm failure is reported on http status code.

Amos Jeffries <[email-masked]> wrote:

> A proxy that sends that ENABLE_UPGRADE is guaranteeing that it *will* 
> service the upgrade and handle the resulting traffic syntax. By itself 
> if necessary.

I ligthly disagreed.

ENABLE_UPGRADE just tells that :upgrade is not considered to
be error which causes stream error of type PROTOCOL_ERROR
emitted and tells possible full duplex handling (as was on
:method = CONNECT).

You can also try Upgrade: on HTTP/1.1 and server or proxy
have permission to ignore it.   Upgrade is just suggestion
from client.  

In that case request is processed as upgrade is not done.
It can still succeed (without protocol change) or fail
as any http request can.

> In the general case a proxy that negotiates a SETTING it cannot 
> guarantee support for is broken. It must instead negotiate a SETTINGS 
> without the feature and re-negotiate with another SETTINGS later when it 
> has better information.

/ Kari Hurtta

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 12 Nov 2017 03:17:01 +1300

> have permission to ignore it.   Upgrade is just suggestion

If ":upgrade" has the same optional nature as Upgrade did there is zero 
point in creating it. Just use the existing Upgrade header in the 
HEADERS frame. That does not require any negotiation.

The whole point of SETTINGS is to promise the recipient of that frame 
that the things mentioned in it will work. No maybes or guessing.

This guarantee provided by SETTINGS is one of the ways HTTP/2 improves 
over HTTP/1.1. No more sending maybe-ignored headers and hoping for 
success a few RTT later. The client can know up front whether that 
connection is a usable channel for the negotiable feature or not.

...

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 11 Nov 2017 17:50:08 +0200 (EET)

Amos Jeffries <[email-masked]>: (Sat Nov 11 16:17:01 2017)
> HEADERS frame. That does not require any negotiation.

Wrong.  HTTP/2 does not support Upgrade, therefore it needs negotiation.

8.1.2.2.  Connection-Specific Header Fields
https://tools.ietf.org/html/rfc7540#section-8.1.2.2

"   HTTP/2 does not use the Connection header field to indicate
"   connection-specific header fields; in this protocol, connection-
"   specific metadata is conveyed by other means.  An endpoint MUST NOT
"   generate an HTTP/2 message containing connection-specific header
"   fields; any message containing connection-specific header fields MUST
"   be treated as malformed (Section 8.1.2.6).

And

"      Note: HTTP/2 purposefully does not support upgrade to another
"      protocol.  The handshake methods described in Section 3 are
"      believed sufficient to negotiate the use of alternative protocols.

Indication that Upgrade: is "upgrade HTTP/2 stream to tunnel of another protocol"
need negotiation.

HTTP/1.1 Upgrade: is "upgrade connection to another protocol".

> that the things mentioned in it will work. No maybes or guessing.

Point of SETTINGS is to promise that that frame is interepreted 
accoding of new specification and not accoding of RFC 7540
which means "stream error (Section 5.4.2) of type PROTOCOL_ERROR".

That is treatment of ":upgrade" pseudo header and "Upgrade" connection
header according of RFC 7540.

SETTINGS can not promise anything about next hops on multihop
environment when there is several upstream targets.

You can NOT know that there is Websocket on particular
:path bofore you know this path. SETTINGS can not tell that.

Ability to do Upgrade to websocket is granularity of
URL path. If you change URL path then may be that 
Upgrade is not possible.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 11 Nov 2017 21:30:19 +0200 (EET)

> connection is a usable channel for the negotiable feature or not.

Sidenote:

If you want SETTINGS to tell that websocket can be used
over HTTP/2 then 
	:upgrade =
and SETTINGS ENABLE_UPGRADE is no go. No general tunneling
as Kazuho Oku <[email-masked]> as suggesting in that thread:

https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0209.html

> If we adjust the three issues (for example, by allowing any method to
> be specified, and use the existence of :upgrade: pseudo header as a
> signal; use 101 to signal protocol change; use attributes of :upgrade:
> header to specify additional headers required for the upgrade), I
> think the approach would become generic.
> 
> For example, creating a websocket tunnel through HTTP/2 would look like below.

In that case SETTINGS ENABLE_UPGRADE tells nothing what upgrades are available
(or you need to do registry for different 32-bit values of
 ENABLE_UPGRADE to map possible upgrade protocols).

Same to say about SETTINGS  ENABLE_CONNECT_PROTOCOL and
    :protocol = 

You are asking SETTINGS ENABLE_WEBSOCKET then
and that is not proposed on draft-mcmanus-httpbis-h2-websockets-01
either.

/ Kari Hurtta