HTTP router point-of-view concerns

Christian Parpart <> Wed, 10 July 2013 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23F7821F9AF3 for <>; Wed, 10 Jul 2013 15:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.976
X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1rMtQfDFc9MX for <>; Wed, 10 Jul 2013 15:54:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 104A011E8141 for <>; Wed, 10 Jul 2013 15:54:56 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Ux3GM-000778-M3 for; Wed, 10 Jul 2013 22:53:30 +0000
Resent-Date: Wed, 10 Jul 2013 22:53:30 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ux3GF-00076O-1Z for; Wed, 10 Jul 2013 22:53:23 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Ux3GD-0005yN-C5 for; Wed, 10 Jul 2013 22:53:22 +0000
Received: by with SMTP id e10so3977598qcy.13 for <>; Wed, 10 Jul 2013 15:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=t2ge8hz07wPWhm4eq5r2dJgrcnDjHUYc5hdBjGRRyHI=; b=wOqC6OHrDZ7jgJLuSSib7BFYRU7ncIl7nQOeHoa52v8Xm7tIwkLPemyM3kbXZOlGEd NPnHE80mPHrC1N8wBLa3EHoV2iSZmmyYtF9Xhx9IHkIo1S6Aj3/zpBbmxVRT/Cp5TlZd pUgifuOEpBHykyzjL+G0pwf6zhR/2Roz/v8igHFgxvdtQi75UiHu83x/vnypDPzP73UV 1Wd72TE0Z9NinBjqo32aSHU/Li15JOK1uWUM+t5PjGS6qnW4J0e4trWROO3XZMubL15i r6FDCtzpQUCoeX3vTKEome9LDfMTWwa/3yY/UVRkMNwnuY9xly81NWfDEI5Bz4MRjAve AA6Q==
MIME-Version: 1.0
X-Received: by with SMTP id t3mr27522634qeq.92.1373496775645; Wed, 10 Jul 2013 15:52:55 -0700 (PDT)
Received: by with HTTP; Wed, 10 Jul 2013 15:52:55 -0700 (PDT)
Date: Thu, 11 Jul 2013 00:52:55 +0200
X-Google-Sender-Auth: DzO7Lb-2CQ3gX0xj2_EFdEJr0pA
Message-ID: <>
From: Christian Parpart <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="047d7b6d7a3069a07804e1302350"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.7
X-W3C-Scan-Sig: 1Ux3GD-0005yN-C5 61a6b7c8fd6ef5f577c21ef25b03a6d6
Subject: HTTP router point-of-view concerns
Archived-At: <>
X-Mailing-List: <> archive/latest/18683
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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
      - http => uint8: 0x01
      - https => uint8: 0x02
      - custom => same as in method (if this is distinction is really
   - :method => uint8: 0x02
      - GET => uint8: 0x01
      - POST => uint8: 0x02
      - PUT => uint8: 0x03
      - DELETE => uint8:0x04
      - 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

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.


You might have noticed that I quietly introduced routing key. This idea is
on behalf of what's blamed in  [1] and [2] about the missing session
feature, so you might easily call it "session" instead of "route", but I
called it "route" because in the use-case I am speaking for (HTTP router)
this value would have been used to create backend stickiness for client

This whole subject is a problem of its own, and I didn't intend to talk
about this, but at least wanted to mention, that it should be part of  the
ENVELOPE header as well, as the HTTP router must inspect this field as fast
as possible, too.

p.s.: in [2] is also noted, that the message payload (DATA) length should
always be known in advance, a highly disagree on that, as there are types
of messages that actually do not always know the length in advance (.e.g.
live streaming servers, if it's video streaming, audio, or text based) or
other kind of feed messages that are layered atop of HTTP, so I'd propose
against that. :0

Now, I hope you won't kill me for my proposals, but I would like to show my
strong intend for the upcoming HTTP/2 to have as less pains as possible,
otherwise upgrading server (and client) software wouldn't make much sense
if the margin of benefit is just too small.

Best regards,
Christian Parpart