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

Re: #385: HTTP2 Upgrade / Negotiation

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 24 Oct 2012 09:56:48 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <20121024075648.GF7331@1wt.eu>
On Wed, Oct 24, 2012 at 06:25:57PM +1100, Mark Nottingham wrote:
> On 24/10/2012, at 6:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> >> A fair number of folks has said they want this, and no one is saying that it's mandatory.
> > 
> > Not being mandatory still means that browsers will have to decide what to
> > do based on this record at one point, with lists of exceptions.
> Yes -- but I'm hearing (so far) from the browser folks that they're willing to do this.

I know, I'm just raising some points so that we don't forget anything.

> So, I'd put it this way:
> The DNS-based upgrade is optimistic; it will be fast as long as there isn't an unknown middlebox present; if there is, it'll be slower to start. The question is how often that will happen, and how detectable / variable it is.
> On the other hand, the Upgrade-based negotiation is pessimistic; it assume that something will go wrong until we prove that both ends speak the same language. It'll be fast but have some limitations at the start (as discussed).
> Ideally, we'd have exactly one way to upgrade for HTTP URIs. However, that *may* not be possible -- if enough people's needs aren't met by the Upgrade path, other mechanisms for doing it will be developed, and if that's going to happen, I'd like it to be interoperable, and ideally part of the spec itself.
> I do hear what you're saying, though. We'll need more data to make hard decisions; at this point I'm just trying to figure out what high-level approaches we're going to pursue in earnest. 
> > And for clear text we'd keep the good old HTTP upgrade which should be
> > optimal for the most common usages (GET/HEAD first) and require that
> > other methods would be handled as 1.1 during the first round trip. I
> > don't see this as a terrible tradeoff.
> At this (early) point it looks like we're going that way, yes. The question is whether we have an optimistic path as well.

I really think that we could consider that https:// is the only fast path.
After all, the web is progressively moving towards more https, and even the
SPDY team wanted full TLS at the beginning. Why not have it this way ? It
would be another incentive for moving web sites to TLS, and would also make
https look faster than http in some carefully biased benchmarks :-)

That said for https to work we still need to fix browser-to-proxy

Received on Wednesday, 24 October 2012 07:57:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC