- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 13 Mar 2015 15:21:55 +0100
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: Greg Wilkins <gregw@intalio.com>, "Jason T. Greene" <jason.greene@redhat.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Well, this discussion quickly dove into the quantum foam between specification and deployed software. I take away from it: - that protocol switching happens immediately after the 101 response - for the downstream. On the upstream it switches after the request has been read. Pretty obvious in hindsight, as those things are. - servers should be predictable in upgrading, either always with content or only without. - the common use case for upgrade on POST does not benefit from h2c and this it seems not worth the effort to implement. Fullfilling the request on HTTP/1.1 format seems to work fine. - maybe a mixed 1.1 up and h2c down request could be made to work, but there seems no gain for anyone in creating this mythical beast. //Stefan > Am 13.03.2015 um 15:04 schrieb Daniel Stenberg <daniel@haxx.se>: > > On Sat, 14 Mar 2015, Greg Wilkins wrote: > >>> Why not attempt a PRI with the explicit http2 option? >> >> Yes that would be a lot better and we already support it in jetty. > > Sure, curl will support that too soon but I think that is beside the point. In this case users can use this option on virtually any server without knowing whether it supports version 2 or not. Like Upgrade: is supposed to work! > >> The issue with the curl usecase using upgrade is that all the upgrade work >> is essentially wasted effort - as the bulk upload is done with HTTP/1.1, > > Yes, but... for example, what if that is the first operation out of several, and then once the first operation has updated to version 2 all the subsequent ones can continue using HTTP/2. And since the upgrade, it would just work with 1.1 servers as we all as 2 servers without the client having to know before-hand. > > And in the end, we usually allow curl to exercise every possible protocol option that is valid (and sometimes also a few that aren't valid) to allow people like readers of this list to test out and torture our own and others servers! I think they call it "enhanced interrogation" nowadays. <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Friday, 13 March 2015 14:22:23 UTC