You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
accept: text/html,application/xhtml+xml<br />
accept-language: en-US,en;q=0.8<br />
cookie: last_page=286A7F3DE<br />
upgrade-insecure-requests: 1<br />
user-agent: Awesome H2/1.0<br />
This might be followed up by this request:<br />
::authority: www.akamai.com<br />
:method: GET<br />
:path: /style.css<br />
:scheme: https<br />
accept: text/html,application/xhtml+xml<br />
accept-language: en-US,en;q=0.8<br />
cookie: last_page=*398AB8E8F<br />
upgrade-insecure-requests: 1<br />
user-agent: Awesome H2/1.0<br />
The following in a contrived and simplified example to give the idea for what HPACK<br />
is doing. The reality is much more of a stark, dystopian landscape and those on the<br />
curious bent should read RFC 7541, “HPACK: Header Compression for <strong>HTTP</strong>/2”.<br />
Let’s assume a client sends the following headers, in order:<br />
Header1: foo<br />
Header2: bar<br />
Header3: bat<br />
When is sends the request it can indicate in the header block that a particular header<br />
and its value should be indexed. It would create a table like:<br />
Index Name Value<br />
62 Header1 foo<br />
63 Header2 bar<br />
64 Header3 bat<br />
On the server side, when it reads the headers it would create the same table. On the<br />
next request when the client sends the request, if it sends the same headers it can simple<br />
send a header block like:<br />
62 63 64<br />
Which the server will then look up and expand into the full headers that those indices<br />
represent.<br />
One of the major implications of this is that each Connection is maintaining state,<br />
something that was nonexistent at the protocol level for <strong>HTTP</strong>/1.<br />
The reality of HPACK is much more complicated. Here are a few tidbits for the curious:<br />
40 | Chapter 3: The Protocol
Change language