Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication

Willy Tarreau <> Fri, 27 April 2012 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B76B521F876A for <>; Fri, 27 Apr 2012 02:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.867
X-Spam-Status: No, score=-9.867 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 80I8kveAipol for <>; Fri, 27 Apr 2012 02:31:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2612C21F8767 for <>; Fri, 27 Apr 2012 02:31:30 -0700 (PDT)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1SNhUm-0007si-2Y for; Fri, 27 Apr 2012 09:29:44 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1SNhUd-0007QG-Ub for; Fri, 27 Apr 2012 09:29:36 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1SNhUa-0000hH-Hs for; Fri, 27 Apr 2012 09:29:33 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q3R9T8YU020662; Fri, 27 Apr 2012 11:29:08 +0200
Date: Fri, 27 Apr 2012 11:29:08 +0200
From: Willy Tarreau <>
To: Nicolas Mailhot <>
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01
X-W3C-Scan-Sig: 1SNhUa-0000hH-Hs 58537175197f98a467ef8b45e6890b85
Subject: Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication
Archived-At: <>
X-Mailing-List: <> archive/latest/13488
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Fri, 27 Apr 2012 09:29:44 +0000

Hi Nicolas,

On Fri, Apr 27, 2012 at 09:16:00AM +0000, Nicolas Mailhot wrote:
> Hi,
> Would it be possible to publish a list of specific questions and have each
> proposal submitter answer how its proposal answers each of them? Just to make
> sure no use-case falls through the cracks? Sure one can read each proposal and
> guess the answers, but I think proposal submitters are the best to answer how
> their proposal could be used. And this way one won't have to fish list archives
> for answers to common questions.

I'm not sure this will help make great progress in the short term (only 1.5
month is left for proposals, and working on them takes a *lot* of time).

> I'd especially like an answer to the following:
> 1. Can the proposal permit secure http/2.0 communication without letting malware
> punch random protocols through firewalls using the http/2.0 secure port?

You'll never ever be able to guarantee this. Malware can use whatever
encapsulation they need. Some communicate via text messages on twitter.
The rule is simple : if at least one bit can leave a place, it is possible
to communicate with the outside world. So this is totally out of the scope
of future designs.

> 2. How can intermediary network nodes request (re-)authentication on secure
> networks when client credentials expire?

Unless I miss your point, that's what the 401 is about, no ?

> 3. How can they communicate authentication location to the client (or is it
> implied and how)? Does this mechanism work for dumb (not-browser) web clients?
> 4. How could other intermediary messaging be handled?

I'm not sure I get these points.

> 5. Is the proposed protocol feature-complete or does it require an http/1.1
> downgrade to handle some existing http use-cases (esp. proxy ones)?

It needs to be able to completely replace it otherwise it will mean much
more work for many implementers, leading to many more bugs and interop

> 6. Is the http/2.0 namespace a superset of the http/1.1 namespace? Are error
> codes specific to the protocol version used or should it be assumed they'd apply
> the same if the protocol was up/down graded?

Since we have to be able to be able to transport 1.1 over 2.0 with "reasonable
fidelity", I think we should at least be able to adopt the existing namespace
whatever it's encoded.

> 7. How will the proposal make writing tools that process HTTP headers and logs
> simpler? Does it reduce HTTP reliance on conventions not commonly used in
> mainstream application writing?

This depends on proposals but it seems like everyone agrees that right now
the syntax is too lax and that we must make it a bit more strict.

> 8. Does it add specific logging constrains that didn't exist in http/1.1?

Logging is out of the scope of HTTP in my opinion as it's an implementation

> 9. How will the proposal improve network efficiency?

At least by reducing message sizes, packet counts and connection counts.