Re: adding Header Continuation

Mark Nottingham <mnot@mnot.net> Tue, 28 May 2013 05:36 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 5DA7721F86C0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 May 2013 22:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 9IHomr-9O9eJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 May 2013 22:36:29 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8321F8629 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 27 May 2013 22:36:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhCXM-0001aY-8T for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 05:33:32 +0000
Resent-Date: Tue, 28 May 2013 05:33:32 +0000
Resent-Message-Id: <E1UhCXM-0001aY-8T@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UhCX4-0001ZB-N4 for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 05:33:14 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UhCWv-0008AP-9m for ietf-http-wg@w3.org; Tue, 28 May 2013 05:33:14 +0000
Received: from [192.168.1.80] (unknown [118.209.184.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BD18722E1F4; Tue, 28 May 2013 01:32:42 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAP+FsNeZ_TyWhitMo4qKkQuN3P8sDcePY7HUHANyRYADNdtH4g@mail.gmail.com>
Date: Tue, 28 May 2013 15:32:37 +1000
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF6DFE02-4E37-4F01-8BEA-4B40430D83BB@mnot.net>
References: <F052EE82-6AD0-4A4B-924E-7A01D71A4037@mnot.net> <CABkgnnVAFbDZAV1NR71in6qOxgN2cmeUdjYfmQYagCGW4Z6kMw@mail.gmail.com> <CAP+FsNeZ_TyWhitMo4qKkQuN3P8sDcePY7HUHANyRYADNdtH4g@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.398, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UhCWv-0008AP-9m 561332afe384f7e57c9ca373716b01e7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: adding Header Continuation
Archived-At: <http://www.w3.org/mid/DF6DFE02-4E37-4F01-8BEA-4B40430D83BB@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18101
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>

OK, that sounds separable. I'm accepting the pull request and opening an issue to track the effect of headers on compression context <https://github.com/http2/http2-spec/issues/102>. 


On 21/05/2013, at 5:07 AM, Roberto Peon <grmocg@gmail.com> wrote:

> Further expounding:
> 
> The contents of header frames MUST be processed by the compression context, even when the stream has been reset. If this is unacceptable, the receiver MAY terminate the session with the appropriate error code indicating why.
> 
> In other words, yes, agreeing about the fact that state must be sync'd.
> The above is useful even when a max size has been negotiated, since servers may decide to reset streams for many reasons
> 
> 
> 
> -=R
> 
> 
> On Mon, May 20, 2013 at 10:02 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 19 May 2013 20:29, Mark Nottingham <mnot@mnot.net> 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.
> 
> --Martin
> 
> 

--
Mark Nottingham   http://www.mnot.net/