Re: HTTP router point-of-view concerns
Roberto Peon <grmocg@gmail.com> Thu, 11 July 2013 19: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 08E8121E804D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 12:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.534
X-Spam-Level:
X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bQm97XyV-3na for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 12:36:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9D38D21E804C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 11 Jul 2013 12:36:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UxMew-00085A-4z for ietf-http-wg-dist@listhub.w3.org; Thu, 11 Jul 2013 19:36:10 +0000
Resent-Date: Thu, 11 Jul 2013 19:36:10 +0000
Resent-Message-Id: <E1UxMew-00085A-4z@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UxMen-00084G-PD for ietf-http-wg@listhub.w3.org; Thu, 11 Jul 2013 19:36:01 +0000
Received: from mail-ob0-f182.google.com ([209.85.214.182]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UxMem-0008QD-Lz for ietf-http-wg@w3.org; Thu, 11 Jul 2013 19:36:01 +0000
Received: by mail-ob0-f182.google.com with SMTP id va7so10560898obc.27 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2013 12:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9FU43TBcrFVQiCDB5AblY19hDj6S9oasodTK4n7StlM=; b=cFK/1gVxe6V8+3FkBe11jjlWDpSd5e2ARU6o20oo1yd4mXDjzX+vhSEVq9vZgqPWBP Ls7kDc9vsNVF3MZ5YnVdh/AFVRXscAv2xDlwXnUzsuB6cMX3AjmXcIbqKc35Thui1qDv kh1qf4n8tDsJQEWzpuHcKk9C12McXVDrJAAl8ZdR48ZBBUX3pZksoXPUVbO8Yk6suJXJ jkKpvnRbPjeL9sQ6W0/dk2cv5kKTTubl14XradxALJMiYWKn7v9o5ItXT3Ym6zGPFwZa vYMZ1CUuLXsAy8yPlQ1j3fAuwPoDS9FPSmi8QPKYEo9vLv2cBL/LNUB2odlv3oDrH0L9 hFxw==
MIME-Version: 1.0
X-Received: by 10.182.171.74 with SMTP id as10mr32738474obc.70.1373571334616; Thu, 11 Jul 2013 12:35:34 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Thu, 11 Jul 2013 12:35:34 -0700 (PDT)
In-Reply-To: <CABP7RbcUkLf3CTAB4jwicnsiKWLGVY6=hX0k=0256SR_gcVt9A@mail.gmail.com>
References: <CA+qvzFPUpcm6kUtJx+rTw8Dpp4Gtx4Bmr3XPDhjNsjchUfN9_w@mail.gmail.com> <51DE1E32.9010801@treenet.co.nz> <CAP+FsNdcYhA=V5Z+zbt70b5e7WmcmXgjG5M9L3vfXeXfTwmRnw@mail.gmail.com> <51DE327C.7010901@treenet.co.nz> <CABkgnnXeqD6wh0dcJ1Dz=4PLAJNkDeGcCuzMr9ATd_7xS7nbGQ@mail.gmail.com> <CABP7RbcUkLf3CTAB4jwicnsiKWLGVY6=hX0k=0256SR_gcVt9A@mail.gmail.com>
Date: Thu, 11 Jul 2013 12:35:34 -0700
Message-ID: <CAP+FsNcOZnLa9GCr6XcZNFdq-mSXG6Q-_1Lb5u=a2YyXNCsVfQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="e89a8ff25454793d5504e1417f68"
Received-SPF: pass client-ip=209.85.214.182; envelope-from=grmocg@gmail.com; helo=mail-ob0-f182.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.689, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UxMem-0008QD-Lz 68909f7f5b68e54fdaea129cb1355bfe
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/CAP+FsNcOZnLa9GCr6XcZNFdq-mSXG6Q-_1Lb5u=a2YyXNCsVfQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18701
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>
I think it is perfectly reasonable for an intermediary to set the compression size to zero if it wishes. Market forces will (in the long-term) pick the correct strategy for this-- assuming the compression is effective at reducing latency, and that people care about latency reductions, then eventually intermediaries might evolve to use it. If it is ineffective at reducing latency, or if reduced latency is not actually desirable, then intermediaries would not use it. The DoS vector you're talking about is not a DoS vector if the intermediary resets all streams before the change-of-state-size comes into effect. When the state size is 0, one should be able to use some kinds of 'indexed' representations, so long as those representations refer only to items in the static tables. Why do you believe that this would use more or less CPU? (It should use less CPU and less memory...) Headers are unbounded in HTTP. If any header is too large, there are only two options: 1) terminate the connection 2) send a RST for that request and shove the bytes through the compressor. This can be done in a streaming fashion so long as the recipient is smart enough to tease out the instruction boundaries (not too hard, and certainly no more difficult than interpreting HTTP/1.0 header fields). Assuming that the state size is 0, these bytes can instead by discarded and do not need to be interpreted at all. On Thu, Jul 11, 2013 at 10:14 AM, James M Snell <jasnell@gmail.com> wrote: > Yes, the ability to set compression context size to 0 is very useful. > My fears around this area are: > > 1. In order to achieve maximum throughput, Intermediaries may opt to > *always* set compression context to 0, forcing the headers to always > be passed as Literals, killing the utility of having the header > compression mechanism there in the first place. > > 2. The assumption of a non-zero default compression context size when > the connection is established opens a race condition that a malicious > sender could exploit in a denial of service attack. Yes, the receiver > could opt to terminate the connection once it detects bad behavior, > but there is still a potential window of time there where the receiver > could be forced to do significant additional work. > > (This is particularly bad given that header continuations are unbounded.) > > 3. Setting the compression context size to 0 does not stop the sender > from sending the Indexed Literal instructions anyway. The receiving > endpoint would still be required to process those instructions even if > the data is not actually being indexed, causing CPU cycles to be > consumed. For any individual block of headers it may not be a > significant load, but it's something that needs to be addressed. > > (This can be fixed in the spec by stating that any attempt to Index > any individual (name,value) whose size is greater than the available > header table size results in a Compression Error. Making this change > would mean that when Compression Context size is 0, the only operation > that would not result in an error is Literal without Indexing. This > was discussed on the list but as far as I can tell it's not yet > captured in the spec). > > 4. The fact that header continuations can be unbounded is deeply > troubling, especially given that the endpoint is required to buffer > and process the complete header block (well.. that's only half true, > the encoding does allow for incremental processing of the HEADERS > frame payloads but the spec requires that the complete header block is > always processed). Sure, the recipient is free to terminate the > connection as soon as it detects bad behavior, but the sender could > end up forcing the recipient to do a significant amount of extra > processing with a never ending sequence of HEADERS frames. Smart > implementations will know how to deal with this, yes, but overall it > adds to the already growing list of "New Complex Things" that an > HTTP/2 implementer needs to know about. > > (In the implementation I've done, I provide a configuration > parameter that allows a developer to cap the number of the > continuations and the total size of the header block) > > I know that we're in "implementation" phase right now and that > everyone is busy getting their code ready for testing in August, but > after updating my implementation to the latest version of the draft, > my concerns with regards to stateful header compression definitely > remain. > > On Thu, Jul 11, 2013 at 9:36 AM, Martin Thomson > <martin.thomson@gmail.com> wrote: > > On 10 July 2013 21:20, Amos Jeffries <squid3@treenet.co.nz> wrote: > >> It seems not to be negotiable from the recipients side. > > > > Compression context size = 0 is entirely negotiable from the recipient > > end, with a small wrinkle, that I know some folks are working on. > > Which is, a client can start using a default compression context size > > prior to learning that a server has no space (substitute intermediary > > as appropriate there). > > > >
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Michael Sweet
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Patrick McManus
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Mark Nottingham
- Re: HTTP router point-of-view concerns Mike Belshe
- Re: HTTP router point-of-view concerns Gábor Molnár
- Re: HTTP router point-of-view concerns Gábor Molnár
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Michael Sweet
- Re: HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Patrick McManus
- Re: HTTP router point-of-view concerns Jeff Pinner
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Ludin, Stephen
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Mark Delany
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Stephen Farrell
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Martin Nilsson
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Nico Williams