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

[Kazuho Oku <[e-mail]>]

2017-11-11 2:10 GMT+08:00 Takeshi Yoshino <[e-mail]>:
> On Sat, Nov 11, 2017 at 2:51 AM, Kari Hurtta <[e-mail]>
> 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.

I agree.

While I agree that having a status code that indicates failure to
upgrade the connection "end-to-end" might be a nice idea, I would also
argue that the necessity is not specific to HTTP/2.

We could have had a connection-cannot-be-upgraded status code for
HTTP/1.1. But in reality, we do not have such a status code, and
nobody has argue for having that (as I know of).

Considering the fact, I would anticipate that we will be fine without
adding a new status code to indicate such failure.

-- 
Kazuho Oku