One document matched: draft-snell-httpbis-bohe-03.xml


<?xml version="1.0"?> 
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?rfc toc="yes"?> 
<?rfc strict="yes"?> 
<?rfc symrefs="yes" ?> 
<?rfc sortrefs="yes"?> 
<?rfc compact="yes"?> 
<rfc category="info" ipr="trust200811" docName="draft-snell-httpbis-bohe-03"> 
  <front> 
    <title abbrev="application/merge-patch"> 
      HTTP/2.0 Discussion: Binary Optimized Header Encoding
    </title> 
 
    <author initials="J.M." surname="Snell" fullname="James M Snell"> 
      <address> 
        <email>jasnell@gmail.com</email> 
      </address> 
    </author> 
    
    <date month="February" year="2013" /> 
 
    <keyword>I-D</keyword> 
    <keyword>http</keyword>
    <keyword>spdy</keyword>
 
    <abstract> 
      <t>This memo describes a proposed alternative encoding for
      headers within SPDY SYN_STREAM, SYN_REPLY and HEADERS 
      frames.</t> 
    </abstract> 
 
  </front> 
  
  <middle> 

    <section title="Binary Optimized Header Encoding">
    
      <t>Binary Optimized Header Encoding is a proposed
      alternative serialization for headers within SPDY SYN_STREAM, 
      SYN_REPLY and HEADERS frames that is designed to optimize 
      generation, consumption and processing of the most commonly 
      used HTTP headers.</t>
      
<figure><preamble>Alternate Header Block Serialization:</preamble><artwork>
 +-------+---------+
 |  NUM  | Headers |
 +-------+---------+
</artwork></figure>

      <t>'NUM' is a single unsigned 8-bit value indicating the total number 
      of distinct headers contained in the encoded block.</t>
      
      <t>'Headers' consists of the complete set of encoded headers. The format
      for each header is determined by whether the header name (the key) and 
      the header value are included in the static "default dictionary" 
      defined by this specification. The first two bits of each encoded 
      header record identify the specific header format used.</t>
      
<figure><preamble>Registered Key + Registered Value Pair</preamble><artwork>
  +--+---+--+
  |00|CNT|ID| 
  +--+---+--+
</artwork></figure>

      <t>If the header name and value are both included in the default
      dictionary, the associated index of the header as provided by the
      dictionary is encoded as a variable-length, unsigned integer in 
      lists of no more than 63 items. For example, the headers ":path=/",
      ":method=GET" and ":scheme=https" would be compactly encoded as:
      03 03 0F 06</t>

<figure><preamble>Registered Key + Unregistered Value</preamble><artwork>
  +--+---+--+---+---+
  |01|FLG|ID|LEN|VAL|
  +--+---+--+---+---+
</artwork></figure>

      <t>If the header name is included in the default dictionary, but the
      value given is not, the header is encoded using five fields: the two-bit 
      opcode (01) followed by six flag bits as defined below, followed by the 
      numerically lowest index of the named header as provided by the default 
      dictionary encoded as a variable-length, unsigned integer, followed by
      another variable-length, unsigned integer specifying the length of the 
      value, followed by the encoded value.</t>

<figure><preamble>Unregistered Key + Value Pair</preamble><artwork>
  +--+---+------+---+------+---+
  |10|FLG|LENkey|key|LENval|val|
  +--+---+------+---+------+---+
</artwork></figure>

      <t>If the header name and value are not included in the default dictionary,
      the header is encoded using six distinct fields: the two-bit opcode (10)
      followed by six flag bits as defined below, followed by a variable-length,
      unsigned integer specifying the key length, followed by the ISO-8859-1
      encoded key name, followed by a variable-length, unsigned integer specifying
      the value length, followed by the encoded value.</t> 

<figure><preamble>Flags:</preamble><artwork>
  FLG = 000000
        ||||||
        |||||Reserved
        ||||Date (Numeric val represents a date)
        |||Numeric (val is one or more uvarints)
        ||Huffman-encoded
        |UTF-8 or ISO8859-1 (1 or 0)
        Binary | Text (1 or 0)
</artwork></figure>

      <t>When the opcode is either 01 or 10, the six-bit FLG field is used to specify
      additional properties about the header value. When the opcode is 00, the FLG
      bits are unused and MUST NOT be set.</t>
      
      <t>Moving from the most significant bit to the least, the flags are:
        <list style="symbols">
          <t>Binary or Text (0x32) - When set, the value is to be interpreted as 
          binary data. When unset, the value is to be interpreted as encoded-text.</t>
          <t>UTF-8 or ISO-8859-1 (0x16) - When set, indicates that the text-encoded
          value is UTF-8 encoded. Otherwise, ISO-8859-1 is assumed. Only used if the 
          Binary bit (0x32) is unset.</t>
          <t>Huffman-encoded (0x08) - When set, indicates that the text-encoded 
          value has been static huffman encoded. The static dictionary used for the
          encoding is dependent on whether the text is UTF-8 or ISO-8859-1 encoded.
          Only used if the Binary bit (0x32) is unset.</t>
          <t>Numeric (0x04) - When set, indicates that the value is encoded as a 
          variable-length unsigned integer. Only used if the Binary bit (0x32) is
          set (indicating a binary value).</t>
          <t>Date (0x02) - When set, indicates that the value is a date and time
          encoded as a variable-length unsigned integer representing the total
          number of seconds that have ellapsed since midnight on January 1st, 1990, 
          GMT. Only used if the Binary (0x32) and Numeric (0x04) bits are both set.</t>
          <t>The final bit (0x01) is reserved.</t>
        </list>
      </t>
    </section>
            
    <section title="Value Encoding">
      
      <t>Header values can be encoded as one of four distinct types: Binary, Text, Numeric
      or Date. Each is indicated by the FLG field.</t>
      
      <t><list style="symbols">
        <t>Binary Header values are encoded as a raw, uninterpreted sequence of binary 
        octets.</t>
        <t>Numeric values are encoded as variable-length, unsigned integers.</t>
        <t>Date values are encoded as variable-length, unsigned integers representing
          the total number of seconds that have ellapsed since midnight on January
          1st, 1990.</t>
        <t>Text values are encoded as a sequence one or more length-prefixed octet 
        sequences representing ISO-8859-1 or UTF-8 encoded characters, conforming to
        the following structure:</t>
      </list></t>      
      
      <figure><artwork>
  string_val = COUNT 1*(LENGTH VAL)
      </artwork></figure>

      <t>Where COUNT is an unsigned 8-bit value specifying the number of octet sequences,
        LENGTH is an unsigned variable-length integer specifying the length of each 
        sequence, and VAL is the specific sequence of encoded octets.</t>
      
    </section>
            
    <section title="Example Headers">
        
        <t>Assuming the following (incomplete) default dictionary:</t>
        
        <texttable>
          <ttcol>ID</ttcol>
          <ttcol>Key</ttcol>
          <ttcol>Value</ttcol>

          <c>0</c><c>date</c><c></c>
          <c>1</c><c>:scheme</c><c></c>
          <c>2</c><c>:scheme</c><c>http</c>
          <c>3</c><c>:scheme</c><c>https</c>
          <c>4</c><c>:scheme</c><c>ftp</c>
          <c>5</c><c>:method</c><c></c>
          <c>6</c><c>:method</c><c>get</c>
          <c>7</c><c>:method</c><c>post</c>
          <c>8</c><c>:method</c><c>put</c>
          <c>9</c><c>:method</c><c>delete</c>
          <c>10</c><c>:method</c><c>options</c>
          <c>11</c><c>:method</c><c>connect</c>
          <c>12</c><c>:method</c><c>patch</c>
          <c>13</c><c>:method</c><c>link</c>
          <c>14</c><c>:path</c><c></c>
          <c>15</c><c>:path</c><c>/</c>
          <c>16</c><c>:host</c><c></c>
          <c>17</c><c>cookie</c><c></c>
          <c>18</c><c>:status</c><c></c>
          <c>19</c><c>:status</c><c>200</c>
          <c>20</c><c>:status</c><c>201</c>
          <c>21</c><c>:status</c><c>202</c>
          <c>22</c><c>:status</c><c>204</c>
          <c>23</c><c>:status</c><c>205</c>
          <c>24</c><c>:status-text</c><c></c>
          <c>25</c><c>:status-text</c><c>OK</c>
          <c>26</c><c>:version</c><c></c>
          <c>27</c><c>:version</c><c>1.0</c>
          <c>28</c><c>:version</c><c>1.1</c>
          <c>29</c><c>:version</c><c>2.0</c>
          <c>30</c><c>accept</c><c></c>
          <c>31</c><c>accept-charset</c><c></c>
          <c>32</c><c>accept-encoding</c><c></c>
          <c>33</c><c>accept-language</c><c></c>
          <c>34</c><c>accept-ranges</c><c></c>
          <c>35</c><c>allow</c><c></c>
          <c>36</c><c>authorizations</c><c></c>
          <c>37</c><c>cache-control</c><c></c>
          <c>38</c><c>content-base</c><c></c>
          <c>39</c><c>content-encoding</c><c></c>
          <c>40</c><c>content-length</c><c></c>
          <c>41</c><c>content-location</c><c></c>
          <c>42</c><c>content-md5</c><c></c>
          <c>43</c><c>content-range</c><c></c>
          <c>44</c><c>content-type</c><c></c>
          <c>45</c><c>etag</c><c></c>
          <c>46</c><c>expect</c><c></c>
          <c>47</c><c>expires</c><c></c>
          <c>48</c><c>from</c><c></c>
          <c>49</c><c>if-match</c><c></c>
          <c>50</c><c>if-modified-since</c><c></c>
          <c>51</c><c>if-none-match</c><c></c>
          <c>52</c><c>if-range</c><c></c>
          <c>53</c><c>if-unmodified-since</c><c></c>
          <c>54</c><c>last-modified</c><c></c>
          <c>55</c><c>location</c><c></c>
          <c>56</c><c>max-forwards</c><c></c>
          <c>57</c><c>origin</c><c></c>
          <c>58</c><c>pragma</c><c></c>
          <c>59</c><c>proxy-authenticate</c><c></c>
          <c>60</c><c>proxy-authorization</c><c></c>
          <c>61</c><c>range</c><c></c>
          <c>62</c><c>referer</c><c></c>
          <c>63</c><c>retry-after</c><c></c>
          <c>64</c><c>server</c><c></c>
          <c>65</c><c>set-cookie</c><c></c>
          <c>66</c><c>status</c><c></c>
          <c>67</c><c>te</c><c></c>
          <c>68</c><c>trailer</c><c></c>
          <c>69</c><c>transfer-encoding</c><c></c>
          <c>70</c><c>transfer-encoding</c><c>gzip</c>
          <c>71</c><c>upgrade</c><c></c>
          <c>72</c><c>user-agent</c><c></c>
          <c>73</c><c>vary</c><c></c>
          <c>74</c><c>via</c><c></c>
          <c>75</c><c>warning</c><c></c>
          <c>76</c><c>www-authenticate</c><c></c>
          <c>77</c><c>access-control-allow-origin</c><c></c>
          <c>78</c><c>content-disposition</c><c></c>
          <c>79</c><c>get-dictionary</c><c></c>
          <c>80</c><c>p3p</c><c></c>
          <c>81</c><c>x-content-type-options</c><c></c>
          <c>82</c><c>x-frame-options</c><c></c>
          <c>83</c><c>x-powered-by</c><c></c>
          <c>84</c><c>x-xss-protection</c><c></c>
          <c>85</c><c>connection</c><c></c>
          <c>86</c><c>connection</c><c>keep-alive</c>
        </texttable>
        
<figure><preamble>The header :version=2.0 would be encoded as:</preamble><artwork>
  01 1D |..|
</artwork></figure>

<figure><preamble>The header :method=GET would be encoded as:</preamble><artwork>
  01 06 |..|
</artwork></figure>

<figure><preamble>The headers :version=2.0 and :method=GET would be encoded as:</preamble><artwork>
  02 06 1D |..|
</artwork></figure>

<figure><preamble>The header :method=foo would be encoded as:</preamble><artwork>
  56 05 05 01 03 66 6F 6F |.....foo|
</artwork></figure>

<figure><preamble>The header foo=bar would be encoded as:</preamble><artwork>
  b6 03 66 6f 6f 05 01    |..foo...|
  03 62 61 72             |.bar|
</artwork></figure>

    </section>
    
    <section title="Security Considerations">
      <t>TBD</t>
    </section>
        
  </middle> 

  <back>
    <references title="Normative References"> 
  &rfc2119;
    </references>        
  </back>
</rfc> 
 

PAFTECH AB 2003-20262026-04-24 05:39:04