- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 11 Nov 2017 15:37:26 +1300
- To: ietf-http-wg@w3.org
On 11/11/17 07:10, Takeshi Yoshino wrote: > On Sat, Nov 11, 2017 at 2:51 AM, Kari Hurtta 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. 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. 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. Amos
Received on Saturday, 11 November 2017 02:37:54 UTC