Re: HTTP router point-of-view concerns

Amos Jeffries <> Thu, 11 July 2013 04:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 933CE21F9A71 for <>; Wed, 10 Jul 2013 21:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BBme7yru7GUL for <>; Wed, 10 Jul 2013 21:22:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1895621F997E for <>; Wed, 10 Jul 2013 21:22:30 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Ux8NA-0004yB-Py for; Thu, 11 Jul 2013 04:20:52 +0000
Resent-Date: Thu, 11 Jul 2013 04:20:52 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ux8N0-0004xS-I1 for; Thu, 11 Jul 2013 04:20:42 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1Ux8Mz-0001sb-E6 for; Thu, 11 Jul 2013 04:20:42 +0000
Received: from [] ( []) by (Postfix) with ESMTP id 4ACE1E6EAF for <>; Thu, 11 Jul 2013 16:20:17 +1200 (NZST)
Message-ID: <>
Date: Thu, 11 Jul 2013 16:20:12 +1200
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-3.104, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Ux8Mz-0001sb-E6 cdf705137960aa96ac1860796113dfc7
Subject: Re: HTTP router point-of-view concerns
Archived-At: <>
X-Mailing-List: <> archive/latest/18689
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 11/07/2013 3:13 p.m., Roberto Peon wrote:
> The intent was that one could negotiate a zero compression state, in 
> which case it ends up being similar to what is proposed here, I think, 
> so long as the appropriate key-value (or key) is in the static table.

It seems not to be negotiable from the recipients side. The sender can 
choose to implement a non-Substituting HEADERS frame, but the recipient 
cannot exactly require it and thus is required to implement Substitution 
state for decoding regardless of whether it is ever used. If I have 
missed something please point it out to me.

PS. not that I am arguing for or against the current aproach. It is just 
sad that the worse form of middleware gains the most benefits and 
everything else is put to a bit of trouble.


> -=R
> On Wed, Jul 10, 2013 at 7:53 PM, Amos Jeffries < 
> <>> wrote:
>     On 11/07/2013 10:52 a.m., Christian Parpart wrote:
>         Hey guys,
>         I am just new to this list and I've just recently started
>         working through the HTTP/2 draft and all the blog articles
>         found about.
>         That being said, I myself have also very concerns others have
>         noticed as well, and would like to deeply show my intention to
>         help standing aside :)
>         I am the implementor of one of the many HTTP servers that's
>         being used in production, and one major feature is HTTP
>         routing / load balancing,
>         and I would really love to implement an HTTP/1.1 successor
>         that is (to be) officially labeled HTTP/2[.0].
>         However, as a varnish [1] and a BSD [2] guy also raised there
>         hands on, is the lag of easy extraction of envelop information
>         of an HTTP request message, such as method, path, but most
>         certainly the host.
>         Please forgive me if this is already on-topic somewhere
>         hidden, however, I would really highly encourage you to consider
>         adding some dedicated frame type for this kind of envelope
>         information.
>         With that in mind, one might say that an HTTP/2 stream is not
>         initiated by a HEADERS frame but the ENVELOPE frame that
>         contains the actual
>         uncompressed and unmystified but compact information about
>         this request message.
>         One humble proposal might indeed be:
>         type: (something unassigned)
>         flags: bit 1 = END_STREAM /* this HTTP message is complete
>         with just these envelope frame, e.g. a simple GET, and no need
>         for user-agent etc. */
>         id: unique stream ID, semantics like any other stream ID
>         body: a key/value table of the envelope data
>         The envelope data table is a simple table of key/value pairs
>         where the key is an 8bit value identifying the entry
>         and a variable length value that is interpreted depending on
>         the key. The list of provided envelope fields ends
>         as the end of the envelope frame has been reached. that means,
>         an envelope must always fit into a single (first) frame.
>           * :scheme => uint8: 0x01
>               o http => uint8: 0x01
>               o https => uint8: 0x02
>               o custom => same as in method (if this is distinction is
>         really
>                 demanded)
>           * :method => uint8: 0x02
>               o GET => uint8: 0x01
>               o POST => uint8: 0x02
>               o PUT => uint8: 0x03
>               o DELETE => uint8:0x04
>               o custom => uint8: 0xFF, followed by one uint8 encoding
>         the size
>                 of the following bytes declaring the plaintext method
>         value,
>                 e.g. "PROPFIND"
>           * :path => uint8: 0x03, uint16 length in network byte order,
>             followed by $length octects declaring the path's value.
>           * :host => uint8: 0x04, uint16: length in network byte order,
>             $length octets declaring the host's value.
>           * :route => uint8: 0x05, uint8: length, $length octets that
>         declare
>             this value. (field is only specified if known, thus
>         previousely
>             announced by the remote server or this frame is part of a
>         response
>             and we are to announce a routing identifier)
>           * :status => uint8: 0x06, uint16: code in network byte order
>          /* if
>             HTTP/2 considers starting response streams the same way */
>         This is the exact information an HTTP client
>         (scheme,method,path,host) or server (status) MUST currently
>         sent as part of the (first) HEADERS frame.
>         So the change I propose is, to extract this information from
>         the HEADERS frame and put it into its own frame that also
>         initiates the stream implicitly.
>         Having this in mind, it is a pleasure to implement HTTP
>         routers because those now don't have to decode the full
>         HEADERS frames but just decode the ENVELOPE frame and pass any
>         continued frame to the directed next-hop server.
>     Sadly the compression draft as written is completely incompatible
>     with this type of load balancing. It operates a *stateful*
>     compressor, such that every single HEADERS frame being received
>     has to be decoded in order to re-encode using a separate
>     connection-specific stateful compressor on the next-hop
>     connections. This is mandatory for the compressed frames
>     regardless of whether the ENVELOPE header is used to provide
>     uncompressed details.
>      The best load balancers can do under the current compression
>     draft is to avoid complex re-encoding by emiting only Literal
>     header representations and skipping all the traffic optimizations
>     compression offers. Which converts them into near perfect DDoS
>     bandwidth-amplification sources.
>     The sad state of affairs is that the *only* type of middleware
>     which benefits from the proposed HTTP/2 is those which performs
>     transparent interception and passive monitoring/recording of users
>     traffic (ie the worst kind). Anything which starts modifying or
>     manipulating (ie doing something useful for the ISP or CDN) MUST
>     implement a full compressor/decompressor pair in order to keep the
>     HTTP/2 statefulness in order.
>     Amos