Re: HTTP 1.1 --> 2.0 Upgrade

On Mon, Aug 20, 2012 at 11:08:02PM -0700, Roberto Peon wrote:
> > That's why operators are rewriting/inlining contents with IP
> > addresses as prefixes to fetch additional objects.
> 
> I hope this isn't the case, as renaming origins in the links that
> content-providers send will break security models and break pages or allow
> for some interesting exploits.

Unfortunately yes, as ugly and disgusting as it is, I have seen it with my own
eyes :-( It even has the side effect of having the browser not send cookies to
fetch images, which can be desirable sometimes but might break other times (eg
when trying to load an avatar maybe).

> That aside, as I understand it, much of the delay on the DNS request is
> actually attributable to the radio start-up time (channel acquisition,
> signaling, etc). This should be viewed as a fixed latency cost for the
> first RTT.

The first one is huge but next ones are still important due to shaping and
massive queuing on the RAN.

> Otherwise, sure, DNS resolutions can take some time, around
> 100-200ms.

Exactly.

> > When mobile operators finally decide to advertise explicit proxies, the
> > proxy
> > will be far from the mobile (say 300ms) but close to the net. There you
> > want
> > your smartphone to always use v2 to talk to these proxies and let those
> > proxies
> > act as they want on the net.
> >
> >
> This would be a matter of proxy configuration in the user-agent, possibly
> including the protocol version to attempt to speak.

It can be done that way indeed.

> I don't see how this is relevant? A browser so configured, if it did do DNS
> resolutions, would/should discard that information as it isn't making that
> connection.
> If it did make a connection not going through the proxy, then the DNS
> information is valuable.
> The DNS information is valuable to the proxy in this case, which is what I
> was trying to say earlier...

I see your point, but again, I don't see this as much valuable if the
upgrade can be safely done without relying on the DNS at all.

> > If you remember, this is exactly like all the conversations we had about
> > WS 2 years ago to save round trips in case of failures. The beauty of the
> > HTTP Upgrade mechanism is that it can fail softly with an automatic
> > fallback
> > to HTTP/1. So as long as port 80 is in use, it is possible to always
> > advertise
> > the "Upgrade: HTTP/2.0" header and hope for upgrades, regardless of any
> > other
> > information. Similarly for https, you can announce HTTP/2.0 in NPN and hope
> > for the next hop to accept it. For alternate-protocol, I don't know (I need
> > to read this specific part of your spec first :-)).
> >
> >
> As I remember those discussions, the design-intent was to cause a
> non-compliant proxy to close the connection. This is related, but different
> from requiring browsers to have decent heuristics for deciding that they
> got the protocol version wrong.

I see it similarly, because the need is how to ensure that either the upgrade
succeeds or we fallback to the alternative method.

> One of the problems I have with upgrade as the sole mechanism is that it
> will keep HTTP/1.1 around indefinitely as a required part of HTTP/2's
> handshake. That doesn't seem very good to me. A user-agent should be able
> to learn about the protocol the site is likely speaking, and use that
> first. If it messes up (which will happen, though rarely), it should be
> able to recover withing the attention-span of the user and remember...

Quite frankly I don't see this ever changing on port 80. We'll more likely
see more and more sites advertise "https://" URIs and browsers will probably
try "https://" by default when an URI is entered. Then the http scheme might
remain port-80 compliant for all sites which do not need https and it will
not be much of a trouble.

> > There should be no valid reason not to make tentative upgrades for any
> > site,
> > except if it's blacklisted. But then, only the user-agent will be able to
> > blacklist it, we won't expect the site's owner to advertise itself as
> > blacklisted.
> >
> >
> I think I agree here. I'd interpret "tentative upgrades" as negotiation for
> the next protocol (via upgrade header), but it is nitpicking.

Yes if you want :-)

> > I'm not speaking about what is delivered in contents, because contents are
> > not interesting for intermediaries, but about the protocol. If you expect
> > a proxy or reverse-proxy to make certain use of a header value and this
> > header transports an address or port information, I already bet there will
> > be a large number of deployment issues (possibly even security issues).
> >
> >
> Note that in all cases, it is the server, which is either public, in which
> case there is no issue, or it is private, and should not be sending this
> header, or the headers should be filtered out if it traverses the firewall
> and refers to an internal IP.

Not only. "Public" servers are often reached from the inside on another IP
address by admins, by monitoring systems or even by other users coming from
other networks. That's quite common. In fact the "public" server often is
just a public view of an internal server with a layer of reverse-proxy in
front of it.

> Generally, publicly reachable servers need to
> know their own name, whether that be domain-name, or IP, or cert, or all of
> the above.

Yes I agree.

> The only party for whom any DNS information or alternate-protocol
> information should be interesting is that which is connection to the
> address given. If it isn't, then it should ignore it. Alternate-protocol as
> it exists today assumes failure for the alternate-protocol until the
> channel is actually setup, at which point the browser can proceed to use
> that channel and possible remember this for future communications.

OK.

> > Typically in the examples above, there would be no DNS resolution. I don't
> > count the number of times I've seen IP:port in app servers config files, or
> > even in haproxy config file. I'm used to see Apache in reverse-proxy where
> > you have your /etc/hosts map the server name to the next hop too. There is
> > no DNS involved there either.
> >
> I'm inclined to believe this could be semi-common for internal sites, but
> it seems implausible that, as a percentage, there are that many DNS
> disobeyers out there.

In general you don't want to make DNS requests for a known next-hop, it is
expensive for no added value. This is why you see so many hard-coded addresses
or /etc/hosts on server-side reverse-proxies and load-balancers. One could say
that such components could be configured differently to have the HTTP version
along with the address, but then again it means we have two referentials for
the version, one part in those elements' config files and another part in the
DNS for outsiders.

> > Another example, think about your latest set-top box you unbox and plug to
> > your network. The manual says "connect to http://192.168.1.100/ with your
> > browser". If a new auth scheme is only available to 2.0, you'd rather have
> > your browser automatically try 2.0 there without any DNS request.
> >
> 
> Well, I'd rather have the browser makers figure out the most appropriate
> heuristic for deciding which to attempt to speak first, and be assured that
> there is a fast-fail fallback to ensure that when it chooses wrong, it
> downgrades within my attention span.

Totally agreed.

> IPv6 got this wrong,

Precisely and IPv6 relied on the DNS to make the transition, which really
did not help at the beginning, to say the least!

> but since we've hopefully learned from that deployment mistake...

Hehe :-)

> > > Agreed. I don't think anyone is yet suggesting *mandating* DNS schemes...
> >
> > No, however if we need to use it to advertise the protocol version, it
> > means
> > we failed to design a proper and efficient upgrade mechanism instead. If
> > the
> > mechanism is valid, there is no need for help from side-band protocols.
> > That
> > is my point.
> >
> 
> What percentage of the world is in a situation where they don't have to do
> DNS resolutions? This seems like optimization for the few instead of for
> the many.

In my opinion it's just on server-side, and internal networks. It's not a
big deal, but it creates a number of dirty situations which are generally
solved the worst way. If we can avoid this it's preferable in my opinion.

> In cases where a user-agent (whether that be a proxy or a browser) has to
> do a DNS resolution, having information that it speaks HTTP/2 or whatever
> seems only beneficial provided such information is used only when the
> user-agent is *actually* making a connection to that IP.

Another point is that DNS makes it difficult to manage multiple services by
multiple entities on the same name. But then again it's mainly an internal
issue only.

Regards,
Willy

Received on Tuesday, 21 August 2012 08:39:21 UTC