- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sat, 11 Nov 2017 12:45:12 +0200 (EET)
- To: Kazuho Oku <kazuhooku@gmail.com>
- CC: Takeshi Yoshino <tyoshino@google.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>
Kazuho Oku <kazuhooku@gmail.com>: (Sat Nov 11 09:46:58 2017) <...> > > 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). There is (sort of) 426 Upgrade Required normally, if Upgrade can not done, http request is processed without protocol change. This status code allows refusing of processing. 426 Upgrade Required is defined on RFC 2817: Upgrading to TLS Within HTTP/1.1 https://tools.ietf.org/html/rfc2817 Yes, that status code is for somewhat different purpose. > Considering the fact, I would anticipate that we will be fine without > adding a new status code to indicate such failure. > > -- > Kazuho Oku / Kari Hurtta
Received on Saturday, 11 November 2017 10:45:48 UTC