One document matched: draft-ietf-httpbis-header-compression-01.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='lib/rfc2629.xslt' ?>
<!--<?rfc header="Documentation"?>-->
<!--?rfc private="RFC2629 through XSLT"?-->
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no"?>
<?rfc editing="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?ref rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!-- <?rfc topblock="no"?> -->
<!--<?rfc strict="no"?>-->
<rfc category="info"
ipr="trust200902"
docName="draft-ietf-httpbis-header-compression-01"
>
<front>
<title abbrev="HTTP/2.0 Header Compression">HTTP/2.0 Header Compression</title>
<author initials="R." surname="Peon" fullname="Roberto Peon">
<organization>Google, Inc</organization>
<address>
<email>fenix@google.com</email>
</address>
</author>
<author initials="H." surname="Ruellan" fullname="Hervé Ruellan">
<organization>Canon CRF</organization>
<address>
<email>herve.ruellan@crf.canon.fr</email>
</address>
</author>
<date month="July" year="2013"/>
<area>Applications</area>
<workgroup>HTTPbis Working Group</workgroup>
<keyword>HTTP</keyword>
<keyword>Header</keyword>
<abstract>
<t>
This document describes a format adapted to efficiently
represent HTTP headers in the context of HTTP/2.0.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document describes a format adapted to efficiently
represent HTTP headers in the context of HTTP/2.0.
</t>
</section>
<section title="Overview" anchor="overview">
<t>
In HTTP/1.X, HTTP headers, which are necessary for the
functioning of the protocol, are transmitted with no
transformations. Unfortunately, the amount of redundancy in
both the keys and the values of these headers is astonishingly
high, and is the cause of increased latency on
lower bandwidth links. This indicates that an alternate
encoding for headers would be beneficial to latency, and that
is what is proposed here.
As shown by <xref target="SPDY">SPDY</xref>, Deflate
compresses HTTP very effectively. However, the use of a
compression scheme which allows for arbitrary matches against
the previously encoded data (such as Deflate) exposes users to
security issues.
In particular, the compression of sensitive data, together
with other data controlled by an attacker, may lead to leakage
of that sensitive data, even when the resultant bytes are
transmitted over an encrypted channel.
Another consideration is that processing and memory costs of a
compressor such as Deflate may also be too high for some
classes of devices, for example when doing forward or reverse
proxying.
</t>
<section title="Outline">
<t>
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.
This scheme is believed to be safe for all known attacks
against the compression context today. 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.
</t>
<t>
The encoder is responsible for deciding which headers to
insert as (name, value) pairs in the header table. The
decoder then does exactly what the encoder prescribes,
ending in a state that exactly matches the encoder's
state. This enables decoders to remain simple and
understand a wide variety of encoders.
</t>
<t>
A header may be represented as a literal or as an index.
If represented as a literal, the representation specifies
whether this header is used to update the indexing table.
The different representations are described in <xref
target="header.representation" />.
</t>
<t>
A set of headers is coded as a difference from the
previous set of headers.
</t>
<t>
An example illustrating the use these different mechanisms
to represent headers is available in <xref
target="example"/>.
</t>
</section>
</section>
<section title="Header Encoding" anchor="header.encoding">
<section title="Encoding Components" anchor="encoding.components">
<t>
The encoding and decoding of headers relies on a few
components. First, a header table (see <xref
target="header.table"/>) is used to associate headers
to index values. Second, a set of headers is encoded as a
difference from the previous reference set of headers (see
<xref target="differential.coding"/>).
</t>
<t>
As messages are exchanged in two directions, from client
to server and from server to client, there are two sets of
components: one for each direction. All the headers sent
in messages from the client to the server are encoded (and
decoded) using one set of components. All the headers sent
in messages from the server to the client (including
headers contained in PUSH_PROMISE frame) are encoded
using the other set of compotents.
</t>
</section>
<section title="Header Table" anchor="header.table">
<t>
A header table consists of an ordered list of (name,
value) pairs. A pair is either inserted at the end of the
table or replaces an existing pair depending on the chosen
representation. A pair can be represented as an index
which is its position in the table, starting with 0 for
the first entry.
</t>
<t>
An input header name matches the header name of a (name,
value) pair stored in the Header Table if they are
equal using a character-based, <spanx>case
sensitive</spanx> comparison.
An input header value matches the header value of a
(name, value) pair stored in the Header Table if they are
equal using a character-based, <spanx>case
sensitive</spanx> comparison.
An input header (name, value) pair matches a pair in the
Header Table if both the name and value are matching as
per above.
</t>
<t>
Generally, the header table will not contain duplicate
header (name, value) entries. However, implementations
MUST be prepared to accept duplicates without signaling an
error. If duplicates are added to the table, they MUST be
treated as distinct entries with their own index
positions.
</t>
<t>
The header table is progressively updated based on headers
represented as literal (as defined in <xref
target="literal" />). Two update mechanisms are
defined:
<list style="symbols">
<t>
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.
</t>
<t>
Substitution indexing: the represented header
contains an index to an existing (name, value)
pair. The existing pair value is replaced by the
pair representing the new header.
</t>
</list>
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.
</t>
<t>
The header table size can be bounded so as to limit the
memory requirements (see the SETTINGS_MAX_BUFFER_SIZE in
<xref target="parameter.negotiation"/>). The header table
size is defined as the sum of the size of each entry of
the table. The size of an entry is the sum of the length
in bytes (as defined in <xref
target="string.literal.representation" />) of its
name, of value's length in bytes and of 32 bytes (for
accounting for the entry structure overhead). The header
table size MUST NOT exceed this limit.
</t>
<t>
Before adding a new entry to the header table or changing
an existing one, a check has to be performed to ensure
that the change will not cause the table to grow in size
beyond the SETTINGS_MAX_BUFFER_SIZE limit. If necessary,
one or more items from the beginning of the table are
removed until there is enough free space available to make
the modification. Dropping an entry from the beginning of
the table causes the index positions of the remaining
entries in the table to be decremented by 1.
<cref>
Feedback is needed on this automatic eviction
strategy.
</cref>
</t>
<t>
When using substitution indexing, it is possible that the
existing item being replaced might be one of the items
removed when performing the necessary size adjustment. In
such cases, the substituted value being added to the
header table is inserted at the beginning of the header
table (at index position #0) and the index positions of
the other remaining entries in the table are incremented
by 1.
</t>
<t>
To optimize the representation of the headers exchanged at
the beginning of an HTTP/2.0 session, the header table is
initialized with common headers. Two lists of initial
headers are provided in <xref target="initial.headers"/>.
One is for messages sent from a client to a server, the
other is for messages sent from a server to a client.
</t>
</section>
<section title="Header Representation" anchor="header.representation">
<section title="Literal Representation" anchor="literal">
<t>
The literal representation defines a new header. A
literal header is represented as:
<list style="symbols">
<t>
A header name, with two possible
representations:
<list style="symbols">
<t>
A literal string, as described in
<xref
target="string.literal.representation"/>.
</t>
<t>
A index in the header table
referencing the name of the
corresponding header. The index is
represented as an integer, as
described in <xref
target="integer.representation"/>.
</t>
</list>
</t>
<t>
The header value, represented as a literal
string, as described in <xref
target="string.literal.representation" />.
</t>
</list>
</t>
</section>
<section title="Indexed Representation" anchor="indexed">
<t>
The indexed representation defines a header as a match
to a (name, value) pair in the header table. An
indexed header is represented as:
<list style="symbols">
<t>
An integer representing the index of the
matching (name, value) pair, as described in
<xref target="integer.representation" />.
</t>
</list>
</t>
</section>
</section>
<section title="Differential Coding" anchor="differential.coding">
<t>
A set of headers is encoded as a difference from the
previous reference set of headers. The initial reference
set of headers is the empty set.
</t>
<t>
An indexed representation toggles the presence of the
header in the current set of headers. If the header
corresponding to the indexed representation was not in the
set, it is added to the set. If the header index was in
the set, it is removed from it.
</t>
<t>
A literal representation adds a header to the current set
of headers.
</t>
<t>
To ensure a correct decoding of a set of headers, the
following steps or equivalent ones MUST be executed by the
decoder.
</t>
<t>
First, upon starting the decoding of a new set of headers,
the reference set of headers is interpreted into the
working set of headers: for each header in the reference
set, an entry is added to the working set, containing the
header name, its value, and its current index in the
header table.
</t>
<t>
Then, the header representations are processed in their
order of occurrence in the frame.
</t>
<t>
For an indexed representation, the decoder checks whether
the index is present in the working set. If true, the
corresponding entry is removed from the working set. If
several entries correspond to this encoded index, all
these entries are removed from the working set. If
the index is not present in the working set, it is used to
retrieve the corresponding header from the header table,
and a new entry is added to the working set representing
this header.
</t>
<t>
For a literal representation, a new entry is added to the
working set representing this header. If the literal
representation specifies that the header is to be indexed,
the header is added accordingly to the header table, and
its index is included in the entry in the working set.
Otherwise, the entry in the working set contains an
undefined index.
</t>
<t>
When all the header representations have been processed,
the working set contains all the headers of the set of
headers.
</t>
<t>
The new reference set of headers is computed by removing
from the working set all the headers that are not present
in the header table.
</t>
<t>
It should be noted that during the decoding of the header
representations, the same index may be associated to
different headers in the working set and in the header
table.
</t>
</section>
</section>
<section title="Detailed Format" anchor="detailed.format">
<section title="Header Blocks" anchor="header.blocks">
<t>
A header block consists of a set of header fields, which
are name-value pairs. Each header field is encoded using
one of the header representation.
</t>
</section>
<section title="Low-level representations" anchor="string.encoding">
<section title="Integer representation" anchor="integer.representation">
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <eref
target="http://en.wikipedia.org/wiki/Variable-length_quantity">
unsigned variable length integer</eref>
representation.
</t>
<t>
The algorithm to represent an integer I is as follows:
<list style="numbers">
<t>If I < 2^N - 1, encode I on N bits</t>
<t>Else, encode 2^N - 1 on N bits and do the
following steps:</t>
<t><list style="numbers">
<t>Set I to (I - (2^N - 1)) and Q to 1</t>
<t>While Q > 0</t>
<t><list style="numbers">
<t>Compute Q and R, quotient and remainder
of I divided by 2^7</t>
<t>If Q is strictly greater than 0, write
one 1 bit; otherwise, write one 0
bit</t>
<t>Encode R on the next 7 bits</t>
<t>I = Q</t>
</list></t>
</list></t>
</list>
</t>
<section title="Example 1: Encoding 10 using a 5-bit prefix"
anchor="integer.representation.example1">
<t>
The value 10 is to be encoded with a 5-bit prefix.
<list style="symbols">
<t>
10 is less than 31 (= 2^5 - 1) and is
represented using the 5-bit prefix.
</t>
</list>
</t>
<figure>
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits
+---+---+---+---+---+---+---+---+
</artwork>
</figure>
</section>
<section title="Example 2: Encoding 1337 using a 5-bit prefix"
anchor="integer.representation.example2">
<t>
The value I=1337 is to be encoded with a 5-bit
prefix.
<list style="symbols">
<t>1337 is greater than 31 (= 2^5 - 1).</t>
<t><list style="symbols">
<t>The 5-bit prefix is filled with its max
value (31).</t>
</list></t>
<t>The value to represent on next bytes is I =
1337 - (2^5 - 1) = 1306.</t>
<t><list style="symbols">
<t>1306 = 128*10 + 26, i.e. Q=10 and
R=26.</t>
<t>Q is greater than 1, bit 8 is set to
1.</t>
<t>The remainder R=26 is encoded on next 7
bits.</t>
<t>I is replaced by the quotient Q=10.</t>
</list></t>
<t>The value to represent on next bytes is I =
10.</t>
<t><list style="symbols">
<t>10 = 128*0 + 10, i.e. Q=0 and R=10.</t>
<t>Q is equal to 0, bit 16 is set to
0.</t>
<t>The remainder R=10 is encoded on next 7
bits.</t>
<t>I is replaced by the quotient Q=0.</t>
</list></t>
<t>The process ends.</t>
</list>
</t>
<figure>
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31
| 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | Q>=1, R=26
| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | Q=0 , R=10
+---+---+---+---+---+---+---+---+
</artwork>
</figure>
</section>
</section>
<section title="String literal representation" anchor="string.literal.representation">
<t>
Literal strings can represent header names or header
values. They are encoded in two parts:
<list style="numbers">
<t>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.
</t>
<t>
The string value represented as a list of
UTF-8 characters.
</t>
</list>
</t>
</section>
</section>
<section title="Indexed Header Representation">
<figure title="Indexed Header">
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | Index (7+) |
+---+---------------------------+
</artwork>
</figure>
<t>
This representation starts with the '1' 1-bit pattern,
followed by the index of the matching pair, represented as
an integer with a 7-bit prefix.
</t>
</section>
<section title="Literal Header Representation">
<section title="Literal Header without Indexing">
<figure title="Literal Header without Indexing - Indexed Name">
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | Index (5+) |
+---+---+---+-------------------+
| Value Length (8+) |
+-------------------------------+
| Value String (Length octets) |
+-------------------------------+
</artwork>
</figure>
<figure title="Literal Header without Indexing - New Name">
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | 0 |
+---+---+---+-------------------+
| Name Length (8+) |
+-------------------------------+
| Name String (Length octets) |
+-------------------------------+
| Value Length (8+) |
+-------------------------------+
| Value String (Length octets) |
+-------------------------------+
</artwork>
</figure>
<t>
This representation, which does not involve updating
the header table, starts with the '011' 3-bit pattern.
</t>
<t>
If the header name matches the header name of a (name,
value) pair stored in the Header Table, the index of
the pair increased by one (index + 1) is represented
as an integer with a 5-bit prefix. Note that if the
index is strictly below 31, one byte is used.
</t>
<t>
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.
</t>
<t>
Header name representation is followed by the header
value represented as a literal string as described in
<xref target="string.literal.representation" />.
</t>
</section>
<section title="Literal Header with Incremental Indexing">
<figure title="Literal Header with Incremental Indexing -
Indexed Name">
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | Index (5+) |
+---+---+---+-------------------+
| Value Length (8+) |
+-------------------------------+
| Value String (Length octets) |
+-------------------------------+
</artwork>
</figure>
<figure title="Literal Header with Incremental Indexing -
New Name">
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 |
+---+---+---+-------------------+
| Name Length (8+) |
+-------------------------------+
| Name String (Length octets) |
+-------------------------------+
| Value Length (8+) |
+-------------------------------+
| Value String (Length octets) |
+-------------------------------+
</artwork>
</figure>
<t>
This representation starts with the '010' 3-bit
pattern.
</t>
<t>
If the header name matches the header name of a (name,
value) pair stored in the Header Table, the index of
the pair increased by one (index + 1) is represented
as an integer with a 5-bit prefix. Note that if the
index is strictly below 31, one byte is used.
</t>
<t>
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.
</t>
<t>
Header name representation is followed by the header
value represented as a literal string as described in
<xref target="string.literal.representation" />.
</t>
</section>
<section title="Literal Header with Substitution Indexing">
<figure title="Literal Header with Substitution Indexing -
Indexed Name">
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | Index (6+) |
+---+---+-----------------------+
| Substituted Index (8+) |
+-------------------------------+
| Value Length (8+) |
+-------------------------------+
| Value String (Length octets) |
+-------------------------------+
</artwork>
</figure>
<figure title="Literal Header with Substitution Indexing -
New Name">
<artwork type="inline">
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |
+---+---+-----------------------+
| Name Length (8+) |
+-------------------------------+
| Name String (Length octets) |
+-------------------------------+
| Substituted Index (8+) |
+-------------------------------+
| Value Length (8+) |
+-------------------------------+
| Value String (Length octets) |
+-------------------------------+
</artwork>
</figure>
<t>
This representation starts with the '00' 2-bit
pattern.
</t>
<t>
If the header name matches the header name of a (name,
value) pair stored in the Header Table, the index of
the pair increased by one (index + 1) is represented
as an integer with a 6-bit prefix. Note that if the
index is strictly below 62, one byte is used.
</t>
<t>
If the header name does not match a header name entry,
the value 0 is represented on 6 bits followed by the
header name, represented as a literal string.
</t>
<t>
The index of the substituted (name, value) pair is
inserted after the header name representation as a
0-bit prefix integer.
</t>
<t>
The index of the substituted pair MUST correspond to a
position in the header table containing a non-void
entry. An index for the substituted pair that
corresponds to empty position in the header table MUST
be treated as an error.
</t>
<t>
This index is followed by the header
value represented as a literal string as described in
<xref target="string.literal.representation" />.
</t>
</section>
</section>
</section>
<section anchor="parameter.negotiation" title="Parameter Negotiation">
<t>
A few parameters can be used to accomodate client and server
processing and memory requirements.
<cref>
These settings are currently not supported as they have
not been integrated in the main specification. Therefore,
the maximum buffer size for the header table is fixed at
4096 bytes.
</cref>
<list style="hanging">
<t hangText="SETTINGS_MAX_BUFFER_SIZE:">
Allows the sender to inform the remote endpoint of the
maximum size it accepts for the header table.
<vspace blankLines="0"/>
The default value is 4096 bytes.
<vspace blankLines="0"/>
<cref>Is this default value OK? Do we need a maximum size? Do we want to allow infinite buffer?</cref>
<vspace blankLines="0"/>
When the remote endpoint receives a SETTINGS frame
containing a SETTINGS_MAX_BUFFER_SIZE setting with a
value smaller than the one currently in use, it MUST
send as soon as possible a HEADER frame with a stream
identifier of 0x0 containing a value smaller than or
equal to the received setting value.
<vspace blankLines="0"/>
<cref>This changes slightly the behaviour of the
HEADERS frame, which should be updated as follows:
</cref>
<vspace blankLines="0"/>
A HEADER frame with a stream identifier of 0x0
indicates that the sender has reduced the maximum size
of the header table. The new maximum size of the
header table is encoded on 32-bit. The decoder MUST
reduce its own header table by dropping entries from
it until the size of the header table is lower than or
equal to the transmitted maximum size.
</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TODO?</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="SPDY" target="http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy">
<front>
<title>SPDY Protocol</title>
<author initials="M" surname="Belshe" fullname="Mike Belshe">
<organization>Twist</organization>
</author>
<author initials="R" surname="Peon" fullname="Roberto Peon">
<organization>Google</organization>
</author>
<date month="February" year="2012"/>
</front>
</reference>
</references>
<section title="Initial header names" anchor="initial.headers">
<t>
<cref>
The tables in this section should be updated based on
statistical analysis of header names frequency and specific
HTTP 2.0 header rules (like removal of some headers).
</cref>
<vspace blankLines="0"/>
<cref>
These tables are not adapted for headers contained in
PUSH_PROMISE frames. Either the tables can be merged, or the
table for responses can be updated.
</cref>
</t>
<section title="Requests">
<t>
The following table lists the pre-defined headers that
make-up the initial header table user to represent
requests sent from a client to a server.
</t>
<texttable anchor="initial.headers.request">
<ttcol>Index</ttcol>
<ttcol>Header Name</ttcol>
<ttcol>Header Value</ttcol>
<c>0</c><c>:scheme</c><c>http</c>
<c>1</c><c>:scheme</c><c>https</c>
<c>2</c><c>:host</c><c></c>
<c>3</c><c>:path</c><c>/</c>
<c>4</c><c>:method</c><c>GET</c>
<c>5</c><c>accept</c><c></c>
<c>6</c><c>accept-charset</c><c></c>
<c>7</c><c>accept-encoding</c><c></c>
<c>8</c><c>accept-language</c><c></c>
<c>9</c><c>cookie</c><c></c>
<c>10</c><c>if-modified-since</c><c></c>
<c>11</c><c>keep-alive</c><c></c>
<c>12</c><c>user-agent</c><c></c>
<c>13</c><c>proxy-connection</c><c></c>
<c>14</c><c>referer</c><c></c>
<c>15</c><c>accept-datetime</c><c></c>
<c>16</c><c>authorization</c><c></c>
<c>17</c><c>allow</c><c></c>
<c>18</c><c>cache-control</c><c></c>
<c>19</c><c>connection</c><c></c>
<c>20</c><c>content-length</c><c></c>
<c>21</c><c>content-md5</c><c></c>
<c>22</c><c>content-type</c><c></c>
<c>23</c><c>date</c><c></c>
<c>24</c><c>expect</c><c></c>
<c>25</c><c>from</c><c></c>
<c>26</c><c>if-match</c><c></c>
<c>27</c><c>if-none-match</c><c></c>
<c>28</c><c>if-range</c><c></c>
<c>29</c><c>if-unmodified-since</c><c></c>
<c>30</c><c>max-forwards</c><c></c>
<c>31</c><c>pragma</c><c></c>
<c>32</c><c>proxy-authorization</c><c></c>
<c>33</c><c>range</c><c></c>
<c>34</c><c>te</c><c></c>
<c>35</c><c>upgrade</c><c></c>
<c>36</c><c>via</c><c></c>
<c>37</c><c>warning</c><c></c>
</texttable>
</section>
<section title="Responses">
<t>
The following table lists the pre-defined headers that
make-up the initial header table used to represent
responses sent from a server to a client. The same header
table is also used to represent request headers sent from
a server to a client in a PUSH_PROMISE frame.
</t>
<texttable anchor="initial.headers.response">
<ttcol>Index</ttcol>
<ttcol>Header Name</ttcol>
<ttcol>Header Value</ttcol>
<c>0</c><c>:status</c><c>200</c>
<c>1</c><c>age</c><c></c>
<c>2</c><c>cache-control</c><c></c>
<c>3</c><c>content-length</c><c></c>
<c>4</c><c>content-type</c><c></c>
<c>5</c><c>date</c><c></c>
<c>6</c><c>etag</c><c></c>
<c>7</c><c>expires</c><c></c>
<c>8</c><c>last-modified</c><c></c>
<c>9</c><c>server</c><c></c>
<c>10</c><c>set-cookie</c><c></c>
<c>11</c><c>vary</c><c></c>
<c>12</c><c>via</c><c></c>
<c>13</c><c>access-control-allow-origin</c><c></c>
<c>14</c><c>accept-ranges</c><c></c>
<c>15</c><c>allow</c><c></c>
<c>16</c><c>connection</c><c></c>
<c>17</c><c>content-disposition</c><c></c>
<c>18</c><c>content-encoding</c><c></c>
<c>19</c><c>content-language</c><c></c>
<c>20</c><c>content-location</c><c></c>
<c>21</c><c>content-md5</c><c></c>
<c>22</c><c>content-range</c><c></c>
<c>23</c><c>link</c><c></c>
<c>24</c><c>location</c><c></c>
<c>25</c><c>p3p</c><c></c>
<c>26</c><c>pragma</c><c></c>
<c>27</c><c>proxy-authenticate</c><c></c>
<c>28</c><c>refresh</c><c></c>
<c>29</c><c>retry-after</c><c></c>
<c>30</c><c>strict-transport-security</c><c></c>
<c>31</c><c>trailer</c><c></c>
<c>32</c><c>transfer-encoding</c><c></c>
<c>33</c><c>warning</c><c></c>
<c>34</c><c>www-authenticate</c><c></c>
</texttable>
</section>
</section>
<section title="Example" anchor="example">
<t>
Here is an example that illustrates different representations
and how tables are updated.
<cref>This section needs to be updated to integrate differential coding.</cref>
</t>
<section title="First header set">
<t>
The first header set to represent is the following:
<figure><artwork type="message/http">
:path: /my-example/index.html
user-agent: my-user-agent
x-my-header: first
</artwork></figure>
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:
<figure><artwork type="message/http">
0x44 (literal header with incremental indexing, name index = 3)
0x16 (header value string length = 22)
/my-example/index.html
0x4D (literal header with incremental indexing, name index = 12)
0x0D (header value string length = 13)
my-user-agent
0x40 (literal header with incremental indexing, new name)
0x0B (header name string length = 11)
x-my-header
0x05 (header value string length = 5)
first
</artwork></figure>
The header table is as follows after the processing of
these headers:
<figure><artwork type="inline">
Header table
+---------+----------------+---------------------------+
| Index | Header Name | Header Value |
+---------+----------------+---------------------------+
| 0 | :scheme | http |
+---------+----------------+---------------------------+
| 1 | :scheme | https |
+---------+----------------+---------------------------+
| ... | ... | ... |
+---------+----------------+---------------------------+
| 37 | warning | |
+---------+----------------+---------------------------+
| 38 | :path | /my-example/index.html | added header
+---------+----------------+---------------------------+
| 39 | user-agent | my-user-agent | added header
+---------+----------------+---------------------------+
| 40 | x-my-header | first | added header
+---------+----------------+---------------------------+
</artwork></figure>
As all the headers in the first header set are indexed in
the header table, all are kept in the reference
set of headers, which is:
<figure><artwork type="inline">
Reference Set:
:path, /my-example/index.html
user-agent, my-user-agent
x-my-header, first
</artwork></figure>
</t>
</section>
<section title="Second header set">
<t>
The second header set to represent is the following:
<figure><artwork type="message/http">
:path: /my-example/resources/script.js
user-agent: my-user-agent
x-my-header: second
</artwork></figure>
Comparing this second header set to the reference set, the
first and third headers are from the reference set are not
present in this second header set and must be removed. In
addition, in this new set, the first and third headers
have to be encoded.
The path header is represented as a literal header with
substitution indexing. The x-my-header will be
represented as a literal header with incremental indexing.
<figure><artwork type="message/http">
0xa6 (indexed header, index = 38: removal from reference set)
0xa8 (indexed header, index = 40: removal from reference set)
0x04 (literal header, substitution indexing, name index = 3)
0x26 (replaced entry index = 38)
0x1f (header value string length = 31)
/my-example/resources/script.js
0x5f 0x0a (literal header, incremental indexing, name index = 40)
0x06 (header value string length = 6)
second
</artwork></figure>
The header table is updated as follow:
<figure><artwork type="inline">
Header table
+---------+----------------+---------------------------+
| Index | Header Name | Header Value |
+---------+----------------+---------------------------+
| 0 | :scheme | http |
+---------+----------------+---------------------------+
| 1 | :scheme | https |
+---------+----------------+---------------------------+
| ... | ... | ... |
+---------+----------------+---------------------------+
| 37 | warning | |
+---------+----------------+---------------------------+
| 38 | :path | /my-example/resources/ | replaced
| | | script.js | header
+---------+----------------+---------------------------+
| 39 | user-agent | my-user-agent |
+---------+----------------+---------------------------+
| 40 | x-my-header | first |
+---------+----------------+---------------------------+
| 41 | x-my-header | second | added header
+---------+----------------+---------------------------+
</artwork></figure>
All the headers in this second header set are indexed in
the header table, therefore, all are kept in the reference
set of headers, which becomes:
<figure><artwork type="inline">
Reference Set:
:path, /my-example/resources/script.js
user-agent, my-user-agent
x-my-header, second
</artwork></figure>
</t>
</section>
</section>
</back>
</rfc>
<!--
vim:et:tw=78:sw=4:
-->
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:04 |