Subject: Rechartering HTTPbis

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jan 2012 14:55:46 +1100

Everyone,

We're getting close to Working Group Last Call. There are about 10 or so outstanding design issues, and I'd like them to be closed by Paris as we're now past the four year mark (on a WG that was originally chartered for a year and a half).

When this effort was started we took great pains to make it clear that we weren't working on a new version of HTTP, because there wasn't implementer support to do so and we wanted to focus upon interoperability and security.

That's clearly changed in the intervening time; two major browsers have implemented SPDY, a non-textual serialisation of HTTP's semantics, and there are now several other implementations as well (full disclosure: including an experimental one in Python by yours truly). 

I've been talking to a number of folks -- including those implementing SPDY, as well as HTTP implementers and the W3C TAG -- about this recently. There seems to be broad agreement that the time is ripe to start work on a new version of HTTP in the IETF, and that it should happen in this Working Group.

Why here? This mailing list is the best approximation of the HTTP community; it has participation (or at least presence) from most implementations, including browsers, servers, intermediaries, CDNs, libraries, tools, etc. I firmly believe that as HTTP evolves, it needs to accommodate the entire community, not just the selected needs of a subset, so rather than creating a new WG or having a private collaboration, it should happen here. 

I've put together a charter proposal (see attached) that has us going to WGLC shortly (something that I want to see us do regardless), and starting work on HTTP/2.0. Note that it does NOT call out a starting point; rather, we'll start by asking for proposals, considering them and selecting one based upon the traditional IETF criteria of rough consensus and running code.

We'll then spend about a year refining that proposal to make sure it is a suitable evolution path for HTTP, while offering better performance, security and interoperability.

Please have a look and tell us your thoughts, indicate support, or express any concern you might have. I'm also happy to talk to you privately if preferable. If there's good support in the WG for doing this, I plan on taking it to the IESG before Paris, so that we can have two meeting slots; one to work on BIS issues (hopefully, WGLC ones), and one to discuss HTTP/2.0.

Regards,

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

---

From: James Snell <[email-masked]>
Date: Mon, 23 Jan 2012 20:50:46 -0800

+1... would love to see that work move forward within this group. I do
have concerns about keeping the scope focused, however. Even tho the
door would be opened to the possibility of new features being
introduced, there is obvious danger in opening those doors too wide. I
strongly feel that things such as the introduction of new request
methods and new header fields, unless there is clear and irrefutable
evidence of their general utility within the core of the spec, should
continue to be pursued as they are today -- within separate I-D's as
extensions to the core protocol. The charter should make it absolutely
clear that the goal is an incremental evolution of HTTP/1.1 rather
than an opportunity for radical changes.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jan 2012 15:52:30 +1100

Thanks, James.

Pretty much everyone I've spoken to about this has raised the same concern. I agree it's going to be a tightrope walk, but I think there's a healthy amount of concern about this in the community, which will help guide development.

Cheers,

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

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Mon, 23 Jan 2012 23:01:01 -0600

On 1/23/2012 10:50 PM, James Snell wrote:
> The charter should make it absolutely

Does it make sense, then, to designate this as an HTTP/1.2 exploration,
as opposed to an outright HTTP/2.0 refactoring?  Somewhere during the
process, if there were a clear mandate to abandon some aspect[s] of the
HTTP/1.1 spec, then the project could recharter itself to HTTP/2.0 with
that narrow, well defined purpose in doing so.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jan 2012 16:02:15 +1100

> that narrow, well defined purpose in doing so.

1.2 would require on-the-wire backwards compatibility with 1.x, which is too constraining. What we really want is *semantic* (not syntactic) compatibility with HTTP as deployed today.

Cheers,

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 24 Jan 2012 18:04:36 +1300

Just my 2c.

It will be an enormous amount of work to come up with a HTTP/2.0

What's the point of doing all that work if it will only be a minor 
incremental change to 1.1, shackled to 1.1 semantics?

I think at this stage it's too soon to decide that we shouldn't change 
semantics.  This is incompatible with a desire to implement many of the 
new features, or improve protocol efficiency.

I think we have a great forum of the right people to come up with 
something better, if maybe we spend a bit of time taking a step back.

What is it we are here for?  What is the web for?  What job does 
HTTP/1.1 currently do, and how might that job be done better?

A minor incremental change could be 1.2.  Many of the things that have 
been discussed as potential desirous paths for the web simply will never 
happen if we restrict ourselves to semantic compatibility at this stage, 
without even looking into the possibility that the web could / should be 
built on something that maybe works completely differently to current HTTP.

Cheers

Adrien

On 24/01/2012 5:52 p.m., Mark Nottingham wrote:
>> On Mon, Jan 23, 2012 at 7:55 PM, Mark Nottingham<[email-masked]>  wrote:
>>> Everyone,
>>>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jan 2012 16:25:57 +1100

Adrien,

If HTTP/2.0 isn't backwards-compatible with the *sematics* (not syntax) of HTTP/1.1, how will following a link on the Web work (for example)?  How will we build gateways between the protocols? Etc.

Cheers,

On 24/01/2012, at 4:04 PM, Adrien de Croy wrote:

> What's the point of doing all that work if it will only be a minor incremental change to 1.1, shackled to 1.1 semantics?
> 
> I think at this stage it's too soon to decide that we shouldn't change semantics.  This is incompatible with a desire to implement many of the new features, or improve protocol efficiency.
> 
> I think we have a great forum of the right people to come up with something better, if maybe we spend a bit of time taking a step back.
> 
> What is it we are here for?  What is the web for?  What job does HTTP/1.1 currently do, and how might that job be done better?
> 
> A minor incremental change could be 1.2.  Many of the things that have been discussed as potential desirous paths for the web simply will never happen if we restrict ourselves to semantic compatibility at this stage, without even looking into the possibility that the web could / should be built on something that maybe works completely differently to current HTTP.
> 
> Cheers
> 
> Adrien
> 
>

---

From: Carlos Prado García <[email-masked]>
Date: Tue, 24 Jan 2012 07:08:55 +0100

Hi all,

IMHO a HTTP/2.0 can be backwards-compatible with the "semantics" of HTTP/1.1 and, at the same time, provides additional verbs, headers, etc.

A gateway 1.1 ---> 2.0 ---> 1.1 can work without problems if 1.0 in the middle do not change the semantic of the message.

At the same time is true that a 2.0 ---> 1.1 can not be possible if the 2.0 message contains any new semantic that 1.1 don't have but for this situation can we define a protocol downgrade equal to the required downgrade in a 1.1 ----> 1.0 sequence with, for example, a keep-alive header. 

May be I don't understand what is the problem.

Carlos,

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 24 Jan 2012 07:43:03 +0100

Hi Mark,

On Tue, Jan 24, 2012 at 02:55:46PM +1100, Mark Nottingham wrote:
(...)
> This mailing list is the best approximation of the HTTP community; it has
> participation (or at least presence) from most implementations, including
> browsers, servers, intermediaries, CDNs, libraries, tools, etc. I firmly
> believe that as HTTP evolves, it needs to accommodate the entire community,
> not just the selected needs of a subset, so rather than creating a new WG or
> having a private collaboration, it should happen here. 

Indeed. And I'll be particularly vigilant on the ability to build gateways
because I've already got several requests to implement SPDY into haproxy,
so once HTTP/2.0 (or whatever we call it) is out, I'm sure I won't be able
to resist to users' pressure. Anyway I'm more than happy to see this move
forwards.

I think that starting from existing HTTP spec limitations and issues is
a safer way to bring something on the table in a reasonable delay than
starting with a big brainstorming about how we can revolutionize the
internet. One more reason to keep focused on current version's remaining
issues till the last minute ;-)

Cheers,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Jan 2012 21:01:02 +1300

> issues till the last minute ;-)

Yes, I was just thinking that.

IMHO item 1 on the agenda should be enumerating the problems we know of 
with HTTP/1.1 that need to be solved. To figure out if the SPDY proposal 
is a good step forward, overkill, or just a framing syntax change. And 
what alternatives or hybrid combinations might work better than either.

AYJ

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 24 Jan 2012 08:13:20 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>HTTP/2.0
>--------

I am going to play the devils advocate and throw a number of spanners
in the general direction of the works:

>[...]we'll start by asking for proposals, considering them and selecting
>one based upon the traditional IETF criteria of rough consensus and
>running code.

> Goals and Milestones:
>
>   Done        First HTTP/1.1 Revision Internet Draft 
>
>   Done        First HTTP Security Properties Internet Draft 
>
>   Feb 2012    Working Group Last Call for HTTP/1.1 Revision 
>
>   Feb 2012    Working Group Last Call for HTTP Security Properties 
>
>   Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a 
>               Proposed Standard 
>
>   Apr 2012    Submit HTTP Security Properties to IESG for consideration as 
>               Informational RFC

Where is that "ask for proposals yadda, yadda, yadda..." stuff ?

>   May 2012    First HTTP/2.0 Internet Draft
>
>   May 2013    Request Last Call for HTTP/2.0
>
>   Jul 2013    Submit HTTP/2.0 to IESG for consideration as a Proposed
>               Standard

One year ?  Yeah, right, as if.

Looking at the above, the only activity I credibly see us perform
is to beatify SPDY.

>* More efficient use of network resources; in particular, reducing the
>  need to use multiple TCP connections

So we're just going to ignore that SCTP already solved this problem
and many other problems, because we just need this as hook to approve SPDY.

>* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the
>  presence of NATs

Apart from "no reverse connections" I have no idea what this means.

>* Maintaining HTTP's ease of deployment

I think this is fundamentally at odds with SPDY's design.

You can write a HTTP webserver in any language or facility that can
do ASCII text, I have even seen such a webserver written in INTERCAL.

SPDY has a very high barrier of entry, zlib compression and a lot of
state, so what exactly do we mean ?

>* Reflecting modern security requirements and practices

Ohh, interesting:  Security against who ?  Security against your
ISP or mobile carrier injecting unwanted ads ?  Security against
your government censoring your web-experience ?  Security against
cross-site-scripting ?  Security against potempkin CA's ?

I could see the discussions take more than a few months, just on this.

>In documenting this protocol, the Working Group must:
>* Meet the goals specified above
>* Make it possible to pass through a HTTP/1.1 message with reasonable
>  fidelity; i.e., to implement a gateway to or from HTTP/1.1

Ok, any protocol worth its salt can pass through a blob of bytes and
call it "a passed through HTTP/1.1 message", but what's the point ?

Where is it going to come from and where is it going to go ?

And why ?

>* consider the needs of a variety of HTTP implementers and users
>  (such as "back-end" or "web api" uses of HTTP, servers and intermediaries)

Ohh, so we are going to cater to "intermediaries" who want to censor the
web ?  I guess we were talking "job-security" then ?

>* Address HTTP proxy and CDN infrastructure requirements
>
>Changes to the existing semantics of HTTP are out of scope in order to
>preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
>request chain. However, the effort may define new semantics to further the
>goals above, along with suitable extensibility mechanisms for defining
>additional semantics.

So, we are not going to actually solve any of the semantic problems
we created, we're just going to wrap the usual mess in a compressed
protocol called SPDY ?

>This work will be known as "HTTP/2.0", unless the Working Group
>determines that this isn't suitable (e.g., for interoperability).

I really don't think it qualifies for that pretentious name, because
all it is set up to be, is tunneling HTTP/1.1 more efficiently
through the tubes.

In my mind, the effort sketched out would be correctly titled
"Beatify the SPDY protocol as a carrier of HTTP/1.1 traffic"

HTTP/2.0 would in my mind be an attempt to actually improve the
protocol, possibly going as far as replacing everything but the
first line which we would have to keep, to ensure the ability
to interoperate with earlier HTTP protocols)

Please be honest...

-- 
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: Thomas Fossati <[email-masked]>
Date: Tue, 24 Jan 2012 09:36:41 +0100

> Looking at the above, the only activity I credibly see us perform

CoAP (without the limitation on the number of encoded Options) and carried over SCTP, would be a good fit for a number of points proposed in the charter -- i.e. I don't feel like SPDY is the only available candidate.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 24 Jan 2012 09:48:04 +0100

Hi Poul-Henning,

> One year ?  Yeah, right, as if.

Well, if we announce one year, maybe we'll manage to succeed in 3.

> and many other problems, because we just need this as hook to approve SPDY.

Maybe HTTP/2.0 could be designed to take advantage of SCTP.

> Apart from "no reverse connections" I have no idea what this means.

My understanding is that we must respect the current model where there is
no need to know the address of the peer anywhere for the protocol to work.
This is what already makes HTTP work very well over UNIX sockets for
instance.

> state, so what exactly do we mean ?

Maybe the points you're expressing are some of the ones to consider
with higher priority to maintain ease of deployment. I was also thinking
that adopting an Upgrade-based protocol could ease transition.

> cross-site-scripting ?  Security against potempkin CA's ?

First, any protocol should have strong requirement for being unambiguous.
Some HTTP implementations are prone to content smugling attacks because
the protocol offers few borders. Everything that affects contents cannot
be considered as part of the security model, however the model should
ensure there are provisions to protect contents (eg: use of TLS when
needed).

> I could see the discussions take more than a few months, just on this.

Even more maybe, based on what we saw on hybi, but that's normal.

> Where is it going to come from and where is it going to go ?

What's most likely to happen is that browsers will quickly adopt the
protocol, and servers will take ages to upgrade. If the protocol offers
real benefit over high latency links (eg: mobile networks), it can make
a lot of sense to implement HTTP2-to-HTTP1 gateways to help many sites
present an HTTP2 interface to the world. That's exactly what is currently
done with IPv6, many sites offering IPv6 connectivity are in fact IPv6
up to the gateway, then IPv4 locally.

> web ?  I guess we were talking "job-security" then ?

Intermediaries are products such as yours and mine :-)

> we created, we're just going to wrap the usual mess in a compressed

Not necessarily.

> "Beatify the SPDY protocol as a carrier of HTTP/1.1 traffic"
 
HTTP/1.1 has a number of issues that make the current spec very
heavy and implementations complex (eg: remember you can't fold
set-cookie, the issues with multiple content-length, etc...).
Taking the opportunity of a new version to clear a few of these
old issues would be nice.

> to interoperate with earlier HTTP protocols)

Maybe that's an option too.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Jan 2012 09:59:12 +0100

On 2012-01-24 04:55, Mark Nottingham wrote:
> ...

Please add...

- Revise Parts 1 through 7 for publication as Internet Standard

This should be mainly fixing problems found past publication, plus 
adjustments we make to better integrate whatever new we come up with.

Re HTTP/next: it would be good to collect a list of things we think we 
should make progress on; not surprisingly, I'd nominate I18N for header 
field values.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Jan 2012 23:09:20 +1300

> old issues would be nice.

Not to mention the issues with Host:, CONNECT-vs-Upgrade:,

> Maybe that's an option too.

One I hope we pick up. Remember, *semantics* is the only thing required 
to be preserved when doing so. A short and streamlined for of transmit 
version of the details above can be found I'm sure, and "messing them up 
again" for transmission over HTTP/1.1 hops is an option.

For example, simply truncating the common header names down to 1 or 2 
bytes and moving to a better timestamp format we could meet all the 
HTTP/2.0 requirements:
  * chop out a visible % of HTTP traffic size
  * be syntactically incompatible with HTTP/1.x
  * capable of trivially gatewaying 1.1-over-2.0 and vice versa
  * with full semantic and feature equivalence
  * and lower barriers to implementation (fingers on telnet + fewer 
bytes = win)

AYJ

---

From: Patrick McManus <[email-masked]>
Date: Tue, 24 Jan 2012 14:45:52 +0000

I just wanted to chime in and say how good it is to see the group moving
on to some of the biggest challenges of the HTTP world. The problems
with HTTP connection management are both huge pain points and
significant blockers for other work. The time is right and I certainly
support the rechartering.

On Tue, 2012-01-24 at 14:55 +1100, Mark Nottingham wrote:
> * A document that specifies HTTP/2.0 an improved binding 
>  of HTTP's semantics to the underlying transport.

---

From: "Robert Brewer" <[email-masked]>
Date: Tue, 24 Jan 2012 07:58:41 -0800

>   * and lower barriers to implementation (fingers on telnet + fewer

Given that the extreme majority of HTTP traffic is automatically
generated, typically via use of a framework, I suspect that far more
humans read HTTP messages directly than write them directly.
Consequently, fewer bytes in header names is probably more of a loss due
to the cognitive load than a win due to reduced keystrokes. It might be
chosen to reduce packet size, but shouldn't be chosen to save fingers.

And I can't believe I'm even writing this, because it's *way* too early
to start offering or debating solutions when we've hardly begun
discussing requirements.

Robert Brewer
[email-masked]

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 24 Jan 2012 20:37:59 +0100

> Apart from "no reverse connections" I have no idea what this means.

As worded it basically means it must run over port tcp/80. SCTP is not
an option if the above is taken literally as most NATs do not know what
to make out of SCTP packets.

> to interoperate with earlier HTTP protocols)

Which is not SPDY.

Regards
Henrik

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 24 Jan 2012 19:43:03 +0000

In message <[email-masked]>, Henrik =?ISO-88

>> to interoperate with earlier HTTP protocols)

Which is why I'm surprised that the first draft is expected in four
months from today...

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 24 Jan 2012 21:05:02 +0100

> Maybe HTTP/2.0 could be designed to take advantage of SCTP.

Heck, even HTTP/1.1 as-is can take advantage of SCTP, and with very
little transport change/mapping it can utilize it very well for framing
as well getting rid of many transport & framing issues of HTTP/1.1.
 
> old issues would be nice.

But SPDY do not.. well sure it addresses the folding issue (there is no
folding in SPDY), but multiple content-length is still an issue. Less so
than in HTTP/1.1 as it's not transport related any more, but still.

Regards
Henrik

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 24 Jan 2012 21:31:20 +0100

Hi Henrik,

> as well getting rid of many transport & framing issues of HTTP/1.1.

Possibly, I don't know in fact.

> than in HTTP/1.1 as it's not transport related any more, but still.

Which is why I'm talking about HTTP/2.0 instead of SPDY. SPDY is something
which exists, HTTP/2.0 is something we must define. Maybe in the end both
will be the same but I'm making a strong difference between "define" and
"use" :-)

[BTW I don't like the name "HTTP/2.0", it reminds me of the marketing term
 "Web 2.0", but that's just a detail]

Regards,
Willy

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 24 Jan 2012 21:59:37 +0100

On Jan 24, 2012, at 8:37 PM, Henrik Nordström wrote:
>>> * Ability to be deployed on today's Internet, using IPv4 and IPv6, in the presence of NATs
>> 

I think that this NAT-friendliness requisite is excessively limiting and, what's more, could be happily outdated by the time this new HTTP is going to be really deployed - which would be really regrettable.

I hope we don't waste this occasion to rethink HTTP deeply, by which I mean that we should not hold us back in experimenting with other transports other than TCP, or else our final outcome will be unnecessarily weakened.

Let this be a real 2.0, not just a buzzword :-)

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 24 Jan 2012 22:10:35 +0100

> Possibly, I don't know in fact.

I did study it in quite some depth some years ago, trying to improve the
existing draft for HTTP over SCTP. It's quite simple mapping provided
one dares to touch the HTTP transport layer (chunking, content-length
etc) which the primary authors of that draft did not want to.

A little more work is needed to address some shortcomings in the
semantics of SCTP (lack of per stream fin and/or rst capabilities). It's
was said something like that is coming, but not sure on the details. 

Hope to get back to this to finalize a proposal for efficient and
reliable HTTP over SCTP.

Regards
Henrik

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 25 Jan 2012 15:49:48 +1300

> chosen to reduce packet size, but shouldn't be chosen to save 

Given my very brief abstract "truncating the common header names" how 
easily would you (already familiar with HTTP/1.1) interpret this blob:

  GET / HTTP/2.0
  H:example.com
  CC:max-age=0
  CNC:close

  HTTP/2.0 200
  D:20120125-153200UTC
  ET:aswa$sf345
  EL:5
  \n
  hello

Hard? no.

~30% more compact.

> to start offering or debating solutions when we've hardly begun

:) Stage 2 - enumerate the options. But yes. lets step back.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jan 2012 07:45:34 +0100

Hi Amos,

> easily would you (already familiar with HTTP/1.1) interpret this blob:

I really like the principle, its still quite readable and makes a smarter
use of upstream bandwidth in highly asymmetric setups (eg: 3G). And having a
single LF instead of CRLF is nice too, as it's quite boring to have complex
parsers that need to have an additional state to handle the case where CR
was seen without LF yet.

Note that this format could be HTTP/1.2 since it's still compatible with
1.x messaging.

That said, there are a number of other issues in HTTP/1.1 that we could get
rid of when switching to a new protocol :
  - get rid of the Host header and only use absolute URIs
  - get rid of content-length and only use transfer-coding (and get rid of
    3 pages in the spec which explain how to determine a message's length)
  - make the connection header mandatory and at a fixed position (eg: the
    first one), this would greatly improve parsers performance
  - have all the connection-related headers first (or maybe optional and 
    inheritable from the first request as long as the connection is kept
    open).

These are just examples, of course, and it's too early for that, but we
all have to start thinking about what we dislike with the current model.

Cheers,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2012 18:17:40 +1100

Hi PHK,

> in the general direction of the works:

Thank you. My *personal* responses below.

> Where is that "ask for proposals yadda, yadda, yadda..." stuff ?

That's implicit at the start. IETF milestones are usually quite brief.

> Looking at the above, the only activity I credibly see us perform

IETF milestones are also pretty much always optimistic. If we don't have consensus on a decent starting point soon, we'd need to revise them (as often happens). 

However, if that does eventuate, I strongly suspect that the people experimenting with SPDY will continue to do so, leaving any standards effort on another track without much momentum (HTTP implementers, please prove me wrong on this, with code).

> and many other problems, because we just need this as hook to approve SPDY.

No, you're going about it wrong. SCTP is easy to argue against; as others have said, it has deployment issues for something as popular as HTTP (and AIUI SCTP over UDP doesn't count).

The real devil's advocate position here is behind BEEP...

> Apart from "no reverse connections" I have no idea what this means.

Ability to be deployed without firewall / nat configuration on a scale that's appropriate to HTTP/1.x's current deployment.

> state, so what exactly do we mean ?

I wrote a SPDY client/server Python library in a very small amount of time; it has significantly less code and complexity as compared to the equivalent HTTP/1.x library. It was significantly easier to get running, and to debug. The hardest part was getting direct access to the zlib api, and that turned out to be ~100 loc, with tests <https://gist.github.com/242459>. YMMV.

If the WG adopts SPDY, my concerns are mostly around their mandatory use of TLS with NPN for negotiation. I also suspect that some form of negotiation for header compression will emerge, but it's early to tell.

> I could see the discussions take more than a few months, just on this.

Yes, they could. In my experience, security-related discussions regarding protocols can either take years, because everyone's an expert and there's no clear requirements or solution, or they're very brief, because there's already an existing, pragmatic solution that is good enough (but not perfect). YMMV.

The real requirement here (and it should probably be clearer) is that there's Mandatory to Implement security -- something that 1.1 doesn't have. 

> call it "a passed through HTTP/1.1 message", but what's the point ?

To have one way to do it. We could start with HTTP-NG, SPDY, BEEP, whatever -- the important thing is to have a single way to do it, and get implementation.

> Where is it going to come from and where is it going to go ?

?? Are you speaking metaphysically here, or?

> web ?  I guess we were talking "job-security" then ?

I wish; IME job security of HTTP intermediation expertise on its own is a touch-and-go sort of thing.

WRT censoring the Web -- even SPDY in its current all-TLS-all-the-time form doesn't help against censorship; the flaws in the CA system are very well-known. If we were serious about this (which is a big IF), we'd need something new (DANE as a starting point, perhaps?).

> we created, we're just going to wrap the usual mess in a compressed

Many of the semantic problems have already been clarified in HTTPbis. For the rest, see below.

> "Beatify the SPDY protocol as a carrier of HTTP/1.1 traffic"

Getting a new serialisation of HTTP's semantics onto the wire specified, implemented and interoperable is a massive task. Starting with a clean slate and letting a committee natter over it for years is a recipe for disaster, and I'd really rather not waste my time on it. 

But hey -- if implementers line up and want to do that, and support it with serious resources, we can go there. I haven't seen it yet. 

I'm willing to listen to the implementers about what they want in this protocol, and to fight people who rock up with bright ideas but nothing else. This cannot be a rubber-stamp effort on SPDY (or whatever else), and it cannot be a love fest to rewrite the core of the Web. There's a fine tightrope to be walked.

I'm also willing to wear appeals to the ADs and IESG if necessary. I'd rather make some harsh consensus calls and piss a few people off than make it a lowest-common-denominator effort. What I'm absolutely not willing to do is to specify a protocol that doesn't get serious deployment.

> to interoperate with earlier HTTP protocols)

"2.0" means "not compatible with the syntax of 1.x on the wire". If marketing people read more into it than that, it's their problem.

Cheers,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 08:51:31 +0000

In message <[email-masked]>, Mark Nottingham wri

>Thank you. My *personal* responses below.

Appreciated.

I have two problems with the proposed project:  The objective and the
timescale.

The timescale is just rubbish, it's not going to happen and we know it.
Pretending otherwise just makes everybody look like ceremonial fools.

But worse: the objetive is almost guaranteed to become a failure,
unless managed very ruthlessly.

If there ever were a protocol subject to Second Systems Syndrome,
it would be HTTP/2.0.  Everybody and his web-programmer is going
to have opinions and we'll never get through their "input" in finite
time.

Print out RFC2616 and the HTTP/1.1bis, put them next to each other
and imagine what the next pile will be like.

Then do the same with the relevant IPv4 and IPv6 RFC's.

Then think.

Being old enough to remember the beneficial reign of Jon Postel, I
want to attack this problem an entirely different way, and use a
criteria which historically have been much more predictive of
protocol success.

My suggestion:

Make a public call for HTTP/2.0 protocol proposals.

Rules:

    1.  Each proposal SHALL be described in a single ID.

    2.  That ID SHALL be 29 pages or less.

    3.  The ID SHALL be an RFC-ready description of the protocol.

    4.  Deadline is 2012-06-01 00:00:00 UTC

    5.  We decide what to do next after the deadline.

Unless we get at good proposal that way, HTTP/2.0 is not worth our time.

Poul-Henning

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 09:12:24 +0000

>  - get rid of the Host header and only use absolute URIs

+1

>    3 pages in the spec which explain how to determine a message's length)

Actually your remaining three ideas can be combined into one idea:

   - Clearly split transport metadata from content metadata, for instance
     by putting a blank line between them.

That removes the need for a Connection header to say which transport
metadata to strip.

I would add a new header that tells how many seconds the connection
can be idle before it is closed.  A value of zero has same semantics
as "Connection: close" has today.

That split also avoids the need to even parse the content metadata
for purposes of transport.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jan 2012 10:35:43 +0100

>      by putting a blank line between them.

I was thinking exactly about the same thing just after sending the mail,
this would leave 4 parts in a message :
  - request/status line
  - transport headers
  - other headers
  - payload

> That removes the need for a Connection header to say which transport

exactly.

> as "Connection: close" has today.

It's always a problem when a client advertises the expected connection
time itself because many intermediaries cannot accomodate such timers,
and issues result from the client expecting everyone in the whole chain
to respect their timers. I'm already seeing stupid people complain from
time to time that some haproxy deployments time out after something like
5 *minutes* without waiting for their response to come and that they
want to configure infinite timeouts !

> for purposes of transport.

Exactly.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 09:45:03 +0000

In message <[email-masked]>, Willy Tarreau writes:

>[...] the client expecting everyone in the whole chain
>to respect their timers.

I didn't say that the timer would be respected, I said that it would
be communicated.  It can at best be a hint, and everybody are entitled
to close whenever they feel like.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jan 2012 10:47:57 +0100

> to close whenever they feel like.

I clearly understood that you wanted it that way, but I can assure you
that it's not how stupid developers will expect it to work. You're aware
that the HTTP specs are only read by low-level implementers like the
persons on this WG. Web developers never read specs because they believe
they "know" well enough unfortunately. And I'm facing them all the day.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 09:52:11 +0000

>they "know" well enough unfortunately. And I'm facing them all the day.

That's why I want the HTTP/2.0 spec to be less than 30 pages, so you
can print it out, stick it on their desk and tell them to learn.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 02:36:30 +1300

>    - get rid of the Host header and only use absolute URIs

+1.

>      3 pages in the spec which explain how to determine a message's length)

+1. I've tried to use that in the above example. "EL:" meaning 
Entity-Length, with no ambiguity about meaning of "Content".

The first chunk can even be a blob of MiME headers from current HTTPbis 
Drafts parts 3-7 . Which leads to...

>      first one), this would greatly improve parsers performance

I disagree on the performance benefit from fixed position. Except for 
Date these are all variable in length headers, which means parsing them 
all anyway. The gain would be coming from making a very small set like 
above which are mandatory to be first, and leaving other extended 
feature headers in an extension blob which can be skipped blindly. 
Optimization taking lessons from the way IPv6 extensions work.
  Perhapse even splitting the list of hop-by-hop headers into a 
specifically marked block which can be wholesale dropped or relayed 
unparsed.

(drat. you suckered me into design again).

> all have to start thinking about what we dislike with the current model.

The things I really dislike you have mentioned already:
* Host: being separate from the URL
* free-form headers like User-Agent, Server, and Via () comment blocks. 
no need for free-form, define a standard syntax please
* Accept-*: being able to duplicate as Accept: entries. ugh.
* size of the headers section not being known up front.
* weak ETags. Still dont get the point of these. Either its a current 
unique ID or its not.

AYJ

---

From: Patrick McManus <[email-masked]>
Date: Wed, 25 Jan 2012 08:54:20 -0500

On Wed, 2012-01-25 at 09:12 +0000, Poul-Henning Kamp wrote:
> , for instance

and another smuggling attack is born :)

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jan 2012 14:57:09 +0100

On Thu, Jan 26, 2012 at 02:36:30AM +1300, Amos Jeffries wrote:
> I disagree on the performance benefit from fixed position.

When I said "fixed position", I used the wrong term, I meant that
I wanted a few of them at the beginning to avoid the two step
phase consisting in :
  1) find the connection header(s) among the whole headers
  2) find the referenced headers among the whole headers

As we exchanged with PHK in the same thread, having two parts would
greatly simplify the design and the parsing... And what you suggested

> specifically marked block which can be wholesale dropped or relayed 

so in short :
  - first line
  - transport headers (hop-by-hop)
  - '\n'
  - other headers
  - '\n'
  - payload

> (drat. you suckered me into design again).

An me too. The temptation is too strong to resist :-)

> * weak ETags. Still dont get the point of these. Either its a current 

Good point on the ETags, I've been used to observe caching issues in
load balanced farms because all servers emitted different ETags and
each time a static object was conditionned by an "if-none-match", it
would obviously not match.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jan 2012 14:58:16 +0100

> and another smuggling attack is born :)

Not necessarily if the places are mandatory. You must always have exactly
2 blank lines in a request and the problem is over.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 03:10:38 +1300

On 25/01/2012 9:51 p.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Mark Nottingham wri
> tes:
>

Before this can happen I think we need to discuss and agree on one thing.

Does the 2.x variance need to be limited to the framing structure 
(request-line CRLF headers CRLF CRLF [entity]) or is it going to be 
delving down into the structure of that "headers" segment?
  ie is it going to be a replacement of the part 2 messaging draft. 
Keeping the drafts 1 and 3-7 as-is? or is it going to supercede them all 
with RFCs using different BNF and new normative limits on some things?

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 03:21:03 +1300

On 25/01/2012 10:12 p.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Willy Tarreau writes:
>

I have just been thinking it would be good to go further than this.  If 
we mandate chunking, it can start immediately after the request-line. 
With the first chunk being the transport headers. Second chunk the 
hop-by-hop headers. Then a chunk for end-to-end and others. That will 
give parsers the size of those header blobs up front so they can process 
or skip faster than trolling through for what is needed.

By avoiding the assumption that the empty line is easily detectable we 
also avoid smuggling attacks a bit cleaner (not 100%, but easier) than 
present approaches can achieve.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jan 2012 15:47:35 +0100

> or skip faster than trolling through for what is needed.

+1 on this.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 14:51:14 +0000

>delving down into the structure of that "headers" segment?

No, we shouldn't try to agree on that, that would be putting the cart
in front of the horse.

Let the people who send in proposals tell us what they think needs
changed, and _then_ once we have seen the proposals, let's talk
about what HTTP/2.0 might/should/could attempt to do.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 14:54:38 +0000

>> hop-by-hop headers.

So now, all of sudden, chunks start having semantic meaning ?

Don't anybody around here get wiser overtime ?

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 04:46:05 +1300

On 26/01/2012 3:54 a.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Willy Tarreau writes:

Some maybe. I'm the newbie though. The water over that cliff is warm 
enough for diving :)

The main point was to embed length details for the headers early, rather 
than semantics.

AYJ

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 16:10:39 +0000

>The main point was to embed length details for the headers early, rather 

I'll agree to that.

* Content metadata firmly removed from transport metadata.

* Length of metadata sections part of initial fixed-length header.

* Option for specifying preliminary metadata in front of content and
  update it to final values after content.  This allows a server to
  Say this looks like "200=OK, 1Mbyte long, text/html, but hold on..."
  then send the object and update with "I was wrong, it was only 800k.",
  "Ohh, and btw, it expires in 4 seconds", "my disk failed, sorry: 206".

And to that you can add gzipping the entire connection, headers included
(jpegs can be zip'ed at level zero to not waste time).

And obviously, a sensible handling of crypto, that allows tunneling
through gateways, load-balancers etc, unto final decrypting host.

... and so on.

But rather that sit and design it here, lets do a call for proposals
and see who can come up with the best and simplest ideas.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jan 2012 17:53:41 +0100

Poul-Henning,

> and see who can come up with the best and simplest ideas.

The benefit of a working group is that we can emerge much better design
by discussing together than a number of individuals can invent alone.
Maybe at one point a call for proposals might make sense, but these
proposals would have a much better quality after some brainstorming
than if individuals try to reinvent the wheel without considering
other people's concerns.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 17:01:26 +0000

>by discussing together than a number of individuals can invent alone.

Absolutely.  But the first point is to find out what we want to
discuss, and it is far from clear that there is any consensus or
even representation in this WG for all the stakeholders.

Gets get some strawmen on the table, then we can discuss.

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 26 Jan 2012 08:42:38 +1300

On 26/01/2012 5:10 a.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Amos Jeffries writes:
>

that will make life really hard for intermediaries.  When can you write 
your cache index information, if information will be countermanded.

> through gateways, load-balancers etc, unto final decrypting host.

I would argue to deprecate tunnelling.

yes deprecate.

It's a major nightmare to lock down.  Crypto should be done with the 
knowledge of the intermediary.

the requirement for scanning content for malware at a gateway is not 
going away, it's getting bigger.

So, I would propose

a) support for SSL/TLS connections to the proxy
b) support for directing the proxy to make an upstream SSL/TLS 
connection, e.g.

GET https://www.wingate.com/secure/ HTTP/x.x

Adrien

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jan 2012 19:52:53 +0000

>your cache index information, if information will be countermanded.

Actually it will make it easier for some of them, for instance during
ESI operations.

It also means that we don't have to abandon a TCP connection just because
something went wrong with a object (ie: more separation of transport
from content)

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 11:32:04 +1300

> than if individuals try to reinvent the wheel without considering

Agreed.

I threw it out there as an idea that had been tempting me for years 
with no real expectation that it would work.
Given a blank call for proposals I would have and missed a huge amount 
of details the two of you pointed out, been forced to go off and write 
up this little thought experiment alone as a devils advocate style idea 
or drop it entirely.

Now its looking like the tweaked version it might actually be useful 
and I'm thinking if we end up with such a call we three (and maybe 
others) should get together and jointly create such an I-D for the 
proposal.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 11:53:45 +1300

On 26.01.2012 08:42, Adrien de Croy wrote:
>> In message, Amos Jeffries writes:
>>
> that will make life really hard for intermediaries.  When can you
> write your cache index information, if information will be
> countermanded.
>
>>

So how would compression type be embeded in the request-line in a way 
not to break HTTP/1.1 servers receiving it?
or were you thinking mandating a gzip wrapper inside each chunk right 
after the chunk intro?
Seems to me this re-introduces the problem SPDY has with sending 
compressed data straight to existing HTTP/1.1 servers.

> going away, it's getting bigger.

I've been wondering about the logistics and benefits of deprecating 
CONNECT style tunnels into Upgrade: header style tunnels. The 
requirement that the protocol being upgraded to be a known registered 
one middleware gets the option to permit or deny based on its own parser 
support and/or configuration settings.
No more of this blind pushing bytes for secure IMAP over port 443 
business, unless the middleware/admin has authorised it to be so.

+1.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 11:58:55 +1300

On 26.01.2012 08:52, Poul-Henning Kamp wrote:
>> write

Provided that the trailer details are limited to transport meta data 
like your example case.

Altering that "text/html" to "image/jpeg" in the trailer or similar 
trick introduces a whole mess of security attacks I don't think we want 
to go near at this point.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 00:13:48 +0100

> >GET https://www.wingate.com/secure/ HTTP/x.x

+2, I would even like to see this as a proposed addition to 1.1. Technically
speaking, nothing prevents this, we just have to define how the proxy must
act upon various issues (eg: invalid certificate, etc...). As it was already
pointed by someone here, there's no place for this in the current draft since
it's not used today, but it would be a cheap and very useful extension.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 00:16:35 +0100

> others) should get together and jointly create such an I-D for the 

Possibly, likely with some other participants. That said we need to
serialize the work a little bit, I'm still having a hard time finding
time to finish reviewing draft-18 !

Willy

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 26 Jan 2012 14:43:47 +1300

actually this raises the issue of aborting transfers.

Currently to abort a chunked transfer, you must close the connection.  
(and this triggers all sorts of nasty buggy behaviour in browsers - most 
of which don't complain).

It would be nice if the chunk header could signal an abort.

On 26/01/2012 11:58 a.m., Amos Jeffries wrote:
> trick introduces a whole mess of security attacks I don't think we 
> want to go near at this point.
>
> AYJ
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 07:17:17 +0100

> of which don't complain).

They should, because the transfer is obviously incomplete if the last
empty chunk has not been seen.

> It would be nice if the chunk header could signal an abort.

It's already possible, we can add attributes on chunk sizes. We could
already have something like this to abort the transfer :

     0;reason=abort\r\n

Anyway I'm not convinced by the usefulness of being able to report
this chunk by chunk, because most common aborts are due to network
timeouts and process crashes, which may happen anywhere, not just
on a chunk border. That's why closing the connection covers all
cases in a non-ambiguous way.

Regards,
Willy

---

From: Dale Anderson <[email-masked]>
Date: Wed, 25 Jan 2012 22:38:30 -0800

Word up. This is live! Hey, can we add "and stuff" now, Hypertext and
Stuff Transmission :P

Dale Anderson

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 08:39:00 +0000

In message <[email-masked]>, Amos Jeffries writ

>not to break HTTP/1.1 servers receiving it?

First of all, I would not allow different compression types.  It's ZLIB
and it's mandatory.

Second, we cannot know if the other end is HTTP/1.1 or HTTP/2.0 until
we see its reply, so the first request would always be in HTTP/1.1 format.

One way to indicate the shift to compressed HTTP/2.0 would be that
the first character of the second request is 'Z', and the entire
connection is compressed from then on.

@ Amos Jeffries:

(about trailer updates to information)

>Provided that the trailer details are limited to transport meta data 

Yes, absolutely.  The content metadata should be transparent from one
end to the other through all intermediaries.

@Adrien de Croy <[email-masked]>

>Actually this raises the issue of aborting transfers.
>

That is one of the primary reasons why I want trailers mandatory:  To
be able to kill a transfer that went awry half way through without
abandonning the connection.

>already have something like this to abort the transfer :

First: YUCK!

Second: That ditches the entire object.  In many cases a 206 would be
perfectly fine.

Third: That reminds me of another thing:  Make the chunk header a fixed
size to improve efficiency.

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Thu, 26 Jan 2012 03:26:24 -0600

> First of all, I would not allow different compression types.  It's ZLIB

Which?  zlib exposes more than one, now.

> we see its reply, so the first request would always be in HTTP/1.1 format.

Or OPTIONS * HTTP/2.0\nHost: thathost.com - or its transparent equivalent.

> connection is compressed from then on.

Byte?  The TCP stack doesn't speak in bytes.  You gained a packet, use it.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 09:32:57 +0000

>Which?  zlib exposes more than one, now.

Well, we'll pick one and only one, but it should have a "null" mode.

>Or OPTIONS * HTTP/2.0\nHost: thathost.com - or its transparent equivalent.

The problem with that is that if it is a HTTP/1.1 only server, you loose
a round-trip or worst case a connection.

All clients will have to cope with HTTP/1.1-only servers for ages,
so making the first request on a connection always be HTTP/1.1, and
then if/when the reply indicates HTTP/2.0 capability, upgrade to 2.0
avoids wasting a round-trip.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 10:35:57 +0100

> First of all, I would not allow different compression types.  It's ZLIB

I find it pretty cumbersome to force everyone to support zlib, especially
in environments where it provides no benefit (small requests/responses)
and only adds CPU usage and latency. It's especially true on intermediary
components which would have to decompress everything to be able to perform
trivial actions such as decide what server to forward to. Using either pure
binary header names or short forms would already be quite efficient.

> we see its reply, so the first request would always be in HTTP/1.1 format.

That's the exact principle of the current Upgrade mechanism.

> connection is compressed from then on.

Better rely on Upgrade. It's well documented and is already used by Websocket.
A number of other alternatives had to be ditched out because they were not
reliable enough through intermediaries.

> abandonning the connection.

Making trailers mandatory will cause a lot of pain to static servers
relying on sendfile() and equivalent mechanisms. Really, I think that
current chunking already offers provisions for reporting issues, and
that trying to improve the minority of unrecoverable error situations
will cost a lot for many components in the normal case.

> size to improve efficiency.

There's no one-size-fits-all. Having small chunks (eg: 256 bytes) will
cause a huge overhead for very small exchanges (eg: auto-completion),
while at the same time significantly reduce on-wire efficiency and CPU
efficiency. Chunking works remarkably well for all sizes nowadays, let's
not reinvent something which works well.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 10:37:48 +0100

> avoids wasting a round-trip.

Indeed, and you also benefit from the existing TCP congestion window.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 09:48:06 +0000

>in environments where it provides no benefit (small requests/responses)

Actually if you look at it, you can simulate ZLIB in null-mode trivially,
so that is not really a valid concern.

It's an idea, I'm not sure if it is a really good idea, but the current
handling of compression is worse.

Compressing cookies would save a lot of bytes, but those are content-metadata
so maybe there are less draconian means.

One benefit of compressing the entire connection is that it offers
"privacy-light", the simple malware which just snoops packets and
searches for "password:" etc, would be out of the picture.

>relying on sendfile() and equivalent mechanisms.

Nobody forces them to send any trailers...

I'm perfectly happy with announcing the intention to send trailers
in the headers.  (Sort of like postscripts "atend")

>Really, I think that

No, chunking offers no way to report anything, all you can do is
close the connection.

>not reinvent something which works well.

If you made the chunked header look like:
	\nXXXXXX\n

Instead of the current

	\r\nX*\r\n

Then the difference in efficiency is utterly marginal for transmitters
but very big for receivers.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jan 2012 11:13:28 +0100

> binary header names or short forms would already be quite efficient.

What's a binary header name?

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jan 2012 23:14:48 +1300

On 26/01/2012 10:48 p.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Willy Tarreau writes:

no gain. compression is equally mandatory and open to snoops as for 
other software.

> in the headers.  (Sort of like postscripts "atend")

Yet if you want to rely on it for broken connections it must be sent or 
that reliance fails.

> but very big for receivers.

16-bit binary numeric length should be long enough for any one chunk 
overhead. One can have multiple chunks inside a Jumbo packet as easily 
as fragmented over multiple packets.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 11:30:13 +0100

> so that is not really a valid concern.

That doesn't change the fact that the recipients must decompress what
they receive to understand what it talks about if the sender is using
compression in a non-null mode.

> so maybe there are less draconian means.

Not everywhere. From what I observe at various places, what takes a lot
of space in requests is :
  - user agent : no need to compress it, just specify a new non-abusive format
  - cookies : the largest ones are those handling an encrypted context so you
    won't compress them

And yes, there are also a number of small requests which will not benefit
from compression.

> searches for "password:" etc, would be out of the picture.

I disagree, it will only make debugging harder, but malware are already
much smarter than humans when it comes to process data. And if most malware
see and manipulate HTTPS contents, it's precisely because they're installed
where the hard work has already been done (ie: in the browser).

> in the headers.  (Sort of like postscripts "atend")

OK.

> No, chunking offers no way to report anything, all you can do is

You can report information on chunk boundaries. But in the middle of
a chunk, I agree you need to close the connection, but it is not specific
to chunking but is general to any variable length protocol.

> If you made the chunked header look like:

Ah OK, I thought you were talking about the size of each chunk. Yes,
a fixed length for the advertised chunk size would be much better. It
too annoys me to have to accept infinitely long series of leading
zeroes.

> but very big for receivers.

100% agree, especially if we get rid of the \r !

Cheers,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 11:37:14 +0100

> What's a binary header name?

Oh I'm realizing I wrote that ! I was meaning the use of enums instead of
headers for the common ones. For instance, we could have bytes 0x80 to 0xFF
directly mapped to most common headers and be able to represent 128 different
headers with a single byte, and have the other chars for the other ones.
We could even push the principle further and have the Connection header
apply the same rules (eg: use high bytes to reference well-known headers
or tokens).

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jan 2012 11:58:39 +0100

> apply the same rules (eg: use high bytes to reference well-known headers

Ack, just clarifying.

An alternative would be to reserve two-letter header field names, and 
assign those to those headers where it makes sense...

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 11:14:22 +0000

>no gain. compression is equally mandatory and open to snoops as for 

Actually, that is not true.  The barrier is significantly higher
if you need to maintain compressed state for all the connections,
compared to just scanning raw packets for red meat.

I will agree that we are talking a white picket fence, not a solid
concrete barrier, but ask anybody how much difference a small white
picket fence makes with respect to dog-poop in your front yard and
you will see the tangible benefit.

>Yet if you want to rely on it for broken connections it must be sent or 

If the server doesn't intend to handle broken objects, either because
it knows it cannot happen (static objects) or that it would be
catastrophic in other ways, it can just close the connection on trouble,
just like we do today.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 11:20:31 +0000

>compression in a non-null mode.

If the client don't want compression, it can just refrain from initiating
a compressed session, and I'm prefectly happy giving servers a way to
announce their abilities.

>  - user agent : no need to compress it, just specify a new non-abusive format

Actually, it should go away, it is totally counter to the idea that
your content would depend on the other end.

if anything, replace it by a client-header that says something intelligent
about rendering abilities and area:

	Render: text, graphics=color, area=1024x768, javascript
	Render: text=color, javascript

>  - cookies : the largest ones are those handling an encrypted context so you

They're usually hexdumped, so I would compress them close to 50%.

>You can report information on chunk boundaries.

It would obivously have to be at chunk boundaries to remain in sync.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Jan 2012 00:54:51 +1300

On 27/01/2012 12:14 a.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Amos Jeffries writes:

I don't mean compared to nothing at all. I mean as compared to each 
other, snoops and legit servers have relatively the same state to 
maintain. A part of the benefit from encryption is the imbalance between 
snoops having to know more and keep more state running perfectly than 
any legit endpoints. Its an unfair game weighted in favor of the good guys.

> you will see the tangible benefit.

But them nastier cat'll jump right over. ;)

AYJ

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 01:14:11 +1300

re signalling an abort.

It's actually a very common requirement when drip-feeding data to a 
client whilst it's being scanned.

I go back to scanning for malware at a gateway.  Sometimes it seems I 
(and my customers) are the only ones interested in this application????

1 It's a requirement to collect an entire entity in order to scan it
2 It's a requirement to prevent agents and humans from timing out.

therefore it's a necessity to send something to the client, potentially 
long before you have the entire entity.  My proposal for progress 
notifications was intended to address exactly this issue.  It's safer to 
send status updates than it is to send actual unscanned entity data.  
However, in the absense of support for update notifications (e.g. with 
103 status or similar), then you have to send unscanned data.

This is an enormous hideous gaping security hole, and browser vendors 
make it worse by their behaviour (or lack thereof) when a transfer is 
aborted (by closing, currently our only option).  In short they do 
nothing, and let you execute the unscanned file.

So, if you're sending chunked to a client, and you decide you need to 
abort the connection, we need a way to signal to the client that it 
should discard what it has received.

Unless all browser vendors (except Opera at last check) change their 
behaviour to warn of an aborted transfer (for what reason they have no 
clue) then it's an ongoing problem.  But even then they are still 
guessing as to why it was aborted.  Was it a network timeout, someone 
tripped over an ethernet cable etc etc?  In the absence of real 
information, a client is probably just going to retry to get the rest.

Why make clients guess when we can make it deterministic?  A simple 
final status code on the final chunk could signal that the transfer was 
aborted, and give a decent reason along with it to drum it into the 
client that they really should discard the entity and not just try to 
fetch the rest of it.

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 13:49:19 +0100

Hi Adrien,

(...)
> My proposal for progress 

I've already thought about this too, including by sending 100 which is
supposed to be harmless.

> nothing, and let you execute the unscanned file.

If the file is truncated, it should not be rendered/delivered/executed
or whatever.

> should discard what it has received.

Then you need some out-of-band to do this. One again, closed connections
appear anywhere in the stream for a wide range of reasons. Too large MSS
which does not pass via some gateways, IPS dropping some packets due to
false positive matches, temporary lack of connectivity (wifi/wimax/3g/sat)
etc... The issues happen at the network level in the middle of data, so
whatever you'd send would be interpreted as part of the missing data
unless you can send it on a chunk boundary.

Imagine this simple scenario :

  +------+    +-------+        | ~ ~ ~ ~ ~ ~ |      +-----+
  | user |----| proxy |--------+   WIMAX     +------| ISP |
  +------+    +-------+       /|\           /|\     +-----+

Lack of connectivity between the proxy and ISP in the middle of a transfer
can only be detected by the proxy which has no way to report that within
the data stream to the user without padding the current chunk.

In fact, it could. We could decide that the X last bytes before a close
are *always* a status report. Still there will be a number of places where
this rule will not be applicable (mainly TCP relays, NAT gateways emitting
RSTs, ...) and this could cause much more confusion than today.

I really fail to get why we have a problem right now because chunking makes
it safe to know that you received the last chunk or that the connection was
aborted.

> information, a client is probably just going to retry to get the rest.

I agree but most often either this info cannot technically be communicated
because the component responsible for the close does not talk the protocol,
or it will not be communicated for a variety of administrative reasons.

Probably we should work on defining better fallbacks for error conditions.

> client that they really should discard the entity and not just try to 

Provided that we can advertise a chunk. This is the point I'm trying to
make. Until the current chunk is not complete, you cannot advertise a
new one.

Regards,
Willy

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 02:04:51 +1300

> make. Until the current chunk is not complete, you cannot advertise a

In our case, we always send complete chunks.  At the point where we 
decide to send a chunk, we have some data, and we know its length, and 
we have decided to send it.

So the signal it would always fall on the start of a new chunk, e.g. we 
scan, determine the content to be malware, and so the next chunk sent 
would be 0 and signal an abort due to malware.

A close would then be less ambiguous, since nothing explicit was 
communicated, the client could then more reliably assume it was a 
transient network error.

I can't really think of a requirement to abort part way through a 
chunk.  Not in this scenario anyway.

If the intermediary is re-chunking then it can easily get around this issue.

Adrien

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 13:23:04 +0000

>If the file is truncated, it should not be rendered/delivered/executed

Depends.

We have reponse 206 for a reason.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 15:01:47 +0100

> would be 0 and signal an abort due to malware.

OK, I see, this is because you're doing deep content analysis.

> chunk.  Not in this scenario anyway.

Probably in your case you never emit truncated chunks, but over the
wire it happens for a variety of reasons, including timeouts and TCP
aborts via active components (TCP proxies and/or firewalls) as I
indicated in a previous example.

> If the intermediary is re-chunking then it can easily get around this issue.

But many have no reason to re-chunk if they're just forwarding data.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 15:03:01 +0100

> We have reponse 206 for a reason.

OK, but in the context I said that, we were talking about chunking.
And this is still true. A chunked-encoded transfer that does not end
with the last 0-byte chunk *is* always an indication of a truncate.

Willy

---

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Jan 2012 09:04:48 -0500

[this is a resend because of a address-must-be-subscribed-to-post filter. Apologies if it hits the list twice]

Lots of great ideas on the list - good to see!

> 2 blank lines in a request and the problem is over.

Of course, depending on what was added, you may receive that injected
data and interpret it as a correct request with exactly 2 blank lines
followed by a bunch of garbage (or perhaps even a second valid request
if the smuggle was particularly good). Things separated by newlines (or
CRLF, or maybe LFCR) are just not a robust enough design. (and of course
implementations should not allow injections of sentinels - but it
happens all the time which is reason enough to not base your framing
around them).

and of course users of text based protocols will insist on 'be liberal
in what you receive' and the problem is back on in full. Heck - see
https://bugzilla.mozilla.org/show_bug.cgi?id=719256 .. in that bug I'm
asked to be liberal in receiving a *negative content-length*.

The question users ask is not "is that disallowed by the spec", it is
"is there a way to possibly squint hard enough and see the data I want
to see - if so do it." we all know that.

The binary length delimiters used in SPDY (for header names, values, and
chunk lengths) are great because they are unambiguous as well as MUCH
cheaper to parse. I'm obviously working on clients now, but when I was
doing high volume intermediaries I spent way too many CPU cycles
scanning the input stream looking for various forms of newlines, colons,
quotation marks, and parsing request headers - I love what a quick
binary length index does to improve that problem, but the real advantage
is that the framing is much more resilient.

I'm unmoved by the inevitable arguments that its too hard to manage a
binary protocol in <language of your choice>. We already have serious
counter examples in node.js, python, and ruby.

here are a couple of other fun classes of bugs that we can avoid
repeating by being less expressive on such basic items as delimiters:

parser doesn't consider the infinite range of length values expressed as
text (I've seen this one a half dozen times over the years) --
http://services.netscreen.com/documentation/signatures/HTTP%3AOVERFLOW%
3ACHUNK-LEN-OFLOW.html

complicated chunk-length definition with extension lists leads to bugs
in parsers -- 
http://lists.ximian.com/pipermail/mono-bugs/2010-April/099471.html

But seriously, this is just a minor sideshow. My experience with SPDY's
header handling and message delimits has simply proven itself to me in
practice - cheap and reliable to work with and compression rates >= 90%
using small memory-friendly windows. It even has a mechanism for
connection-wide headers (the settings frame). Comapred to HTTP/1 it is a
real pleasure. Those bits are not the interesting part of the work in
front of us imo.

The interesting parts to me are transaction (re-)prioritization, push
semantics (and caching related issues), flow control, good rules around
ip pooling especially involving credentials, caching, bandwidth
utilization and congestion responsiveness (especially against real time
flows), and an upgrade/alternate-protocol mechanism from plaintext http.

-Patrick

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 14:05:56 +0000

>with the last 0-byte chunk *is* always an indication of a truncate.

Yes, absolutely.  I just wish there were a way to end the transmission
and say: "Sorry, that went awry, but we can still use this connection.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Jan 2012 09:10:14 -0500

> and say: "Sorry, that went awry, but we can still use this connection.

in SPDY you do that with RST_STREAM::CANCEL. The connection, and any
other concurrent streams, are uneffected.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 15:11:28 +0100

> and say: "Sorry, that went awry, but we can still use this connection.

The only solution I can think of would be to send padding up to the
current chunk size and advertise "0" with some extension to indicate
the wish to reuse the connection. But I really think that the cost of
handling all impacts of a failed connections sensibly offsets the small
expected gain for these rare conditions.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jan 2012 14:19:15 +0000

In message <1327586688.2052.386.camel@ds9>, Patrick McManus writes:

>cheaper to parse.

Indeed, which points at another possible attack-angle on HTTP/2.0:

Make HTTP/2.0 the speed-optimized but feature-limited version, and
leave HTTP/1.1 for the feature-optimized version.

>flows), and an upgrade/alternate-protocol mechanism from plaintext http.

And those "interesting parts" is what will make the HTTP/2.0 spec a
500 page monster, unless we stop now and smell the roses.

The thing we are looking for here, are not tons and tons of weird-ass
options, but simple, general mechanisms which are easy to describe,
easy to use and easy to make work right.

For instance, starting to put "congestion responsiveness", whatever
it is, on top of TCP sounds just plain bogus to me.

It shoulds like an attempt to work around a problem which should
be solved where it lives (TCP & deep black buffers ?) rather than
inefficiently band-aided around at a random higher different level.
(See also: OSI protocols)

---

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Jan 2012 09:19:26 -0500

> actually this raises the issue of aborting transfers.

this is one of my favorite SPDY features.. the abort semantics:

1] allow a transaction to be aborted without impacting the connection
2] allow either end to do so. Clients often want to cancel transactions
because of things like changing pages before the last load was complete.
The client no longer has to guess if it would be faster to open a new
connection or wait for the current transaction to finish downloading.
3] include an option for a REFUSED_STREAM semantic that can be used to
indicate a safe-retry is possible. (e.g. database down - we didn't
process anything).

It really is a good starting point.

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 03:28:31 +1300

On 27/01/2012 3:11 a.m., Willy Tarreau wrote:
>> In message<[email-masked]>, Willy Tarreau writes:
>>
> current chunk size

only if you're mid-chunk when you decide that the chunk you started 
sending you don't want to any more.

Maybe you shouldn't have decided to send it if you weren't ready.

> and advertise "0" with some extension to indicate

Sure the number of reset connections is very small, and you can't 
advertise anything anyway since you can't send any more.

This is only useful when you want to abort, and you can do so on any 
chunk boundary.  Those that wish to use this can tweak their code to 
make it effective, those that don't or just want to pass stuff through, 
that's fine.

But checking for attributes on the final 0 chunk seems to me to be a 
cheap way to get the benefit of abort when you want it.

I'd suggest the number of aborted sends due to content would outweigh 
network errors.

But anyway, it's a basic principle, if you make a decision that affects 
another party, you should communicate it.  If you can't you can't, but 
you shouldn't say "Because I can't ALWAYS communicate it, I will choose 
instead to NEVER do it".  That's sociopathic :)

---

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Jan 2012 09:32:05 -0500

> (See also: OSI protocols)

all I'm saying is that spdy's propensity to use 1 connection where HTTP
is currently using dozens has significant implications on how congestion
control impacts the transport. Most of those implications are very
good[1]! A few might not be so great[2].

It seems pretty clear to me that the IETF is the right place to have the
discussions about the tradeoffs of how an application protocol interacts
with the network.

-Patrick

[1] probably include reduced bufferbloat, less use of constants like IW
and default RTO, better ability to respond to various fast-recovery loss
signals

[2] due to in-order guarantees of tcp, loss events create fate sharing
of that delay between the multiplexed transactions on a spdy connection
- something you don't see with HTTP/1 parallel tcp connections.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Jan 2012 09:47:56 -0500

> we see its reply, so the first request would always be in HTTP/1.1 format.

That's a problem with HTTP/1 that needs to be fixed in HTTP/2. not only
do you not know the server protocol version until you see the first
response you aren't actually guaranteed that the version applies to
anything except that one response.

Due to LB and scripting gateways we see the server response version
change in between response headers on the same connection all the time.

In http/2 We need to define a version level for the connection
properties that does not change once the connection is established, and
probably still allow individual responses to define what level of the
spec they were created at for their non-connection oriented headers to
be interpreted correctly.

SPDY has this problem tackled too. The spdy vs http/1 negotiation is
done as part of the SSL handshake using NPN. The negotiation doesn't add
any new round trips to the handshake and it allows either a clear path
for spdy or a fall back to http/1 before any application protocol bytes
are sent down the pipe. New versions of the protocol would be selected
in the same way.

And yes, I believe mandatory security is a desirable property to be able
to rely on 100% of the time. Some will disagree.

---

From: Jeroen de Borst <[email-masked]>
Date: Thu, 26 Jan 2012 15:01:34 +0000

That sounds a lot like WAP 1.x. This was justifiable given the memory and processing constraints of early mobile devices, but this became a dead-end: as soon as the devices were capable of doing regular HTTP the implementers switched to WAP 2.0 (completely HTTP 1.1 based)..... Interesting that a full circle is being considered.

Zlib in SPDY turns out to be pretty efficient. Requests for inline links (which typically have a lot in common with the request for the parent page) compression causes the request to be ~10% in size of the original request. WAP 1.x encoding never seemed to go below ~50% (because certain headers like User-Agent couldn't be encoded as efficiently as the more structured headers).

Jeroen

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Thursday, January 26, 2012 2:37 AM
To: Julian Reschke
Cc: Poul-Henning Kamp; Amos Jeffries; [email-masked]
Subject: Re: Header field name representation, was: Rechartering HTTPbis

On Thu, Jan 26, 2012 at 11:13:28AM +0100, Julian Reschke wrote:
> >I find it pretty cumbersome to force everyone to support zlib, 
> >especially in environments where it provides no benefit (small 
> >requests/responses) and only adds CPU usage and latency. It's 
> >especially true on intermediary components which would have to 
> >decompress everything to be able to perform trivial actions such as 
> >decide what server to forward to. Using either pure binary header names or short forms would already be quite efficient.
> >...
> 

Oh I'm realizing I wrote that ! I was meaning the use of enums instead of headers for the common ones. For instance, we could have bytes 0x80 to 0xFF directly mapped to most common headers and be able to represent 128 different headers with a single byte, and have the other chars for the other ones.
We could even push the principle further and have the Connection header apply the same rules (eg: use high bytes to reference well-known headers or tokens).

Regards,
Willy

---

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Jan 2012 10:38:10 -0500

>   - user agent : no need to compress it, just specify a new non-abusive format

I'll just say that there are an enormous number of voices that want to
influence the user-agent header. I don't believe any statement from the
HTTP-WG would have any impact other than making the relevant spec that
mandated a particular U-A either DOA or be partially implemented.
Neither is a good outcome :)

>   - cookies : the largest ones are those handling an encrypted context so you

cookies tend to repeat between transactions on a connection. So the
first encrypted cookie on a connection would not compress well (it will
compress some just because it is expressed in text), but subsequent ones
compress extremely well because of their redundancy. An HTTP/2 with a
lower connection count means more transactions per connection and
therefore greater opportunities for that optimization.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 26 Jan 2012 07:57:31 -0800

+1

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 17:06:50 +0100

> Maybe you shouldn't have decided to send it if you weren't ready.

That's not what I'm saying. Again, any intermediary has many reasons
to close anywhere. Many do not even know what HTTP is nor what a
chunk is. Chunks are not atomic. And even intermediaries which talk
HTTP cannot all buffer all chunks. When you have a 16kB buffer per
connection, a chunk rarely fits there so you have to transfer as you
get them.

> I'd suggest the number of aborted sends due to content would outweigh 

It depends on the environment. In your products since you have valid
reasons to abort when matching contents, that's certainly true. But I
know many other infrastructures where no such filtering happens, and
the primary reason for an abort is a timeout, the second one is the
usual process crash in the middle of a processing due to an application
bug.

> instead to NEVER do it".  That's sociopathic :)

I agree with this point of view. As I said, what I'm against is making
it harder to support the normal case just to favor better error recovery
for the fatal cases. For instance, re-opening a connection is cheap. OK
it's a round-trip, but if it happens less that 1/10000 times it's probably
better than padding megabytes of chunks or making parsers more complex.

Willy

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 09:18:07 +1300

> connection, a chunk rarely fits there so you have to transfer as you

sure, and these types of intermediaries can continue to do the same 
thing.  If they want to be 2.0 compliant they can at least recognise 
abort signals on 0 chunks, even if they can't generate them.

But I don't see that as a reason to not add such a feature to the 
protocol.  Others can benefit.

> usual process crash in the middle of a processing due to an application

This comes back to my other point about who is interested (apart from 
all my customers) in scanning at an intermediary.

> for the fatal cases.
the abort signal isn't just so you can re-use the connection, although 
that is an added benefit, in our case the primary benefit is to be able 
to signal the receiver that the entity should be abandoned for some 
reason other than a transient network failure.  E.g. don't try again.

> For instance, re-opening a connection is cheap. OK

I don't think you'd need to pad chunks.  Any intermediary that is 
scanning will be passing data through some filtering layers.

It's inconceivable that such data would not be de-chunked prior to being 
passed through the filters (else all filters would need to handle chunks).

Therefore it's likely the data would need to be re-chunked at the other 
end of the filter chain.

Adrien

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 09:46:43 +1300

one other thing, I think we are losing site of context here.

We're discussing possible features for a new protocol which is not 
necessarily syntactically compatible with HTTP/1.x

This means that every piece of deployed HTTP infrastructure would need 
to be upgraded if it wishes to support the new protocol.

So raising roadblocks for general protocol features on the basis of very 
limited existing 1.x implementations serves no useful purpose.

In that light, I'll throw something else out there.

I think it may possibly solve more problems than it would create to 
simply use a different port for "http 2.0", and not try to achieve 
backward compatibility / interoperability with 1.x on the same port.

There - I said it :)

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 21:54:18 +0100

On Fri, Jan 27, 2012 at 09:18:07AM +1300, Adrien de Croy wrote:
(...)
> protocol.  Others can benefit.

As long as it's only the reason on the 0 chunk, I find it very cheap
for everyone, and it's even doable right now although not exploited.
So I'm clearly in favor of that option.

(...)
> all my customers) in scanning at an intermediary.

There are various degrees in scanning. I see a lot of URL filtering, and
few content filtering. But this will surely evolve for legal reasons, and
due to the diversity of mobile terminals making it harder to maintain an
up-to-date panel of anti-malware suite for all these devices.

> reason other than a transient network failure.  E.g. don't try again.

Indeed, that was your point, I think it was PHK who advocated the connection
reuse.

> Therefore it's likely the data would need to be re-chunked at the other 

For usages like yours, I agree on the benefits you could take from this
extension. Making it a best effort ensures that those who need it can,
and that we don't make the framing silly for those who wouldn't benefit
from it. So that's a +1 from me :-)

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 22:01:55 +0100

> necessarily syntactically compatible with HTTP/1.x

Indeed.

> backward compatibility / interoperability with 1.x on the same port.

The same subject was discussed to great extents on hybi, and the big
problem with using a new port and/or with incompatible upgrades is
that you enter a chicken-and-egg problem. Browsers won't use the
new protocol by default until there is enough adoption on the server
side, and server siders won't waste their time and money deploying and
maintaining a second parallel infrastructure for years just for the few
geeks around who click the "use fancy http" box. The current status of
HTTP pipelining and TCP ECN describes the process very well.

Due to the size of the current web, the only upgrade path seems to be
by starting compatible and possibly upgrading, but in any case the
failure must be immediate and clean, otherwise painful failures will
result in the new version being disabled by default and enabled by
noone.

> There - I said it :)

So did I :-)

Willy

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 26 Jan 2012 22:47:46 +0100

> this would leave 4 parts in a message :

Everything transport should be at a transport layer, wrapping the
exchanged messages. So I would put it like

- message oriented hop by hop transport, defining message boundaries,
abnormal termination, TLS negotiation, tunneling, multi-streaming etc as
desired.
- request/response meta data
- entity content

with everything transport completely interchangeable without affecting
any of the functionality or semantics of the exchanged messages as such.

authentication is a little tricky to define cleanly however as it's a
property of both transport and message, and hop-by-hop and end-to-end..

the other question is if there should be support for non-message based
content (i.e. streams etc).

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 11:03:19 +1300

> HTTP pipelining and TCP ECN describes the process very well.

yeah, that's a fairly compelling argument against any sort of change.

we need to overcome this if we want to move forwards.  Forever is a long 
time, and to be stuck with HTTP as it is....

Maybe there is some other compelling issue we can overcome with http, 
which would provide the incentive to deploy 2.0 and we can slip all the 
other changes in on the coat-tails of the answer to that.

Although Google with SPDY have proven that new protocols can be deployed.

But at the moment, if we were to make all the proposed changes to HTTP, 
it would be like trying to change TCP to have 32bit port numbers.

At least with IP4 -> IP6 there is a compulsion, due to address space.  
There's no such compulsion with HTTP, it works well enough for the 
people who use it.

It's depressing but it's something we all face.  Unless we can get 
commitment from all major server and client vendors to implement and 
roll out changes, we won't get very far.  So maybe we should start there?

At least if we moved to a different port, intermediaries (e.g. those 
intercepting TCP/80) would be none-the-wiser and wouldn't try to mess 
with the traffic/protocol.  That would limit the scope of required 
supporting agent types to just clients and servers for a start.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jan 2012 23:32:55 +0100

> time, and to be stuck with HTTP as it is....

Well, HTTP/1.0 is still much present too... 15 years after RFC2068.

> Although Google with SPDY have proven that new protocols can be deployed.

I'm not sure there are *that* many deployments, except enthousiasts. Home
users generally do not experience much filtering. However in the enterprise
world you can literally wait for several years before your new port is open
with all the filtering components installed etc...

> it would be like trying to change TCP to have 32bit port numbers.

If we make them by brute force, yes. If we make them as an upgrade, it
might work. PHK suggested that the first request should be 1.1 and that
upon this connection we'd upgrade to 2.0. I too find that this is the
safest path. The client does not need to speak to other ports, and
knows after one round trip whether the server supports the upgrade or
not. This is quite cheap and compatible with existing infrastructure,
allowing both versions to coexist.

> supporting agent types to just clients and servers for a start.

Not always, it's often the opposite. I've seen mobile phone operator platforms
where only 80 and 443 are proxied to the outside, the rest simply being
blocked. And in the enterprise world, you generally do not even route to
the outside, you have to pass through a number of proxies.

Still, HTTP Upgrade header makes a lot of sense for this.

Regards,
Willy

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 11:45:56 +1300

> allowing both versions to coexist.

I wouldn't rely on support for Upgrade.  Since there's basically no 
deployed users of it (I've never seen an upgrade header in 17 years) I 
would expect it to break on many intermediaries, and so the test for 
HTTP/2.0 support wouldn't be reliable.

Therefore it's likely everyone will choose instead CONNECT to tunnel, 
it's reliable.

In fact due to the number of sites moving to https, the incidence of 
traffic bypassing everything with a tunnel through the proxy is becoming 
a bigger and bigger problem.

Hence my previous statement about deprecating CONNECT, and making sure a 
corporate proxy has access to the payload and http protocol.

It would be trivially simple for a client to issue GET https://etc 
instead of tunnelling... in fact it would simplify client code a fair 
bit.... if the client could rely on the proxy supporting it.

So... maybe we need an OPTIONS command specifically for proxies, to 
enable a proxy to advertise supported protocol features.

POP3 has it, SMTP has it, maybe it's HTTPs turn now :)

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Jan 2012 00:11:14 +0100

> HTTP/2.0 support wouldn't be reliable.

It's currently being used for WebSocket. Granted it breaks on a number
of intermediary but what was observed is a fast and clean failure,
which means that the client can fallback to the good old protocol.
Adding support for Upgrade to existing components is quite easy so
most products will evolve to correctly support WebSocket and will
provide you with Upgrade for free.

> Therefore it's likely everyone will choose instead CONNECT to tunnel, 

It's not designed for origin server usage, and is not reliable across
intercepting proxies, because it's a proxy-only method which is detected
by some proxies. I've experimented with that at one mobile phone operator
too. Sending a CONNECT on port 80 (which was intercepted by a modified
Squid) would simply result in a hang, probably because the outgoing
connection did not look like HTTP and was not sent to the proper components.

> a bigger and bigger problem.

Which is why you suggested the "GET https://" scheme which I agree with.

+1.

> enable a proxy to advertise supported protocol features.

It could be a good idea though it would require one additional round trip,
and would still not indicate whether intermediaries correctly support the
same features.

> POP3 has it, SMTP has it, maybe it's HTTPs turn now :)

POP, SMTP etc are hop-by-hop. HTTP is end-to-end with invisible hops
everywhere and their own incomplete implementation. *this* is the problem.
Regarding this, PHK is right that if we want correct implementations of
the next spec, it should be short and easy to understand.

Willy

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 27 Jan 2012 12:29:42 +1300

> connection did not look like HTTP and was not sent to the proper components.

connect should only EVER be sent to a proxy the client knows about.  So 
it should in general not be intercepted.
anything that intercepts CONNECT should pass it through to the original 
destination.

WinGate supports interception of CONNECT, but this only happens if the 
client is configured to use a proxy outside the firewall.

That's generally undesired behaviour in corporate environments.

> and would still not indicate whether intermediaries correctly support the

Actually it wouldn't require an additional round trip.  the client could 
make the request once, each time it starts and only to the proxy it's 
configured to use.

Maybe it should be called PROXYCAPA or something.  And it needs to 
return information in a machine-readable format unlike OPTIONS.

The proxy could advertise:

* support for https URIs
* support for tunnelling (absense means no support, don't send)
* support for upgrade, and to which protocols
* support for progress notifications
* etc

> the next spec, it should be short and easy to understand.

+1, complexity has always been a big problem.

However I don't see that going away, since entity headers are 
intermingled in the transport protocol.

Even the name implies it's just a transfer protocol.  SMTP, FTP etc all 
restrict their activity purely to transferring things.

HTTP blurred the boundaries, and cares about what it is transporting.  
Personally I think it should not, and entity headers should be deemed 
part of the payload.

But content-negotiation made that difficult, and we can't really back 
out of it.

I also wonder whether some of the subtleties of content negotiation have 
largely made no splash at all... like the convoluted q values.  I'd like 
to see them go.

I'd also like to see the Accept header go.  It's just mindless bloat.

Expect can go as well IMO

Adrien

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Jan 2012 15:01:06 +1300

On 27/01/2012 12:29 p.m., Adrien de Croy wrote:
> connect should only EVER be sent to a proxy the client knows about.  
> So it should in general not be intercepted.
> anything that intercepts CONNECT should pass it through to the 
> original destination.
>
> Actually it wouldn't require an additional round trip.  the client 
> could make the request once, each time it starts and only to the proxy 
> it's configured to use.
>

POCO (Point orf contact options) ? its shorter too.

> intermingled in the transport protocol.

Re-read the first few messages of the thought experiment between Willy, 
PHK and myself. One of the early adjustments was to split the headers 
into two distinct groups along that boundary, with fixing that problem 
in mind.

>
> Even the name implies it's just a transfer protocol.  SMTP, FTP etc 
> all restrict their activity purely to transferring things.
>

Yes we *can*. With the step to HTTP/2 it could be perfectly reasonable 
to start with one-liner hop-by-hop transport negotiation round trips 
like FTP and SMTP use.
Slow, but possible.

Give it some thought and make a proposal for how to do it fast :). The 
next time we get a chance to fix that problem it will be HTTP/3.

>
> I also wonder whether some of the subtleties of content negotiation 
> have largely made no splash at all... like the convoluted q values.  
> I'd like to see them go.
>

Same here. But, we can simply declare such negotiation and entity 
details as outside of the transport protocol in a HTTP/1.x internal 
wrapper blob of some type and leave the details unchanged. SPDY did this 
but wrapped the whole lot.

> Expect can go as well IMO

Maybe, Expect or Prefer might be of some use on the intiial OPTIONS 
request if that ends up happening. Later requests of course dont really 
need it since they can assume some minimum level of feature support.

AYJ

---

From: "Jose Mathew Manimala" <[email-masked]>
Date: Fri, 27 Jan 2012 02:56:14 +0000

Just a random question, will 2.0 support secure sockets the same way as 1.1 and will there be any causes for concern over how ssl is to be implemented for 2.0?

Thanks,
Jose

-----Original Message-----
From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Jan 2012 15:01:06 
To: <[email-masked]>
Subject: Re: Rechartering HTTPbis

AYJ

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 12:04:19 -0700

> headers with a single byte, and have the other chars for the other ones.

Sounds a bit like CoAP:

https://datatracker.ietf.org/doc/draft-ietf-core-coap/

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Jan 2012 21:05:08 +0100

> https://datatracker.ietf.org/doc/draft-ietf-core-coap/

Indeed, we could see similarities. However CoAP appears to be mainly aimed
at embedded system where a byte is counted as 8 bits, and where it makes
sense to trade scalability for compactness.

Regards,
Willy

---

From: David Morris <[email-masked]>
Date: Fri, 27 Jan 2012 13:46:18 -0800 (PST)

> components which would have to decompress everything to be able to perform

I talked with a hardware vendor yesterday who had implemented an HTTP 
server and client (and other stuff) in 128KB of ram in a special device.

Adding mandatory zlib support would kill his product.

---

From: patrick mcmanus <[email-masked]>
Date: Fri, 27 Jan 2012 17:42:31 -0500

On 1/27/2012 4:46 PM, David Morris wrote:
> server and client (and other stuff) in 128KB of ram in a special 
> device. Adding mandatory zlib support would kill his product. 
and mandatory TLS will probably bury it :) (*)

but I don't think extreme ram constraint can be a serious requirement 
for a next generation web transport protocol.

All the folks running computers in their pockets with 4000x that memory 
deserve an experience with always on encryption and compression to deal 
with the high latency mobile world we're looking at.  Just one vendor, 
Apple, shipped 93 million such devices last year .

Making security optional in HTTP/1 has been a disaster (firesheep and 
cookies anyone?). Making compression optional isn't a security disaster 
of course, but it has generally been a giant performance opportunity 
lost. It was all reasonable at the time, but this is a new time. There 
are tail cases where each approach doesn't buy you much, but being able 
to rely on the property (and thus that it won't be unapplied in an 
important case out of convenience, cheapness, whatever) is far more 
important.

-Patrick

(*) it isn't obvious to me that 128KB isn't plenty for the decompress 
format, I suspect the "and other stuff" comment means we should just 
assume the extreme limit for the discussion rather than playing 
name-that-tune with our own guesses at how tightly it can be implemented.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Jan 2012 10:31:30 +1100

> Pretending otherwise just makes everybody look like ceremonial fools.

In my experience, standards groups given generous schedules will fill those schedules (and then ask for more time). At this point it's impossible to know what the timescale is, because we don't know how much work there is to do. However, implementers are already deploying a candidate, and the longer they do so, the less likely we'll be able to change it to incorporate other concerns.

As such, I'd rather put pressure on the effort to deliver, and throw an exception when it needs more time, rather than let it pontificate for three years and come up with nothing. I'm happy to re-charter the effort if and when it demonstrates that it needs more time to perform productive work.

> unless managed very ruthlessly.

Go on...

> to have opinions and we'll never get through their "input" in finite

Yes. We've managed that in HTTPbis, and we'll continue to do so. New features go elsewhere, unless they're specifically chartered in.

>    5.  We decide what to do next after the deadline.

We're actually not too far from this, discounting the size requirement. The current plan is to gather proposals and evaluate in a few months; if we can't get consensus, the WG will stop HTTP/2.0 work.

I'm happy to adjust the charter proposal to make this more clear.

BTW, Mike's current proto-draft of SPDY weighs in at 44 pages.

> Unless we get at good proposal that way, HTTP/2.0 is not worth our time.

"Do it my way, or it's not worth our time?" Really?

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Jan 2012 10:37:33 +1100

On 24/01/2012, at 7:59 PM, Julian Reschke wrote:

> This should be mainly fixing problems found past publication, plus adjustments we make to better integrate whatever new we come up with.

My current thinking is that we'd re-charter separately for that.

> Re HTTP/next: it would be good to collect a list of things we think we should make progress on; not surprisingly, I'd nominate I18N for header field values.

So, that's an interesting question.

If we want HTTP/1.1 <-> 2.0 gateways, and we don't want to force them to know about individual header semantics, that implies that we can't really change header encoding, doesn't it?

Regards,

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 00:58:49 +0100

Hi Pat,

> for a next generation web transport protocol.

I agree on this precise point, but this is not counting devices having
to deal with huge number of connections.

For instance, haproxy requires around 40 GB of RAM to handle one million
concurrent connections on Linux, and this is with 8 kB buffers and with
a finely tuned network stack. 8 kB buffers are already quite small for
todays web, but as you can guess it, people running with that large
amounts of sessions only deal with small request/response patterns and
will probably migrate to WebSocket. Having to handle zlib constraints
in such usages is totally useless. It will bring no noticeable network
benefit on such traffic, and having to decompress the stream to parse
it on a machine which is already almost packet-bound will require
tremendous amounts of CPU power and will probably add unneeded latency.
To get back to the haproxy example, right now it's able to process up
to 2 million tiny requests per second on a Core2 3 GHz (this is cheating
using pipelining etc). The parser is optimized to avoid reading the same
byte twice. Having to deal with the complexity of inflating the stream
to get the headers will significantly impact the request rate for a gain
that will be minor if we already manage to reduce header size and number.

I agree this is another extreme case, but we're trying to make HTTP
scalable and cheaper on resources. And there are product vendors who
already manage to support much higher connection counts because they
can access to much lower layers and optimize their resources even more.
On the other hand, the added complexity of handling a compressed stream
will surely affect their ability to sustain the same performance levels.

> Apple, shipped 93 million such devices last year .

But here we're comparing apples and oranges (no pun intended). My opinion
is that any CPU will be able to handle a tens of connections at a time.
Given David's numbers, a CPU equipped with 1 MB of RAM would be able to
ten connections. The issue really is on the server -and more importantly-
intermediary side. We need these components to scale if we want to serve
more users.

> cookies anyone?).

But making it mandatory will be even worse in my opinion. This will result
in new "dummy" implementations aimed at people who don't need the feature.
We'll see the NULL crypts again and things like this. This will also easily
result in having users even more accustomed to click "I understand the risks"
when presented a security warning. Firesheep is just a joke right now, I'm
more concerned by malware running inside the browsers that are insensible
to encryption and authentication.

> Making compression optional isn't a security disaster 
> lost.

For web browsing yes, but right now HTTP is used for many other things.
One of my customer uses Curl to upload compressed log files every night
over HTTP. The added compression here will not bring anything at all.
Similarly, most downloads are already compressed files/images/etc...
Compression really is useful for many things but not for all. And it
comes with a cost.

> It was all reasonable at the time, but this is a new time. There 

In fact, I like the idea of having compression, encryption, etc... well
defined in the protocol, but negociated between parties. This way it's
possible to continue to use HTTP for things other than pure browsing
without the impact of unused or unwanted features.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 01:04:47 +0100

On Sat, Jan 28, 2012 at 10:37:33AM +1100, Mark Nottingham wrote:
> If we want HTTP/1.1 <-> 2.0 gateways, and we don't want to force them to know
> about individual header semantics, that implies that we can't really change
> header encoding, doesn't it?

Unless we clearly define the transformation operation, which might be
lossy and advertised as one operational limit to such gateways.

Just my 2 cents,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Jan 2012 11:08:12 +1100

> lossy and advertised as one operational limit to such gateways.

I don't think that's workable, at least for proxies, which aren't under the control of the client or the server. It also makes gateways (reverse proxies) really complex, as you'd have to configure them very specifically.

E.g., if I want to use a "foo" extension header that has non-ascii content, I'd have to teach every intermediary along the way about its syntax. 

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 01:22:33 +0100

> E.g., if I want to use a "foo" extension header that has non-ascii content, I'd have to teach every intermediary along the way about its syntax. 

But if we define that all headers have the same non-ascii encoding, there
is no need for teaching everyone in the chain, right ?

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Jan 2012 11:28:02 +1100

> is no need for teaching everyone in the chain, right ?

How do you transform those non-ascii headers to ascii when you convert the message to HTTP/1.1?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 00:37:35 +0000

In message <[email-masked]>, Mark Nottingham wri

>We're actually not too far from this, discounting the size requirement. 

Please understand that the size-requirement is crucial.

The current trend in "more text is better than less text" in
RFC-writing is killing internet standardization as a concept, because
implementing protocols become an increasingly onerous job.

In general, adding text rather than formal specifications generally
makes standards more prone to misinterpretation rather than less
clear.

>The current plan is to gather proposals and evaluate in a few months; if 
>we can't get consensus, the WG will stop HTTP/2.0 work.

Ok, that was nowhere to be found on your original proposed schedule
which just magically had a first draft in 4 months time.

>BTW, Mike's current proto-draft of SPDY weighs in at 44 pages.

Well, he'll have to edit down then.

(SPDY is an absolutely worthwhile prototype, but as Fred. P.  Brooks
cautioned:  "Always throw the prototype away, you will anyway.")

>"Do it my way, or it's not worth our time?" Really?

Not my way:  Jon Postels, Einstens & Antoine de Saint Exupery's way.

I hate to be nasty about this, but the fact that HTTPbis made
RFC2616s page-count double is a major fiasco in my eyes, and I do
not really consider the result an improvement over RFC2616 in any
significant way.

Yes, things have been clarified, and explained, but the matter
of the fact is that HTTP/1.1 sucks as protocol engineering, and
no amount of lipstick or explanations can change that fact.

We know HTTP/1.X is doing it wrong, and given compatibility
constraints, there's nothing we can do about it, and all the
time spent clarifying it, is just wasted IMO.

But HTTP/1.1 is also an incredibly entrenched protocol, and
that raises the bar significantly for HTTP/2.0.

If any protocol is going to be goldplated as "HTTP/2.0", it had
damn well better be simpler to understand, simpler to implement,
have less weird corner-cases AND be faster than HTTP/1.1 is.

Otherwise it will just be IPv4 vs. IPv6 all over again.

So lets see some lean and simple proposals which get the job done.

If we find one or more of them worthwhile, we'll go over it in the
WG and by the time we're done waving our flags and airing our
rocking-horses, it will have explode by a factor of three.

If we start out at 29 pages, that means we'll end just shy of
100 pages, which is a bit over the top, but livable.

Poul-Henning

PS: Feel free to call me a grumpy old man.  Having been on the long
ride from ITU-T X.xxx recommendations for OSI protocols over
SNMPv1/v2/v3 and IPv6, not to mention various other standardisation
debacles, I feel I have earned my opinions.

PPS: And don't forget that IT-"journalists" already have started
wetting their pants about "The Future of the INTERNET: HTTP/2.0"
and similar rubish.  Just wait until the WG misses its first
deadline:  "INTERNET FUTURE HANGS IN THE BALANCE" etc.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 00:38:38 +0000

In message <[email-masked]>, David Morris wri

>Adding mandatory zlib support would kill his product.

No it would not.  A NULL implementation of ZLIB is virtually no code
(and obviously gives no compression...)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 00:40:56 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>> Re HTTP/next: it would be good to collect a list of things we think we =
>should make progress on; not surprisingly, I'd nominate I18N for header =
>field values.
>

I18N in transport headers:  Forget it, it would kill performance if
done right, and do nobody any good if not.

I18N in content headers: Sure, be my guest.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Jan 2012 11:44:15 +1100

On 28/01/2012, at 11:37 AM, Poul-Henning Kamp wrote:

> I hate to be nasty about this

[ I smiled when I read this ]

> but the fact that HTTPbis made

I'll repeat that much of that is boilerplate (because we went from one document to seven), change logs (AHEM, Julian), and indices. And that in many places, we cut out substantial amounts of text (e.g., ~10 pages from p6). Anyway.

> So lets see some lean and simple proposals which get the job done.

I'm absolutely with you in spirit. However, an arbitrary number like "29" doesn't help; the WG can bias towards simplicity when selecting a proposal.

> debacles, I feel I have earned my opinions.

I get that.

> deadline:  "INTERNET FUTURE HANGS IN THE BALANCE" etc.

Whatever. If I had worried about looking foolish, I would have stopped a long time ago.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Jan 2012 11:52:47 +1100

+1

And to make it clear, part of the reason for calling for proposals is to avoid having every detail of their generation discussed on this list; we simply can't start from first principles and do a ground-up protocol design here. 

Regards,

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 28 Jan 2012 15:08:04 +1300

On 28/01/2012 1:40 p.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Mark Nottingham wri
> tes:
>

Skipping over I18N and its multiple charsets and going specifically to 
UTF-8 representation of the existing header could be an option though.

We already have a set of well defined transport headers with defined 
ASCII/UTF-8 interchangeable characters. New headers will have to 
consider whether they exist only on HTTP/2 links or also apply to HTTP/1 
links and choose relevant naming characters based on that. Transport 
being hop-by-hop this is a choice they can make safely.

The message and entity meta headers which cross hops  is where the 
problems occur by the bucket full. I somehow doubt it would be a good 
idea to make two distinct header formats, but who knows.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 28 Jan 2012 15:20:15 +1300

> Just a random question, will 2.0 support secure sockets the same way as 1.1 and will there be any causes for concern over how ssl is to be implemented for 2.0?

What do you mean "same way"?

Several of us want to kill CONNECT in it scurrent incarnation, but 
Upgrade: is pretty much mandatory for 2.0 to rollout across 1.x.

Port 443 has always just been HTTP-over-TLS protocol. Irrelevant which 
version of HTTP was being sent over the encrypted tunnel. I personally 
doubt that would change.

AYJ

---

From: "Jose Mathew Manimala" <[email-masked]>
Date: Sat, 28 Jan 2012 02:27:24 +0000

The reply cleared up my question, thank you for the reply :)
Thanks,
Jose

-----Original Message-----
From: Amos Jeffries <[email-masked]>
Date: Sat, 28 Jan 2012 15:20:15 
To: <[email-masked]>
Subject: Re: Rechartering HTTPbis

AYJ

---

From: patrick mcmanus <[email-masked]>
Date: Fri, 27 Jan 2012 21:47:53 -0500

Hey Willy,

On 1/27/2012 6:58 PM, Willy Tarreau wrote:
> concurrent connections on Linux,

that's impressive to be sure.

I presume when we get around to really discussing SPDY as a base 
proposal Google will share their experiences on what its like to deal 
with compressed headers in huge numbers of concurrent streams. One of 
the really good things about looking at SPDY is that there is 
significant code and operational experience with it - if only every WG 
endeavor were so lucky! My impression is that it is frankly no big deal, 
but on a really large volume that's just second hand information. One of 
the mitigators is that header compression normally uses 2KB windows and 
is quite effective with that fairly small amount of state. SPDY does 
allow bigger windows, but it would be reasonable in my mind to run some 
experiments and consider specifying something like 4KB or less for 
HTTP/2 if the results supported it.

Its worth noting that in SPDY header compression is mandatory to apply, 
but message body compression is only mandatory to implement. (i.e. if 
you receive it you have to decompress, and you can always generate at 
any time, but you are not required to generate). Knowing that this is 
always a possibility, regardless of what might have happened to a 
accept-encoding header in any kind of proxied environment, incents the 
compression of compressable data.

I'm ok with optional behaviors (such as compression) based on the data 
being transmitted. The implementation can take a look at the data and 
decide what the right thing to do is based on that (your compressed log 
example, most media formats, etc..). But I don't like optional behavior 
based on deployment context (i.e. no tls because I'm on a secure lan, 
I'm a back end server, etc..) .  That's a million times harder to get 
100% right imo.

I really believe users need to be able to depend on security and (at 
least header) compression being active. One of the lessons of HTTP/1 is 
that optional implementations of those things don't yield the right 
results for the web.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 07:49:00 +0100

> How do you transform those non-ascii headers to ascii when you convert the message to HTTP/1.1?

I would apply a lossy conversion (reverse-mapping between UTF-8 and 8859-1).
So whatever fits 8859-1 would correctly be mapped, and the rest would be lost
or quoted. I don't think it's that big an issue if this is a well-known
limitation. That said I agree with PHK that transport headers should be
left 100% ASCII to save performance.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 08:44:26 +0100

> not really consider the result an improvement over RFC2616 in any

I don't see this as a fiasco, quite the opposite in fact. We spent a lot of
time and used a lot of words enumerating corner cases and giving
recommendations in order to expose known corner cases. Precisely because the
original spec was not precise enough. If we'd had specific MUST/MUST NOT in the
original spec concerning strict parsing, multiple Host/Content-length header
processing, how to handle ranges or set-cookie, etc... http-bis would be much
smaller and possibly wouldn't exist. So I'm in favor for strict rules before
small size, even if the strict rules result in more pages. It's also important
to explain the intent of some unclear design choices so that when people
implement them, they don't blindly code something they can't even test but
instead they apply appropriate error processing for their context.

> no amount of lipstick or explanations can change that fact.

It will not change that fact but we're basically drawing a map of all known
landmines so that implementers save their legs. We all know how it sucks to
be an implementer and we all know that we're permanently tempted by this
tradeoff between complexity and usefulness resulting in "oh I don't need
that anyway, let's skip those 3 pages and cross fingers". That's why the
design intent is sometimes important to convince implementers to do something
apparently useless to save their butt.

> Otherwise it will just be IPv4 vs. IPv6 all over again.

IPv4 vs IPv6 is not a matter of spec size, but a matter of complexity to
convert a lot of application code which used to stuff IPv4 addresses into
integers and function return values (eg: inet_addr()).

> 100 pages, which is a bit over the top, but livable.

3 days ago I have printed p1, p2 and p7 on 2 per-page and 2 sides, without
the changelogs, to review the text. It's not that big, I carry it everywhere
with me and it's not even heavy. BTW  I think that the split is really a good
thing because we don't need all parts. Transport and contents are two things
different enough to be split.

> PS: Feel free to call me a grumpy old man.

Come on, your uptime is far from wrapping. I'm sure there is even a
fair number of participants with bit 6 set in this WG :-)

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 09:09:31 +0100

> (and obviously gives no compression...)

You can't decompress with no code, and if you need to decompress to parse
headers, that's an issue.

I must say I'm still worried with having to support zlib just in order
to be able parse transport headers !

Willy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 09:10:44 +0100

> My current thinking is that we'd re-charter separately for that.

Hm. Isn't it foreseeable that we'll have to tune P1 more anyway for a 
different on-the-wire format?

> If we want HTTP/1.1<->  2.0 gateways, and we don't want to force them to know about individual header semantics, that implies that we can't really change header encoding, doesn't it?

Indeed: and I think that's a problem with the plan.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 09:12:28 +0100

> done right, and do nobody any good if not.

How would saying that it's UTF-8 affect performance?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 08:13:25 +0000

>integers and function return values (eg: inet_addr()).

Nope.

IPv4 vs. IPv6 *is* all about providing no tangible benefit that
warrants the effort to "sidegrade".

We fought hard to get some variant of "ISP-independent hosting"
into the spec, ("anycasting" were one such idea) so that customers
would not be locked into a single ISP, but could buy bandwidth
where it were cheapest.

That feature got killed by certain big ISP's who could see where
it led, and pretty much as a result of that, the only feature IPv6
ever had that could entice people to install it were gone.

Look around you:  The IPv4 shortage has not led to wide-spread
migration to IPv6, people still perceive the marketplace a much
more sensible solution than a new protocol.

>Transport and contents are two things different enough to be split.

Yes, absolutely, and I think we should go the full mile in HTTP/2.0
and make it a *transport only* protocol, that is what that second
'T' means and we should stick to it.

For all the content stuff we can just point back to HTTP/1.1(bis).

>fair number of participants with bit 6 set in this WG :-)

Not many of them wrote an OSI TP4 stack before they were 25 :-)

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 09:13:51 +0100

On 2012-01-28 07:49, Willy Tarreau wrote:
>>>>>> If we want HTTP/1.1<->  2.0 gateways, and we don't want to force them to know

There is no quoting we can use, unless we define a new one...

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 08:15:19 +0000

>UTF-8 representation of the existing header could be an option though.

Which transport headers is it that you think need ASCII++ ?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 08:41:55 +0000

In message <[email-masked]>, Julian Reschke writes:
>On 2012-01-28 01:44, Mark Nottingham wrote:

>I just checked, and not counting change logs, collected ABNFs etc, we 
>went from ~180 to ~250.

	"Perfection is achieved, not when there is nothing more to
	add, but when there is nothing left to take away."
		-- Antoine de Saint-Exupery

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 08:28:33 +0000

>to be able parse transport headers !

Then only support HTTP/1.1, it'll be here for the next 20 years.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 08:13:32 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>I'm absolutely with you in spirit. However, an arbitrary number like 
>"29" doesn't help; the WG can bias towards simplicity when selecting a 
>proposal.

"Simplicity" doesn't dot it, "29" is a nice concrete number for
people to have in mind every time they dream up a new fantastic
"must have" feature.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 09:27:35 +0100

That includes stuff we adopted from other specs (RFC 2616, RFC 2817), 
new registries, examples, etc.

As far as I can tell, the actual amount of prose per protocol feature 
actually went down.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 09:24:12 +0100

Hi Julian,

> There is no quoting we can use, unless we define a new one...

This is what I was suggesting ; in fact, I suspect that along the design,
we'll have to take notes of issues we'll have to face for 2.0->1.1 gateways.
At one point we'll have to decide if some issues are serious and need be
addressed in 2.0 draft, or if they're minor enough to justify an RFC to
explain the best practices to apply on gateways to ensure a high level
of interoperability, possibly with minor tweaks on the 1.1 servers to
accomodate them.

Because I suspect that if it's just a matter of deciding that some char
encoding is lost or converted to a TBD quoted format, it's possible that
most 1.1 implementors won't care a dime and that remaining ones will be
able to apply minor code updates on their side in order to benefit from
2.0.

For me it's exactly the same principle as server-side coders who take
care of extracting the X-Forwarded-For header to get the real client's
address : just a minor tweak to make it easier to accept a gateway which
provides other benefits.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 09:52:21 +0100

On 2012-01-28 09:41, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Julian Reschke writes:

And then, quoting selectively is another matter :-)

"That includes stuff we adopted from other specs (RFC 2616, RFC 2817), 
new registries, examples, etc.

actually went down."

If you feel that any of what was added isn't needed then please follow up.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 10:28:38 +0000

>If you feel that any of what was added isn't needed then please follow up.

Ok, yes, let me follow up, which ironically is going to take
some length, because I probably have been a bit too brief
and summary during a stressed work-week.

As I said earlier:  I consider HTTP/1.1 a lost cause, and I think
the time spent trying to un-loose it has been wasted, except for
any lessons hopefully learned, about what not to do.

One of the main nightmares, if not THE fundamental mistake, of
HTTP/1.1 is the intermingling of transport and content.

The OSI protocols sucked, but there are some very tangible benefits
in sound layering which we hopefully should have learned from them.

The transport/content mixup is so fundamental in HTTP/1.1 that
most people don't even realize it, so here is a little quiz:

Which 3 tokens of this HTTP request is transport information:

	>>> GET / HTTP/1.1
	>>> Host: www.example.com
	>>> User-Agent: fetch libfetch/2.0
	>>> Connection: close

Answer: "HTTP/1.1", "www.example.com" and "close".

Everything else is content, including "GET".

The mixup happens because in HTTP/1.1 "GET" is also used to define
the transport semantics, for instance the precense/absence of object
bodies in the transaction.

That's just plain wrong: If you intend to send a body, there
should be a clear, dedicated transport indication of it.

HTTP is short for Hyper-Text TRANSPORT Protocol and while we cannot
do anything about the "Hyper-Text", (except be happy Tim didn't
come out with 10 years earlier: "Turbo-Text Tranport Protocol"
whould have been awful :-)  we can and should respect the TRANSPORT bit.

HTTP/2.0 should *only* be a transport protocol.

What the content is, and what its metadata makes it mean, is not a
transport issue and should be standardized separately from the
semantics of their transport across the net.

Separating transport from content does not have anything to do with,
nor does it affect or threathen the existence of caches, malware-scanners
or other value-add HTTP devices.  Those roles operate at the content
level, but like everybody else in the HTTP world, they have to move
their results with a transport protocol.

So cut to the bone, what HTTP/2.0 should be able to do is:

Need to have:
	1. Establish  connections
	2. Transmit unadultered objects each consisting of two 
	   transparent arrays of bytes: metadata + object
	3. Detect transmission failures.
	4. Be DoS resistant
Nice to have:
	5. Detect if HTTP/1.1 peer is HTTP/2.0 capable and upgrade.
	6. Multiplex multiple objects
	7. Pipeline multiple requests
	8. Optimize transmission wrt. bandwidth and latency. ("compression")
Off limits:
	9. Non-strict client-server model (security risk)
	10. Congestion control (That's TCP's job)
	11. Adaptation or conversion of objects (presentation, not transport)
	12. Maintain state across different connections (session, not transport)
	13. Authentication (session, not transport)
	14. Privacy/Security/Integrity (HTTPS/2.0, not HTTP/2.0)

Before anybody says "Heck I can do that in 3 pages", let me point
out that there are important and difficult technical issues to sort
out.

For starters, being DoS resistent (#4) is a lot harder than most
people think in a client-server scenario.

HTTP/1.1 interop (#5) needs some serious thought, because we don't
want to expend a RTT on it.  The easiest way is probably to make
the first transaction on a new TCP connection be HTTP/1.1 by default,
unless we already know that destination to be HTTP/2.0 able, in
which case the initial HTTP/1.1 transaction can be a costless
"UPGRADE".

We should not break the strict client-server model (#9), that would
just be asking for security holes and implementation complexity.

The "server push" people desire, can be simulated inside a strict
client-server model with multiplexing (#6) and transactions that
just never seem to end.

Providing security/integrity/privacy (#14) should go into a parallel
HTTPS/2.0 standard, which SHALL use the same fundamental "move
object+ metadata transparantly" model as HTTP/2.0, so that all the
RFC's about how to understand the moved objects don't have to care
about which transport is used.  The major trouble there is deciding
the issue of being able to route/load-balance HTTPS traffic one way
or the other.

If done right, along the lines above, HTTP/2.0 will be a big step
forward, in simplicity, efficiency and security, over HTTP/1.1's
transport part, and the speedup alone will give people plenty of
reason to upgrade.

SPDY offers a very credible bid on many of these points, but goes
far further than a transport protocol should in many other areas.

Therefore I belive that rubberstamping SPDY into HTTP/2.0 would
continue the most fundamental mistakes HTTP/1.1 suffers from.

For instance SPDY imposes structure on the object-metadata (2.6.7
HEADERS) and needlessly reimplements much of TCPs connection
management for each of the multiplexed "streams".

But if SPDY can do all that in 44 pages, I am only even more
convinced that a credible HTTP/2.0 can be done in 29 pages.

So get sharpen your pencils, and lets see some good proposals
for a Hyper-Text TRANSPORT protocol 2.0.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 11:32:01 +0100

> different on-the-wire format?

Elaborating...: even if we don't put "internet standard" on the charter 
we'll have to think about what do to with HTTPbis errata, plus the 
changes we may *want* to do in P1 to make it better work with a new wire 
format.

The simplest way to do that IMHO is to maintain new (minor) revisions of 
P1...P7 - we have the infrastructure (trac, tools, mailing list), and 
the right people (authors & reviewers).

As we did with HTTPbis we really don't need to know right now what 
standards level that output would get.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 11:35:17 +0100

On 2012-01-28 11:28, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Julian Reschke writes:

I appreciate the thoughtful answer, but what you list has nothing to 
with RFC 2616 vs HTTPbis.

I do agree that whatever is done better get the layering right. My 
conclusion although is different: calling something HTTP/2.0 which 
doesn't roughly address the same use cases would be totally confusing.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 10:45:27 +0000

>doesn't roughly address the same use cases would be totally confusing.

As "totally confusing" as HTTP/1.1(bis) ?  :-)

I don't think we have a choice in practice.

Either we chop this monster into bites we can understand or chew,
or we're wasting our time on a long interminable death-march towards
IPv6 adoption.

In terms of practical standards documents, a HTTP/2.0 RFC could
have a section which simply point back into HTTP/1.1bis and say
"Use these bits to interpret and understand the content+metadata
parts".  If/when later, the content+metadata part gets cleaned up
in dedicated RFCs, those RFC's will refer directly to the HTTP/2.0
RFC, less that section.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 11:50:52 +0100

On 2012-01-28 11:45, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Julian Reschke writes:
>

I don't find it totally confusing.

> or we're wasting our time on a long interminable death-march towards

We've been doing that; this is why we have 3 base documents and 4 
optional modules (your mileage wrt "base" and "optional" obviously varies).

> in dedicated RFCs, those RFC's will refer directly to the HTTP/2.0

Organization aside the question is whether things like methods, payload 
formats, and status codes are integral parts of HTTP/2.0. I think they are.

I *agree* with improving the layering, and maybe giving the transport 
layer a specific name, but "HTTP/2.0" it can't be.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 11:07:59 +0000

>formats, and status codes are integral parts of HTTP/2.0. I think they are.

I think they are not:  They are what is being transported, and
good transportation does not interfere with the goods being transported.

>layer a specific name, but "HTTP/2.0" it can't be.

I'm going to point you at that annoying 'T' and ask you what the
heck else HTTP/2.0 would be doing, but transporting ? :-)

That said, I don't particularly care about what the document or
protocol is called, because it has no user-visible impact if we do
our job right.

In fact, we can probably avoid a LOT of idle spin-cycles in the
"IT-press" by not naming anything "HTTP/2.0", ever.

Is "WTP" already taken ? 

... by anybody we care about ? :-)

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 12:19:25 +0100

On 2012-01-28 12:07, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Julian Reschke writes:

HTTP == "Hypertext *Transfer* Protocol".

> heck else HTTP/2.0 would be doing, but transporting ? :-)

See above. It would be only about transport we wouldn't have things like 
DELETE, PATCH, nor status codes like 307.

+1

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 11:37:45 +0000

>HTTP == "Hypertext *Transfer* Protocol".

TRANSFER transitive verb
   1 a: to convey from one person, place, or situation to another: move, shift
     b: to cause to pass from one to another: transmit, transport
     [...]

>DELETE, PATCH, nor status codes like 307.

Those are all things being transported, just like GET, PUT and 200
are and they are no different from a transport point of view, should
not be treated any different from a transport point of view, and
their interpretation and semantics should be standardized separately
from the transport, just like GET, PUT and 200.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 12:43:58 +0100

On 2012-01-28 12:37, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Julian Reschke writes:

Yes. People have known these to be defined by "HTTP" for ~20 years now. 
I see no reason to change that.

Best regards, Julian

---

From: "Markus Lanthaler" <[email-masked]>
Date: Sat, 28 Jan 2012 19:53:08 +0800

> from the transport, just like GET, PUT and 200.

Sorry to ask a (probably stupid) question in this context. Isn't HTTP
supposed to be an application protocol? Wasn't one main problems with SOAP
that it abused HTTP as a transport protocol?

--
Markus Lanthaler
@markuslanthaler

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 11:54:59 +0000

>I see no reason to change that.

As I said:  I'm not keen on calling anything HTTP/2.0

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 12:05:35 +0000

In message <00dc01ccddb3$69f96be0$3dec43a0$@[email-masked]>, "Markus Lanthal

>that it abused HTTP as a transport protocol?

That's a very pertinent question.

The first version of HTTP was clearly not a transport protocol since it
used TCP as transport protocol: One TCP connection for each
request/response.

But onto that were hacked the various "keep-live" hacks, which
suddenly turned HTTP a transport protocol, but without proper design
of semantics.

Without keepalive, there were/is no doubt about how you
find out if a request has a object-body.  But when the keep-alive
hack was added, they forgot to add a transport-header that said
"has body", instead implementations had to divine this from the
semantics of the request.

And from there it went downhill, into chunked encoding, transfer-encoding
and now various ridiculous proposals for how to bolt pipelining and
multiplexing onto the side.

This history is a good argument against calling the transport protocol
HTTP/2.0, but it not a good argument for not doing proper layering.

---

From: Petite Abeille <[email-masked]>
Date: Sat, 28 Jan 2012 13:57:13 +0100

> 		-- Antoine de Saint-Exupery

Non sequitur:

"Grown-ups never understand anything for themselves, and it is tiresome for children to be always and forever explaining things to them."
-- Antoine de Saint-Exupéry

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 14:40:10 +0100

> Everything else is content, including "GET".

It's not that black and white nowadays. Many sites "route" by URI,
meaning the "/" is also part of the transport to some extent (eg:
route to static servers rather than application servers).

> HTTP/2.0 should *only* be a transport protocol.

I don't think so because it will not solve current issues and will
not even replace what HTTP initially was (remember HTTP/0.9 that was
only able to retrieve a file without any header nor anything related
to transport ?).

However I think that there should be several very clear layers in HTTP2, so
that we get rid of this mixup and ensure that intermediaries can focus on
their own job without caring about upper layers. Right now I've identified
(from top to bottom) :

     4- payload         -> path, content-types, etc...
     3- session         -> cookies, user info, auth
     2- scrambling      -> TLS or whatever comes next
     1- transport       -> MUX, pipelining, keep-alive

We also still want to support untrusted proxies (eg: your ISP's), so it
is possible to stack layers 1, 2, 3 below this when talking to proxies :

 proxy  < 4- payload         -> path, content-types, etc...
   to   < 3- session         -> cookies, user info, auth
 server < 2- scrambling      -> TLS or whatever comes next
  ----  < 1- transport       -> MUX, pipelining, keep-alive
 client<  3- session         -> cookies, user info, auth
   to  <  2- scrambling      -> TLS or whatever comes next
 proxy <  1- transport       -> MUX, pipelining, keep-alive

Obviously some layers are not always present. For instance, if you acces
a proxy without any need for authentication, you might want to use only
layer 1 to talk to the proxy on top of which you can stack 1-to-4 to
communicate to the server. That also fits very well Adrien's proposal of
"GET https://".

The big benefit I see with such a layering is that it's easy to split it
into 4 parts which are worked on in parallel by different teams. For
instance I'm a total loser when it comes to contents and I'm sure the
cache and content filtering guys know that much better than me. However I
have my views on current shortcomings at the transport layer which need
to be addressed (eg: bad interaction with TCP due to congestion control
or early RST on close), and on what costs a lot to products operating at
this layer.

> So cut to the bone, what HTTP/2.0 should be able to do is:
(...)
For me this is layer 1 above. As long as you're interested in working
on this layer, you can then let other people work on the other layers
without declaring them useless.

> people think in a client-server scenario.

Agreed!

> which case the initial HTTP/1.1 transaction can be a costless

I too vouch for the Upgrade method, it's cheap, compatible and saves
one round trip thanks to the "1xx is not final" statement :-) It even
allows the server to respond with 2.0 semantics.

> client-server model with multiplexing (#6) and transactions that

That can be left to WebSocket which is already handling this after
an 1.1 Upgrade too. In fact 1.1 could be the common point to upgrade
to newer protocols.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 28 Jan 2012 14:09:36 +0000

>route to static servers rather than application servers).

They're welcome to do so in the future as well, but it should be
clearer for everybody involved that they are rounting based on
the request content then.

The reason I made the URI part of object-metadata, is that it
may need security/privacy/integrity protection.

>     1- transport       -> MUX, pipelining, keep-alive

I generally agree, but I'm not sure if 1&2 are above/below or side-by-side.

That question really boils down to if the Host: header is privacy
protected or not.  This becomes a particularly intricate dance once
anonymising proxies are involved.

If Host: should have privacy, then HTTPS, as we know it, where the
entire TCP connection is encrypted, is the answer.

If Host: should not have privacy, in order to allow traffic directors,
load-balancers and similar to dispatch secure traffic without terminating
the crypto-session, then a payload-only SSL scheme would be preferable.

I'm in no position to make a call on this.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Jan 2012 15:20:35 +0100

On Sat, Jan 28, 2012 at 02:09:36PM +0000, Poul-Henning Kamp wrote:
> >Many sites "route" by URI,

Indeed.

> may need security/privacy/integrity protection.

Yes, I know.

> anonymising proxies are involved.

Right now there is no privacy on the Host header since it's advertised in
clear text over TLS/SNI (and used as such at some sites to route to the
appropriate farm without having to decipher the stream). I would really
put the Host in the transport layer to avoid any of the current issues,
such as servers which believe this already works this way and trust the
connection instead of the request.

> the crypto-session, then a payload-only SSL scheme would be preferable.

Payload + session, as cookies are used for many things but are sensitive.
I'd really like to have other session indications in the lower layers so
that we don't need to decipher SSL anymore to find the proper server in a
load-balanced farm. That's what's been discussed for IPv6 flow labels [1]
BTW and would avoid the current mess where load balancers are the single
non-scalable point where SSL has to be deciphered just for this. We could
have the transport carry a "public session ID" for instance or even simply
a "public session cookie".

Regards,
Willy

[1] http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance-01

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 28 Jan 2012 16:32:24 +0100

> I'm in no position to make a call on this.

Keep in mind that when using TLS on most widespread UAs (i.e. Safari, Chrome, Opera, IE, curl) the server host name is in any case made available in cleartext through SNI in the handshake.
I fear that to avoid that, some change to the TLS spec would be required.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Jan 2012 12:03:15 +1100

> whould have been awful :-)  we can and should respect the TRANSPORT bit.

Actually, it's not. It's been "transfer" from day 1 (e.g., <http://www.w3.org/Protocols/HTTP/AsImplemented.html>).

---

From: Karl Dubost <[email-masked]>
Date: Tue, 31 Jan 2012 10:54:42 -0500

> Although Google with SPDY have proven that new protocols can be deployed.

In which (pragmatic) ways?
I do not count a controlled end-point (chrome) to end-point (Google servers) as deployment in a distributed infrastructure.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

---

From: Karl Dubost <[email-masked]>
Date: Tue, 31 Jan 2012 11:00:09 -0500

Le 27 janv. 2012 à 17:42, patrick mcmanus a écrit :
> All the folks running computers in their pockets with 4000x that memory deserve an experience with always on encryption and compression to deal with the high latency mobile world we're looking at.  Just one vendor, Apple, shipped 93 million such devices last year .

Which is a world small market share. You have to take into account the world handset market shares. I think Nokia and Samsung are still leading the pack and most of them are not so called smartphones.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 31 Jan 2012 10:08:11 -0800

Oops, resend from right address.
On Jan 31, 2012 9:56 AM, "William Chan (陈智昌)" <[email-masked]> wrote:

> On Jan 31, 2012 7:56 AM, "Karl Dubost" <[email-masked]> wrote:
> >
> >
> > I do not count a controlled end-point (chrome) to end-point (Google
> servers) as deployment in a distributed infrastructure.
>
> Firefox 11 supports SPDY too. There are non-Google SPDY servers too.
> Strangeloop and Cotendo and others support SPDY too for example. What do
> you mean by controlled endpoint?
>
> >
> > --