Re: Editorial Issues: Section 4.2.2

Martin Thomson <> Wed, 24 April 2013 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C193221F8D92 for <>; Wed, 24 Apr 2013 11:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[AWL=3.599, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s2Yxe-6YQ1uK for <>; Wed, 24 Apr 2013 11:14:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E1B321F8D31 for <>; Wed, 24 Apr 2013 11:14:48 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UV4Cl-0007SY-Dt for; Wed, 24 Apr 2013 18:14:07 +0000
Resent-Date: Wed, 24 Apr 2013 18:14:07 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UV4Ch-0007QN-7b for; Wed, 24 Apr 2013 18:14:03 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UV4Cc-0006WA-35 for; Wed, 24 Apr 2013 18:14:03 +0000
Received: by with SMTP id ed20so1897735lab.17 for <>; Wed, 24 Apr 2013 11:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QFrsx/VsAnS2YZ5w6jTI72aHB0TLZtseCg1IQ4KyFoA=; b=R4jZYeO4hPEtOaWVNNENOa3EhaVctFZ4XE9nXUkjbfQqfqajLYMPsnmurx7xGc40Tj qXlMQA/NFLOVAiREYD7kHDqPxp1gs9RW/nUkypNJSPQl54kpEKYLAgpqxjpmL9H8t1py pB1kEwbg6jOQaA4J5KhGzRBX2/6bR9jEgklQO5dk/C/dlVHSQ4DhGUIgCVwE+Thh7llE mHePajPQ29Itk9Vvs+bi9Sw/jBtwXfN/6ysGjky7Z3pcgFwcFmCqHEsZFogkhzw3fMKb zljjizufEknghJFouCk/PB09FTkgOXWy78JvEgkQKt8fqc7Byhy5t1/G/WzUMsz7QoE/ xf5Q==
MIME-Version: 1.0
X-Received: by with SMTP id ob8mr18144793lbb.55.1366827211459; Wed, 24 Apr 2013 11:13:31 -0700 (PDT)
Received: by with HTTP; Wed, 24 Apr 2013 11:13:31 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 24 Apr 2013 11:13:31 -0700
Message-ID: <>
From: Martin Thomson <>
To: James M Snell <>
Cc: "" <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.696, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UV4Cc-0006WA-35 602203b2c5e484f492280053ace2d0fb
Subject: Re: Editorial Issues: Section 4.2.2
Archived-At: <>
X-Mailing-List: <> archive/latest/17550
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hey James,

On 24 April 2013 10:11, James M Snell <> wrote:
> Recommend reworking this to:
>   The following fields MUST be present in all HTTP requests:
>   ":method":  the HTTP method for this request (e.g.  "GET", "POST",
>   "HEAD", etc) ([HTTP-p2], Section 4)
>   ":path":  the request-target for this URI with "/"
>   prefixed (see [HTTP-p1], Section 3.1.1).  For example, for
>   "" the path would be
>   "/search?q=dogs". [[anchor26: what forms of the HTTPbis
>   request-target are allowed here?]]
>   ":host":  the host and optional port portions (see [RFC3986],
>   Section 3.2) of the URI for this request (e.g. "
>   1234").  This header field is the same as the HTTP 'Host'
>   header field ([HTTP-p1], Section 5.4).
>   ":scheme":  the scheme portion of the URI for this request (e.g.
>   "https")

Feel free to send a pull request for this.  I see no reason not to
make this sort of change.

There are a lot of less obvious edits of this nature.  From my
perspective, there are too many to fix at once.  For instance, the
entirety of Section 5 needs to be moved to more relevant locations.

There's no reason why you can't just raise an issue or pull request
for editorial stuff that bugs you.

> Also, I recommend removing the additional requirement given in the
> paragraph that follows:
>   All header field names starting with ":" (whether defined in this
>   document or future extensions to this document) MUST appear before
>   any other header fields.
> The challenge with this is that if we go with any of the proposed
> Delta-based header encoding schemes currently on the table, it is
> difficult to ensure that : prefixed headers are encoded first in the
> header block. It may even be counter productive to the task of
> producing an optimized serialization.

I'm going to suggest that we defer this and remove it when we edit in
header compression, if necessary.  There may be a way to retain this
property.  For instance, we might require operations on ':'-headers to
occur before non-':'-headers.  That might not surface in some
implementations (I wouldn't see why this is something that you would
preserve in your Java implementation, it's just unnecessary
complication), but it might make a routing intermediary marginally
more performant.