Re: question on non header block data of chained HEADERS and PP

James M Snell <> Mon, 29 July 2013 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8862021F96A8 for <>; Mon, 29 Jul 2013 13:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y-0vuR+WjTsc for <>; Mon, 29 Jul 2013 13:58:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 226AB21F9980 for <>; Mon, 29 Jul 2013 13:58:01 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1V3uTk-0006sv-Pj for; Mon, 29 Jul 2013 20:55:40 +0000
Resent-Date: Mon, 29 Jul 2013 20:55:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1V3uTZ-0006ri-Kg for; Mon, 29 Jul 2013 20:55:29 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1V3uTT-0000at-15 for; Mon, 29 Jul 2013 20:55:29 +0000
Received: by with SMTP id f4so14368004oah.35 for <>; Mon, 29 Jul 2013 13:54:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WOCtmGLZgdv+F14fkvx5XnnKdGColTsZGimC11oyLyk=; b=F1XUONbLNaAsPF4qN5Bh30sLMIdYxE7SS1uIbv3OeKkxT6qdFUkYlyV4PjidHYfbVE nAJVcD6RFPAGumS/6cwSmVf6e8jxIg6stW6AJ3Cs+1XbkX+OLbYzrZg98sFwgsxxAS8L uUnX083HlG1BftoEE4aTXiaepwhxnjcoTIjc3etoaAaZ61jBFqh2uforDZQCJ+2tbIhA z2CoeeF+qc8i/YNxFTiL9IcbiUG7ZB9N9OSP0ERVDyZ3RGGLoAXTfyl8S8Pg7C2qCRfN Y/h3HLya8xeCDwEF086JnKUTOFaIA+wQjlYiSaGqOCzH1H4cPzO0YyoSUMSmG9ztTzDj wxrg==
X-Received: by with SMTP id g7mr59100112oep.18.1375131295482; Mon, 29 Jul 2013 13:54:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 29 Jul 2013 13:54:35 -0700 (PDT)
In-Reply-To: <>
References: <>
From: James M Snell <>
Date: Mon, 29 Jul 2013 13:54:35 -0700
Message-ID: <>
To: Patrick McManus <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-1.753, BAYES_00=-1.9, 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: 1V3uTT-0000at-15 3460e83f68211a38bad19972c2711920
Subject: Re: question on non header block data of chained HEADERS and PP
Archived-At: <>
X-Mailing-List: <> archive/latest/18964
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

When going through the implementation on this, I couldn't help but
think that a special-purpose continuation frame type would actually be
best here.. to keep this kind of issue from coming up at all.

Right now, if I send a header block that needs to be split across
multiple HEADERS frames, there is some ambiguity about whether the
frame header of each of those HEADERS frames need to be identical
other than the END_HEADERS flag. If the HEADERS frame contains the
Priority field, does the priority field need to be set in every
continued HEADERS frame? Does the value need to be the same? If I
change the Priority value in each does it change the priority each

Similar issue with the PUSH_PROMISE...

...It's also a bit wasteful of bytes on the wire (e.g. if I sent
continued PUSH_PROMISE frames, every one would be required to contain
the 4-byte promised stream identifier even tho really really only need
the first frame in the sequence to have it).

It would almost be (just a bit) easier to have a special
CONTINUED_HEADERS frame type such that... If I send a HEADERS frame
where END_HEADERS is NOT set, the next N-frames MUST be
CONTINUED_HEADERS until END_HEADERS is set. The only flag on
CONTINUED_HEADERS is END_HEADERS and the payload is a header block
fragment only. Likewise with PUSH_PROMISE.. if I send a PUSH_PROMISE
frame where END_HEADERS is NOT set, the next N-frames MUST be

On Fri, Jul 26, 2013 at 11:14 AM, Patrick McManus <> wrote:
> HEADERS and PUSH PROMISE can have their header block fragmented among
> multiple contiguous frames. That's clear.
> For PP I'm a ltitle unusure how Promised-Stream-ID fits into those
> fragments. Is it present in all of them? the frame diagram seems to assert
> that it is present in every PP frame, but the definition of END_PUSH_PROMISE
> says "the payload of all PUSH_PROMISE frames are concatenated and
> interpreted as a single block". and the Promised-Stream-ID is definitely
> part of the definition of payload (which we have defined as everything after
> the first 8 bytes of frame header).
> The right thing is probably that it is present in all of them, but is not
> considered part of the payload for purposes of determining the header block.
> A clarification seems needed. If that's right, do we need a rule saying the
> Promised-Stream-ID must be the same across all the fragments?
> I think HEADERS has a similar problem with Priority.. it uses a "payload"
> definition of the headers block that would include priority (but
> shouldn't)...
> -Patrick