This is a never finished Internet Draft with my thoughts about the HTTP/2.0 protocol.

Network Working Group                                            P. Kamp
Internet-Draft                                    Den Andensidste Viking
Intended status: Informational                             April 2, 2012
Expires: October 4, 2012

                  An architectural vision for HTTP/2.0


   The HTTP protocol is undoubtedly one of the biggest successes of the
   Internet family of protocols, and the world has changed a lot under
   the architectural assumptions it was built on.  Before rushing into
   standardization of HTTP/2.0 based on past experience and grievances
   with HTTP/1.1, we should examine what the architecture underlying the
   next 10-20 years of web-browsing must do for us.

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 4, 2012.

Copyright Notice

   Copyright (C) The Internet Society (2012).  All Rights Reserved.

Kamp                     Expires October 4, 2012                [Page 1]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  When I'm sixty-four: What are we looking at  . . . . . . . . .  4
   3.  New Kid on the Block: HTTP routers . . . . . . . . . . . . . .  5
     3.1.  Taking care of business: What a HTTP router does . . . . .  5
     3.2.  I got 99 problems: Trouble for HTTP routers  . . . . . . .  6
     3.3.  When I wish upon a star: What we can do for HTTP
           routers  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Everybody's Got Something to Hide Except Me and My Monkey  . .  8
   5.  Return to sender: The client-server model  . . . . . . . . . . 10
   6.  Route sixty-six: Getting there . . . . . . . . . . . . . . . . 11
   7.  Little Deuce Coupe: Smarter rides than TCP . . . . . . . . . . 12
   8.  Counting the Cattle: A more efficient protocol . . . . . . . . 13
   9.  Under Wraps: What to protect . . . . . . . . . . . . . . . . . 15
     9.1.  The envelope . . . . . . . . . . . . . . . . . . . . . . . 15
     9.2.  The metadata . . . . . . . . . . . . . . . . . . . . . . . 15
     9.3.  The body . . . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Headbanging The Piano: Bringing it all together. . . . . . . . 17
     10.1. Container level  . . . . . . . . . . . . . . . . . . . . . 17
     10.2. Message Level  . . . . . . . . . . . . . . . . . . . . . . 18
     10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23

Kamp                     Expires October 4, 2012                [Page 2]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

1.  Introduction

   HTTP is not what it used to be, and although the protocol has scaled
   remarkably well, the current level of performance seems insufficient
   for even the very short term growth of the internet.

   Efforts have been made to find optimizations and improvements But
   usually in a frame of mind of incremental improvement, rather than
   architectual review.

   This document is a loose architectural sketch of how HTTP/2.0 could
   look, more or less based on a single persons random sketchings and

   The intention is not that the bits and pieces of this document should
   be polished and ratified as a protocol, but to present some ideas and
   observations for discussion.

Kamp                     Expires October 4, 2012                [Page 3]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

2.  When I'm sixty-four: What are we looking at

   Jim Gettys long time ago warned the X11 project that "The only thing
   worse than generalizing from one example is generalizing from no
   examples at all."  Far too many standardization efforts neglegt this
   sage wisdom.

   But in one area we will have to extrapolate from just one example:
   What is the probably lifetime of HTTP/2.0 going to be ?

   HTTP/1.1 was first standardized in 1997 and there is no credible
   reason to belive we will get rid of it for at least another five
   years, so assuming and aiming for a 20 year lifetime of HTTP/2.0 is

   What computing will look like in 20 years time is anyones guess, but
   we do have some clues to the near term developments: Computers won't
   run faster.  The current solid-state and process technologies have
   hit a clock speed barrier around 3-5 GHz which shows no signs of
   being radically breached in the near term.

   What we see instead of higher clock speed, is inceasingly imperfect
   parallelism (NUMA), increasingly complex instruction sets and
   attempts to offload processing to dedicated hardware.  For instance
   most network cards already have support for calculating TCP/IP

   With respect to bandwidth, there does not seem to be any similar
   restrictions, although the technological problems of extending beyond
   10 and 40 Gbit/s are not trivial.  I think it is fully reasonable to
   expect transmission media with 1 Tbit/s capacity in the next 20

   I think that given HTTP's central role in mass communication, being
   able to deal with HTTP/2.0 at that speed, either in hardware or
   software is a goal in its own right.

Kamp                     Expires October 4, 2012                [Page 4]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

3.  New Kid on the Block: HTTP routers

   Probably the most radical change in the HTTP ecosystem is the
   appearance of a new role in addition to the client, proxy & server

   For reasons of scalability and redundancy, most larger websites today
   deploy light-weight proxies with load-balancing and load-directing

   In terms of RFC standardization, these boxes are clearly proxies, and
   as such they have been treated until now.

   But these boxes occupy a very special role, because they sit where
   the traffic is most densely concentrated, and they usually take
   almost no notice of the semantic meaning of the HTTP messages they

   I propose we introduce a new role for these boxes, and name them
   "HTTP routers", since their role is much closer to that of a packet
   router, than of a webserver.

3.1.  Taking care of business: What a HTTP router does

   In a typical large-ish web-site, the HTTP router is responsible for
   directing incoming HTTP requests to HTTP servers based on simple
   criteria, and to direct the reponse from the HTTP server back to the

   Because of this central position in the HTTP message path the HTTP
   router is where the traffic concentration is highest, and where both
   intentional and malicious traffic must be handled somehow.

   The HTTP router seldom terminates the HTTP path in any meaningful
   way, it simply picks it off one TCP connection and places it on
   another, pretty much like a packet router will shuffle packets
   between its interfaces.

   A very common routing criteria is "does the HTTP server work ?"  With
   two or more equally capable HTTP servers to choose from, the HTTP
   router will route requests only to those HTTP servers which seem to
   actually work.

   This simple routing policy allows HTTP servers to crash, to be taken
   down for maintenance or to be moved, without taking the entire
   website offline as a result.

   Other more involved criteria might be to send requests for images and

Kamp                     Expires October 4, 2012                [Page 5]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   other static elements to one set of servers and requests relating to
   dynamic content to another set of servers, based on pattern-matching
   the URI.

3.2.  I got 99 problems: Trouble for HTTP routers

   HTTP routers run into some deficiences of the HTTP/1.1 definition,
   which seriously cramp their style.  Some of these problems are at a
   functional level and some are purely performance.

   An example of a functional problem is the lack of a session concept
   in HTTP.

   A that a very common routing criteria is session-stability.  The
   clients first request is routed to a web-server using some random
   criteria, but subsequent requests from that same client should be
   routed to the same backend, even if that criteria changes, because
   the client and/or backend maintains state, for instance the contents
   of a shopping basket, of relevance to the "session".

   Most often this session concept is simulated with Cookies, but
   amongst other sideeffects, this makes objects which would otherwise
   be perfectly cacheable impossible to cache in shared proxies.

   In the performance class of problems, the most prominent is the
   indeterminacy of HTTP/1.1 message length: Only once we encouter the
   end do we know where to find it.  Implementation wise, things would
   be so much easier, if the length were sent up front, so that memory
   allocation and socket-API paramters can be chosen intelligently.

3.3.  When I wish upon a star: What we can do for HTTP routers

   If a HTTP/2.0 router should be able to deal with 1Tbit/s of traffic,
   we need to avoid complicated encodings or transformations for the
   fields it must examine.

   We should probably adopt how other routable protocols have a clear
   distinction between the "envelope" and "the contents" and designate a
   small subset of the HTTP message attributes as part of the envelope
   and make them convenient for HTTP routers to work with.

   Given how almost universal the "session" concept on the Internet we
   should add it to the HTTP/2.0 standard, and make it available for
   HTTP routers to use as a "flow-label" for routing.

   At the byte-serialization level, we should also try to the extent
   possible, to use prefix coding to make available information about
   what will happen next.  For instance HTTP messages should state

Kamp                     Expires October 4, 2012                [Page 6]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   clearly, with one single bit, if there they have a body/entity coming
   or not, so that the HTTP router does not have to investigate three
   different HTTP headers to make this determination.

Kamp                     Expires October 4, 2012                [Page 7]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

4.  Everybody's Got Something to Hide Except Me and My Monkey

   Cryptographic services is a minefield, but we have to navigate it.

   On all sides of this issue are strong desires to try to advance
   political and rights agendas by technical means, and as we have seen
   countless times before, getting tangled up in OSI layer 8 can doom
   any standard.

   In the FreeBSD project the admonition "We deliver tools, not
   policies" has been used to capture this attitude to political and
   emotional subjects, and I would recommend the HTTPbis WG adopts it as

   One of the most controversial subjects are proxies which interfere
   with free speech, either by preventing, modifying or by deanonymizing

   But we cannot escape however, that there are legitimate situations
   for proxies interfering with trafic, from preventing malware
   infection and leakage of sensitive documents over parental controls
   of minors web-browsing, to legal requirements to record all

   Similarly, while most users have a right to privacy of communication,
   some users specifically do not, for instance inmates in jails.

   Implementing cryptographic policies is hard, the inmate with privacy
   restriction can trivially implement a covert channel by surfing an
   webpage in a particular pattern and it has been shown that the
   interval between packets can leak information about a password typed
   over a protected connection.

   Neither HTTP/2.0 nor any other protocol can do anything about
   situations like that, such is the nature of secrecy.

   What we can do with HTTP/2.0 is support legitimate cryptographic
   functionalities and be fair about it, by provide precise and correct
   information about the actual cryptographic situation, to all parties
   in a HTTP exchange, so that both clients and servers know if they are
   subject to meddling proxies or if they have end to end privacy and

   In HTTP/1.1 the choice to do cryptographic protection is almost
   universally for the server to make, typically in the form of a
   mandatory redirect from unprotected to protected pages.

   It might be worth considering if clients should have a way of

Kamp                     Expires October 4, 2012                [Page 8]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   requesting cryptographic protection in cases where the server does
   not by default demand it, but obviously subject to the servers
   willingness to engage.

   One particular aspect of cryptography is efficiency, and it would be
   very desirable if the upgrade from unprotected to crypto-protected
   communications did not require a new TCP connection to be

   It would also be an performance advantage, if protected and
   unprotected messages can share the same TCP connection, for instance
   on the multiplexed path between a proxy and a server.

Kamp                     Expires October 4, 2012                [Page 9]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

5.  Return to sender: The client-server model

   Very fundamental to the HTTP protocol, is the strict client-server
   model of interaction, but the increasingly interactive
   webapplications have indicated a need for "server-push" or "reverse

   Breaking the conceptually simple client-server model should not be
   done lightly, doing so requires a lot of hard questions about command
   and control of the client computer.

   At the same time it would be foolish to rule out extensions to the
   client-server model in the next 20 years, so HTTP/2.0 should not be
   designed to rely on the "ping-pong" aspect of current HTTP traffic,
   even if that is all it is going to allow initially.

   Sticking to the client-server model does not preclude supporting
   multiplexing and pipelining of request, in fact HTTP/2.0 should most
   certainly do so, simply for reasons of speed and resource

Kamp                     Expires October 4, 2012               [Page 10]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

6.  Route sixty-six: Getting there

   Today the almost universal carrier of HTTP is the TCP protocol, and
   the entrenched infrastructure of firewalls and gateways on the
   internet makes it foolish to even imagine that HTTP/2.0 could be
   deployed rapidly if it required new TCP ports to be opened.

   This means that coexistence with HTTP/1.1 and possibly HTTPS on a
   single TCP port is an inescapeable requirement for HTTP/2.0.

   Initially it is to be expected that most servers will only offer
   HTTP/1.1 and therefore clients will send a HTTP/1.1 request with some
   kind of hint that they are willing to do HTTP/2.0 also.  If the
   server bites, the protocol is upgraded and HTTP/2.0 happiness

   At some point, hopefully, a critical mass of HTTP/2.0 servers is
   reached, and it makes sense for clients to attempt to go directly on
   HTTP/2.0 right away, and suffer the cost of a retry if the server
   does not support HTTP/2.0.

   This situation can be significantly optimized, if the HTTP/2.0
   protocol allows a client to send an optional "magic string" on a
   newly opened connection to detect non HTTP/2.0 servers.

   This string should be designed to be as short as possible, while
   still producing a error message from HTTP/1.1 servers which does not
   result in the TCP connection being closed, while at the same time
   being clearly distinct from any legal HTTP/2.0 message.

   One possible way would be to "wrap" the HTTP/2.0 request in an almost
   legitimate HTTP/1.1 operation:

                       "X / HTTP/1.1" CRNL
                       "Content-Length: 48" CRNL
                       [48 bytes of HTTP/2.0 request]

   A HTTP/1.1 server will return an error, which can be recognized
   because it starts with "HTTP..." whereas the a HTTP/2.0 server would
   send a HTTP/2.0 reponse to the request, ignoring the HTTP/1.1 "bogo-

   For something like this to work, it is imperative that the HTTP/2.0
   serialization of a response can never start with the bytevalue 'H'
   and it may be advisable to also "blacklist" certain other characters,
   CR and NL for instance.

Kamp                     Expires October 4, 2012               [Page 11]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

7.  Little Deuce Coupe: Smarter rides than TCP

   A surprising large fraction of todays webtraffic could fit into UDP
   packets, one for the request and one for the reponse.

   This idea is not without problems however, there is a significant
   potential for Dos-amplification in any UDP protocol where the reponse
   is larger than the request,

   But there are many closed domains where such risks may have no
   relevance, and the benefit of using UDP might be very high in terms
   of time and cost.

   I will not advocate that HTTP/2.0 standardize HTTP over UDP, but
   neither should it be prevented.

   One of the biggest factors in the IP protocols success is that the
   packet were defined independent of the underlying transmission media,
   allowing IP packets to spread from 56kbit leased lines to norwegian
   carrier pigeons without any need to reopen RFC 791.

   When finalizing the serialization of HTTP/2.0 messages onto
   bytestreams, we should focus on such "portability" rather than assume
   that HTTP/2.0 is a TCP-only protocol.

Kamp                     Expires October 4, 2012               [Page 12]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

8.  Counting the Cattle: A more efficient protocol

   HTTP/1.1 was designed in an era where things were very different, and
   as much help as it was to be able to TELNET to pretty much any server
   and "do a hand-job", the number of bytes and cpu-cycles wasted in
   HTTP/1.1 is simply monumental.

   There are many ways reduce the size of HTTP messages and they should
   all be considered in turn.

   At the most fundamental level, is not sending stuff to begin with.
   For instance a credible case can be made that the "Date:" header is
   surplus to requirements in a majority of circumstances.

   The next level is to send less, for instance sending the allowable
   cache time of an object as a number of seconds ("300") takes up a lot
   less space than sending the time it expires ("Mon, 02 Apr 2012
   19:10:42 GMT")

   Next up is sending things less often, for instance if HTTP/2.0 has a
   functional session-mechanism, it would be enough for the client to
   send "User-Agent" and most cookies to the server only on the first
   HTTP message on the connection, for all subsequent messages a "ditto"
   would suffice.

   And finally we get to sending data more efficiently.  Many cookies
   have cryptographic content which are ASCII encoded using base64 or
   HEX encoding.  HTTP never has and never will run over transmission
   paths which are not 8-bit clean, and allowing cookies to have binary
   content would reduce their size by 25 to 50%.

   If properly designed, a moving from ASCII to a binary protocol may
   save further bytes.

   Finally, it is possible to resort to general purpose compression, but
   a well designed protocol encoding may give the good old LZW a run for
   the money, both in terms of simplicity and memory requirements.

   But bytes is not the only cost we care about and all bytes are not
   created equal.  The byte that causes a HTTP message to spill into the
   next packet is much more expensive than one which merely adds a byte
   to the current packet.  Any attempt to design a serialization needs
   to to seriously study the tradeoff between bytes scavenged and bytes
   well spent to improve protocol implementation.

   One example would be to prefix a HTTP message with the number of
   bytes in it.  In HTTP/1.1 one reads until a [CR]NL[CR]NL sequence
   appears, but unless the client is a keyboard and TELNET it knows full

Kamp                     Expires October 4, 2012               [Page 13]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   well up front, or could easily find out up front, how many bytes it
   is going to send to the server.

   Announcing what is to follow in the serialization is a significant
   optimization for the receiver, which can select and prepare
   sufficient storage, and minimize the number of context-switches,
   while still getting optimal memory layout.

Kamp                     Expires October 4, 2012               [Page 14]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

9.  Under Wraps: What to protect

   The new role of HTTP routers makes a compelling reason to subdivide a
   HTTP/2.0 message further than the 2 and a bit parts we have operated
   with in HTTP/1.1.

   I would split it in three parts

9.1.  The envelope

   The envelope is the information necessary to route the HTTP message
   to the right place, and I would propose that it consist of the
   following parts of a HTTP message:

                           URI, less the query part.
                           Host: header
                           A server assigned session number (or zero)
                           The length of the metadata.
                           The length of the body (or zero)
                           Status (200/305/502 etc)
                           Session number (or zero)
                           The length of the metadata.
                           The length of the body (or zero)

   I will go a step further and claim that we can live without
   cryptographic protection of this envelope.

   There are trivial workarounds to obfuscate all of these fields for
   purposes of privacy, and their integrity can be ensured by signing
   them in the protected part of the message.

   Taking the envelope out of the cryptographically protected part of
   messages, means that HTTP routers can route protected traffic,
   without terminating the TLS sessions.

   The envelope should be byteserialized with an eye to maximum
   procesing efficiency in HTTP routers, possibly at the expense of some
   bytes which could theoretically be saved.  All fields should have
   length prefixes and the fixed sized fields be clustered at the front.

9.2.  The metadata

   Metadata are the bits of the HTTP message which are necessary for
   correct semantic interpretation of the message.  This is pretty much
   everything else we have in the HTTP/1.1 message which not related to
   transport or connection management.

Kamp                     Expires October 4, 2012               [Page 15]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   HTTP routers will not need to examine this part of the message, if
   they do, they are not HTTP routers but HTTP proxies.

   The metadata should be byteserialized to minimize both size and
   processing overhead.

9.3.  The body

   The body is an opaque sequence of bytes, but it it may be relevant to
   do transport level compression on it, even if it has already close to
   optimal entropy.

   One example where this could make sense is a non-caching proxy
   repeatedly requesting an image file on behalf of different clients.

Kamp                     Expires October 4, 2012               [Page 16]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

10.  Headbanging The Piano: Bringing it all together.

   Bringing all these strands together, here is my strawman proposal for
   what a HTTP/2.0 protocol could look like.

10.1.  Container level

   At the bottom most level we have a level which is responsible for
   efficient transmission, multiplexing, and negotiation of connection

                           uint8_t                 type;
                           uint8_t                 flags;
                           uint16_t                channel;
                           uint32_t                length;
                           uint8_t[$length]        message;

   The type field, tells what kind of contents is being sent.  Being the
   first field, type can trivially be subject to the 'H'/CR/NL

   Two types should be allocated for tunneling HTTP/1.1 request and
   reponses transparently.  If container-level compression is
   negotiated/available the HTTP/1.1 messages can be compressed, cookies
   and all.

   The exact allocation policy for further types is up for grabs.  It
   may make sense to encode the request (GET/PUT/POST) at this level, to
   get better utilization of this field.

   The flags can indicate if this particular container is subject to TLS
   and/or if it has been compressed at the container level.  The exact
   parameters of the TLS or compression are subject to negotiation.

   It may make sense to define a "final" flag bit, to indicate the last
   chunk of a progressively delivered HTTP object body, similar to the
   "0 length chunk" used for chunked encoding in HTTP/1.1.

   Channel indicates which logical channel the container belongs to.  A
   default maximum number of available channels is subject to
   negotiation.  A client can use the available channels to send
   multiple requests at one time, a proxy could dedicate a channel to
   each client to maximize compression efficiency of metadata blocks.

   Channel zero is "magic" and is used for negotiation of parameters and
   for the TLS handshake if protection is called for.

   The length field is big enough to transfer well sized chunks of data,

Kamp                     Expires October 4, 2012               [Page 17]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   but still of a fixed size which will make it easier to implement HTTP
   routing at high speeds, in hardware or software.

10.2.  Message Level

   The message level is for transferring the envelope and metadata of a
   HTTP message in a container.

   If the metadata is cryptographically protected it may make sense to
   use one container for the envelope and one for the metadata, but in
   the case where neither envelope nor metadata is protected, a single
   container should be used.

   The envelope fields should be serialized in a length prefixed
   efficient format, the metadata should follow it, in whatever highly
   efficent serialization we find best.

10.3.  Examples

   The above structure is deliberately very flexible and therefore
   hopefully powerfull enough to absorb the next two decades of whacky

   Such general constructs can be very hard to fully grasp without some
   examples, so here are some of the ones I thought about along the way.

   "//" marks the start of comments.

Kamp                     Expires October 4, 2012               [Page 18]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   The canonical HTTP/1.1 to HTTP/2.0 upgrade

   C->S    GET /foo HTTP/1.1 CRNL
           Host: CRNL
           Upgrade: http20-gzip-tls CRNL   // Client can do HTTP/2.0
                                           // + gzip container compr.
                                           // + TLS support

   S->C    101 Switching Protocols CRNL
           {type=HTTP20-Response,chan=1,len=A} [{envelope}{metadata}]
           {type=HTTP20-Body,chan=1,len=B} [<html>Hello World...]
           {type=CAN-DO,chan=0,len=D} [maxchan=6,gzip=0,tls=0]
                           // Server will service channels 1...6
                           // Server does not offer gzip c-compr.
                           // Server does not offer TLS service.
           {type=HTTP20-Body,chan=1,flag=final,len=C} [...</html>]
   C->S    {type=HTTP20-Request,chan=2,len=E} [{envelope}{metadata}]
   C->S    {type=HTTP20-Request,chan=3,len=F} [{envelope}{metadata}]
   S->C    {type=HTTP20-Response,chan=2,len=G} [{envelope}{metadata}]
   C->S    {type=HTTP20-Request,chan=4,len=H} [{envelope}{metadata}]
   S->C    {type=HTTP20-Body,chan=2,flag=final,len=I} [JPEG image]
   S->C    {type=HTTP20-Response,chan=3,len=J} [{envelope}{metadata}]

   The canonical HTTP/2.0 to HTTP/1.1 downgrade

   C->S    X / HTTP/1.1 CRNL
           Content-Length: XX CRNL
           {type=HTTP20-Request,chan=1,len=A} [{envelope}{metadata}]
   S->C    HTTP/1.1 501 Not Implemented CRNL
           Content-Length: XX CRNl
           (grumble grumble grumble) CRNL
           <HTML> NL
           <H2>Grumble grumble grumble</H2> NL
   C->S    GET /foobar.html CRNL
           Host: CRNL
           Yadda: yadda, yadda, yadda CRNL
   S->C    HTTP/1.1 200 Ok
           Content-length: 12323

Kamp                     Expires October 4, 2012               [Page 19]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   The HTTP/2.0 response to HTTP/1.1 Hedging

   C->S    X / HTTP/1.1 CRNL
           Content-Length: XX CRNL
           {type=HTTP20-Request,chan=1,len=A} [{envelope}{metadata}]
   S->C    {type=HTTP20-Reponse,chan=1,len=B} [{envelope}{metadata}]
           {type=HTTP20-Body,chan=1,flags=final,len=B} [{rickroll.wav}]
           {type=HTTP20-Body,chan=1,flags=final,len=B} [{rickroll.wav}]
           {type=CAN-DO,chan=0,len=D} [maxchan=10,gzip=1,tls=0]

Kamp                     Expires October 4, 2012               [Page 20]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

11.  Security Considerations

   Several, read the text.

Kamp                     Expires October 4, 2012               [Page 21]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

Author's Address

   Poul-Henning Kamp
   Den Andensidste Viking
   Herluf Trollesvej 3
   Slagelse  DK-4200

Kamp                     Expires October 4, 2012               [Page 22]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

Full Copyright Statement

   Copyright (C) The Internet Society (2012).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP 11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice

Kamp                     Expires October 4, 2012               [Page 23]

Internet-Draft    An architectural vision for HTTP/2.0        April 2012

   this standard.  Please address the information to the IETF Executive


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Kamp                     Expires October 4, 2012               [Page 24]