Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

[Kari Hurtta <[e-mail]>]

Takeshi Yoshino <[e-mail]>: (Fri Nov 10 18:51:05 2017)

> Suppose that we have a reverse proxy that has a single H2 connection with a
> browser which is unbundled by the proxy to different target backends (still
> H2 but with fewer streams) where some backends can handle tunneling, but
> some cannot. The proxy needs to either:
> - forward the SETTINGS to the browser to allow it to use tunneling, but
> convert tunneling requests to the tunneling/H2 non-capable backends to one
> over H1
> - don't forward the SETTINGS as not all backends are capable of it
> 
> As SETTINGS is about hop-by-hop characteristics, we need to consolidate the
> bit as above at bundling points. I think this is fine and we don't want to
> introduce any complicated mechanism to perform e2e negotiation. Do you all
> agree on this?

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.

I assume that that SETTINGS is send on initial server settings
(connection preface SETTINGS).

/ Kari Hurtta