On Sat, Nov 11, 2017 at 2:51 AM, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote: > 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. > Ideally I want to allow a browser to know as much as possible info about the capability of the path with less speculative attempts, for less fallback. So, I investigated this situation and explored how much info we could give to the SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL). But yes, the tool, "SETTINGS", we have is only about the peer end of a connection. I think it does make sense to just follow that principle. We can build the opt-in mechanism by that for each hop, and then, proxies are still allowed to emit errors on capability mismatch between connections, as you said. We could design error code, fallback, etc. for this kind of cases if it turns out we really need to take care of. For the initial implementation, maybe we could just let browsers give up when a connection attempt fails on a connection with ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) announced.
Received on Friday, 10 November 2017 18:10:56 UTC