Re: HTTP 1.1 --> 2.0 Upgrade

On Mon, Aug 20, 2012 at 10:04 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Roberto,
>
> On Mon, Aug 20, 2012 at 03:43:16PM -0700, Roberto Peon wrote:
> > > > > 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.
>
> Not in mobile environments. The highest waste of time between your
> smartphone
> and the net are the first DNS requests for the various subdomains required
> to
> download a page. 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.

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. Otherwise, sure, DNS resolutions can take some time, around
100-200ms.


> 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.
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...


> > > 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.
>
> 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.

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...


> 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.


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

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.


> > > 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?
>
> 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.

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. IPv6 got this wrong, but since we've
hopefully learned from that deployment mistake...


> >
> > 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 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.

-=R