- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Fri, 10 Nov 2017 19:51:52 +0200 (EET)
- To: Takeshi Yoshino <tyoshino@google.com>
- CC: Kazuho Oku <kazuhooku@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, hybi <hybi@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
Takeshi Yoshino <tyoshino@google.com>: (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
Received on Friday, 10 November 2017 17:52:29 UTC