Re: HTTP/2 Expression of luke-warm interest: Varnish

On Jul 16, 2012, at 10:59 AM, Mark Nottingham wrote:

> 
> On 16/07/2012, at 4:43 PM, Poul-Henning Kamp wrote:
> 
>> In message <4C9C45EE-57B6-49FE-A475-B46BE192A221@mnot.net>, Mark Nottingham wri
>> tes:
>> 
>>> Much of your commentary seems to assume that we're now deciding what 
>>> HTTP/2.0 will be; in fact, we're choosing a starting point for further 
>>> work. 
>> 
>> No, my commentary is based on the experience that if you pick
>> a starting point, without first defining the problem(s) you are
>> trying to solve and the goal(s) you are trying to reach, then
>> that starting point is where you are going to end up. 
> 
> The goals were defined in our current charter:
>  http://datatracker.ietf.org/wg/httpbis/charter/

Those are not goals. Quoting the first part of this:

   There is emerging implementation experience and interest in a protocol that 
   retains the semantics of HTTP, without the legacy of HTTP/1.x message framing 
   and syntax, which have been identified as hampering performance and encouraging 
   misuse of the underlying transport. 

   As such, there is an opportunity to create a new major 
   (non-wire-compatible) version of HTTP. 

   To do this, the Working Group will solicit candidates for this work from 
   the community, to be submitted as Internet-Drafts…

It doesn't say what these HTTP/2 candidates are supposed to do. All it says is:
 - they must retain HTTP semantics
 - they don't have to keep the message framing and syntax

Those are constraints, not goals. The charter doesn't even go so far as to specify "make web pages load faster" as a goal, or "better use of bandwidth", or even "prioritization of resources"

While we all seem to be working on the assumption that those are the goals, they're not stated anywhere. This is why we keep having discussions about whether server push is a MUST or a MUST NOT, and whether we need transport layer of application layer security, and whether those should be part of this proposal.

The popularity contest is not all bad. It gives us a much lower chance of failure, but PHK is right. Once we accept SPDY as the starting point of HTTP/2, changes are going to be minimal, because of all the running code and install base. While Chrome and Firefox update often, many servers hardly ever get updated. We'd need a very good reason for any departure from what SPDY/3 currently is, especially for any change that is not backwards compatible with the current SPDY.

Yoav

Received on Monday, 16 July 2012 08:54:25 UTC