W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: HTTP 1.1 --> 2.0 Upgrade

From: Eliot Lear <lear@cisco.com>
Date: Tue, 21 Aug 2012 09:21:14 +0200
Message-ID: <503336EA.2030203@cisco.com>
To: James M Snell <jasnell@gmail.com>
CC: ietf-http-wg@w3.org
James,

IMHO upgrade discovery is an absolute requirement for anything using the
http: scheme.  Otherwise how do you get to 2.0?  Also, nobody has
proposed an alternate scheme, and I suspect such a proposal would be
contentious, to say the least.

Eliot

On 8/21/12 6:59 AM, James M Snell wrote:
> So, I've been catching up on this thread and there's just one thing
> that I just want to clarify: the upgrade mechanism that's being
> discussed is not going to be a mandatory component of HTTP/2.0,
> correct? That is, I as an implementor am not going to be required to
> do this upgrade dance with every new connection, regardless of how it
> actually happens... right? I'm just saying because there are a vast
> array of use cases where such a dance is going to be wholly
> unnecessary... I would even argue that, in MANY cases, having
> something as simple as http2://www.example.com
> <http://www.example.com> that operates on a different default port is
> going to be more than sufficient if the environment is fairly
> controlled and predictable on both ends. Throughout this discussion,
> there seems to be an implicit assumption that upgrade discoverability
> is an absolute requirement.
>
> - James
>
> On Mon, Aug 20, 2012 at 9:23 PM, Amos Jeffries <squid3@treenet.co.nz
> <mailto:squid3@treenet.co.nz>> wrote:
>
>     On 21.08.2012 10:43, Roberto Peon wrote:
>
>         On Mon, Aug 20, 2012 at 2:27 PM, Willy Tarreau <w@1wt.eu
>         <mailto:w@1wt.eu>> wrote:
>
>             On Mon, Aug 20, 2012 at 01:55:46PM -0700, Roberto Peon wrote:
>             >
>
>             > For this to work, it also mandates some annoying
>             interaction between the
>             > HTTP/1.1 code and whatever follows it.
>
>             Yes, that's what I find a bit annoying eventhough it's not
>             terribly
>             complex as long as we support GET requests over URIs with
>             the same
>             headers as the first one.
>
>             > > > Having the data in DNS could short-circuit this, but
>             shouldn't be a
>             > > > dependency.
>             > >
>             > > The DNS requires a round trip anyway and it currently
>             where time is
>             wasted
>             > > in mobile environments.
>             > >
>             >
>             > This is an unavoidable round-trip, though. If you don't
>             know where to go,
>             > one must figure that out.
>
>             Not necessarily (eg: explicit proxies). Eventhough the
>             proxy knows it can
>             talk 2.0 with the server, how does the client know it can
>             talk 2.0 to the
>             proxy ?
>
>
>         Good question. I'd assume proxy.pac or equivalent
>         configuration would have
>         to spell it out.
>         In any case, the cost of getting it wrong with most explicit
>         proxy setups
>         is fairly small because the proxy is generally close.
>         We need to worry about avoiding additional RTTs when RTTs are
>         big, not so
>         much when they're small.
>
>
>     .. .for values of "small" which can reach more than 20 seconds:
>     http://www.potaroo.net/ispcol/2012-05/notquite.html
>
>     Since a failed connection attempt is a full TCP handshake
>     connection. Doing one failure for HTTP/2 and a second attempt for
>     HTTP/1 would be worst-case around 45 seconds to *start* the
>     request process.
>
>
>
>
>             Also, you can still have /etc/hosts pre-filled with some
>             of your operator's
>             important services (login portal or whatever helps you
>             troubleshoot your
>             connection settings). One might even imagine that common
>             DNS entries could
>             regularly be pushed in multicast to end users to save a
>             few round trips. Or
>             these entries might have been advertised in HTTP response
>             headers as you
>             once
>             explained to me :-)
>
>
>         Agreed, in the cases where you've replaced DNS, DNS is
>         irrelevant. :)
>
>
>     +1.
>
>
>
>
>             In fact there are plenty of ways to access services over
>             HTTP and I tend to
>             find it akwards to increase dependency on DNS.
>
>
>         The idea as I understood it wasn't to add any dependency--
>         merely a way of
>         advertising what protocol can be spoken next during what is
>         (for all but
>         those who ignore DNS). In these cases, the client would
>         attempt the new
>         protocol first, likely get an error quickly, and downgrade
>         immediately.
>         With a local proxy, this should not at all be costly as, well,
>         it has a
>         small RTT to the user.
>
>
>     Consider the pathway scenario, which is more common:
>       A->B->C->D
>
>     DNS can tell A what D's capabilities are. But A is not connecting
>     there. Depending on those capability advertisements when available
>     would be a costly mistake.
>
>
>
>
>
>             > > Maybe this could still be done over the established
>             connection using an
>             > > Upgrade ? However, I'd hope we avoid announcing IP and
>             ports in
>             exchanges,
>             > > as it will cause the NAT mess we managed to avoid for
>             years with HTTP
>             and
>             > > which made other protocols disappear.
>             >
>             > I'm not understanding how this would cause NAT messes?
>             I'd guess that
>             most
>             > external sites would just continue to use :80 and :443.
>
>             There should be a single reliable way of getting a host IP
>             and a port.
>             Right
>             now it works well. If you change your /etc/hosts to access
>             your development
>             site, you reach it without any issue and everything works
>             well. If you want
>             to install a reverse-proxy-cache in front of it, you can
>             have this cache
>             use the hard-coded IP address and have it work fine.
>
>
>     Swap "host" with "recipient" and you have the requirements lined
>     up correctly. Final end-server in the chain does not matter in the
>     architecture like HTTP where proxy has  existence, the host being
>     connected to is all that matters. Any overlap between the two is
>     just a convenience.
>
>
>
>
>             At the moment you start exchanging IP addresses in the
>             protocol, you're
>             getting
>             into trouble. Sometimes the IP is valid, sometimes it
>             doesn't mean
>             anything and
>             must be rewritten by *someone* along the chain, but most
>             often, this
>             *someone*
>             doesn't care or is not the same as the one which
>             translates the address. I
>             guess
>             everyone here has already been involved in helping any
>             admin to rewrite
>             Location
>             headers that were improperly set by a customer application
>             that had no clue
>             about the valid host name or IP from the outside. This is
>             typically the
>             situation we should try to avoid.
>
>
>         Everything which doesn't handle this already is significantly
>         broken--
>         sometimes links have IP addresses in 'em. This is expected and
>         valid for
>         the web...
>
>
>
>             In my opinion, once an IP address and a port are known,
>             whatever the means,
>             whether they're entered by hand in a URL bar of a browser,
>             configured in
>             /etc/hosts, are specified in a config file as the address
>             of a web service
>             or as a next hop for a reverse-proxy, we shouldn't care
>             how that address
>             was
>             learned, we should be able to use HTTP/2 over it if desired.
>
>
>         Wouldn't the proxy be doing the DNS resolutions here to figure
>         this out?
>
>
>     *sometimes*. There is a lack of MUT NOT clause in the specs to
>     prevent clients doing for example; same-origin validation.
>
>
>         The client would likely have to do UPGRADE or
>         alternate-protocol or NPN to
>         the proxy to figure out what it'd be using, but that'd be
>         normal...
>
>
>     Exactly why, IMHO, alternatives to those are a waste of time
>     considering unless they can provide the same guarantee for
>     handling transit over middleware (both explicit and interceptors)
>     safely.
>
>     SRV is a non-starter due to end-host servers not being aware of
>     the details to emit for intermediaries.
>
>     I think we should be taking Upgrade: and defining ways to optimize
>     it. Willy had some proposals for merging multiple requests and
>     defining 1.1->2.0 mapping in the headers of request #1. Figuring
>     out how much of that is useful and where it could be improved
>     would be a good way to progress the bootstrapping.
>
>
>
>
>             > Some internal sites
>             > wouldn't, and the network there is controlled well
>             enough that this
>             should
>             > cause no problem. In any case, sites are incented to be
>             sure that users
>             can
>             > connect to them, and will quickly decide to simply keep
>             using :80 and
>             :443.
>             > When one has an inspecting intermediary, it probably
>             won't like to see
>             the
>             > upgrade, but probably would be perfectly fine with a
>             different connection
>             > (e.g. TLS on :443). There is simply less complexity
>             there, imho.
>
>             Possibly, but this doesn't require relying on a side-band
>             registry to know
>             the address and ports. After all, you have enumerated the
>             well-known ports
>             above. It could be mandated that if an http connection to
>             :80 fails, a
>             browser
>             should automatically retry on 443 for instance, without
>             having to deal with
>             registries such as DNS which are OK on the internet and
>             never maintainable
>             internally, nor with IP addresses advertised in headers.
>
>
>         Agreed. I don't think anyone is yet suggesting *mandating* DNS
>         schemes...
>
>
>
>     I think we should be doing a twofold definition:
>     * port 80 Upgrade: from 1.x to 2.0
>        - long term plans to obsolete HTTP/1.x
>
>     * port 80 Upgrade: from HTTP to HTTPS/2
>        - long term plans to obsolete port 443 usage and make the
>     http:// scheme TLS-enabled/secure whenever possible.
>
>
>     Amos
>
>
Received on Tuesday, 21 August 2012 07:21:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 August 2012 07:22:03 GMT