Re: adding Header Continuation

Martin Thomson <> Mon, 20 May 2013 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E28A921F93C8 for <>; Mon, 20 May 2013 10:04:12 -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 0F6tN+ipEmWD for <>; Mon, 20 May 2013 10:04:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 90C0121F935E for <>; Mon, 20 May 2013 10:04:04 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UeTUh-0005YW-GO for; Mon, 20 May 2013 17:03:31 +0000
Resent-Date: Mon, 20 May 2013 17:03:31 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UeTUV-0005WI-Uo for; Mon, 20 May 2013 17:03:19 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UeTUU-0001EW-Uf for; Mon, 20 May 2013 17:03:19 +0000
Received: by with SMTP id p58so2180537wes.7 for <>; Mon, 20 May 2013 10:02:52 -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:content-transfer-encoding; bh=hqJmp9HoFjKdmfq/ElW3jOAZ09LpUO5O4lGBL8/5DE4=; b=y4fj7iPzWRedv4h7UbOrDO2+/x9hEXmVp2a8haeTZJRG2FdlCAVEOkvkCQQOXZWDqS 8BEM027ROPqRTPdmlbF9qwoze3FcfkmHOmkpfnGGkyZRrcfuI4HFCiE7DbEn0RSja237 pPRz4b6LTX0jS8gDHIB9XytJAEiPjjEdQupENxVBuV3RjhpkJcI0WFKWs7jS20luf0Eq IKfMdncbW15Tea6ttpkUUoC0jPrIXz7V7eBqe4Z9fmWSrdTB9gXV4ygzPZauuT15hXV7 9YS3lLIenpNGLB3D8N0jfIz6SaezNTPz1/fV1OfDGqCZpx+BbBdauVnkJ5pdnKoes30u alIQ==
MIME-Version: 1.0
X-Received: by with SMTP id gn1mr15767504wib.5.1369069372117; Mon, 20 May 2013 10:02:52 -0700 (PDT)
Received: by with HTTP; Mon, 20 May 2013 10:02:52 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 20 May 2013 10:02:52 -0700
Message-ID: <>
From: Martin Thomson <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.688, 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: 1UeTUU-0001EW-Uf 2b3af5427da7be1b211f442126b931ae
Subject: Re: adding Header Continuation
Archived-At: <>
X-Mailing-List: <> archive/latest/18041
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 19 May 2013 20:29, Mark Nottingham <> wrote:
> Without going into the fine details of the text, are we ready to have such a thing?

Yes.  But.

I think that we need to be a little clearer on what happens when size
limits are exceeded.

grmocg wrote:
> If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.

Resetting a stream isn't going to be possible, unless the receiver
first applies any changes to local compression state.  I remain
concerned that the header compression scheme will need to deal with
the same issue.

I'd like to see a discussion resolve on what strategy(ies) we want to
permit for dealing with bad peers for oversized stuff, for this and
perhaps also frames in general.  A generally applicable strategy seems
plausible.  In that discussion we should cover whether we permit the
declaration of size limits.