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

Willy Tarreau <w@1wt.eu> Fri, 27 April 2012 09:31 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76B521F876A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 27 Apr 2012 02:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.867
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80I8kveAipol for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 27 Apr 2012 02:31:30 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2612C21F8767 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 27 Apr 2012 02:31:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SNhUm-0007si-2Y for ietf-http-wg-dist@listhub.w3.org; Fri, 27 Apr 2012 09:29:44 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <w@1wt.eu>) id 1SNhUd-0007QG-Ub for ietf-http-wg@listhub.w3.org; Fri, 27 Apr 2012 09:29:36 +0000
Received: from 1wt.eu ([62.212.114.60]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1SNhUa-0000hH-Hs for ietf-http-wg@w3.org; 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 <w@1wt.eu>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20120427092908.GA20042@1wt.eu>
References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <loom.20120427T104110-359@post.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20120427T104110-359@post.gmane.org>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
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: maggie.w3.org 1SNhUa-0000hH-Hs 58537175197f98a467ef8b45e6890b85
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication
Archived-At: <http://www.w3.org/mid/20120427092908.GA20042@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13488
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1SNhUm-0007si-2Y@frink.w3.org>
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
issues.

> 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
choice.

> 9. How will the proposal improve network efficiency?

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

Regards,
Willy