Re: HTTP router point-of-view concerns
Roberto Peon <grmocg@gmail.com> Thu, 11 July 2013 19:38 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 623D821F846E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 12:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.536
X-Spam-Level:
X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Nbm2+6SWicq1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 12:38:09 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2A38911E8112 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 11 Jul 2013 12:38:09 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UxMgY-0008Mn-Ic for ietf-http-wg-dist@listhub.w3.org; Thu, 11 Jul 2013 19:37:50 +0000
Resent-Date: Thu, 11 Jul 2013 19:37:50 +0000
Resent-Message-Id: <E1UxMgY-0008Mn-Ic@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 1UxMgQ-0008Kv-J5 for ietf-http-wg@listhub.w3.org; Thu, 11 Jul 2013 19:37:42 +0000
Received: from mail-ob0-f173.google.com ([209.85.214.173]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UxMgP-0008TU-GX for ietf-http-wg@w3.org; Thu, 11 Jul 2013 19:37:42 +0000
Received: by mail-ob0-f173.google.com with SMTP id wc20so10262845obb.4 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2013 12:37:15 -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=lDL59ng+1haxVFym5gAeCqA1XeMCx6GnVTYLp85aMdA=; b=qqPLTrjpfv6azY4Y7RRVWwlLp+20st5/WG9XNGziaHU167UBJSBEzpGmZewhSdkpIO xIJykUfzFIgGr/WzfHhLSWMVegmvbuc8Kj1JSImwq19w1BVQfA9LG4J5py4zQiDKgfpv ymElbKaRAIt4fDi2AUWXcVlWWyEiQ9JXzRHVt3WL9JoWtDjCLbPJrCV9hH1/BxFYDmhD 5wAyoWK/n2qaN+v4OtXtpdIMl56Q3bFJdyLmUun5AYvHqdeOpVrhG4NaSRcz144l981n JYEzqoMM554mjVNo4O/tFZq6kGtGn2OVsXrWwriFC5OPvwaM3VpikDvFQb5V5jrYjs2Y UFPw==
MIME-Version: 1.0
X-Received: by 10.182.181.99 with SMTP id dv3mr33352217obc.71.1373571435604; Thu, 11 Jul 2013 12:37:15 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Thu, 11 Jul 2013 12:37:15 -0700 (PDT)
In-Reply-To: <092D65A8-8CB7-419D-B6A4-77CAE40A0026@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> <092D65A8-8CB7-419D-B6A4-77CAE40A0026@gmail.com>
Date: Thu, 11 Jul 2013 12:37:15 -0700
Message-ID: <CAP+FsNfpHY-Eai7T+vW01LRPweKmSfVhWO-Tj0ii4wWzX6fwUg@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Sam Pullara <spullara@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, 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="089e0158b6a67e331c04e1418560"
Received-SPF: pass client-ip=209.85.214.173; envelope-from=grmocg@gmail.com; helo=mail-ob0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.680, 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 1UxMgP-0008TU-GX 3d6fdcba2c93b06cd6a0b720028496df
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/CAP+FsNfpHY-Eai7T+vW01LRPweKmSfVhWO-Tj0ii4wWzX6fwUg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18702
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>
If one doesn't care about number of bytes on the wire, or if one doesn't care about user-perceived latency, then obviously compression is a waste. If one does care, then, especially on slower links, header compression does a great deal to reduce latency as the HTTP metadata eats up a significant fraction of available bandwidth on those links. -=R On Thu, Jul 11, 2013 at 10:21 AM, Sam Pullara <spullara@gmail.com> wrote: > How sure are we that the entire idea of header compression isn't a bad > idea? I implemented something similar in the WebLogic T3 protocol > (BubblingAbbrevTable, probably still in there) and it was mostly just a > pain. If I were to go back I would just use gzip with some agreed upon seed > dictionary. Thought I would bring this up since it seems like it is a very > controversial feature to begin with. > > Sam > > On 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