Subject: HTTP 2.0/flag day

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Mar 2012 11:13:22 +0200

I'm seeing a bunch of messages that seem to be based on the assumption
that after the creation of an HTTP 2.0 that all HTTP 1.x would
disappear in the transition to HTTP 2.0.  I am not anticipating a flag
day here, and I would guess that HTTP 1.1 would still be around for
any use cases that do not need features of any 2.0 proposal.  Does
that make sense to others, or do we have a design constraint that all
use cases currently met by HTTP 1.X must also be met (with the same
security and performance properties) by 2.0?

regards,

Ted Hardie

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Mar 2012 11:20:33 +0200

On 2012-03-26 11:13, Ted Hardie wrote:
> ...

That's a good question.

I expect that many people will agree that some things are not essential, 
but that it might be hard to agree on exactly which parts...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Mar 2012 11:33:26 +0200

I tend to think that common use cases will be met, but but its nature, we'll not be able to meet *all* possible use cases.

E.g, some people out there might be using chunk-extensions, and I think it's uncontroversial that they'll disappear in 2.0 (especially since we've decided to deprecate them in 1.1).

Another example is Trailers (although they have some proponents).

The interesting discussion for me is whether we support use cases that are *possible*, but not yet proven. E.g., the discussion about P2P HTTP; it's interesting, but highly speculative. Personally, I'm inclined to avoid explicitly supporting these cases, although we shouldn't go out of our way to prohibit them.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 09:46:53 +0000

In message <CA+9kkMCZPUH1sgWpNhBCN=[email-masked]>
, Ted Hardie writes:

>[...] or do we have a design constraint that all

It's very expensive to insist on requirements containing phrases
like "all use cases", it typically will cost you a factor of 10
more in effort, relative to writing "all relevant use cases".

I personally would hope that HTTP/2.0 attempts to improve on HTTP/1.1
and thereby replace it, for the vast majority of the use-cases.

I particular I would almost insist on loosing stuff from HTTP/1.1
which is badly thought out (header concatenation), unused (TE: gzip)
or inefficient (CRLF demarkation).

If possible, we should replace it in HTTP/2.0 with stuff which
people want and need, such as a workable session concept, water-tight
cryptographic services, DoS resistance and high performance, realizing
that not every user desires or even want to live with all these features.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 27 Mar 2012 11:47:39 +1300

> security and performance properties) by 2.0?

By my reading that is the chartered requirement anyway. If we do not 
meet or improve all scenarios already *in-use* within HTTP/1.x then the 
upgrade attempt will have failed. Why bother moving to or even creating 
a protocol that does not do what we need it to?

IMHO, best not to do it with a flag-day, but the WG may disagree on 
that.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 27 Mar 2012 06:53:32 +0200

> a protocol that does not do what we need it to?

I agree with you Amos. If the new protocol has no chance to progressively
replace 1.1 just like 1.1 slowly took over 1.0 and 0.9, then it will be a
mess because instead of having to support 3 versions in our products forever
we'll have to support 4. There will be a transition period for sure, but
with enough incentive to migrate, maybe we can get rid of most of 1.1 and
below in less than 10 years (at least I hope).

> IMHO, best not to do it with a flag-day, but the WG may disagree on 

I don't believe in flag days for this. If we have something compatible
with what exists, it will be slowly but surely be adopted.

Willy