[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00

Network Working Group                                         H. Ruellan
Internet-Draft                                               J. Fujisawa
Expires: September 12, 2013                                  Canon, Inc.
                                                           R. Bellessort
                                                               Y. Fablet
                                                          March 11, 2013


     Header Diff: A compact HTTP header representation for HTTP/2.0
                      draft-ruellan-headerdiff-00

Abstract

   This document describes a format adapted to efficiently represent
   HTTP headers in the context of HTTP/2.0.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 http://datatracker.ietf.org/drafts/current/.

   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 September 12, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Ruellan, et al.        Expires September 12, 2013               [Page 1]

Documentation               HTTP Header Diff                  March 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Outline . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Integration within HTTP/2.0 . . . . . . . . . . . . . . .   4
       2.3.1.  Deflate Usage . . . . . . . . . . . . . . . . . . . .   5
   3.  Indexing Strategies . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Indexing Tables . . . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Header Table  . . . . . . . . . . . . . . . . . . . .   6
       3.1.2.  Name Table  . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Header Representation . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Literal Representation  . . . . . . . . . . . . . . .   7
       3.2.2.  Indexed Representation  . . . . . . . . . . . . . . .   7
       3.2.3.  Delta Representation  . . . . . . . . . . . . . . . .   7
   4.  Detailed Format . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Low-level representations . . . . . . . . . . . . . . . .   8
       4.1.1.  Integer representation  . . . . . . . . . . . . . . .   8
       4.1.2.  String literal representation . . . . . . . . . . . .  10
     4.2.  Indexed Header Representation . . . . . . . . . . . . . .  10
       4.2.1.  Short Indexed Header  . . . . . . . . . . . . . . . .  10
       4.2.2.  Long Indexed Header . . . . . . . . . . . . . . . . .  11
     4.3.  Literal Header Representation . . . . . . . . . . . . . .  11
       4.3.1.  Literal Header without Indexing . . . . . . . . . . .  11
       4.3.2.  Literal Header with Indexing  . . . . . . . . . . . .  12
     4.4.  Delta Header Representation . . . . . . . . . . . . . . .  12
       4.4.1.  Delta Header without Indexing . . . . . . . . . . . .  12
       4.4.2.  Delta Header with Indexing  . . . . . . . . . . . . .  13
   5.  Parameter Negotiation . . . . . . . . . . . . . . . . . . . .  13
   6.  Open Questions  . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Typed Codecs  . . . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Specific header processing  . . . . . . . . . . . . . . .  14
     6.3.  Security Issues . . . . . . . . . . . . . . . . . . . . .  15
     6.4.  Deflate Partial Usage . . . . . . . . . . . . . . . . . .  15
     6.5.  Max length and entry numbers  . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  Initial header names . . . . . . . . . . . . . . . .  16
     A.1.  Requests  . . . . . . . . . . . . . . . . . . . . . . . .  16
     A.2.  Responses . . . . . . . . . . . . . . . . . . . . . . . .  18
     A.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  19
       A.3.1.  First header set  . . . . . . . . . . . . . . . . . .  19
       A.3.2.  Second header set . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22





Ruellan, et al.        Expires September 12, 2013               [Page 2]

Documentation               HTTP Header Diff                  March 2013


1.  Introduction

   This document describes a format adapted to efficiently represent
   HTTP headers in the context of HTTP/2.0.

2.  Overview

2.1.  Design Principles

   HTTP headers can be represented in various ways.  As shown by SPDY,
   Deflate compresses very well HTTP headers.  But the use of Deflate
   has been found to cause security issues.  In particular, the
   compression of sensitive data, together with other data controlled by
   an attacker, may lead to leakage of the sensitive data.  The
   processing and memory costs may also be too high for some classes of
   devices.

   Having a lightweight compact HTTP header representation is therefore
   useful.  To design this representation, the focus was put on the
   following points:

   o  Simplicity: the representation should have a small number of
      options that allow handling any kind of headers; in particular,
      the use of dedicated codecs for each type of header value is not
      considered here.

   o  Efficiency: the representation should provide good compression at
      a small encoding/decoding cost for both processing and memory.

   o  Flexibility: the representation should be compatible with
      constrained devices, but also provide improved efficiency when
      more capable devices are used.

   o  Deflate-friendly: Deflate has proven its efficiency for encoding
      HTTP headers.  A good HTTP header representation should be
      efficient as a pre-compression step prior to applying Deflate.

2.2.  Outline

   The HTTP header representation described in this document is based on
   indexing tables that store (name,value) pairs, called header tables
   in the remainder of this document.  Header tables are incrementally
   updated during the whole HTTP/2.0 session.  Two independent header
   tables are used during a HTTP/2.0 session, one for HTTP request
   headers and one for HTTP response headers.

   The encoder is responsible for deciding which headers to insert as
   (name,value) pairs in the header table.  The decoder follows exactly



Ruellan, et al.        Expires September 12, 2013               [Page 3]

Documentation               HTTP Header Diff                  March 2013


   what the encoder prescribes.  This enables decoders to remain simple
   and understand a wide variety of encoders.

   A header may be represented as a literal, an index or a delta.  If
   represented as a literal or a delta, the representation specifies
   whether this header is used to update the indexing table.  The
   different representations are described in Section 3.2.

   To improve literal headers representation compactness, header names
   are indexed in a specific name table.  Two independent name tables
   are used during a HTTP/2.0 session, one for HTTP request headers and
   another for HTTP response headers.

   An example illustrating the use of the different tables to represent
   headers is available in Appendix A.3.  Once a set of header is
   represented using the available representations, it can optionally be
   compressed with Deflate.

2.3.  Integration within HTTP/2.0

   The headers are inserted in the HTTP/2.0 frames at the same place as
   defined in SPDY (next chart was adapted from draft-ietf-httpbis-
   http2-00).

   +------------------------------------+
   |1|    version    |         1        |
   +------------------------------------+
   |  Flags (8)  |  Length (24 bits)    |
   +------------------------------------+
   |X|           Stream-ID (31bits)     |
   +------------------------------------+
   |X| Associated-To-Stream-ID (31bits) |
   +------------------------------------+
   | Pri|Unused | Slot |                |
   +-------------------+                |
   | Number of Name/Value pairs (int32) |
   +------------------------------------+
   |     Encoded name/value pair        |   <+
   +------------------------------------+    | (*)
   |           (repeats)                |   <+

   (*) This section is the "Name/Value Header Block",
       and may be compressed.


   The modifications to SPDY are the following:





Ruellan, et al.        Expires September 12, 2013               [Page 4]

Documentation               HTTP Header Diff                  March 2013


   o  The headers are not represented as string tokens but using one of
      the possible representation described in Section 4.

   o  The Deflate step is made optional.

2.3.1.  Deflate Usage

   The header representation described in Section 4 is amenable to
   Deflate compression.  The Deflate algorithm improves the compression
   at the expense of additional processing.

   At least two potential drawbacks have been identified when using
   Deflate.  First, security issues may arise when using Deflate, like
   the CRIME attack [1].  Second, it may increase the workload of
   network intermediaries: they may need to uncompress and recompress
   the headers of all messages, even though they only need to process a
   few of them.

   The use of Deflate may still be envisioned if properly set up.
   Several approaches are available and should be studied:

      Restricting Deflate to Huffman-only coding is an option.  This is
      supported by many Deflate implementations such as zlib.  It may be
      used in the environments subject to CRIME attacks.  This approach
      should be compared to the direct use of hand-tailored Huffman
      coding.

      The use of indexing mechanisms prior Deflate may solve some
      security issues.  More precise analysis of the security impact of
      using indexing mechanisms prior Deflate should be studied as
      described in Section 6.3.

      Partial use of Deflate on a selected subset of headers may also be
      an option as described in Section 6.4.

      Restricting the use of Deflate to safe cases, such as controlled
      environments (widgets, native applications), anonymous connections
      and so on can be envisioned.  For instance, restricting the use of
      Deflate to HTTP response headers should not enable CRIME-like
      attacks.

3.  Indexing Strategies









Ruellan, et al.        Expires September 12, 2013               [Page 5]

Documentation               HTTP Header Diff                  March 2013


3.1.  Indexing Tables

3.1.1.  Header Table

   A header table consists in an ordered list of (name, value) pairs.
   Once a header pair is inserted in the header table, its index does
   not change until the pair gets removed.  A pair is either inserted at
   the end of the table or replaces an existing pair depending on the
   chosen representation.

   Header names should be represented as lower-case strings.  A header
   name is matching with a pair name if they are equal using a
   character-based, _case insensitive_ comparison.  A header value is
   matching with a pair value if they are equal using a character-based,
   _case sensitive_ comparison.  A header is matching with a
   (name,value) pair if both name and value are matching.

   The header table is progressively updated based on headers
   represented as literal (as defined in Section 3.2.1) or delta (as
   defined in Section 3.2.3).  Two update mechanisms are defined:

   o  Incremental indexing: the represented header is inserted at the
      end of the header table as a (name, value) pair.  The inserted
      pair index is set to the next free index in the table: it is equal
      to the number of headers in the table before its insertion.

   o  Substitution indexing: the represented header contains an index to
      an existing (name,value) pair.  The existing pair value is
      replaced by the header value.

   Incremental and substitution indexing are optional.  If none of them
   is selected in a header representation, the header table is not
   updated.  In particular, no update happens on the header table when
   processing an indexed representation.

   The header table size can be bounded so as to limit the memory
   requirements.  The header table size is defined as the sum of the
   length (as defined in Section 4.1.2) of the values of all header
   table pairs.  Header names are not counted in the header table size.

3.1.2.  Name Table

   A name table is an ordered list of name entries that is used to
   efficiently represent header names.  A header name is matching a name
   table entry if they are equal using a character-based, _case
   insensitive_ comparison.





Ruellan, et al.        Expires September 12, 2013               [Page 6]

Documentation               HTTP Header Diff                  March 2013


   If a header name is matching a name table entry, it is represented as
   an integer based on the index of the entry, as described in
   Section 4.1.1.  If a header name is not matching any of the name
   table entry, it is represented as a string, as described in
   Section 4.1.2.  A new entry containing the name is then inserted at
   the end of the name table.  Once inserted in the name table, a header
   name is never removed and its index is never changing.

   To optimize the representation of the headers exchanged at the
   beginning of the HTTP/2.0 session, the header name table is initally
   populated with common header names.  The initial header names list is
   provided in Appendix A.

3.2.  Header Representation

3.2.1.  Literal Representation

   The literal representation defines a header independentently of the
   header table.  A literal header is represented as:

   o  A header name, represented using the name table, as described in
      Section 3.1.2.

   o  The header value, represented as a literal string, as described in
      Section 4.1.2.

3.2.2.  Indexed Representation

   The indexed representation defines a header as a match to a
   (name,value) pair in the header table.  An indexed header is
   represented as:

   o  An integer representing the index of the matching (name,value)
      pair, as described in Section 4.1.1.

3.2.3.  Delta Representation

   The delta representation defines a header as a reference to a
   (name,value) pair contained in the header table.  The names must
   match between the represented header and the reference pair.  The
   values should start by a common substring between the represented
   header and the reference pair.

   A delta header is represented as:

   o  An integer representing the index of the reference (name, value)
      pair, as described in Section 4.1.1.  The pair name must match the
      name of the header.



Ruellan, et al.        Expires September 12, 2013               [Page 7]

Documentation               HTTP Header Diff                  March 2013


   o  An integer representing the length of the common prefix shared
      between the header value and the pair value, as described in
      Section 4.1.1.

   o  A string representing the suffix value to append to the common
      prefix to obtain the header value, as defined in Section 4.1.2.

4.  Detailed Format

4.1.  Low-level representations

4.1.1.  Integer representation

   Integers are used to represent name indexes, pair indexes or string
   lengths.  The integer representation keeps byte-alignment as much as
   possible as this allows various processing optimizations as well as
   efficient use of DEFLATE.  For that purpose, an integer
   representation always finishes at the end of a byte.

   An integer is represented in two parts: a prefix that fills the
   current byte and an optional list of bytes that are used if the
   integer value does not fit in the prefix.  The number of bits of the
   prefix (called N) is a parameter of the integer representation.

   The N-bit prefix allows filling the current byte.  If the value is
   small enough (strictly less than 2^N-1), it is encoded within the
   N-bit prefix.  Otherwise all the bits of the prefix are set to 1 and
   the value is encoded using an unsigned variable length integer [2]
   representation.

   The algorithm to represent an integer I is as follows:

   1.  If I < 2^N - 1, encode I on N bits

   2.  Else, encode 2^N - 1 on N bits and do the following steps:

   3.

       1.  Set I to (I - 2^N - 1) and Q to 1

       2.  While Q > 0

       3.

           1.  Compute Q and R, quotient and remainder of I divided by
               2^7





Ruellan, et al.        Expires September 12, 2013               [Page 8]

Documentation               HTTP Header Diff                  March 2013


           2.  If Q is strictly greater than 0, write one 1 bit;
               otherwise, write one 0 bit

           3.  Encode R on the next 7 bits

           4.  I = Q

4.1.1.1.  Example 1: Encoding 10 using a 5-bit prefix

   The value 10 is to be encoded with a 5-bit prefix.

   o  10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit
      prefix.

   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  X  |  X  |  X  |  0  |  1  |  0  |  1  |  0  | 10 stored on 5 bits
   +-----+-----+-----+-----+-----+-----+-----+-----+


4.1.1.2.  Example 2: Encoding 1337 using a 5-bit prefix

   The value I=1337 is to be encoded with a 5-bit prefix.

   o  1337 is greater than 31 (= 2^5 - 1).

   o

      *  The 5-bit prefix is filled with its max value (31).

   o  The value to represent on next bytes is I = 1337 - 2^5 = 1305.

   o

      *  1305 = 128*10 + 25, i.e.  Q=10 and R=25.

      *  Q is greater than 1, bit 8 is set to 1.

      *  The remainder R=25 is encoded on next 7 bits.

      *  I is replaced by the quotient Q=10.

   o  The value to represent on next bytes is I = 10.

   o

      *  10 = 128*0 + 10, i.e.  Q=0 and R=10.



Ruellan, et al.        Expires September 12, 2013               [Page 9]

Documentation               HTTP Header Diff                  March 2013


      *  Q is equal to 0, bit 16 is set to 0.

      *  The remainder R=10 is encoded on next 7 bits.

      *  I is replaced by the quotient Q=0.

   o  The process ends.

    +----+-----+-----+-----+-----+-----+-----+-----+
   |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  X  |  X  |  X  |  1  |  1  |  1  |  1  |  1  |  Prefix = 31
   |  1  |  0  |  0  |  1  |  1  |  0  |  0  |  1  |  Q>=1, R=25
   |  0  |  0  |  0  |  0  |  1  |  0  |  1  |  0  |  Q=0 , R=10
   +-----+-----+-----+-----+-----+-----+-----+-----+


4.1.2.  String literal representation

   Literal strings can represent header names, header values or header
   values suffix in the case of delta coding.  They are encoded in two
   parts:

   1.  The string length, defined as the number of bytes needed to store
       its UTF-8 representation, is represented as an integer with a
       zero bits prefix.  If the string length is strictly less than
       128, it is represented as one byte.

   2.  The string value represented as a list of UTF-8 characters.

4.2.  Indexed Header Representation

   Indexed headers can be represented as short indexed header if the
   matching pair index is strictly below 64.  Otherwise it is
   represented as a long indexed header.

4.2.1.  Short Indexed Header

   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   2   |   3   |   4   |   5   |   6   |   7   |
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   1   |   0   |             00 0000 - 11 1111                 |
   |       |       |            Matching pair index                |
   |       |       |         (if strictly lower than 64)           |
   +-------+-------+-------+-------+-------+-------+-------+-------+






Ruellan, et al.        Expires September 12, 2013              [Page 10]

Documentation               HTTP Header Diff                  March 2013


   This representation starts with the '10' 2-bit pattern, followed by
   the index of the matching pair, represented on 6 bits.  A short
   indexed header is always coded in one byte.

4.2.2.  Long Indexed Header

   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   2   |   3   |  ...  |  ...  |   e   |   f   |
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   1   |   1   |  00  0000 0000 0000 - 11 1111 1111 1111 1111  |
   |       |       |                Matching pair index            |
   |       |       |        (if equal to or greater than 64)       |
   +-------+-------+-------+-------+-------+-------+-------+-------+


   This representation starts with the '11' 2-bit pattern, followed by
   the value of the index of the matching pair minus 64, represented as
   an integer with a 14-bit prefix A long indexed header is coded in two
   bytes if the index minus 64 is strictly below 16383.

4.3.  Literal Header Representation

4.3.1.  Literal Header without Indexing

   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   2   |   3   |   4   |   5   |   6   |   7   |
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |       |       |       |                0 0000                 |
   |       |       |       |         New header name symbol        |
   |   0   |   0   |   0   |---------------------------------------|
   |       |       |       |             0 0001 - 1 1111           |
   |       |       |       |    Index of matching header name      |
   +-------+-------+-------+-------+-------+-------+-------+-------+


   This representation, which does not involve updating the header
   table, starts with the '000' 3-bit pattern.

   If the header name matches a header name entry whose index is IN, the
   value (IN+1) is represented as an integer with a 5-bit prefix.  Note
   that if the index is strictly below 30, one byte is used.

   If the header name does not match a header name entry, the value 0 is
   represented on 5 bits followed by the header name, represented as a
   literal string.

   Header name representation is followed by the header value
   represented as a literal string.



Ruellan, et al.        Expires September 12, 2013              [Page 11]

Documentation               HTTP Header Diff                  March 2013


4.3.2.  Literal Header with Indexing

   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   2   |   3   |   4   |   5   |   6   |   7   |
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |       |       |       |       |             0000              |
   |       |       |       |Indexing|     New header name symbol    |
   |   0   |   0   |   1   |       |-------------------------------|
   |       |       |       | Mode  |           0001 - 1111         |
   |       |       |       |       | Index of matching header name |
   +-------+-------+-------+-------+-------+-------+-------+-------+


   This representation starts with the '001' 3-bit pattern.  The fourth
   bit sets the indexing mode: 0 for incremental indexing, 1 for
   substitution indexing.

   If the header name matches a header name entry whose index is IN, the
   value (IN+1) is represented as an integer with a 4-bit prefix.  Note
   that if the index is strictly below 14, one byte is used.

   If the header name does not match a header name entry, the value 0 is
   represented on 4 bits followed by the header name, represented as a
   literal string.

   Header name representation is followed by the header value
   represented as a string as described in Section 4.1.2.  In the case
   of substitution indexing, the substituted (name,value) pair index is
   inserted before the header value as a zero-bit prefix integer.  The
   header value is represented as a literal string.

4.4.  Delta Header Representation

4.4.1.  Delta Header without Indexing

   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   2   |   3   |   4   |   5   |   6   |   7   |
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   0   |           0 0000 - 1 1111             |
   |       |       |       |        Index of reference pair        |
   +-------+-------+-------+-------+-------+-------+-------+-------+


   This representation starts with the '010' 3-bit pattern.

   It continues with the index IR of the reference header pair.  The
   value IR is represented as an integer with a 5-bit prefix.  Note that
   if the index is strictly below 31, one byte is used.



Ruellan, et al.        Expires September 12, 2013              [Page 12]

Documentation               HTTP Header Diff                  March 2013


   Index value is followed by:

   1.  the length of the common prefix shared between the header value
       and the pair value, represented as an integer with a zero-bit
       prefix.

   2.  the header value suffix represented as a literal string.

4.4.2.  Delta Header with Indexing

   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   2   |   3   |   4   |   5   |   6   |   7   |
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |   0   |   1   |   1   |Indexing|       0000 - 1111            |
   |       |       |       |  Mode |  Index of reference pair      |
   +-------+-------+-------+-------+-------+-------+-------+-------+


   This representation starts with the '011' 3-bit pattern.  The fourth
   bit sets the indexing mode, 0 for incremental indexing and 1 for
   substitution indexing.

   It continues with the index IR of the reference header pair.  The
   value IR is represented as an integer with a 4-bit prefix.  Note that
   if the index is strictly below 15, one byte is used.

   Index value is followed by:

   1.  the length of the common prefix shared between the header value
       and the pair value, represented as an integer with a zero-bit
       prefix.

   2.  the header value suffix, represented as a literal string.

5.  Parameter Negotiation

   Two parameters may be used to accomodate the client and server
   processing and memory requirements:

   o  A parameter Nh that configures the size of the header table.  The
      size can be computed as 2^Nh.  Nh is exchanged as an unsigned
      integer.

   o  A parameter Nd that configures the Deflate step.  If Nd is equal
      to zero, no Deflate step is used.  Otherwise, Deflate is used with
      a sliding window equal to 2^Nd.  Huffman-only coding is advertised
      using the Deflate block initial bits.  Nd is exchanged as an
      unsigned integer.



Ruellan, et al.        Expires September 12, 2013              [Page 13]

Documentation               HTTP Header Diff                  March 2013


   This section should be further completed, including but not limited
   to the following points:

   o  Define default values?

   o  Define when negotiation happens: at the beginning only, any time
      during the session...

   o  Define how are exchanged these parameters, probably using SETTINGS
      frames, through the definition of 4 settings (outgoing-Nd,
      outgoing-Nh, preferred-incomingNd, preferred-incoming-Nh).

6.  Open Questions

6.1.  Typed Codecs

   Typed codecs may be useful to represent header values, especially on
   response side.  An additional typed header representation could be
   defined, adding support for a small number of codecs such as:

   o  An Integer codec: may be useful for headers such as 'Age' and
      'Content-Length'.

   o  A Date codec: may be useful for headers such as 'Date', 'Expires',
      'If-Modified-Since', 'Last-Modified'.

6.2.  Specific header processing

   Some (name,value) pairs may be singled out to improve network nodes
   processing, such as:

   o  The request line (verb, version and URL) for HTTP requests.

   o  The response line (status and version) for HTTP responses.

   For those headers, the specification may define specific rules that
   can improve the processing cost, at the expense of some compression
   loss:

   o  All those headers are placed as the first headers in the
      SYN_STREAM frame, with a predefined order.

   o  Verb, version and status are represented as integers with zero-bit
      prefix.

   o  Indexed, delta or literal representation may be used for URL
      values.  In the case of delta and literal representation, only the
      substitution mode is used so that a processor only needs to store



Ruellan, et al.        Expires September 12, 2013              [Page 14]

Documentation               HTTP Header Diff                  March 2013


      the URL of the previous message to compute the URL of the current
      message.

6.3.  Security Issues

   Adequate use of delta and indexed representation before using of
   Deflate are supposed to solve security issues such as the CRIME
   attack.  For instance, if cookie headers are represented as indexed
   headers as much as possible, attackers may be prevented from
   progressively learning its value.

   This point should be confirmed with deeper analysis.  Additional
   study should also be done to evaluate whether the proposed indexed
   and delta representation create any new security issue.

6.4.  Deflate Partial Usage

   To circumvent Deflate issues related to both security and network
   intermediaries, the header set of a given message can be split in two
   buckets.  A first bucket would be sent without using Deflate, while
   the second bucket would be further compressed using Deflate.  The
   decision would be done by the encoder.  The specification could
   define a minimum set of headers that SHOULD never be compressed using
   Deflate, for instance URLs and cookies.

   Another possibility would be to define Deflate as a specific
   representation.  The use of Deflate would then be decided on per-
   header basis.  That would enable excluding any header that may
   contain sensitive data.  The overall scheme would be less efficient
   though (padding bits and so on).

   Additional analysis of the complexity and benefit of these approaches
   would be needed to go further.  For instance, these approaches should
   be compared to the use of Deflate restricted to Huffman-coding in
   terms of simplicity and compression benefits.

6.5.  Max length and entry numbers

   The integer representation allows representation of unbounded values.
   If bounding the table entries number or string lengths, the integer
   encoding may be further optimized.

   o  Decide whether to limit the length of strings to a max value and
      if so which value, 32768?

   o  Decide whether to limit name table entries to 256?

   o  Decide whether to limit header table entries to 16384?



Ruellan, et al.        Expires September 12, 2013              [Page 15]

Documentation               HTTP Header Diff                  March 2013


7.  Security Considerations

   This section should be completed according the previous sections.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  References

Appendix A.  Initial header names

A.1.  Requests

   Indexes strictly lower than 14 are always encoded on 1 byte.  Hence,
   the 14 most frequent names should be set in the 14 first positions.
   This table may be updated based on statistical analysis of header
   names frequency and specific HTTP 2.0 header rules (like removal of
   'proxy-connection', url being split or not...).

   +---------+------------------------------------+
   |  Index  | Header Name                        |
   +---------+------------------------------------+
   |    0    | accept                             |
   +---------+------------------------------------+
   |    1    | accept-charset                     |
   +---------+------------------------------------+
   |    2    | accept-encoding                    |
   +---------+------------------------------------+
   |    3    | accept-language                    |
   +---------+------------------------------------+
   |    4    | cookie                             |
   +---------+------------------------------------+
   |    5    | method                             |
   +---------+------------------------------------+
   |    6    | host                               |
   +---------+------------------------------------+
   |    7    | if-modified-since                  |
   +---------+------------------------------------+
   |    8    | keep-alive                         |
   +---------+------------------------------------+
   |    9    | url                                |
   +---------+------------------------------------+
   |   10    | user-agent                         |
   +---------+------------------------------------+
   |   11    | version                            |
   +---------+------------------------------------+
   |   12    | proxy-connection                   |



Ruellan, et al.        Expires September 12, 2013              [Page 16]

Documentation               HTTP Header Diff                  March 2013


   +---------+------------------------------------+
   |   13    | referer                            |
   +---------+------------------------------------+
   |   14    | accept-datetime                    |
   +---------+------------------------------------+
   |   15    | authorization                      |
   +---------+------------------------------------+
   |   16    | allow                              |
   +---------+------------------------------------+
   |   17    | cache-control                      |
   +---------+------------------------------------+
   |   18    | connection                         |
   +---------+------------------------------------+
   |   19    | content-length                     |
   +---------+------------------------------------+
   |   20    | content-md5                        |
   +---------+------------------------------------+
   |   21    | content-type                       |
   +---------+------------------------------------+
   |   22    | date                               |
   +---------+------------------------------------+
   |   23    | expect                             |
   +---------+------------------------------------+
   |   24    | from                               |
   +---------+------------------------------------+
   |   25    | if-match                           |
   +---------+------------------------------------+
   |   26    | if-none-match                      |
   +---------+------------------------------------+
   |   27    | if-range                           |
   +---------+------------------------------------+
   |   28    | if-unmodified-since                |
   +---------+------------------------------------+
   |   29    | max-forwards                       |
   +---------+------------------------------------+
   |   30    | pragma                             |
   +---------+------------------------------------+
   |   31    | proxy-authorization                |
   +---------+------------------------------------+
   |   32    | range                              |
   +---------+------------------------------------+
   |   33    | te                                 |
   +---------+------------------------------------+
   |   34    | upgrade                            |
   +---------+------------------------------------+
   |   35    | via                                |
   +---------+------------------------------------+
   |   36    | warning                            |



Ruellan, et al.        Expires September 12, 2013              [Page 17]

Documentation               HTTP Header Diff                  March 2013


   +---------+------------------------------------+


A.2.  Responses

   Indexes strictly lower than 14 are always encoded on 1 byte.  Hence,
   the 14 most frequent names should be set in the 14 first positions.
   This table may be updated based on statistical analysis of header
   names frequency and specific HTTP 2.0 header rules.

   +---------+------------------------------------+
   |  Index  | Header Name                        |
   +---------+------------------------------------+
   |    0    | age                                |
   +---------+------------------------------------+
   |    1    | cache-control                      |
   +---------+------------------------------------+
   |    2    | content-length                     |
   +---------+------------------------------------+
   |    3    | content-type                       |
   +---------+------------------------------------+
   |    4    | date                               |
   +---------+------------------------------------+
   |    5    | etag                               |
   +---------+------------------------------------+
   |    6    | expires                            |
   +---------+------------------------------------+
   |    7    | last-modified                      |
   +---------+------------------------------------+
   |    8    | server                             |
   +---------+------------------------------------+
   |    9    | set-cookie                         |
   +---------+------------------------------------+
   |   10    | status                             |
   +---------+------------------------------------+
   |   11    | vary                               |
   +---------+------------------------------------+
   |   12    | version                            |
   +---------+------------------------------------+
   |   13    | via                                |
   +---------+------------------------------------+
   |   14    | access-control-allow-origin        |
   +---------+------------------------------------+
   |   15    | accept-ranges                      |
   +---------+------------------------------------+
   |   16    | allow                              |
   +---------+------------------------------------+
   |   17    | connection                         |



Ruellan, et al.        Expires September 12, 2013              [Page 18]

Documentation               HTTP Header Diff                  March 2013


   +---------+------------------------------------+
   |   18    | content-disposition                |
   +---------+------------------------------------+
   |   19    | content-encoding                   |
   +---------+------------------------------------+
   |   20    | content-language                   |
   +---------+------------------------------------+
   |   21    | content-location                   |
   +---------+------------------------------------+
   |   22    | content-md5                        |
   +---------+------------------------------------+
   |   23    | content-range                      |
   +---------+------------------------------------+
   |   24    | link                               |
   +---------+------------------------------------+
   |   25    | location                           |
   +---------+------------------------------------+
   |   26    | p3p                                |
   +---------+------------------------------------+
   |   27    | pragma                             |
   +---------+------------------------------------+
   |   28    | proxy-authenticate                 |
   +---------+------------------------------------+
   |   29    | refresh                            |
   +---------+------------------------------------+
   |   30    | retry-after                        |
   +---------+------------------------------------+
   |   31    | strict-transport-security          |
   +---------+------------------------------------+
   |   32    | trailer                            |
   +---------+------------------------------------+
   |   33    | transfer-encoding                  |
   +---------+------------------------------------+
   |   34    | warning                            |
   +---------+------------------------------------+
   |   35    | www-authenticate                   |
   +---------+------------------------------------+


A.3.  Example

   Here is an example that illustrates different representations and how
   tables are updated.

A.3.1.  First header set

   The first header set to represent is the following:




Ruellan, et al.        Expires September 12, 2013              [Page 19]

Documentation               HTTP Header Diff                  March 2013


   url: http://www.example.org/my-example/index.html
   user-agent: my-user-agent
   x-my-header: first


   The header table is empty, all headers are represented as literal
   headers with indexing.  The 'x-my-header' header name is not in the
   header name table and is encoded literally.  This gives the following
   representation:

   0x2A      (literal header with indexing, name index = 9)
   0x2C      (header value string length = 44)
   http://www.example.org/my-example/index.html
   0x2B      (literal header with indexing, name index = 10)
   0x0D      (header value string length = 43)
   my-user-agent
   0x20      (literal header with indexing, new name)
   0x0B      (header name string length = 11)
   x-my-header
   0x05      (header value string length = 5)
   first


   The header tables are as follow after the processing of these
   headers:

   Name table
   +---------+---------------------------------------------+
   |  Index  | Header Name                                 |
   +---------+---------------------------------------------+
   |    0    | accept                                      |
   +---------+---------------------------------------------+
   |    1    | accept-charset                              |
   +---------+---------------------------------------------+
   |   ...   | ...                                         |
   +---------+---------------------------------------------+
   |   36    | warning                                     |
   +---------+---------------------------------------------+
   |   37    | x-my-header                                 | added name
   +---------+---------------------------------------------+


   Header table
   +----+-------------+------------------------------------+
   | 0  |     url     | http://www.example.org/            | added pair
   |    |             |       my-example/index.html        |
   +----+-------------+------------------------------------+
   | 1  |  user-agent | my-user-agent                      | added pair



Ruellan, et al.        Expires September 12, 2013              [Page 20]

Documentation               HTTP Header Diff                  March 2013


   +----+-------------+------------------------------------+
   | 2  | x-my-header | first                              | added pair
   +----+-------------+------------------------------------+


A.3.2.  Second header set

   The second header set to represent is the following:

   url: http://www.example.org/my-example/resources/script.js
   user-agent: my-user-agent
   x-my-header: second


   The url header is represented as a delta header with substitution.
   The user-agent header will be represented as a short header.  The x
   -my-header will be represented as a literal header with indexing.

   0x70       (delta header with substitution, header index = 0)
   0x22       (common prefix length = 32)
   0x13       (suffix value length = 19)
   resources/script.js
   0x81       (indexed header, index = 1)
   0x2f 0x17  (literal header with indexing, name index = 37)
   0x05       (header value string length = 5)
   second


   The name table remains unchanged.  The header table is updated as
   follow:

   +----+-------------+------------------------------------+
   | 0  |     url     | http://www.example.org/            | substituted
   |    |             |     my-example/resources/script.js | pair
   +----+-------------+------------------------------------+
   | 1  |  user-agent | my-user-agent                      |
   +----+-------------+------------------------------------+
   | 2  | x-my-header | first                              |
   +----+-------------+------------------------------------+
   | 3  | x-my-header | second                             | added pair
   +----+-------------+------------------------------------+










Ruellan, et al.        Expires September 12, 2013              [Page 21]

Documentation               HTTP Header Diff                  March 2013


Authors' Addresses

   Herve Ruellan

   Email: herve.ruellan@crf.canon.fr


   Jun Fujisawa
   Canon, Inc.
   3-30-2 Shimomaruko
   Ohta-ku, Tokyo   146-8501
   Japan

   Email: fujisawa.jun@canon.co.jp


   Romain Bellessort

   Email: romain.bellessort@crf.canon.fr


   Youenn Fablet

   Email: youenn.fablet@crf.canon.fr


























Ruellan, et al.        Expires September 12, 2013              [Page 22]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/