Ignore:
Timestamp:
16/01/13 19:23:08 (10 years ago)
Author:
martin.thomson@…
Message:

Adding new introduction section.

Location:
draft-ietf-httpbis-http2/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.html

    r2124 r2125  
    428428      <link rel="Copyright" href="#rfc.copyrightnotice">
    429429      <link rel="Index" href="#rfc.index">
    430       <link rel="Chapter" title="1 Overview" href="#rfc.section.1">
    431       <link rel="Chapter" title="2 HTTP/2.0 Framing Layer" href="#rfc.section.2">
    432       <link rel="Chapter" title="3 HTTP Layering over HTTP/2.0" href="#rfc.section.3">
    433       <link rel="Chapter" title="4 Design Rationale and Notes" href="#rfc.section.4">
    434       <link rel="Chapter" title="5 Security Considerations" href="#rfc.section.5">
    435       <link rel="Chapter" title="6 Privacy Considerations" href="#rfc.section.6">
    436       <link rel="Chapter" title="7 Requirements Notation" href="#rfc.section.7">
    437       <link rel="Chapter" title="8 Acknowledgements" href="#rfc.section.8">
    438       <link rel="Chapter" href="#rfc.section.9" title="9 Normative References">
     430      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
     431      <link rel="Chapter" title="2 Starting HTTP/2.0" href="#rfc.section.2">
     432      <link rel="Chapter" title="3 HTTP/2.0 Framing Layer" href="#rfc.section.3">
     433      <link rel="Chapter" title="4 HTTP Layering over HTTP/2.0" href="#rfc.section.4">
     434      <link rel="Chapter" title="5 Design Rationale and Notes" href="#rfc.section.5">
     435      <link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6">
     436      <link rel="Chapter" title="7 Privacy Considerations" href="#rfc.section.7">
     437      <link rel="Chapter" title="8 Requirements Notation" href="#rfc.section.8">
     438      <link rel="Chapter" title="9 Acknowledgements" href="#rfc.section.9">
     439      <link rel="Chapter" href="#rfc.section.10" title="10 Normative References">
    439440      <link rel="Appendix" title="A Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.A">
    440441      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.588, 2012-08-25 12:28:24, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    … …  
    447448      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-http2-latest">
    448449      <meta name="dct.issued" scheme="ISO8601" content="2013-01-16">
    449       <meta name="dct.abstract" content="This document describes HTTP/2.0, a protocol designed for low-latency transport of content over the World Wide Web. HTTP/2.0 introduces two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport (likely TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of the protocol provides HTTP-like RFC2616 semantics for compatibility with existing HTTP application servers.">
    450       <meta name="description" content="This document describes HTTP/2.0, a protocol designed for low-latency transport of content over the World Wide Web. HTTP/2.0 introduces two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport (likely TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of the protocol provides HTTP-like RFC2616 semantics for compatibility with existing HTTP application servers.">
     450      <meta name="dct.abstract" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
     451      <meta name="description" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
    451452   </head>
    452453   <body onload="init();">
    … …  
    493494      <p class="title">Hypertext Transfer Protocol version 2.0<br><span class="filename">draft-ietf-httpbis-http2-latest</span></p>
    494495      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    495       <p>This document describes HTTP/2.0, a protocol designed for low-latency transport of content over the World Wide Web. HTTP/2.0
    496          introduces two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport
    497          (likely TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of
    498          the protocol provides HTTP-like <a href="#RFC2616">RFC2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> semantics for compatibility with existing HTTP application servers.
     496      <p>This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables
     497         more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push
     498         of resources from server to client.
     499      </p> 
     500      <p>This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7}
     501         are unmodified.
    499502      </p>
    500503      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
    … …  
    529532      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
    530533      <ul class="toc">
    531          <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#intro">Overview</a><ul>
     534         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#intro">Introduction</a><ul>
    532535               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.1">Document Organization</a></li>
    533536               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.2">Definitions</a></li>
    534537            </ul>
    535538         </li>
    536          <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#FramingLayer">HTTP/2.0 Framing Layer</a><ul>
    537                <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1">Session (Connections)</a></li>
    538                <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2">Framing</a><ul>
    539                      <li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#ControlFrames">Control frames</a></li>
    540                      <li><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#DataFrames">Data frames</a></li>
     539         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#starting">Starting HTTP/2.0</a><ul>
     540               <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#versioning">HTTP/2.0 Version Identification</a></li>
     541               <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#discover-http">Starting HTTP/2.0 for "http:" URIs</a></li>
     542               <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#discover-https">Starting HTTP/2.0 for "https:" URIs</a></li>
     543            </ul>
     544         </li>
     545         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#FramingLayer">HTTP/2.0 Framing Layer</a><ul>
     546               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1">Session (Connections)</a></li>
     547               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2">Framing</a><ul>
     548                     <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#ControlFrames">Control frames</a></li>
     549                     <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#DataFrames">Data frames</a></li>
    541550                  </ul>
    542551               </li>
    543                <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3">Streams</a><ul>
    544                      <li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#StreamFrames">Stream frames</a></li>
    545                      <li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#StreamCreation">Stream creation</a><ul>
    546                            <li><a href="#rfc.section.2.3.2.1">2.3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3.2.1">Unidirectional streams</a></li>
    547                            <li><a href="#rfc.section.2.3.2.2">2.3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3.2.2">Bidirectional streams</a></li>
     552               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3">Streams</a><ul>
     553                     <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#StreamFrames">Stream frames</a></li>
     554                     <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#StreamCreation">Stream creation</a><ul>
     555                           <li><a href="#rfc.section.3.3.2.1">3.3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3.2.1">Unidirectional streams</a></li>
     556                           <li><a href="#rfc.section.3.3.2.2">3.3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3.2.2">Bidirectional streams</a></li>
    548557                        </ul>
    549558                     </li>
    550                      <li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#StreamPriority">Stream priority</a></li>
    551                      <li><a href="#rfc.section.2.3.4">2.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3.4">Stream headers</a></li>
    552                      <li><a href="#rfc.section.2.3.5">2.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3.5">Stream data exchange</a></li>
    553                      <li><a href="#rfc.section.2.3.6">2.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#StreamHalfClose">Stream half-close</a></li>
    554                      <li><a href="#rfc.section.2.3.7">2.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#StreamClose">Stream close</a></li>
     559                     <li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#StreamPriority">Stream priority</a></li>
     560                     <li><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3.4">Stream headers</a></li>
     561                     <li><a href="#rfc.section.3.3.5">3.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3.5">Stream data exchange</a></li>
     562                     <li><a href="#rfc.section.3.3.6">3.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#StreamHalfClose">Stream half-close</a></li>
     563                     <li><a href="#rfc.section.3.3.7">3.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#StreamClose">Stream close</a></li>
    555564                  </ul>
    556565               </li>
    557                <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.4">Error Handling</a><ul>
    558                      <li><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#SessionErrorHandler">Session Error Handling</a></li>
    559                      <li><a href="#rfc.section.2.4.2">2.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#StreamErrorHandler">Stream Error Handling</a></li>
     566               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.4">Error Handling</a><ul>
     567                     <li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#SessionErrorHandler">Session Error Handling</a></li>
     568                     <li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#StreamErrorHandler">Stream Error Handling</a></li>
    560569                  </ul>
    561570               </li>
    562                <li><a href="#rfc.section.2.5">2.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.5">Data flow</a></li>
    563                <li><a href="#rfc.section.2.6">2.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.6">Control frame types</a><ul>
    564                      <li><a href="#rfc.section.2.6.1">2.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#SYN_STREAM">SYN_STREAM</a></li>
    565                      <li><a href="#rfc.section.2.6.2">2.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#SYN_REPLY">SYN_REPLY</a></li>
    566                      <li><a href="#rfc.section.2.6.3">2.6.3</a>&nbsp;&nbsp;&nbsp;<a href="#RST_STREAM">RST_STREAM</a></li>
    567                      <li><a href="#rfc.section.2.6.4">2.6.4</a>&nbsp;&nbsp;&nbsp;<a href="#SETTINGS">SETTINGS</a></li>
    568                      <li><a href="#rfc.section.2.6.5">2.6.5</a>&nbsp;&nbsp;&nbsp;<a href="#PING">PING</a></li>
    569                      <li><a href="#rfc.section.2.6.6">2.6.6</a>&nbsp;&nbsp;&nbsp;<a href="#GOAWAY">GOAWAY</a></li>
    570                      <li><a href="#rfc.section.2.6.7">2.6.7</a>&nbsp;&nbsp;&nbsp;<a href="#HEADERS">HEADERS</a></li>
    571                      <li><a href="#rfc.section.2.6.8">2.6.8</a>&nbsp;&nbsp;&nbsp;<a href="#WINDOW_UPDATE">WINDOW_UPDATE</a></li>
    572                      <li><a href="#rfc.section.2.6.9">2.6.9</a>&nbsp;&nbsp;&nbsp;<a href="#CREDENTIAL">CREDENTIAL</a></li>
    573                      <li><a href="#rfc.section.2.6.10">2.6.10</a>&nbsp;&nbsp;&nbsp;<a href="#HeaderBlock">Name/Value Header Block</a><ul>
    574                            <li><a href="#rfc.section.2.6.10.1">2.6.10.1</a>&nbsp;&nbsp;&nbsp;<a href="#Compression">Compression</a></li>
     571               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.5">Data flow</a></li>
     572               <li><a href="#rfc.section.3.6">3.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.6">Control frame types</a><ul>
     573                     <li><a href="#rfc.section.3.6.1">3.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#SYN_STREAM">SYN_STREAM</a></li>
     574                     <li><a href="#rfc.section.3.6.2">3.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#SYN_REPLY">SYN_REPLY</a></li>
     575                     <li><a href="#rfc.section.3.6.3">3.6.3</a>&nbsp;&nbsp;&nbsp;<a href="#RST_STREAM">RST_STREAM</a></li>
     576                     <li><a href="#rfc.section.3.6.4">3.6.4</a>&nbsp;&nbsp;&nbsp;<a href="#SETTINGS">SETTINGS</a></li>
     577                     <li><a href="#rfc.section.3.6.5">3.6.5</a>&nbsp;&nbsp;&nbsp;<a href="#PING">PING</a></li>
     578                     <li><a href="#rfc.section.3.6.6">3.6.6</a>&nbsp;&nbsp;&nbsp;<a href="#GOAWAY">GOAWAY</a></li>
     579                     <li><a href="#rfc.section.3.6.7">3.6.7</a>&nbsp;&nbsp;&nbsp;<a href="#HEADERS">HEADERS</a></li>
     580                     <li><a href="#rfc.section.3.6.8">3.6.8</a>&nbsp;&nbsp;&nbsp;<a href="#WINDOW_UPDATE">WINDOW_UPDATE</a></li>
     581                     <li><a href="#rfc.section.3.6.9">3.6.9</a>&nbsp;&nbsp;&nbsp;<a href="#CREDENTIAL">CREDENTIAL</a></li>
     582                     <li><a href="#rfc.section.3.6.10">3.6.10</a>&nbsp;&nbsp;&nbsp;<a href="#HeaderBlock">Name/Value Header Block</a><ul>
     583                           <li><a href="#rfc.section.3.6.10.1">3.6.10.1</a>&nbsp;&nbsp;&nbsp;<a href="#Compression">Compression</a></li>
    575584                        </ul>
    576585                     </li>
    … …  
    579588            </ul>
    580589         </li>
    581          <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#HTTPLayer">HTTP Layering over HTTP/2.0</a><ul>
    582                <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1">Connection Management</a><ul>
    583                      <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1.1">Use of GOAWAY</a></li>
     590         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#HTTPLayer">HTTP Layering over HTTP/2.0</a><ul>
     591               <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Connection Management</a><ul>
     592                     <li><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1.1">Use of GOAWAY</a></li>
    584593                  </ul>
    585594               </li>
    586                <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2">HTTP Request/Response</a><ul>
    587                      <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2.1">Request</a></li>
    588                      <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2.2">Response</a></li>
    589                      <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#Authentication">Authentication</a><ul>
    590                            <li><a href="#rfc.section.3.2.3.1">3.2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2.3.1">Stateless Authentication</a></li>
    591                            <li><a href="#rfc.section.3.2.3.2">3.2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2.3.2">Stateful Authentication</a></li>
     595               <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2">HTTP Request/Response</a><ul>
     596                     <li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2.1">Request</a></li>
     597                     <li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2.2">Response</a></li>
     598                     <li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#Authentication">Authentication</a><ul>
     599                           <li><a href="#rfc.section.4.2.3.1">4.2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2.3.1">Stateless Authentication</a></li>
     600                           <li><a href="#rfc.section.4.2.3.2">4.2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2.3.2">Stateful Authentication</a></li>
    592601                        </ul>
    593602                     </li>
    594603                  </ul>
    595604               </li>
    596                <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3">Server Push Transactions</a><ul>
    597                      <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3.1">Server implementation</a></li>
    598                      <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3.2">Client implementation</a></li>
     605               <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.3">Server Push Transactions</a><ul>
     606                     <li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.3.1">Server implementation</a></li>
     607                     <li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.3.2">Client implementation</a></li>
    599608                  </ul>
    600609               </li>
    601610            </ul>
    602611         </li>
    603          <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4">Design Rationale and Notes</a><ul>
    604                <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Separation of Framing Layer and Application Layer</a></li>
    605                <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2">Error handling - Framing Layer</a></li>
    606                <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.3">One Connection Per Domain</a></li>
    607                <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.4">Fixed vs Variable Length Fields</a></li>
    608                <li><a href="#rfc.section.4.5">4.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.5">Compression Context(s)</a></li>
    609                <li><a href="#rfc.section.4.6">4.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.6">Unidirectional streams</a></li>
    610                <li><a href="#rfc.section.4.7">4.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.7">Data Compression</a></li>
    611                <li><a href="#rfc.section.4.8">4.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.8">Server Push</a></li>
     612         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5">Design Rationale and Notes</a><ul>
     613               <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.1">Separation of Framing Layer and Application Layer</a></li>
     614               <li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.2">Error handling - Framing Layer</a></li>
     615               <li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.3">One Connection Per Domain</a></li>
     616               <li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.4">Fixed vs Variable Length Fields</a></li>
     617               <li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.5">Compression Context(s)</a></li>
     618               <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.6">Unidirectional streams</a></li>
     619               <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.7">Data Compression</a></li>
     620               <li><a href="#rfc.section.5.8">5.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.8">Server Push</a></li>
    612621            </ul>
    613622         </li>
    614          <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5">Security Considerations</a><ul>
    615                <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.1">Use of Same-origin constraints</a></li>
    616                <li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.2">HTTP Headers and HTTP/2.0 Headers</a></li>
    617                <li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.3">Cross-Protocol Attacks</a></li>
    618                <li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.4">Server Push Implicit Headers</a></li>
     623         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6">Security Considerations</a><ul>
     624               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.1">Use of Same-origin constraints</a></li>
     625               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.2">HTTP Headers and HTTP/2.0 Headers</a></li>
     626               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.3">Cross-Protocol Attacks</a></li>
     627               <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.4">Server Push Implicit Headers</a></li>
    619628            </ul>
    620629         </li>
    621          <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6">Privacy Considerations</a><ul>
    622                <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.1">Long Lived Connections</a></li>
    623                <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.2">SETTINGS frame</a></li>
     630         <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">Privacy Considerations</a><ul>
     631               <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.1">Long Lived Connections</a></li>
     632               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.2">SETTINGS frame</a></li>
    624633            </ul>
    625634         </li>
    626          <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">Requirements Notation</a></li>
    627          <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8">Acknowledgements</a></li>
    628          <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">Normative References</a></li>
     635         <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8">Requirements Notation</a></li>
     636         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9">Acknowledgements</a></li>
     637         <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">Normative References</a></li>
    629638         <li><a href="#rfc.authors">Authors' Addresses</a></li>
    630639         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
    … …  
    635644         <li><a href="#rfc.index">Index</a></li>
    636645      </ul>
    637       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="intro" href="#intro">Overview</a></h1>
    638       <p id="rfc.section.1.p.1">One of the bottlenecks of HTTP implementations is that HTTP relies on multiple connections for concurrency. This causes several
    639          problems, including additional round trips for connection setup, slow-start delays, and connection rationing by the client,
    640          where it tries to avoid opening too many connections to any single server. HTTP pipelining helps some, but only achieves partial
    641          multiplexing. In addition, pipelining has proven non-deployable in existing browsers due to intermediary interference.
    642       </p>
    643       <p id="rfc.section.1.p.2">HTTP/2.0 adds a framing layer for multiplexing multiple, concurrent streams across a single TCP connection (or any reliable
    644          transport stream). The framing layer is optimized for HTTP-like request-response streams, such that applications which run
    645          over HTTP today can work over HTTP/2.0 with little or no change on behalf of the web application writer.
    646       </p>
    647       <p id="rfc.section.1.p.3">The HTTP/2.0 session offers four improvements over HTTP: </p>
    648       <ul class="empty">
    649          <li>Multiplexed requests: There is no limit to the number of requests that can be issued concurrently over a single HTTP/2.0 connection.</li>
    650          <li>Prioritized requests: Clients can request certain resources to be delivered first. This avoids the problem of congesting the
    651             network channel with non-critical resources when a high-priority request is pending.
    652          </li>
    653          <li>Compressed headers: Clients today send a significant amount of redundant data in the form of HTTP headers. Because a single
    654             web page may require 50 or 100 subrequests, this data is significant.
    655          </li>
    656          <li>Server pushed streams: Server Push enables content to be pushed from servers to clients without a request.</li>
    657       </ul>
    658       <p id="rfc.section.1.p.4">HTTP/2.0 attempts to preserve the existing semantics of HTTP. All features such as cookies, ETags, Vary headers, Content-Encoding
    659          negotiations, etc work as they do with HTTP; HTTP/2.0 only replaces the way the data is written to the network.
     646      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="intro" href="#intro">Introduction</a></h1>
     647      <p id="rfc.section.1.p.1">HTTP is a wildly successful protocol. <a href="#HTTP-p1">HTTP/1.1 message encapsulation</a> <cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" id="rfc.xref.HTTP-p1.1">[HTTP-p1]</cite> is optimized for implementation simplicity and accessibility, not application performance. As such it has several characteristics
     648         that have a negative overall effect on application performance.
     649      </p>
     650      <p id="rfc.section.1.p.2">The HTTP/1.1 encapsulation ensures that only one request can be delivered at a time on a given connection. HTTP/1.1 pipelining,
     651         which is not widely deployed, only partially addresses these concerns. Clients that need to make multiple requests therefore
     652         use commonly multiple connections to a server or servers in order to reduce the overall latency of those requests.
     653      </p>
     654      <p id="rfc.section.1.p.3">Furthermore, HTTP/1.1 headers are represented in an inefficient fashion, which, in addition to generating more or larger network
     655         packets, can cause the small initial TCP window to fill more quickly than is ideal. This results in excessive latency where
     656         multiple requests are made on a new TCP connection.
     657      </p>
     658      <p id="rfc.section.1.p.4">This document defines an optimized mapping of the HTTP semantics to a TCP connection. This optimization reduces the latency
     659         costs of HTTP by allowing parallel requests on the same connection and by using an efficient coding for HTTP headers. Prioritization
     660         of requests lets more important requests complete faster, further improving application performance.
     661      </p>
     662      <p id="rfc.section.1.p.5">HTTP/2.0 applications have an improved impact on network congestion due to the use of fewer TCP connections to achieve the
     663         same effect. Fewer TCP connections compete more fairly with other flows. Long-lived connections are also more able to take
     664         better advantage of the available network capacity, rather than operating in the slow start phase of TCP.
     665      </p>
     666      <p id="rfc.section.1.p.6">The HTTP/2.0 encapsulation also enables more efficient processing of messages by providing efficient message framing. Processing
     667         of headers in HTTP/2.0 messages is more efficient (for entities that process many messages).
    660668      </p>
    661669      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Document Organization
    662670      </h2>
    663       <p id="rfc.section.1.1.p.1">The HTTP/2.0 Specification is split into two parts: a framing layer (<a href="#FramingLayer" title="HTTP/2.0 Framing Layer">Section&nbsp;2</a>), which multiplexes a TCP connection into independent, length-prefixed frames, and an HTTP layer (<a href="#HTTPLayer" title="HTTP Layering over HTTP/2.0">Section&nbsp;3</a>), which specifies the mechanism for overlaying HTTP request/response pairs on top of the framing layer. While some of the
     671      <p id="rfc.section.1.1.p.1">The HTTP/2.0 Specification is split into three parts: starting HTTP/2.0 (<a href="#starting" title="Starting HTTP/2.0">Section&nbsp;2</a>), which covers how a HTTP/2.0 is started; a framing layer (<a href="#FramingLayer" title="HTTP/2.0 Framing Layer">Section&nbsp;3</a>), which multiplexes a TCP connection into independent, length-prefixed frames; and an HTTP layer (<a href="#HTTPLayer" title="HTTP Layering over HTTP/2.0">Section&nbsp;4</a>), which specifies the mechanism for overlaying HTTP request/response pairs on top of the framing layer. While some of the
    664672         framing layer concepts are isolated from the HTTP layer, building a generic framing layer has not been a goal. The framing
    665673         layer is tailored to the needs of the HTTP protocol and server push.
    … …  
    679687         <li>stream error: An error on an individual HTTP/2.0 stream.</li>
    680688      </ul>
    681       <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="FramingLayer" href="#FramingLayer">HTTP/2.0 Framing Layer</a></h1>
    682       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Session (Connections)
    683       </h2>
    684       <p id="rfc.section.2.1.p.1">The HTTP/2.0 framing layer (or "session") runs atop a reliable transport layer such as <a href="#RFC0793">TCP</a> <cite title="Transmission Control Protocol" id="rfc.xref.RFC0793.1">[RFC0793]</cite>. The client is the TCP connection initiator. HTTP/2.0 connections are persistent connections.
    685       </p>
    686       <p id="rfc.section.2.1.p.2">For best performance, it is expected that clients will not close open connections until the user navigates away from all web
     689      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="starting" href="#starting">Starting HTTP/2.0</a></h1>
     690      <p id="rfc.section.2.p.1">Just as HTTP/1.1 does, HTTP/2.0 uses the "http:" and "https:" URI schemes. An HTTP/2.0-capable client is therefore required
     691         to discover whether a server (or intermediary) supports HTTP/2.0.
     692      </p>
     693      <p id="rfc.section.2.p.2">Different discovery mechanisms are defined for "http:" and "https:" URIs. Discovery for "http:" URIs is described in <a href="#discover-http" title="Starting HTTP/2.0 for &#34;http:&#34; URIs">Section&nbsp;2.2</a>; discovery for "https:" URIs is described in <a href="#discover-https" title="Starting HTTP/2.0 for &#34;https:&#34; URIs">Section&nbsp;2.3</a>.
     694      </p>
     695      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="versioning" href="#versioning">HTTP/2.0 Version Identification</a></h2>
     696      <p id="rfc.section.2.1.p.1">HTTP/2.0 is identified in using the string "HTTP/2.0". This identification is used in the HTTP/1.1 Upgrade header, in the <a href="#TLSNPN">TLS-NPN</a> <cite title="TLS Next Protocol Negotiation" id="rfc.xref.TLSNPN.1">[TLSNPN]</cite> [[TBD]] field and other places where protocol identification is required.
     697      </p>
     698      <p id="rfc.section.2.1.p.2">[[Editor's Note: please remove the following text prior to the publication of a final version of this document.]]</p>
     699      <p id="rfc.section.2.1.p.3">Only implementations of the final, published RFC can identify themselves as "HTTP/2.0". Until such an RFC exists, implementations
     700         MUST NOT identify themselves using "HTTP/2.0".
     701      </p>
     702      <p id="rfc.section.2.1.p.4">Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only. Implementations
     703         of draft versions MUST NOT identify using this string.
     704      </p>
     705      <p id="rfc.section.2.1.p.5">Implementations of draft versions of the protocol MUST add the corresponding draft number to the identifier before the separator
     706         ('/'). For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-03/2.0".
     707      </p>
     708      <p id="rfc.section.2.1.p.6">Non-compatible experiments that are based on these draft versions MUST include a further identifier. For example, an experimental
     709         implementation of packet mood-based encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-07-emo/2.0".
     710         Note that any label MUST conform with the "token" syntax defined in Section 3.2.4 of <a href="#HTTP-p1" id="rfc.xref.HTTP-p1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[HTTP-p1]</cite></a>. Experimenters are encouraged to coordinate their experiments on the ietf-http-wg@w3.org mailing list.
     711      </p>
     712      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="discover-http" href="#discover-http">Starting HTTP/2.0 for "http:" URIs</a></h2>
     713      <p id="rfc.section.2.2.p.1">A client that makes a request to an "http:" URI without prior knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism <a href="#HTTP-p2" id="rfc.xref.HTTP-p2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[HTTP-p2]</cite></a>. The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0.
     714      </p>
     715      <p id="rfc.section.2.2.p.2">For example:</p>
     716      <div id="rfc.figure.u.1"></div><pre>   GET /default.htm HTTP/1.1
     717   Host: server.example.com
     718   Connection: Upgrade
     719   Upgrade: HTTP/2.0
     720</pre><p id="rfc.section.2.2.p.4">A server that does not support HTTP/2.0 can respond to the request as though the Upgrade header field were absent:</p>
     721      <div id="rfc.figure.u.2"></div><pre>   HTTP/1.1 200 OK
     722   Content-length: 243
     723   Content-type: text/html
     724      ...
     725</pre><p id="rfc.section.2.2.p.6">A server that supports HTTP/2.0 can accept the upgrade with a 101 (Switching Protocols) status code. After the empty line
     726         that terminates the 101 response, the server can begin sending HTTP/2.0 frames. These frames MUST include a response to the
     727         request that initiated the Upgrade.
     728      </p>
     729      <div id="rfc.figure.u.3"></div><pre>   HTTP/1.1 101 Switching Protocols
     730   Connection: Upgrade
     731   Upgrade: HTTP/2.0
     732
     733   [ HTTP/2.0 frames ...
     734</pre><p id="rfc.section.2.2.p.8">A client can learn that a particular server supports HTTP/2.0 by other means. A client MAY immediately send HTTP/2.0 frames
     735         to a server that is known to support HTTP/2.0. [[Open Issue: This is not definite. We may yet choose to perform negotiation
     736         for every connection. Reasons include intermediaries; phased upgrade of load-balanced server farms; etc...]] [[Open Issue:
     737         We need to enumerate the ways that clients can learn of HTTP/2.0 support.]]
     738      </p>
     739      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="discover-https" href="#discover-https">Starting HTTP/2.0 for "https:" URIs</a></h2>
     740      <p id="rfc.section.2.3.p.1">[[TBD, maybe NPN]]</p>
     741      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="FramingLayer" href="#FramingLayer">HTTP/2.0 Framing Layer</a></h1>
     742      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Session (Connections)
     743      </h2>
     744      <p id="rfc.section.3.1.p.1">The HTTP/2.0 framing layer (or "session") runs atop a reliable transport layer such as <a href="#RFC0793">TCP</a> <cite title="Transmission Control Protocol" id="rfc.xref.RFC0793.1">[RFC0793]</cite>. The client is the TCP connection initiator. HTTP/2.0 connections are persistent connections.
     745      </p>
     746      <p id="rfc.section.3.1.p.2">For best performance, it is expected that clients will not close open connections until the user navigates away from all web
    687747         pages referencing a connection, or until the server closes the connection. Servers are encouraged to leave connections open
    688748         for as long as possible, but can terminate idle connections if necessary. When either endpoint closes the transport-level
    689          connection, it MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section&nbsp;2.6.6</a>) frame so that the endpoints can reliably determine if requests finished before the close.
    690       </p>
    691       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;Framing
    692       </h2>
    693       <p id="rfc.section.2.2.p.1">Once the connection is established, clients and servers exchange framed messages. There are two types of frames: control frames (<a href="#ControlFrames" title="Control frames">Section&nbsp;2.2.1</a>) and data frames (<a href="#DataFrames" title="Data frames">Section&nbsp;2.2.2</a>). Frames always have a common header which is 8 bytes in length.
    694       </p>
    695       <p id="rfc.section.2.2.p.2">The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a version
     749         connection, it MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section&nbsp;3.6.6</a>) frame so that the endpoints can reliably determine if requests finished before the close.
     750      </p>
     751      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;Framing
     752      </h2>
     753      <p id="rfc.section.3.2.p.1">Once the connection is established, clients and servers exchange framed messages. There are two types of frames: control frames (<a href="#ControlFrames" title="Control frames">Section&nbsp;3.2.1</a>) and data frames (<a href="#DataFrames" title="Data frames">Section&nbsp;3.2.2</a>). Frames always have a common header which is 8 bytes in length.
     754      </p>
     755      <p id="rfc.section.3.2.p.2">The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a version
    696756         number, a frame type, flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried
    697757         after the common header. The simple header is designed to make reading and writing of frames easy.
    698758      </p>
    699       <p id="rfc.section.2.2.p.3">All integer values, including length, version, and type, are in network byte order. HTTP/2.0 does not enforce alignment of
     759      <p id="rfc.section.3.2.p.3">All integer values, including length, version, and type, are in network byte order. HTTP/2.0 does not enforce alignment of
    700760         types in dynamically sized frames.
    701761      </p>
    702       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="ControlFrames" href="#ControlFrames">Control frames</a></h3>
    703       <div id="rfc.figure.u.1"></div> <pre>+----------------------------------+
     762      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="ControlFrames" href="#ControlFrames">Control frames</a></h3>
     763      <div id="rfc.figure.u.4"></div> <pre>+----------------------------------+
    704764|C| Version(15bits) | Type(16bits) |
    705765+----------------------------------+
    … …  
    708768|               Data               |
    709769+----------------------------------+
    710   </pre> <p id="rfc.section.2.2.1.p.2">Control bit: The 'C' bit is a single bit indicating if this is a control message. For control frames this value is always
     770  </pre> <p id="rfc.section.3.2.1.p.2">Control bit: The 'C' bit is a single bit indicating if this is a control message. For control frames this value is always
    711771         1.
    712772      </p>
    713       <p id="rfc.section.2.2.1.p.3">Version: The version number of the HTTP/2.0 protocol. This document describes HTTP/2.0 version 3.</p>
    714       <p id="rfc.section.2.2.1.p.4">Type: The type of control frame. See Control Frames for the complete list of control frames.</p>
    715       <p id="rfc.section.2.2.1.p.5">Flags: Flags related to this frame. Flags for control frames and data frames are different.</p>
    716       <p id="rfc.section.2.2.1.p.6">Length: An unsigned 24-bit value representing the number of bytes after the length field.</p>
    717       <p id="rfc.section.2.2.1.p.7">Data: data associated with this control frame. The format and length of this data is controlled by the control frame type.</p>
    718       <p id="rfc.section.2.2.1.p.8">Control frame processing requirements: </p>
     773      <p id="rfc.section.3.2.1.p.3">Version: The version number of the HTTP/2.0 protocol. This document describes HTTP/2.0 version 3.</p>
     774      <p id="rfc.section.3.2.1.p.4">Type: The type of control frame. See Control Frames for the complete list of control frames.</p>
     775      <p id="rfc.section.3.2.1.p.5">Flags: Flags related to this frame. Flags for control frames and data frames are different.</p>
     776      <p id="rfc.section.3.2.1.p.6">Length: An unsigned 24-bit value representing the number of bytes after the length field.</p>
     777      <p id="rfc.section.3.2.1.p.7">Data: data associated with this control frame. The format and length of this data is controlled by the control frame type.</p>
     778      <p id="rfc.section.3.2.1.p.8">Control frame processing requirements: </p>
    719779      <ul class="empty">
    720780         <li>Note that full length control frames (16MB) can be large for implementations running on resource-limited hardware. In such
    … …  
    723783         </li>
    724784      </ul>
    725       <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;<a id="DataFrames" href="#DataFrames">Data frames</a></h3>
    726       <div id="rfc.figure.u.2"></div> <pre>+----------------------------------+
     785      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="DataFrames" href="#DataFrames">Data frames</a></h3>
     786      <div id="rfc.figure.u.5"></div> <pre>+----------------------------------+
    727787|C|       Stream-ID (31bits)       |
    728788+----------------------------------+
    … …  
    731791|               Data               |
    732792+----------------------------------+
    733   </pre> <p id="rfc.section.2.2.2.p.2">Control bit: For data frames this value is always 0.</p>
    734       <p id="rfc.section.2.2.2.p.3">Stream-ID: A 31-bit value identifying the stream.</p>
    735       <p id="rfc.section.2.2.2.p.4">Flags: Flags related to this frame. Valid flags are: </p>
     793  </pre> <p id="rfc.section.3.2.2.p.2">Control bit: For data frames this value is always 0.</p>
     794      <p id="rfc.section.3.2.2.p.3">Stream-ID: A 31-bit value identifying the stream.</p>
     795      <p id="rfc.section.3.2.2.p.4">Flags: Flags related to this frame. Valid flags are: </p>
    736796      <ul class="empty">
    737          <li>0x01 = FLAG_FIN - signifies that this frame represents the last frame to be transmitted on this stream. See Stream Close (<a href="#StreamClose" title="Stream close">Section&nbsp;2.3.7</a>) below.
     797         <li>0x01 = FLAG_FIN - signifies that this frame represents the last frame to be transmitted on this stream. See Stream Close (<a href="#StreamClose" title="Stream close">Section&nbsp;3.3.7</a>) below.
    738798         </li>
    739799         <li>0x02 = FLAG_COMPRESS - indicates that the data in this frame has been compressed.</li>
    740800      </ul>
    741       <p id="rfc.section.2.2.2.p.5">Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a data frame is
     801      <p id="rfc.section.3.2.2.p.5">Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a data frame is
    742802         8 bytes + length. It is valid to have a zero-length data frame.
    743803      </p>
    744       <p id="rfc.section.2.2.2.p.6">Data: The variable-length data payload; the length was defined in the length field.</p>
    745       <p id="rfc.section.2.2.2.p.7">Data frame processing requirements: </p>
     804      <p id="rfc.section.3.2.2.p.6">Data: The variable-length data payload; the length was defined in the length field.</p>
     805      <p id="rfc.section.3.2.2.p.7">Data frame processing requirements: </p>
    746806      <ul class="empty">
    747          <li>If an endpoint receives a data frame for a stream-id which is not open and the endpoint has not sent a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section&nbsp;2.6.6</a>) frame, it MUST send issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the error code INVALID_STREAM for the stream-id.
     807         <li>If an endpoint receives a data frame for a stream-id which is not open and the endpoint has not sent a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section&nbsp;3.6.6</a>) frame, it MUST send issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the error code INVALID_STREAM for the stream-id.
    748808         </li>
    749809         <li>If the endpoint which created the stream receives a data frame before receiving a SYN_REPLY on that stream, it is a protocol
    750             error, and the recipient MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id.
     810            error, and the recipient MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id.
    751811         </li>
    752812         <li>Implementors note: If an endpoint receives multiple data frames for invalid stream-ids, it MAY close the session.</li>
    … …  
    760820         </li>
    761821      </ul>
    762       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Streams
    763       </h2>
    764       <p id="rfc.section.2.3.p.1">Streams are independent sequences of bi-directional data divided into frames with several properties: </p>
     822      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;Streams
     823      </h2>
     824      <p id="rfc.section.3.3.p.1">Streams are independent sequences of bi-directional data divided into frames with several properties: </p>
    765825      <ul class="empty">
    766826         <li>Streams may be created by either the client or server.</li>
    … …  
    769829         <li>Streams may be cancelled.</li>
    770830      </ul>
    771       <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="StreamFrames" href="#StreamFrames">Stream frames</a></h3>
    772       <p id="rfc.section.2.3.1.p.1">HTTP/2.0 defines 3 control frames to manage the lifecycle of a stream: </p>
     831      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="StreamFrames" href="#StreamFrames">Stream frames</a></h3>
     832      <p id="rfc.section.3.3.1.p.1">HTTP/2.0 defines 3 control frames to manage the lifecycle of a stream: </p>
    773833      <ul class="empty">
    774834         <li>SYN_STREAM - Open a new stream</li>
    … …  
    776836         <li>RST_STREAM - Close a stream</li>
    777837      </ul>
    778       <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="StreamCreation" href="#StreamCreation">Stream creation</a></h3>
    779       <p id="rfc.section.2.3.2.p.1">A stream is created by sending a control frame with the type set to SYN_STREAM (<a href="#SYN_STREAM" title="SYN_STREAM">Section&nbsp;2.6.1</a>). If the server is initiating the stream, the Stream-ID must be even. If the client is initiating the stream, the Stream-ID
     838      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="StreamCreation" href="#StreamCreation">Stream creation</a></h3>
     839      <p id="rfc.section.3.3.2.p.1">A stream is created by sending a control frame with the type set to SYN_STREAM (<a href="#SYN_STREAM" title="SYN_STREAM">Section&nbsp;3.6.1</a>). If the server is initiating the stream, the Stream-ID must be even. If the client is initiating the stream, the Stream-ID
    780840         must be odd. 0 is not a valid Stream-ID. Stream-IDs from each side of the connection must increase monotonically as new streams
    781841         are created. E.g. Stream 2 may be created after stream 3, but stream 7 must not be created after stream 9. Stream IDs do not
    782842         wrap: when a client or server cannot create a new stream id without exceeding a 31 bit value, it MUST NOT create a new stream.
    783843      </p>
    784       <p id="rfc.section.2.3.2.p.2">The stream-id MUST increase with each new stream. If an endpoint receives a SYN_STREAM with a stream id which is less than
    785          any previously received SYN_STREAM, it MUST issue a session error (<a href="#SessionErrorHandler" title="Session Error Handling">Section&nbsp;2.4.1</a>) with the status PROTOCOL_ERROR.
    786       </p>
    787       <p id="rfc.section.2.3.2.p.3">It is a protocol error to send two SYN_STREAMs with the same stream-id. If a recipient receives a second SYN_STREAM for the
    788          same stream, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the status code PROTOCOL_ERROR.
    789       </p>
    790       <p id="rfc.section.2.3.2.p.4">Upon receipt of a SYN_STREAM, the recipient can reject the stream by sending a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the error code REFUSED_STREAM. Note, however, that the creating endpoint may have already sent additional frames for
     844      <p id="rfc.section.3.3.2.p.2">The stream-id MUST increase with each new stream. If an endpoint receives a SYN_STREAM with a stream id which is less than
     845         any previously received SYN_STREAM, it MUST issue a session error (<a href="#SessionErrorHandler" title="Session Error Handling">Section&nbsp;3.4.1</a>) with the status PROTOCOL_ERROR.
     846      </p>
     847      <p id="rfc.section.3.3.2.p.3">It is a protocol error to send two SYN_STREAMs with the same stream-id. If a recipient receives a second SYN_STREAM for the
     848         same stream, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the status code PROTOCOL_ERROR.
     849      </p>
     850      <p id="rfc.section.3.3.2.p.4">Upon receipt of a SYN_STREAM, the recipient can reject the stream by sending a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the error code REFUSED_STREAM. Note, however, that the creating endpoint may have already sent additional frames for
    791851         that stream which cannot be immediately stopped.
    792852      </p>
    793       <p id="rfc.section.2.3.2.p.5">Once the stream is created, the creator may immediately send HEADERS or DATA frames for that stream, without needing to wait
     853      <p id="rfc.section.3.3.2.p.5">Once the stream is created, the creator may immediately send HEADERS or DATA frames for that stream, without needing to wait
    794854         for the recipient to acknowledge.
    795855      </p>
    796       <h4 id="rfc.section.2.3.2.1"><a href="#rfc.section.2.3.2.1">2.3.2.1</a>&nbsp;Unidirectional streams
     856      <h4 id="rfc.section.3.3.2.1"><a href="#rfc.section.3.3.2.1">3.3.2.1</a>&nbsp;Unidirectional streams
    797857      </h4>
    798       <p id="rfc.section.2.3.2.1.p.1">When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag set, it creates a unidirectional stream which the creating
    799          endpoint can use to send frames, but the receiving endpoint cannot. The receiving endpoint is implicitly already in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;2.3.6</a>) state.
    800       </p>
    801       <h4 id="rfc.section.2.3.2.2"><a href="#rfc.section.2.3.2.2">2.3.2.2</a>&nbsp;Bidirectional streams
     858      <p id="rfc.section.3.3.2.1.p.1">When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag set, it creates a unidirectional stream which the creating
     859         endpoint can use to send frames, but the receiving endpoint cannot. The receiving endpoint is implicitly already in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;3.3.6</a>) state.
     860      </p>
     861      <h4 id="rfc.section.3.3.2.2"><a href="#rfc.section.3.3.2.2">3.3.2.2</a>&nbsp;Bidirectional streams
    802862      </h4>
    803       <p id="rfc.section.2.3.2.2.p.1">SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are bidirectional streams. Both endpoints can send data on
     863      <p id="rfc.section.3.3.2.2.p.1">SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are bidirectional streams. Both endpoints can send data on
    804864         a bi-directional stream.
    805865      </p>
    806       <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="StreamPriority" href="#StreamPriority">Stream priority</a></h3>
    807       <p id="rfc.section.2.3.3.p.1">The creator of a stream assigns a priority for that stream. Priority is represented as an integer from 0 to 7. 0 represents
     866      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="StreamPriority" href="#StreamPriority">Stream priority</a></h3>
     867      <p id="rfc.section.3.3.3.p.1">The creator of a stream assigns a priority for that stream. Priority is represented as an integer from 0 to 7. 0 represents
    808868         the highest priority and 7 represents the lowest priority.
    809869      </p>
    810       <p id="rfc.section.2.3.3.p.2">The sender and recipient SHOULD use best-effort to process streams in the order of highest priority to lowest priority.</p>
    811       <h3 id="rfc.section.2.3.4"><a href="#rfc.section.2.3.4">2.3.4</a>&nbsp;Stream headers
     870      <p id="rfc.section.3.3.3.p.2">The sender and recipient SHOULD use best-effort to process streams in the order of highest priority to lowest priority.</p>
     871      <h3 id="rfc.section.3.3.4"><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;Stream headers
    812872      </h3>
    813       <p id="rfc.section.2.3.4.p.1">Streams carry optional sets of name/value pair headers which carry metadata about the stream. After the stream has been created,
    814          and as long as the sender is not closed (<a href="#StreamClose" title="Stream close">Section&nbsp;2.3.7</a>) or half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;2.3.6</a>), each side may send HEADERS frame(s) containing the header data. Header data can be sent in multiple HEADERS frames, and
     873      <p id="rfc.section.3.3.4.p.1">Streams carry optional sets of name/value pair headers which carry metadata about the stream. After the stream has been created,
     874         and as long as the sender is not closed (<a href="#StreamClose" title="Stream close">Section&nbsp;3.3.7</a>) or half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;3.3.6</a>), each side may send HEADERS frame(s) containing the header data. Header data can be sent in multiple HEADERS frames, and
    815875         HEADERS frames may be interleaved with data frames.
    816876      </p>
    817       <h3 id="rfc.section.2.3.5"><a href="#rfc.section.2.3.5">2.3.5</a>&nbsp;Stream data exchange
     877      <h3 id="rfc.section.3.3.5"><a href="#rfc.section.3.3.5">3.3.5</a>&nbsp;Stream data exchange
    818878      </h3>
    819       <p id="rfc.section.2.3.5.p.1">Once a stream is created, it can be used to send arbitrary amounts of data. Generally this means that a series of data frames
    820          will be sent on the stream until a frame containing the FLAG_FIN flag is set. The FLAG_FIN can be set on a SYN_STREAM (<a href="#SYN_STREAM" title="SYN_STREAM">Section&nbsp;2.6.1</a>), SYN_REPLY (<a href="#SYN_REPLY" title="SYN_REPLY">Section&nbsp;2.6.2</a>), HEADERS (<a href="#HEADERS" title="HEADERS">Section&nbsp;2.6.7</a>) or a DATA (<a href="#DataFrames" title="Data frames">Section&nbsp;2.2.2</a>) frame. Once the FLAG_FIN has been sent, the stream is considered to be half-closed.
    821       </p>
    822       <h3 id="rfc.section.2.3.6"><a href="#rfc.section.2.3.6">2.3.6</a>&nbsp;<a id="StreamHalfClose" href="#StreamHalfClose">Stream half-close</a></h3>
    823       <p id="rfc.section.2.3.6.p.1">When one side of the stream sends a frame with the FLAG_FIN flag set, the stream is half-closed from that endpoint. The sender
     879      <p id="rfc.section.3.3.5.p.1">Once a stream is created, it can be used to send arbitrary amounts of data. Generally this means that a series of data frames
     880         will be sent on the stream until a frame containing the FLAG_FIN flag is set. The FLAG_FIN can be set on a SYN_STREAM (<a href="#SYN_STREAM" title="SYN_STREAM">Section&nbsp;3.6.1</a>), SYN_REPLY (<a href="#SYN_REPLY" title="SYN_REPLY">Section&nbsp;3.6.2</a>), HEADERS (<a href="#HEADERS" title="HEADERS">Section&nbsp;3.6.7</a>) or a DATA (<a href="#DataFrames" title="Data frames">Section&nbsp;3.2.2</a>) frame. Once the FLAG_FIN has been sent, the stream is considered to be half-closed.
     881      </p>
     882      <h3 id="rfc.section.3.3.6"><a href="#rfc.section.3.3.6">3.3.6</a>&nbsp;<a id="StreamHalfClose" href="#StreamHalfClose">Stream half-close</a></h3>
     883      <p id="rfc.section.3.3.6.p.1">When one side of the stream sends a frame with the FLAG_FIN flag set, the stream is half-closed from that endpoint. The sender
    824884         of the FLAG_FIN MUST NOT send further frames on that stream. When both sides have half-closed, the stream is closed.
    825885      </p>
    826       <p id="rfc.section.2.3.6.p.2">If an endpoint receives a data frame after the stream is half-closed from the sender (e.g. the endpoint has already received
     886      <p id="rfc.section.3.3.6.p.2">If an endpoint receives a data frame after the stream is half-closed from the sender (e.g. the endpoint has already received
    827887         a prior frame for the stream with the FIN flag set), it MUST send a RST_STREAM to the sender with the status STREAM_ALREADY_CLOSED.
    828888      </p>
    829       <h3 id="rfc.section.2.3.7"><a href="#rfc.section.2.3.7">2.3.7</a>&nbsp;<a id="StreamClose" href="#StreamClose">Stream close</a></h3>
    830       <p id="rfc.section.2.3.7.p.1">There are 3 ways that streams can be terminated: </p>
     889      <h3 id="rfc.section.3.3.7"><a href="#rfc.section.3.3.7">3.3.7</a>&nbsp;<a id="StreamClose" href="#StreamClose">Stream close</a></h3>
     890      <p id="rfc.section.3.3.7.p.1">There are 3 ways that streams can be terminated: </p>
    831891      <ul class="empty">
    832892         <li>Normal termination: Normal stream termination occurs when both sender and recipient have half-closed the stream by sending
    … …  
    837897            to complete the stream and that no further data will be sent on the stream. When a RST_STREAM is sent from the stream recipient,
    838898            the sender, upon receipt, should stop sending any data on the stream. The stream recipient should be aware that there is a
    839             race between data already in transit from the sender and the time the RST_STREAM is received. See Stream Error Handling (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>)
     899            race between data already in transit from the sender and the time the RST_STREAM is received. See Stream Error Handling (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>)
    840900         </li>
    841901         <li>TCP connection teardown: If the TCP connection is torn down while un-closed streams exist, then the endpoint must assume that
    … …  
    843903         </li>
    844904      </ul>
    845       <p id="rfc.section.2.3.7.p.2">If an endpoint receives a data frame after the stream is closed, it must send a RST_STREAM to the sender with the status PROTOCOL_ERROR.</p>
    846       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Error Handling
    847       </h2>
    848       <p id="rfc.section.2.4.p.1">The HTTP/2.0 framing layer has only two types of errors, and they are always handled consistently. Any reference in this specification
    849          to "issue a session error" refers to <a href="#SessionErrorHandler" title="Session Error Handling">Section&nbsp;2.4.1</a>. Any reference to "issue a stream error" refers to <a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>.
    850       </p>
    851       <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<a id="SessionErrorHandler" href="#SessionErrorHandler">Session Error Handling</a></h3>
    852       <p id="rfc.section.2.4.1.p.1">A session error is any error which prevents further processing of the framing layer or which corrupts the session compression
    853          state. When a session error occurs, the endpoint encountering the error MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section&nbsp;2.6.6</a>) frame with the stream id of most recently received stream from the remote endpoint, and the error code for why the session
     905      <p id="rfc.section.3.3.7.p.2">If an endpoint receives a data frame after the stream is closed, it must send a RST_STREAM to the sender with the status PROTOCOL_ERROR.</p>
     906      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;Error Handling
     907      </h2>
     908      <p id="rfc.section.3.4.p.1">The HTTP/2.0 framing layer has only two types of errors, and they are always handled consistently. Any reference in this specification
     909         to "issue a session error" refers to <a href="#SessionErrorHandler" title="Session Error Handling">Section&nbsp;3.4.1</a>. Any reference to "issue a stream error" refers to <a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>.
     910      </p>
     911      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="SessionErrorHandler" href="#SessionErrorHandler">Session Error Handling</a></h3>
     912      <p id="rfc.section.3.4.1.p.1">A session error is any error which prevents further processing of the framing layer or which corrupts the session compression
     913         state. When a session error occurs, the endpoint encountering the error MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section&nbsp;3.6.6</a>) frame with the stream id of most recently received stream from the remote endpoint, and the error code for why the session
    854914         is terminating. After sending the GOAWAY frame, the endpoint MUST close the TCP connection.
    855915      </p>
    856       <p id="rfc.section.2.4.1.p.2">Note that the session compression state is dependent upon both endpoints always processing all compressed data. If an endpoint
     916      <p id="rfc.section.3.4.1.p.2">Note that the session compression state is dependent upon both endpoints always processing all compressed data. If an endpoint
    857917         partially processes a frame containing compressed data without updating compression state properly, future control frames
    858918         which use compression will be always be errored. Implementations SHOULD always try to process compressed data so that errors
    859919         which could be handled as stream errors do not become session errors.
    860920      </p>
    861       <p id="rfc.section.2.4.1.p.3">Note that because this GOAWAY is sent during a session error case, it is possible that the GOAWAY will not be reliably received
     921      <p id="rfc.section.3.4.1.p.3">Note that because this GOAWAY is sent during a session error case, it is possible that the GOAWAY will not be reliably received
    862922         by the receiving endpoint. It is a best-effort attempt to communicate with the remote about why the session is going down.
    863923      </p>
    864       <h3 id="rfc.section.2.4.2"><a href="#rfc.section.2.4.2">2.4.2</a>&nbsp;<a id="StreamErrorHandler" href="#StreamErrorHandler">Stream Error Handling</a></h3>
    865       <p id="rfc.section.2.4.2.p.1">A stream error is an error related to a specific stream-id which does not affect processing of other streams at the framing
    866          layer. Upon a stream error, the endpoint MUST send a RST_STREAM (<a href="#RST_STREAM" title="RST_STREAM">Section&nbsp;2.6.3</a>) frame which contains the stream id of the stream where the error occurred and the error status which caused the error. After
     924      <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;<a id="StreamErrorHandler" href="#StreamErrorHandler">Stream Error Handling</a></h3>
     925      <p id="rfc.section.3.4.2.p.1">A stream error is an error related to a specific stream-id which does not affect processing of other streams at the framing
     926         layer. Upon a stream error, the endpoint MUST send a RST_STREAM (<a href="#RST_STREAM" title="RST_STREAM">Section&nbsp;3.6.3</a>) frame which contains the stream id of the stream where the error occurred and the error status which caused the error. After
    867927         sending the RST_STREAM, the stream is closed to the sending endpoint. After sending the RST_STREAM, if the sender receives
    868928         any frames other than a RST_STREAM for that stream id, it will result in sending additional RST_STREAM frames. An endpoint
    … …  
    870930         does not cause the HTTP/2.0 session to be closed.
    871931      </p>
    872       <p id="rfc.section.2.4.2.p.2">If an endpoint has multiple RST_STREAM frames to send in succession for the same stream-id and the same error code, it MAY
     932      <p id="rfc.section.3.4.2.p.2">If an endpoint has multiple RST_STREAM frames to send in succession for the same stream-id and the same error code, it MAY
    873933         coalesce them into a single RST_STREAM frame. (This can happen if a stream is closed, but the remote sends multiple data frames.
    874934         There is no reason to send a RST_STREAM for each frame in succession).
    875935      </p>
    876       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Data flow
    877       </h2>
    878       <p id="rfc.section.2.5.p.1">Because TCP provides a single stream of data on which HTTP/2.0 multiplexes multiple logical streams, clients and servers must
     936      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;Data flow
     937      </h2>
     938      <p id="rfc.section.3.5.p.1">Because TCP provides a single stream of data on which HTTP/2.0 multiplexes multiple logical streams, clients and servers must
    879939         intelligently interleave data messages for concurrent sessions.
    880940      </p>
    881       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;Control frame types
    882       </h2>
    883       <h3 id="rfc.section.2.6.1"><a href="#rfc.section.2.6.1">2.6.1</a>&nbsp;<a id="SYN_STREAM" href="#SYN_STREAM">SYN_STREAM</a></h3>
    884       <p id="rfc.section.2.6.1.p.1">The SYN_STREAM control frame allows the sender to asynchronously create a stream between the endpoints. See Stream Creation (<a href="#StreamCreation" title="Stream creation">Section&nbsp;2.3.2</a>)
    885       </p>
    886       <div id="rfc.figure.u.3"></div> <pre>+------------------------------------+
     941      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;Control frame types
     942      </h2>
     943      <h3 id="rfc.section.3.6.1"><a href="#rfc.section.3.6.1">3.6.1</a>&nbsp;<a id="SYN_STREAM" href="#SYN_STREAM">SYN_STREAM</a></h3>
     944      <p id="rfc.section.3.6.1.p.1">The SYN_STREAM control frame allows the sender to asynchronously create a stream between the endpoints. See Stream Creation (<a href="#StreamCreation" title="Stream creation">Section&nbsp;3.3.2</a>)
     945      </p>
     946      <div id="rfc.figure.u.6"></div> <pre>+------------------------------------+
    887947|1|    version    |         1        |
    888948+------------------------------------+
    … …  
    906966+------------------------------------+    |
    907967|           (repeats)                |   &lt;+
    908             </pre> <p id="rfc.section.2.6.1.p.3">Flags: Flags related to this frame. Valid flags are: </p>
     968            </pre> <p id="rfc.section.3.6.1.p.3">Flags: Flags related to this frame. Valid flags are: </p>
    909969      <ul class="empty">
    910          <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;2.3.6</a>) state.
    911          </li>
    912          <li>0x02 = FLAG_UNIDIRECTIONAL - a stream created with this flag puts the recipient in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;2.3.6</a>) state.
     970         <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;3.3.6</a>) state.
     971         </li>
     972         <li>0x02 = FLAG_UNIDIRECTIONAL - a stream created with this flag puts the recipient in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;3.3.6</a>) state.
    913973         </li>
    914974      </ul>
    915       <p id="rfc.section.2.6.1.p.4">Length: The length is the number of bytes which follow the length field in the frame. For SYN_STREAM frames, this is 10 bytes
     975      <p id="rfc.section.3.6.1.p.4">Length: The length is the number of bytes which follow the length field in the frame. For SYN_STREAM frames, this is 10 bytes
    916976         plus the length of the compressed Name/Value block.
    917977      </p>
    918       <p id="rfc.section.2.6.1.p.5">Stream-ID: The 31-bit identifier for this stream. This stream-id will be used in frames which are part of this stream.</p>
    919       <p id="rfc.section.2.6.1.p.6">Associated-To-Stream-ID: The 31-bit identifier for a stream which this stream is associated to. If this stream is independent
     978      <p id="rfc.section.3.6.1.p.5">Stream-ID: The 31-bit identifier for this stream. This stream-id will be used in frames which are part of this stream.</p>
     979      <p id="rfc.section.3.6.1.p.6">Associated-To-Stream-ID: The 31-bit identifier for a stream which this stream is associated to. If this stream is independent
    920980         of all other streams, it should be 0.
    921981      </p>
    922       <p id="rfc.section.2.6.1.p.7">Priority: A 3-bit priority (<a href="#StreamPriority" title="Stream priority">Section&nbsp;2.3.3</a>) field.
    923       </p>
    924       <p id="rfc.section.2.6.1.p.8">Unused: 5 bits of unused space, reserved for future use.</p>
    925       <p id="rfc.section.2.6.1.p.9">Slot: An 8 bit unsigned integer specifying the index in the server's CREDENTIAL vector of the client certificate to be used
    926          for this request. see CREDENTIAL frame (<a href="#CREDENTIAL" title="CREDENTIAL">Section&nbsp;2.6.9</a>). The value 0 means no client certificate should be associated with this stream.
    927       </p>
    928       <p id="rfc.section.2.6.1.p.10">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section&nbsp;2.6.10</a>).
    929       </p>
    930       <p id="rfc.section.2.6.1.p.11">If an endpoint receives a SYN_STREAM which is larger than the implementation supports, it MAY send a RST_STREAM with error
    931          code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section (<a href="#ControlFrames" title="Control frames">Section&nbsp;2.2.1</a>).
    932       </p>
    933       <h3 id="rfc.section.2.6.2"><a href="#rfc.section.2.6.2">2.6.2</a>&nbsp;<a id="SYN_REPLY" href="#SYN_REPLY">SYN_REPLY</a></h3>
    934       <p id="rfc.section.2.6.2.p.1">SYN_REPLY indicates the acceptance of a stream creation by the recipient of a SYN_STREAM frame.</p>
    935       <div id="rfc.figure.u.4"></div> <pre>+------------------------------------+
     982      <p id="rfc.section.3.6.1.p.7">Priority: A 3-bit priority (<a href="#StreamPriority" title="Stream priority">Section&nbsp;3.3.3</a>) field.
     983      </p>
     984      <p id="rfc.section.3.6.1.p.8">Unused: 5 bits of unused space, reserved for future use.</p>
     985      <p id="rfc.section.3.6.1.p.9">Slot: An 8 bit unsigned integer specifying the index in the server's CREDENTIAL vector of the client certificate to be used
     986         for this request. see CREDENTIAL frame (<a href="#CREDENTIAL" title="CREDENTIAL">Section&nbsp;3.6.9</a>). The value 0 means no client certificate should be associated with this stream.
     987      </p>
     988      <p id="rfc.section.3.6.1.p.10">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section&nbsp;3.6.10</a>).
     989      </p>
     990      <p id="rfc.section.3.6.1.p.11">If an endpoint receives a SYN_STREAM which is larger than the implementation supports, it MAY send a RST_STREAM with error
     991         code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section (<a href="#ControlFrames" title="Control frames">Section&nbsp;3.2.1</a>).
     992      </p>
     993      <h3 id="rfc.section.3.6.2"><a href="#rfc.section.3.6.2">3.6.2</a>&nbsp;<a id="SYN_REPLY" href="#SYN_REPLY">SYN_REPLY</a></h3>
     994      <p id="rfc.section.3.6.2.p.1">SYN_REPLY indicates the acceptance of a stream creation by the recipient of a SYN_STREAM frame.</p>
     995      <div id="rfc.figure.u.7"></div> <pre>+------------------------------------+
    936996|1|    version    |         2        |
    937997+------------------------------------+
    … …  
    9511011+------------------------------------+    |
    9521012|           (repeats)                |   &lt;+
    953             </pre> <p id="rfc.section.2.6.2.p.3">Flags: Flags related to this frame. Valid flags are: </p>
     1013            </pre> <p id="rfc.section.3.6.2.p.3">Flags: Flags related to this frame. Valid flags are: </p>
    9541014      <ul class="empty">
    955          <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;2.3.6</a>) state.
     1015         <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;3.3.6</a>) state.
    9561016         </li>
    9571017      </ul>
    958       <p id="rfc.section.2.6.2.p.4">Length: The length is the number of bytes which follow the length field in the frame. For SYN_REPLY frames, this is 4 bytes
     1018      <p id="rfc.section.3.6.2.p.4">Length: The length is the number of bytes which follow the length field in the frame. For SYN_REPLY frames, this is 4 bytes
    9591019         plus the length of the compressed Name/Value block.
    9601020      </p>
    961       <p id="rfc.section.2.6.2.p.5">Stream-ID: The 31-bit identifier for this stream.</p>
    962       <p id="rfc.section.2.6.2.p.6">If an endpoint receives multiple SYN_REPLY frames for the same active stream ID, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the error code STREAM_IN_USE.
    963       </p>
    964       <p id="rfc.section.2.6.2.p.7">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section&nbsp;2.6.10</a>).
    965       </p>
    966       <p id="rfc.section.2.6.2.p.8">If an endpoint receives a SYN_REPLY which is larger than the implementation supports, it MAY send a RST_STREAM with error
    967          code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section (<a href="#ControlFrames" title="Control frames">Section&nbsp;2.2.1</a>).
    968       </p>
    969       <h3 id="rfc.section.2.6.3"><a href="#rfc.section.2.6.3">2.6.3</a>&nbsp;<a id="RST_STREAM" href="#RST_STREAM">RST_STREAM</a></h3>
    970       <p id="rfc.section.2.6.3.p.1">The RST_STREAM frame allows for abnormal termination of a stream. When sent by the creator of a stream, it indicates the creator
     1021      <p id="rfc.section.3.6.2.p.5">Stream-ID: The 31-bit identifier for this stream.</p>
     1022      <p id="rfc.section.3.6.2.p.6">If an endpoint receives multiple SYN_REPLY frames for the same active stream ID, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the error code STREAM_IN_USE.
     1023      </p>
     1024      <p id="rfc.section.3.6.2.p.7">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section&nbsp;3.6.10</a>).
     1025      </p>
     1026      <p id="rfc.section.3.6.2.p.8">If an endpoint receives a SYN_REPLY which is larger than the implementation supports, it MAY send a RST_STREAM with error
     1027         code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section (<a href="#ControlFrames" title="Control frames">Section&nbsp;3.2.1</a>).
     1028      </p>
     1029      <h3 id="rfc.section.3.6.3"><a href="#rfc.section.3.6.3">3.6.3</a>&nbsp;<a id="RST_STREAM" href="#RST_STREAM">RST_STREAM</a></h3>
     1030      <p id="rfc.section.3.6.3.p.1">The RST_STREAM frame allows for abnormal termination of a stream. When sent by the creator of a stream, it indicates the creator
    9711031         wishes to cancel the stream. When sent by the recipient of a stream, it indicates an error or that the recipient did not want
    9721032         to accept the stream, so the stream should be closed.
    9731033      </p>
    974       <div id="rfc.figure.u.5"></div> <pre>+----------------------------------+
     1034      <div id="rfc.figure.u.8"></div> <pre>+----------------------------------+
    9751035|1|   version    |         3       |
    9761036+----------------------------------+
    … …  
    9811041|          Status code             |
    9821042+----------------------------------+
    983             </pre> <p id="rfc.section.2.6.3.p.3">Flags: Flags related to this frame. RST_STREAM does not define any flags. This value must be 0.</p>
    984       <p id="rfc.section.2.6.3.p.4">Length: An unsigned 24-bit value representing the number of bytes after the length field. For RST_STREAM control frames, this
     1043            </pre> <p id="rfc.section.3.6.3.p.3">Flags: Flags related to this frame. RST_STREAM does not define any flags. This value must be 0.</p>
     1044      <p id="rfc.section.3.6.3.p.4">Length: An unsigned 24-bit value representing the number of bytes after the length field. For RST_STREAM control frames, this
    9851045         value is always 8.
    9861046      </p>
    987       <p id="rfc.section.2.6.3.p.5">Stream-ID: The 31-bit identifier for this stream.</p>
    988       <p id="rfc.section.2.6.3.p.6">Status code: (32 bits) An indicator for why the stream is being terminated.The following status codes are defined: </p>
     1047      <p id="rfc.section.3.6.3.p.5">Stream-ID: The 31-bit identifier for this stream.</p>
     1048      <p id="rfc.section.3.6.3.p.6">Status code: (32 bits) An indicator for why the stream is being terminated.The following status codes are defined: </p>
    9891049      <ul class="empty">
    9901050         <li>1 - PROTOCOL_ERROR. This is a generic error, and should only be used if a more specific error is not available.</li>
    … …  
    10081068         <li>Note: 0 is not a valid status code for a RST_STREAM.</li>
    10091069      </ul>
    1010       <p id="rfc.section.2.6.3.p.7">After receiving a RST_STREAM on a stream, the recipient must not send additional frames for that stream, and the stream moves
     1070      <p id="rfc.section.3.6.3.p.7">After receiving a RST_STREAM on a stream, the recipient must not send additional frames for that stream, and the stream moves
    10111071         into the closed state.
    10121072      </p>
    1013       <h3 id="rfc.section.2.6.4"><a href="#rfc.section.2.6.4">2.6.4</a>&nbsp;<a id="SETTINGS" href="#SETTINGS">SETTINGS</a></h3>
    1014       <p id="rfc.section.2.6.4.p.1">A SETTINGS frame contains a set of id/value pairs for communicating configuration data about how the two endpoints may communicate.
     1073      <h3 id="rfc.section.3.6.4"><a href="#rfc.section.3.6.4">3.6.4</a>&nbsp;<a id="SETTINGS" href="#SETTINGS">SETTINGS</a></h3>
     1074      <p id="rfc.section.3.6.4.p.1">A SETTINGS frame contains a set of id/value pairs for communicating configuration data about how the two endpoints may communicate.
    10151075         SETTINGS frames can be sent at any time by either endpoint, are optionally sent, and are fully asynchronous. When the server
    10161076         is the sender, the sender can request that configuration data be persisted by the client across HTTP/2.0 sessions and returned
    10171077         to the server in future communications.
    10181078      </p>
    1019       <p id="rfc.section.2.6.4.p.2">Persistence of SETTINGS ID/Value pairs is done on a per origin/IP pair (the "origin" is the set of scheme, host, and port
     1079      <p id="rfc.section.3.6.4.p.2">Persistence of SETTINGS ID/Value pairs is done on a per origin/IP pair (the "origin" is the set of scheme, host, and port
    10201080         from the URI. See <a href="#RFC6454" id="rfc.xref.RFC6454.1"><cite title="The Web Origin Concept">[RFC6454]</cite></a>). That is, when a client connects to a server, and the server persists settings within the client, the client SHOULD return
    10211081         the persisted settings on future connections to the same origin AND IP address and TCP port. Clients MUST NOT request servers
    10221082         to use the persistence features of the SETTINGS frames, and servers MUST ignore persistence related flags sent by a client.
    10231083      </p>
    1024       <div id="rfc.figure.u.6"></div> <pre>+----------------------------------+
     1084      <div id="rfc.figure.u.9"></div> <pre>+----------------------------------+
    10251085|1|   version    |         4       |
    10261086+----------------------------------+
    … …  
    10311091|          ID/Value Pairs          |
    10321092|             ...                  |
    1033             </pre> <p id="rfc.section.2.6.4.p.4">Control bit: The control bit is always 1 for this message.</p>
    1034       <p id="rfc.section.2.6.4.p.5">Version: The HTTP/2.0 version number.</p>
    1035       <p id="rfc.section.2.6.4.p.6">Type: The message type for a SETTINGS message is 4.</p>
    1036       <p id="rfc.section.2.6.4.p.7">Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client should clear any previously persisted SETTINGS ID/Value pairs.
     1093            </pre> <p id="rfc.section.3.6.4.p.4">Control bit: The control bit is always 1 for this message.</p>
     1094      <p id="rfc.section.3.6.4.p.5">Version: The HTTP/2.0 version number.</p>
     1095      <p id="rfc.section.3.6.4.p.6">Type: The message type for a SETTINGS message is 4.</p>
     1096      <p id="rfc.section.3.6.4.p.7">Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client should clear any previously persisted SETTINGS ID/Value pairs.
    10371097         If this frame contains ID/Value pairs with the FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its existing,
    10381098         persisted settings, and then persist the values with the flag set which are contained within this frame. Because persistence
    10391099         is only implemented on the client, this flag can only be used when the sender is the server.
    10401100      </p>
    1041       <p id="rfc.section.2.6.4.p.8">Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a SETTINGS frame
     1101      <p id="rfc.section.3.6.4.p.8">Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a SETTINGS frame
    10421102         is 8 bytes + length.
    10431103      </p>
    1044       <p id="rfc.section.2.6.4.p.9">Number of entries: A 32-bit value representing the number of ID/value pairs in this message.</p>
    1045       <p id="rfc.section.2.6.4.p.10">ID: A 32-bit ID number, comprised of 8 bits of flags and 24 bits of unique ID. </p>
     1104      <p id="rfc.section.3.6.4.p.9">Number of entries: A 32-bit value representing the number of ID/value pairs in this message.</p>
     1105      <p id="rfc.section.3.6.4.p.10">ID: A 32-bit ID number, comprised of 8 bits of flags and 24 bits of unique ID. </p>
    10461106      <ul class="empty">
    10471107         <li>ID.flags:
    … …  
    10871147         </li>
    10881148      </ul>
    1089       <p id="rfc.section.2.6.4.p.11">Value: A 32-bit value.</p>
    1090       <p id="rfc.section.2.6.4.p.12">The message is intentionally extensible for future information which may improve client-server communications. The sender
     1149      <p id="rfc.section.3.6.4.p.11">Value: A 32-bit value.</p>
     1150      <p id="rfc.section.3.6.4.p.12">The message is intentionally extensible for future information which may improve client-server communications. The sender
    10911151         does not need to send every type of ID/value. It must only send those for which it has accurate values to convey. When multiple
    10921152         ID/value pairs are sent, they should be sent in order of lowest id to highest id. A single SETTINGS frame MUST not contain
    … …  
    10941154         all values except the first one.
    10951155      </p>
    1096       <p id="rfc.section.2.6.4.p.13">A server may send multiple SETTINGS frames containing different ID/Value pairs. When the same ID/Value is sent twice, the
     1156      <p id="rfc.section.3.6.4.p.13">A server may send multiple SETTINGS frames containing different ID/Value pairs. When the same ID/Value is sent twice, the
    10971157         most recent value overrides any previously sent values. If the server sends IDs 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE
    10981158         in a first SETTINGS frame, and then sends IDs 4 and 5 with the FLAG_SETTINGS_PERSIST_VALUE, when the client returns the persisted
    10991159         state on its next SETTINGS frame, it SHOULD send all 5 settings (1, 2, 3, 4, and 5 in this example) to the server.
    11001160      </p>
    1101       <h3 id="rfc.section.2.6.5"><a href="#rfc.section.2.6.5">2.6.5</a>&nbsp;<a id="PING" href="#PING">PING</a></h3>
    1102       <p id="rfc.section.2.6.5.p.1">The PING control frame is a mechanism for measuring a minimal round-trip time from the sender. It can be sent from the client
     1161      <h3 id="rfc.section.3.6.5"><a href="#rfc.section.3.6.5">3.6.5</a>&nbsp;<a id="PING" href="#PING">PING</a></h3>
     1162      <p id="rfc.section.3.6.5.p.1">The PING control frame is a mechanism for measuring a minimal round-trip time from the sender. It can be sent from the client
    11031163         or the server. Recipients of a PING frame should send an identical frame to the sender as soon as possible (if there is other
    11041164         pending data waiting to be sent, PING should take highest priority). Each ping sent by a sender should use a unique ID.
    11051165      </p>
    1106       <div id="rfc.figure.u.7"></div> <pre>+----------------------------------+
     1166      <div id="rfc.figure.u.10"></div> <pre>+----------------------------------+
    11071167|1|   version    |         6       |
    11081168+----------------------------------+
    … …  
    11111171|            32-bit ID             |
    11121172+----------------------------------+
    1113             </pre> <p id="rfc.section.2.6.5.p.3">Control bit: The control bit is always 1 for this message.</p>
    1114       <p id="rfc.section.2.6.5.p.4">Version: The HTTP/2.0 version number.</p>
    1115       <p id="rfc.section.2.6.5.p.5">Type: The message type for a PING message is 6.</p>
    1116       <p id="rfc.section.2.6.5.p.6">Length: This frame is always 4 bytes long.</p>
    1117       <p id="rfc.section.2.6.5.p.7">ID: A unique ID for this ping, represented as an unsigned 32 bit value. When the client initiates a ping, it must use an odd
     1173            </pre> <p id="rfc.section.3.6.5.p.3">Control bit: The control bit is always 1 for this message.</p>
     1174      <p id="rfc.section.3.6.5.p.4">Version: The HTTP/2.0 version number.</p>
     1175      <p id="rfc.section.3.6.5.p.5">Type: The message type for a PING message is 6.</p>
     1176      <p id="rfc.section.3.6.5.p.6">Length: This frame is always 4 bytes long.</p>
     1177      <p id="rfc.section.3.6.5.p.7">ID: A unique ID for this ping, represented as an unsigned 32 bit value. When the client initiates a ping, it must use an odd
    11181178         numbered ID. When the server initiates a ping, it must use an even numbered ping. Use of odd/even IDs is required in order
    11191179         to avoid accidental looping on PINGs (where each side initiates an identical PING at the same time).
    11201180      </p>
    1121       <p id="rfc.section.2.6.5.p.8">Note: If a sender uses all possible PING ids (e.g. has sent all 2^31 possible IDs), it can wrap and start re-using IDs.</p>
    1122       <p id="rfc.section.2.6.5.p.9">If a server receives an even numbered PING which it did not initiate, it must ignore the PING. If a client receives an odd
     1181      <p id="rfc.section.3.6.5.p.8">Note: If a sender uses all possible PING ids (e.g. has sent all 2^31 possible IDs), it can wrap and start re-using IDs.</p>
     1182      <p id="rfc.section.3.6.5.p.9">If a server receives an even numbered PING which it did not initiate, it must ignore the PING. If a client receives an odd
    11231183         numbered PING which it did not initiate, it must ignore the PING.
    11241184      </p>
    1125       <h3 id="rfc.section.2.6.6"><a href="#rfc.section.2.6.6">2.6.6</a>&nbsp;<a id="GOAWAY" href="#GOAWAY">GOAWAY</a></h3>
    1126       <p id="rfc.section.2.6.6.p.1">The GOAWAY control frame is a mechanism to tell the remote side of the connection to stop creating streams on this session.
     1185      <h3 id="rfc.section.3.6.6"><a href="#rfc.section.3.6.6">3.6.6</a>&nbsp;<a id="GOAWAY" href="#GOAWAY">GOAWAY</a></h3>
     1186      <p id="rfc.section.3.6.6.p.1">The GOAWAY control frame is a mechanism to tell the remote side of the connection to stop creating streams on this session.
    11271187         It can be sent from the client or the server. Once sent, the sender will not respond to any new SYN_STREAMs on this session.
    11281188         Recipients of a GOAWAY frame must not send additional streams on this session, although a new session can be established for
    … …  
    11301190         or maintenance), while still finishing processing of previously established streams.
    11311191      </p>
    1132       <p id="rfc.section.2.6.6.p.2">There is an inherent race condition between an endpoint sending SYN_STREAMs and the remote sending a GOAWAY message. To deal
     1192      <p id="rfc.section.3.6.6.p.2">There is an inherent race condition between an endpoint sending SYN_STREAMs and the remote sending a GOAWAY message. To deal
    11331193         with this case, the GOAWAY contains a last-stream-id indicating the stream-id of the last stream which was created on the
    11341194         sending endpoint in this session. If the receiver of the GOAWAY sent new SYN_STREAMs for sessions after this last-stream-id,
    … …  
    11361196         the receiver may want to re-create the stream later on a new session).
    11371197      </p>
    1138       <p id="rfc.section.2.6.6.p.3">Endpoints should always send a GOAWAY message before closing a connection so that the remote can know whether a stream has
     1198      <p id="rfc.section.3.6.6.p.3">Endpoints should always send a GOAWAY message before closing a connection so that the remote can know whether a stream has
    11391199         been partially processed or not. (For example, if an HTTP client sends a POST at the same time that a server closes a connection,
    11401200         the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate
    11411201         where it stopped working).
    11421202      </p>
    1143       <p id="rfc.section.2.6.6.p.4">After sending a GOAWAY message, the sender must ignore all SYN_STREAM frames for new streams.</p>
    1144       <div id="rfc.figure.u.8"></div> <pre>+----------------------------------+
     1203      <p id="rfc.section.3.6.6.p.4">After sending a GOAWAY message, the sender must ignore all SYN_STREAM frames for new streams.</p>
     1204      <div id="rfc.figure.u.11"></div> <pre>+----------------------------------+
    11451205|1|   version    |         7       |
    11461206+----------------------------------+
    … …  
    11511211|          Status code             |
    11521212+----------------------------------+
    1153             </pre> <p id="rfc.section.2.6.6.p.6">Control bit: The control bit is always 1 for this message.</p>
    1154       <p id="rfc.section.2.6.6.p.7">Version: The HTTP/2.0 version number.</p>
    1155       <p id="rfc.section.2.6.6.p.8">Type: The message type for a GOAWAY message is 7.</p>
    1156       <p id="rfc.section.2.6.6.p.9">Length: This frame is always 8 bytes long.</p>
    1157       <p id="rfc.section.2.6.6.p.10">Last-good-stream-Id: The last stream id which was replied to (with either a SYN_REPLY or RST_STREAM) by the sender of the
     1213            </pre> <p id="rfc.section.3.6.6.p.6">Control bit: The control bit is always 1 for this message.</p>
     1214      <p id="rfc.section.3.6.6.p.7">Version: The HTTP/2.0 version number.</p>
     1215      <p id="rfc.section.3.6.6.p.8">Type: The message type for a GOAWAY message is 7.</p>
     1216      <p id="rfc.section.3.6.6.p.9">Length: This frame is always 8 bytes long.</p>
     1217      <p id="rfc.section.3.6.6.p.10">Last-good-stream-Id: The last stream id which was replied to (with either a SYN_REPLY or RST_STREAM) by the sender of the
    11581218         GOAWAY message. If no streams were replied to, this value MUST be 0.
    11591219      </p>
    1160       <p id="rfc.section.2.6.6.p.11">Status: The reason for closing the session. </p>
     1220      <p id="rfc.section.3.6.6.p.11">Status: The reason for closing the session. </p>
    11611221      <ul class="empty">
    11621222         <li>0 - OK. This is a normal session teardown.</li>
    … …  
    11661226         </li>
    11671227      </ul>
    1168       <h3 id="rfc.section.2.6.7"><a href="#rfc.section.2.6.7">2.6.7</a>&nbsp;<a id="HEADERS" href="#HEADERS">HEADERS</a></h3>
    1169       <p id="rfc.section.2.6.7.p.1">The HEADERS frame augments a stream with additional headers. It may be optionally sent on an existing stream at any time.
     1228      <h3 id="rfc.section.3.6.7"><a href="#rfc.section.3.6.7">3.6.7</a>&nbsp;<a id="HEADERS" href="#HEADERS">HEADERS</a></h3>
     1229      <p id="rfc.section.3.6.7.p.1">The HEADERS frame augments a stream with additional headers. It may be optionally sent on an existing stream at any time.
    11701230         Specific application of the headers in this frame is application-dependent. The name/value header block within this frame
    11711231         is compressed.
    11721232      </p>
    1173       <div id="rfc.figure.u.9"></div> <pre>+------------------------------------+
     1233      <div id="rfc.figure.u.12"></div> <pre>+------------------------------------+
    11741234|1|   version     |          8       |
    11751235+------------------------------------+
    … …  
    11891249+------------------------------------+    |
    11901250|           (repeats)                |   &lt;+
    1191             </pre> <p id="rfc.section.2.6.7.p.3">Flags: Flags related to this frame. Valid flags are: </p>
     1251            </pre> <p id="rfc.section.3.6.7.p.3">Flags: Flags related to this frame. Valid flags are: </p>
    11921252      <ul class="empty">
    1193          <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;2.3.6</a>) state.
     1253         <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section&nbsp;3.3.6</a>) state.
    11941254         </li>
    11951255      </ul>
    1196       <p id="rfc.section.2.6.7.p.4">Length: An unsigned 24 bit value representing the number of bytes after the length field. The minimum length of the length
     1256      <p id="rfc.section.3.6.7.p.4">Length: An unsigned 24 bit value representing the number of bytes after the length field. The minimum length of the length
    11971257         field is 4 (when the number of name value pairs is 0).
    11981258      </p>
    1199       <p id="rfc.section.2.6.7.p.5">Stream-ID: The stream this HEADERS block is associated with.</p>
    1200       <p id="rfc.section.2.6.7.p.6">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section&nbsp;2.6.10</a>).
    1201       </p>
    1202       <h3 id="rfc.section.2.6.8"><a href="#rfc.section.2.6.8">2.6.8</a>&nbsp;<a id="WINDOW_UPDATE" href="#WINDOW_UPDATE">WINDOW_UPDATE</a></h3>
    1203       <p id="rfc.section.2.6.8.p.1">The WINDOW_UPDATE control frame is used to implement per stream flow control in HTTP/2.0. Flow control in HTTP/2.0 is per
     1259      <p id="rfc.section.3.6.7.p.5">Stream-ID: The stream this HEADERS block is associated with.</p>
     1260      <p id="rfc.section.3.6.7.p.6">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section&nbsp;3.6.10</a>).
     1261      </p>
     1262      <h3 id="rfc.section.3.6.8"><a href="#rfc.section.3.6.8">3.6.8</a>&nbsp;<a id="WINDOW_UPDATE" href="#WINDOW_UPDATE">WINDOW_UPDATE</a></h3>
     1263      <p id="rfc.section.3.6.8.p.1">The WINDOW_UPDATE control frame is used to implement per stream flow control in HTTP/2.0. Flow control in HTTP/2.0 is per
    12041264         hop, that is, only between the two endpoints of a HTTP/2.0 connection. If there are one or more intermediaries between the
    12051265         client and the origin server, flow control signals are not explicitly forwarded by the intermediaries. (However, throttling
    12061266         of data transfer by any recipient may have the effect of indirectly propagating flow control information upstream back to
    12071267         the original sender.) Flow control only applies to the data portion of data frames. Recipients must buffer all control frames.
    1208          If a recipient fails to buffer an entire control frame, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the status code FLOW_CONTROL_ERROR for the stream.
    1209       </p>
    1210       <p id="rfc.section.2.6.8.p.2">Flow control in HTTP/2.0 is implemented by a data transfer window kept by the sender of each stream. The data transfer window
     1268         If a recipient fails to buffer an entire control frame, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the status code FLOW_CONTROL_ERROR for the stream.
     1269      </p>
     1270      <p id="rfc.section.3.6.8.p.2">Flow control in HTTP/2.0 is implemented by a data transfer window kept by the sender of each stream. The data transfer window
    12111271         is a simple uint32 that indicates how many bytes of data the sender can transmit. After a stream is created, but before any
    12121272         data frames have been transmitted, the sender begins with the initial window size. This window size is a measure of the buffering
    … …  
    12171277         to receive more data.
    12181278      </p>
    1219       <div id="rfc.figure.u.10"></div> <pre>+----------------------------------+
     1279      <div id="rfc.figure.u.13"></div> <pre>+----------------------------------+
    12201280|1|   version    |         9       |
    12211281+----------------------------------+
    … …  
    12261286|X|  Delta-Window-Size (31-bits)   |
    12271287+----------------------------------+
    1228             </pre> <p id="rfc.section.2.6.8.p.4">Control bit: The control bit is always 1 for this message.</p>
    1229       <p id="rfc.section.2.6.8.p.5">Version: The HTTP/2.0 version number.</p>
    1230       <p id="rfc.section.2.6.8.p.6">Type: The message type for a WINDOW_UPDATE message is 9.</p>
    1231       <p id="rfc.section.2.6.8.p.7">Length: The length field is always 8 for this frame (there are 8 bytes after the length field).</p>
    1232       <p id="rfc.section.2.6.8.p.8">Stream-ID: The stream ID that this WINDOW_UPDATE control frame is for.</p>
    1233       <p id="rfc.section.2.6.8.p.9">Delta-Window-Size: The additional number of bytes that the sender can transmit in addition to existing remaining window size.
     1288            </pre> <p id="rfc.section.3.6.8.p.4">Control bit: The control bit is always 1 for this message.</p>
     1289      <p id="rfc.section.3.6.8.p.5">Version: The HTTP/2.0 version number.</p>
     1290      <p id="rfc.section.3.6.8.p.6">Type: The message type for a WINDOW_UPDATE message is 9.</p>
     1291      <p id="rfc.section.3.6.8.p.7">Length: The length field is always 8 for this frame (there are 8 bytes after the length field).</p>
     1292      <p id="rfc.section.3.6.8.p.8">Stream-ID: The stream ID that this WINDOW_UPDATE control frame is for.</p>
     1293      <p id="rfc.section.3.6.8.p.9">Delta-Window-Size: The additional number of bytes that the sender can transmit in addition to existing remaining window size.
    12341294         The legal range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes.
    12351295      </p>
    1236       <p id="rfc.section.2.6.8.p.10">The window size as kept by the sender must never exceed 2^31 (although it can become negative in one special case). If a sender
     1296      <p id="rfc.section.3.6.8.p.10">The window size as kept by the sender must never exceed 2^31 (although it can become negative in one special case). If a sender
    12371297         receives a WINDOW_UPDATE that causes the its window size to exceed this limit, it must send RST_STREAM with status code FLOW_CONTROL_ERROR
    12381298         to terminate the stream.
    12391299      </p>
    1240       <p id="rfc.section.2.6.8.p.11">When a HTTP/2.0 connection is first established, the default initial window size for all streams is 64KB. An endpoint can
     1300      <p id="rfc.section.3.6.8.p.11">When a HTTP/2.0 connection is first established, the default initial window size for all streams is 64KB. An endpoint can
    12411301         use the SETTINGS control frame to adjust the initial window size for the connection. That is, its peer can start out using
    12421302         the 64KB default initial window size when sending data frames before receiving the SETTINGS. Because SETTINGS is asynchronous,
    … …  
    12521312         </li>
    12531313      </ul>
    1254       <p id="rfc.section.2.6.8.p.12">In the case of option 2, both sides must compute the window size based on the initial window size in the SETTINGS. For example,
     1314      <p id="rfc.section.3.6.8.p.12">In the case of option 2, both sides must compute the window size based on the initial window size in the SETTINGS. For example,
    12551315         if the recipient sets the initial window size to be 16KB, and the sender sends 64KB immediately on connection establishment,
    12561316         the sender will discover its window size is -48KB on receipt of the SETTINGS. As the recipient consumes the first 16KB, it
    … …  
    12581318         again, and it can resume transmitting data frames.
    12591319      </p>
    1260       <p id="rfc.section.2.6.8.p.13">After the recipient reads in a data frame with FLAG_FIN that marks the end of the data stream, it should not send WINDOW_UPDATE
     1320      <p id="rfc.section.3.6.8.p.13">After the recipient reads in a data frame with FLAG_FIN that marks the end of the data stream, it should not send WINDOW_UPDATE
    12611321         frames as it consumes the last data frame. A sender should ignore all the WINDOW_UPDATE frames associated with the stream
    12621322         after it send the last frame for the stream.
    12631323      </p>
    1264       <p id="rfc.section.2.6.8.p.14">The data frames from the sender and the WINDOW_UPDATE frames from the recipient are completely asynchronous with respect to
     1324      <p id="rfc.section.3.6.8.p.14">The data frames from the sender and the WINDOW_UPDATE frames from the recipient are completely asynchronous with respect to
    12651325         each other. This property allows a recipient to aggressively update the window size kept by the sender to prevent the stream
    12661326         from stalling.
    12671327      </p>
    1268       <h3 id="rfc.section.2.6.9"><a href="#rfc.section.2.6.9">2.6.9</a>&nbsp;<a id="CREDENTIAL" href="#CREDENTIAL">CREDENTIAL</a></h3>
    1269       <p id="rfc.section.2.6.9.p.1">The CREDENTIAL control frame is used by the client to send additional client certificates to the server. A HTTP/2.0 client
     1328      <h3 id="rfc.section.3.6.9"><a href="#rfc.section.3.6.9">3.6.9</a>&nbsp;<a id="CREDENTIAL" href="#CREDENTIAL">CREDENTIAL</a></h3>
     1329      <p id="rfc.section.3.6.9.p.1">The CREDENTIAL control frame is used by the client to send additional client certificates to the server. A HTTP/2.0 client
    12701330         may decide to send requests for resources from different origins on the same HTTP/2.0 session if it decides that that server
    12711331         handles both origins. For example if the IP address associated with both hostnames matches and the SSL server certificate
    … …  
    12731333         client certificate, the client needs a mechanism to send additional client certificates to the server.
    12741334      </p>
    1275       <p id="rfc.section.2.6.9.p.2">The server is required to maintain a vector of client certificates associated with a HTTP/2.0 session. When the client needs
     1335      <p id="rfc.section.3.6.9.p.2">The server is required to maintain a vector of client certificates associated with a HTTP/2.0 session. When the client needs
    12761336         to send a client certificate to the server, it will send a CREDENTIAL frame that specifies the index of the slot in which
    12771337         to store the certificate as well as proof that the client posesses the corresponding private key. The initial size of this
    … …  
    12831343         slots as possible.
    12841344      </p>
    1285       <p id="rfc.section.2.6.9.p.3">TLS renegotiation with client authentication is incompatible with HTTP/2.0 given the multiplexed nature of HTTP/2.0. Specifically,
     1345      <p id="rfc.section.3.6.9.p.3">TLS renegotiation with client authentication is incompatible with HTTP/2.0 given the multiplexed nature of HTTP/2.0. Specifically,
    12861346         imagine that the client has 2 requests outstanding to the server for two different pages (in different tabs). When the renegotiation
    12871347         + client certificate request comes in, the browser is unable to determine which resource triggered the client certificate
    12881348         request, in order to prompt the user accordingly.
    12891349      </p>
    1290       <div id="rfc.figure.u.11"></div> <pre>+----------------------------------+
     1350      <div id="rfc.figure.u.14"></div> <pre>+----------------------------------+
    12911351|1|000000000000001|0000000000001011|
    12921352+----------------------------------+
    … …  
    13031363|            Certificate           |  |
    13041364+----------------------------------+ &lt;+
    1305             </pre> <p id="rfc.section.2.6.9.p.5">Slot: The index in the server's client certificate vector where this certificate should be stored. If there is already a certificate
     1365            </pre> <p id="rfc.section.3.6.9.p.5">Slot: The index in the server's client certificate vector where this certificate should be stored. If there is already a certificate
    13061366         stored at this index, it will be overwritten. The index is one based, not zero based; zero is an invalid slot index.
    13071367      </p>
    1308       <p id="rfc.section.2.6.9.p.6">Proof: Cryptographic proof that the client has possession of the private key associated with the certificate. The format is
     1368      <p id="rfc.section.3.6.9.p.6">Proof: Cryptographic proof that the client has possession of the private key associated with the certificate. The format is
    13091369         a TLS digitally-signed element (<a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>, <a href="http://tools.ietf.org/html/rfc5246#section-4.7">Section 4.7</a>). The signature algorithm must be the same as that used in the CertificateVerify message. However, since the MD5+SHA1 signature
    13101370         type used in TLS 1.0 connections can not be correctly encoded in a digitally-signed element, SHA1 must be used when MD5+SHA1
    … …  
    13141374         For a 1024-bit RSA key, the CREDENTIAL message would be ~500 bytes.
    13151375      </p>
    1316       <p id="rfc.section.2.6.9.p.7">Certificate: The certificate chain, starting with the leaf certificate. Each certificate must be encoded as a 32 bit length,
     1376      <p id="rfc.section.3.6.9.p.7">Certificate: The certificate chain, starting with the leaf certificate. Each certificate must be encoded as a 32 bit length,
    13171377         followed by a DER encoded certificate. The certificate must be of the same type (RSA, ECDSA, etc) as the client certificate
    13181378         associated with the SSL connection.
    13191379      </p>
    1320       <p id="rfc.section.2.6.9.p.8">If the server receives a request for a resource with unacceptable credential (either missing or invalid), it must reply with
     1380      <p id="rfc.section.3.6.9.p.8">If the server receives a request for a resource with unacceptable credential (either missing or invalid), it must reply with
    13211381         a RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon receipt of a RST_STREAM frame with INVALID_CREDENTIALS,
    13221382         the client should initiate a new stream directly to the requested origin and resend the request. Note, HTTP/2.0 does not allow
    13231383         the server to request different client authentication for different resources in the same origin.
    13241384      </p>
    1325       <p id="rfc.section.2.6.9.p.9">If the server receives an invalid CREDENTIAL frame, it MUST respond with a GOAWAY frame and shutdown the session.</p>
    1326       <h3 id="rfc.section.2.6.10"><a href="#rfc.section.2.6.10">2.6.10</a>&nbsp;<a id="HeaderBlock" href="#HeaderBlock">Name/Value Header Block</a></h3>
    1327       <p id="rfc.section.2.6.10.p.1">The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and HEADERS control frames, and shares a common format:</p>
    1328       <div id="rfc.figure.u.12"></div> <pre>+------------------------------------+
     1385      <p id="rfc.section.3.6.9.p.9">If the server receives an invalid CREDENTIAL frame, it MUST respond with a GOAWAY frame and shutdown the session.</p>
     1386      <h3 id="rfc.section.3.6.10"><a href="#rfc.section.3.6.10">3.6.10</a>&nbsp;<a id="HeaderBlock" href="#HeaderBlock">Name/Value Header Block</a></h3>
     1387      <p id="rfc.section.3.6.10.p.1">The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and HEADERS control frames, and shares a common format:</p>
     1388      <div id="rfc.figure.u.15"></div> <pre>+------------------------------------+
    13291389| Number of Name/Value pairs (int32) |
    13301390+------------------------------------+
    … …  
    13381398+------------------------------------+
    13391399|           (repeats)                |
    1340             </pre> <p id="rfc.section.2.6.10.p.3">Number of Name/Value pairs: The number of repeating name/value pairs following this field.</p>
    1341       <p id="rfc.section.2.6.10.p.4">List of Name/Value pairs: </p>
     1400            </pre> <p id="rfc.section.3.6.10.p.3">Number of Name/Value pairs: The number of repeating name/value pairs following this field.</p>
     1401      <p id="rfc.section.3.6.10.p.4">List of Name/Value pairs: </p>
    13421402      <ul class="empty">
    13431403         <li>Length of Name: a 32-bit value containing the number of octets in the name field. Note that in practice, this length must
    … …  
    13501410         <li>Value: 0 or more octets, 8-bit sequences of data, excluding 0.</li>
    13511411      </ul>
    1352       <p id="rfc.section.2.6.10.p.5">Each header name must have at least one value. Header names are encoded using the <a href="#ASCII">US-ASCII character set</a> <cite title="US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986." id="rfc.xref.ASCII.1">[ASCII]</cite> and must be all lower case. The length of each name must be greater than zero. A recipient of a zero-length name MUST issue
    1353          a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id.
    1354       </p>
    1355       <p id="rfc.section.2.6.10.p.6">Duplicate header names are not allowed. To send two identically named headers, send a header with two values, where the values
     1412      <p id="rfc.section.3.6.10.p.5">Each header name must have at least one value. Header names are encoded using the <a href="#ASCII">US-ASCII character set</a> <cite title="US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986." id="rfc.xref.ASCII.1">[ASCII]</cite> and must be all lower case. The length of each name must be greater than zero. A recipient of a zero-length name MUST issue
     1413         a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id.
     1414      </p>
     1415      <p id="rfc.section.3.6.10.p.6">Duplicate header names are not allowed. To send two identically named headers, send a header with two values, where the values
    13561416         are separated by a single NUL (0) byte. A header value can either be empty (e.g. the length is zero) or it can contain multiple,
    13571417         NUL-separated values, each with length greater than zero. The value never starts nor ends with a NUL character. Recipients
    1358          of illegal value fields MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id.
    1359       </p>
    1360       <h4 id="rfc.section.2.6.10.1"><a href="#rfc.section.2.6.10.1">2.6.10.1</a>&nbsp;<a id="Compression" href="#Compression">Compression</a></h4>
    1361       <p id="rfc.section.2.6.10.1.p.1">The Name/Value Header Block is a section of the SYN_STREAM, SYN_REPLY, and HEADERS frames used to carry header meta-data.
     1418         of illegal value fields MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id.
     1419      </p>
     1420      <h4 id="rfc.section.3.6.10.1"><a href="#rfc.section.3.6.10.1">3.6.10.1</a>&nbsp;<a id="Compression" href="#Compression">Compression</a></h4>
     1421      <p id="rfc.section.3.6.10.1.p.1">The Name/Value Header Block is a section of the SYN_STREAM, SYN_REPLY, and HEADERS frames used to carry header meta-data.
    13621422         This block is always compressed using zlib compression. Within this specification, any reference to 'zlib' is referring to
    13631423         the <a href="#RFC1950">ZLIB Compressed Data Format Specification Version 3.3 as part of RFC1950.</a> <cite title="ZLIB Compressed Data Format Specification version 3.3" id="rfc.xref.RFC1950.1">[RFC1950]</cite></p>
    1364       <p id="rfc.section.2.6.10.1.p.2">For each HEADERS compression instance, the initial state is initialized using the following <a href="#UDELCOMPRESSION">dictionary</a> <cite title="A Methodology to Derive SPDY's Initial Dictionary for Zlib Compression" id="rfc.xref.UDELCOMPRESSION.1">[UDELCOMPRESSION]</cite>:
    1365       </p>
    1366       <div id="rfc.figure.u.13"></div> <pre class="ccmarker cct"><span>&lt;CODE BEGINS&gt;</span></pre><pre class="text">const unsigned char http2_dictionary_txt[] = {
     1424      <p id="rfc.section.3.6.10.1.p.2">For each HEADERS compression instance, the initial state is initialized using the following <a href="#UDELCOMPRESSION">dictionary</a> <cite title="A Methodology to Derive SPDY's Initial Dictionary for Zlib Compression" id="rfc.xref.UDELCOMPRESSION.1">[UDELCOMPRESSION]</cite>:
     1425      </p>
     1426      <div id="rfc.figure.u.16"></div> <pre class="ccmarker cct"><span>&lt;CODE BEGINS&gt;</span></pre><pre class="text">const unsigned char http2_dictionary_txt[] = {
    13671427  0x00, 0x00, 0x00, 0x07, 0x6f, 0x70, 0x74, 0x69,  \\ - - - - o p t i
    13681428  0x6f, 0x6e, 0x73, 0x00, 0x00, 0x00, 0x04, 0x68,  \\ o n s - - - - h
    … …  
    15441604  0x2c, 0x65, 0x6e, 0x71, 0x3d, 0x30, 0x2e         \\ - e n q - 0 -
    15451605};
    1546 </pre><pre class="ccmarker ccb"><span>&lt;CODE ENDS&gt;</span></pre> <p id="rfc.section.2.6.10.1.p.4">The entire contents of the name/value header block is compressed using zlib. There is a single zlib stream for all name value
     1606</pre><pre class="ccmarker ccb"><span>&lt;CODE ENDS&gt;</span></pre> <p id="rfc.section.3.6.10.1.p.4">The entire contents of the name/value header block is compressed using zlib. There is a single zlib stream for all name value
    15471607         pairs in one direction on a connection. HTTP/2.0 uses a SYNC_FLUSH between each compressed frame.
    15481608      </p>
    1549       <p id="rfc.section.2.6.10.1.p.5">Implementation notes: the compression engine can be tuned to favor speed or size. Optimizing for size increases memory use
     1609      <p id="rfc.section.3.6.10.1.p.5">Implementation notes: the compression engine can be tuned to favor speed or size. Optimizing for size increases memory use
    15501610         and CPU consumption. Because header blocks are generally small, implementors may want to reduce the window-size of the compression
    15511611         engine from the default 15bits (a 32KB window) to more like 11bits (a 2KB window). The exact setting is chosen by the compressor,
    15521612         the decompressor will work with any setting.
    15531613      </p>
    1554       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="HTTPLayer" href="#HTTPLayer">HTTP Layering over HTTP/2.0</a></h1>
    1555       <p id="rfc.section.3.p.1">HTTP/2.0 is intended to be as compatible as possible with current web-based applications. This means that, from the perspective
     1614      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="HTTPLayer" href="#HTTPLayer">HTTP Layering over HTTP/2.0</a></h1>
     1615      <p id="rfc.section.4.p.1">HTTP/2.0 is intended to be as compatible as possible with current web-based applications. This means that, from the perspective
    15561616         of the server business logic or application API, the features of HTTP are unchanged. To achieve this, all of the application
    15571617         request and response header semantics are preserved, although the syntax of conveying those semantics has changed. Thus, the
    1558          rules from the <a href="#RFC2616">HTTP/1.1 specification in RFC2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">[RFC2616]</cite> apply with the changes in the sections below.
    1559       </p>
    1560       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Connection Management
    1561       </h2>
    1562       <p id="rfc.section.3.1.p.1">Clients SHOULD NOT open more than one HTTP/2.0 session to a given <a href="#RFC6454">origin</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.2">[RFC6454]</cite> concurrently.
    1563       </p>
    1564       <p id="rfc.section.3.1.p.2">Note that it is possible for one HTTP/2.0 session to be finishing (e.g. a GOAWAY message has been sent, but not all streams
     1618         rules from the <a href="#RFC2616">HTTP/1.1 specification in RFC2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> apply with the changes in the sections below.
     1619      </p>
     1620      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Connection Management
     1621      </h2>
     1622      <p id="rfc.section.4.1.p.1">Clients SHOULD NOT open more than one HTTP/2.0 session to a given <a href="#RFC6454">origin</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.2">[RFC6454]</cite> concurrently.
     1623      </p>
     1624      <p id="rfc.section.4.1.p.2">Note that it is possible for one HTTP/2.0 session to be finishing (e.g. a GOAWAY message has been sent, but not all streams
    15651625         have finished), while another HTTP/2.0 session is starting.
    15661626      </p>
    1567       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;Use of GOAWAY
     1627      <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;Use of GOAWAY
    15681628      </h3>
    1569       <p id="rfc.section.3.1.1.p.1">HTTP/2.0 provides a GOAWAY message which can be used when closing a connection from either the client or server. Without a
     1629      <p id="rfc.section.4.1.1.p.1">HTTP/2.0 provides a GOAWAY message which can be used when closing a connection from either the client or server. Without a
    15701630         server GOAWAY message, HTTP has a race condition where the client sends a request (a new SYN_STREAM) just as the server is
    15711631         closing the connection, and the client cannot know if the server received the stream or not. By using the last-stream-id in
    15721632         the GOAWAY, servers can indicate to the client if a request was processed or not.
    15731633      </p>
    1574       <p id="rfc.section.3.1.1.p.2">Note that some servers will choose to send the GOAWAY and immediately terminate the connection without waiting for active
     1634      <p id="rfc.section.4.1.1.p.2">Note that some servers will choose to send the GOAWAY and immediately terminate the connection without waiting for active
    15751635         streams to finish. The client will be able to determine this because HTTP/2.0 streams are determinstically closed. This abrupt
    15761636         termination will force the client to heuristically decide whether to retry the pending requests. Clients always need to be
    … …  
    15781638         as the server never having sent a GOAWAY.
    15791639      </p>
    1580       <p id="rfc.section.3.1.1.p.3">More sophisticated servers will use GOAWAY to implement a graceful teardown. They will send the GOAWAY and provide some time
     1640      <p id="rfc.section.4.1.1.p.3">More sophisticated servers will use GOAWAY to implement a graceful teardown. They will send the GOAWAY and provide some time
    15811641         for the active streams to finish before terminating the connection.
    15821642      </p>
    1583       <p id="rfc.section.3.1.1.p.4">If a HTTP/2.0 client closes the connection, it should also send a GOAWAY message. This allows the server to know if any server-push
     1643      <p id="rfc.section.4.1.1.p.4">If a HTTP/2.0 client closes the connection, it should also send a GOAWAY message. This allows the server to know if any server-push
    15841644         streams were received by the client.
    15851645      </p>
    1586       <p id="rfc.section.3.1.1.p.5">If the endpoint closing the connection has not received any SYN_STREAMs from the remote, the GOAWAY will contain a last-stream-id
     1646      <p id="rfc.section.4.1.1.p.5">If the endpoint closing the connection has not received any SYN_STREAMs from the remote, the GOAWAY will contain a last-stream-id
    15871647         of 0.
    15881648      </p>
    1589       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;HTTP Request/Response
    1590       </h2>
    1591       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;Request
     1649      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;HTTP Request/Response
     1650      </h2>
     1651      <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;Request
    15921652      </h3>
    1593       <p id="rfc.section.3.2.1.p.1">The client initiates a request by sending a SYN_STREAM frame. For requests which do not contain a body, the SYN_STREAM frame
     1653      <p id="rfc.section.4.2.1.p.1">The client initiates a request by sending a SYN_STREAM frame. For requests which do not contain a body, the SYN_STREAM frame
    15941654         MUST set the FLAG_FIN, indicating that the client intends to send no further data on this stream. For requests which do contain
    15951655         a body, the SYN_STREAM will not contain the FLAG_FIN, and the body will follow the SYN_STREAM in a series of DATA frames.
    15961656         The last DATA frame will set the FLAG_FIN to indicate the end of the body.
    15971657      </p>
    1598       <p id="rfc.section.3.2.1.p.2">The SYN_STREAM Name/Value section will contain all of the HTTP headers which are associated with an HTTP request. The header
     1658      <p id="rfc.section.4.2.1.p.2">The SYN_STREAM Name/Value section will contain all of the HTTP headers which are associated with an HTTP request. The header
    15991659         block in HTTP/2.0 is mostly unchanged from today's HTTP header block, with the following differences:
    16001660      </p>
    … …  
    16331693         </li>
    16341694      </ul>
    1635       <p id="rfc.section.3.2.1.p.3">The user-agent is free to prioritize requests as it sees fit. If the user-agent cannot make progress without receiving a resource,
     1695      <p id="rfc.section.4.2.1.p.3">The user-agent is free to prioritize requests as it sees fit. If the user-agent cannot make progress without receiving a resource,
    16361696         it should attempt to raise the priority of that resource. Resources such as images, SHOULD generally use the lowest priority.
    16371697      </p>
    1638       <p id="rfc.section.3.2.1.p.4">If a client sends a SYN_STREAM without all of the method, host, path, scheme, and version headers, the server MUST reply with
     1698      <p id="rfc.section.4.2.1.p.4">If a client sends a SYN_STREAM without all of the method, host, path, scheme, and version headers, the server MUST reply with
    16391699         a HTTP 400 Bad Request reply.
    16401700      </p>
    1641       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;Response
     1701      <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;Response
    16421702      </h3>
    1643       <p id="rfc.section.3.2.2.p.1">The server responds to a client request with a SYN_REPLY frame. Symmetric to the client's upload stream, server will send
     1703      <p id="rfc.section.4.2.2.p.1">The server responds to a client request with a SYN_REPLY frame. Symmetric to the client's upload stream, server will send
    16441704         data after the SYN_REPLY frame via a series of DATA frames, and the last data frame will contain the FLAG_FIN to indicate
    16451705         successful end-of-stream. If a response (like a 202 or 204 response) contains no body, the SYN_REPLY frame may contain the
    16461706         FLAG_FIN flag to indicate no further data will be sent on the stream.
    16471707      </p>
    1648       <p id="rfc.section.3.2.2.p.2"> </p>
     1708      <p id="rfc.section.4.2.2.p.2"> </p>
    16491709      <ul class="empty">
    16501710         <li>The response status line is unfolded into name/value pairs like other HTTP headers and must be present:
    … …  
    16611721         </li>
    16621722      </ul>
    1663       <p id="rfc.section.3.2.2.p.3">If a client receives a SYN_REPLY without a status or without a version header, the client must reply with a RST_STREAM frame
     1723      <p id="rfc.section.4.2.2.p.3">If a client receives a SYN_REPLY without a status or without a version header, the client must reply with a RST_STREAM frame
    16641724         indicating a PROTOCOL ERROR.
    16651725      </p>
    1666       <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="Authentication" href="#Authentication">Authentication</a></h3>
    1667       <p id="rfc.section.3.2.3.p.1">When a client sends a request to an origin server that requires authentication, the server can reply with a "401 Unauthorized"
     1726      <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a id="Authentication" href="#Authentication">Authentication</a></h3>
     1727      <p id="rfc.section.4.2.3.p.1">When a client sends a request to an origin server that requires authentication, the server can reply with a "401 Unauthorized"
    16681728         response, and include a WWW-Authenticate challenge header that defines the authentication scheme to be used. The client then
    16691729         retries the request with an Authorization header appropriate to the specified authentication scheme.
    16701730      </p>
    1671       <p id="rfc.section.3.2.3.p.2">There are four options for proxy authentication, Basic, Digest, NTLM and Negotiate (SPNEGO). The first two options were defined
     1731      <p id="rfc.section.4.2.3.p.2">There are four options for proxy authentication, Basic, Digest, NTLM and Negotiate (SPNEGO). The first two options were defined
    16721732         in <a href="#RFC2617">RFC2617</a> <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.1">[RFC2617]</cite>, and are stateless. The second two options were developed by Microsoft and specified in <a href="#RFC4559">RFC4559</a> <cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows" id="rfc.xref.RFC4559.1">[RFC4559]</cite>, and are stateful; otherwise known as multi-round authentication, or connection authentication.
    16731733      </p>
    1674       <h4 id="rfc.section.3.2.3.1"><a href="#rfc.section.3.2.3.1">3.2.3.1</a>&nbsp;Stateless Authentication
     1734      <h4 id="rfc.section.4.2.3.1"><a href="#rfc.section.4.2.3.1">4.2.3.1</a>&nbsp;Stateless Authentication
    16751735      </h4>
    1676       <p id="rfc.section.3.2.3.1.p.1">Stateless Authentication over HTTP/2.0 is identical to how it is performed over HTTP. If multiple HTTP/2.0 streams are concurrently
     1736      <p id="rfc.section.4.2.3.1.p.1">Stateless Authentication over HTTP/2.0 is identical to how it is performed over HTTP. If multiple HTTP/2.0 streams are concurrently
    16771737         sent to a single server, each will authenticate independently, similar to how two HTTP connections would independently authenticate
    16781738         to a proxy server.
    16791739      </p>
    1680       <h4 id="rfc.section.3.2.3.2"><a href="#rfc.section.3.2.3.2">3.2.3.2</a>&nbsp;Stateful Authentication
     1740      <h4 id="rfc.section.4.2.3.2"><a href="#rfc.section.4.2.3.2">4.2.3.2</a>&nbsp;Stateful Authentication
    16811741      </h4>
    1682       <p id="rfc.section.3.2.3.2.p.1">Unfortunately, the stateful authentication mechanisms were implemented and defined in a such a way that directly violates
     1742      <p id="rfc.section.4.2.3.2.p.1">Unfortunately, the stateful authentication mechanisms were implemented and defined in a such a way that directly violates
    16831743         RFC2617 - they do not include a "realm" as part of the request. This is problematic in HTTP/2.0 because it makes it impossible
    16841744         for a client to disambiguate two concurrent server authentication challenges.
    16851745      </p>
    1686       <p id="rfc.section.3.2.3.2.p.2">To deal with this case, HTTP/2.0 servers using Stateful Authentication MUST implement one of two changes: </p>
     1746      <p id="rfc.section.4.2.3.2.p.2">To deal with this case, HTTP/2.0 servers using Stateful Authentication MUST implement one of two changes: </p>
    16871747      <ul class="empty">
    16881748         <li>Servers can add a "realm=&lt;desired realm&gt;" header so that the two authentication requests can be disambiguated and run concurrently.
    … …  
    16951755         </li>
    16961756      </ul>
    1697       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;Server Push Transactions
    1698       </h2>
    1699       <p id="rfc.section.3.3.p.1">HTTP/2.0 enables a server to send multiple replies to a client for a single request. The rationale for this feature is that
     1757      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;Server Push Transactions
     1758      </h2>
     1759      <p id="rfc.section.4.3.p.1">HTTP/2.0 enables a server to send multiple replies to a client for a single request. The rationale for this feature is that
    17001760         sometimes a server knows that it will need to send multiple resources in response to a single request. Without server push
    17011761         features, the client must first download the primary resource, then discover the secondary resource(s), and request them.
    … …  
    17041764         the performance benefit.
    17051765      </p>
    1706       <p id="rfc.section.3.3.p.2">Browsers receiving a pushed response MUST validate that the server is authorized to push the URL using the <a href="#RFC6454">browser same-origin</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.3">[RFC6454]</cite> policy. For example, a HTTP/2.0 connection to www.foo.com is generally not permitted to push a response for www.evil.com.
    1707       </p>
    1708       <p id="rfc.section.3.3.p.3">If the browser accepts a pushed response (e.g. it does not send a RST_STREAM), the browser MUST attempt to cache the pushed
     1766      <p id="rfc.section.4.3.p.2">Browsers receiving a pushed response MUST validate that the server is authorized to push the URL using the <a href="#RFC6454">browser same-origin</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.3">[RFC6454]</cite> policy. For example, a HTTP/2.0 connection to www.foo.com is generally not permitted to push a response for www.evil.com.
     1767      </p>
     1768      <p id="rfc.section.4.3.p.3">If the browser accepts a pushed response (e.g. it does not send a RST_STREAM), the browser MUST attempt to cache the pushed
    17091769         response in same way that it would cache any other response. This means validating the response headers and inserting into
    17101770         the disk cache.
    17111771      </p>
    1712       <p id="rfc.section.3.3.p.4">Because pushed responses have no request, they have no request headers associated with them. At the framing layer, HTTP/2.0
     1772      <p id="rfc.section.4.3.p.4">Because pushed responses have no request, they have no request headers associated with them. At the framing layer, HTTP/2.0
    17131773         pushed streams contain an "associated-stream-id" which indicates the requested stream for which the pushed stream is related.
    17141774         The pushed stream inherits all of the headers from the associated-stream-id with the exception of ":host", ":scheme", and
    … …  
    17161776         request headers with the cached resource.
    17171777      </p>
    1718       <p id="rfc.section.3.3.p.5">Implementation note: With server push, it is theoretically possible for servers to push unreasonable amounts of content or
     1778      <p id="rfc.section.4.3.p.5">Implementation note: With server push, it is theoretically possible for servers to push unreasonable amounts of content or
    17191779         resources to the user-agent. Browsers MUST implement throttles to protect against unreasonable push attacks.
    17201780      </p>
    1721       <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;Server implementation
     1781      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;Server implementation
    17221782      </h3>
    1723       <p id="rfc.section.3.3.1.p.1">When the server intends to push a resource to the user-agent, it opens a new stream by sending a unidirectional SYN_STREAM.
     1783      <p id="rfc.section.4.3.1.p.1">When the server intends to push a resource to the user-agent, it opens a new stream by sending a unidirectional SYN_STREAM.
    17241784         The SYN_STREAM MUST include an Associated-To-Stream-ID, and MUST set the FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST include
    17251785         headers for ":scheme", ":host", ":path", which represent the URL for the resource being pushed. Subsequent headers may follow
    … …  
    17281788         user-agent would not be able to differentiate the requests.
    17291789      </p>
    1730       <p id="rfc.section.3.3.1.p.2">The Associated-To-Stream-ID must be the ID of an existing, open stream. The reason for this restriction is to have a clear
     1790      <p id="rfc.section.4.3.1.p.2">The Associated-To-Stream-ID must be the ID of an existing, open stream. The reason for this restriction is to have a clear
    17311791         endpoint for pushed content. If the user-agent requested a resource on stream 11, the server replies on stream 11. It can
    17321792         push any number of additional streams to the client before sending a FLAG_FIN on stream 11. However, once the originating
    … …  
    17341794         before the originating stream is closed, they only need to be created before the originating stream closes.
    17351795      </p>
    1736       <p id="rfc.section.3.3.1.p.3">It is illegal for a server to push a resource with the Associated-To-Stream-ID of 0.</p>
    1737       <p id="rfc.section.3.3.1.p.4">To minimize race conditions with the client, the SYN_STREAM for the pushed resources MUST be sent prior to sending any content
     1796      <p id="rfc.section.4.3.1.p.3">It is illegal for a server to push a resource with the Associated-To-Stream-ID of 0.</p>
     1797      <p id="rfc.section.4.3.1.p.4">To minimize race conditions with the client, the SYN_STREAM for the pushed resources MUST be sent prior to sending any content
    17381798         which could allow the client to discover the pushed resource and request it.
    17391799      </p>
    1740       <p id="rfc.section.3.3.1.p.5">The server MUST only push resources which would have been returned from a GET request.</p>
    1741       <p id="rfc.section.3.3.1.p.6">Note: If the server does not have all of the Name/Value Response headers available at the time it issues the HEADERS frame
     1800      <p id="rfc.section.4.3.1.p.5">The server MUST only push resources which would have been returned from a GET request.</p>
     1801      <p id="rfc.section.4.3.1.p.6">Note: If the server does not have all of the Name/Value Response headers available at the time it issues the HEADERS frame
    17421802         for the pushed resource, it may later use an additional HEADERS frame to augment the name/value pairs to be associated with
    17431803         the pushed stream. The subsequent HEADERS frame(s) must not contain a header for ':host', ':scheme', or ':path' (e.g. the
    … …  
    17461806         any data frames on the stream.
    17471807      </p>
    1748       <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;Client implementation
     1808      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;Client implementation
    17491809      </h3>
    1750       <p id="rfc.section.3.3.2.p.1">When fetching a resource the client has 3 possibilities: </p>
     1810      <p id="rfc.section.4.3.2.p.1">When fetching a resource the client has 3 possibilities: </p>
    17511811      <ul class="empty">
    17521812         <li>the resource is not being pushed</li>
    … …  
    17541814         <li>the resource is being pushed, and the data has started to arrive</li>
    17551815      </ul>
    1756       <p id="rfc.section.3.3.2.p.2">When a SYN_STREAM and HEADERS frame which contains an Associated-To-Stream-ID is received, the client must not issue GET requests
     1816      <p id="rfc.section.4.3.2.p.2">When a SYN_STREAM and HEADERS frame which contains an Associated-To-Stream-ID is received, the client must not issue GET requests
    17571817         for the resource in the pushed stream, and instead wait for the pushed stream to arrive.
    17581818      </p>
    1759       <p id="rfc.section.3.3.2.p.3">If a client receives a server push stream with stream-id 0, it MUST issue a session error (<a href="#SessionErrorHandler" title="Session Error Handling">Section&nbsp;2.4.1</a>) with the status code PROTOCOL_ERROR.
    1760       </p>
    1761       <p id="rfc.section.3.3.2.p.4">When a client receives a SYN_STREAM from the server without a the ':host', ':scheme', and ':path' headers in the Name/Value
     1819      <p id="rfc.section.4.3.2.p.3">If a client receives a server push stream with stream-id 0, it MUST issue a session error (<a href="#SessionErrorHandler" title="Session Error Handling">Section&nbsp;3.4.1</a>) with the status code PROTOCOL_ERROR.
     1820      </p>
     1821      <p id="rfc.section.4.3.2.p.4">When a client receives a SYN_STREAM from the server without a the ':host', ':scheme', and ':path' headers in the Name/Value
    17621822         section, it MUST reply with a RST_STREAM with error code HTTP_PROTOCOL_ERROR.
    17631823      </p>
    1764       <p id="rfc.section.3.3.2.p.5">To cancel individual server push streams, the client can issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with error code CANCEL. Upon receipt, the server MUST stop sending on this stream immediately (this is an Abrupt termination).
    1765       </p>
    1766       <p id="rfc.section.3.3.2.p.6">To cancel all server push streams related to a request, the client may issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with error code CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames
     1824      <p id="rfc.section.4.3.2.p.5">To cancel individual server push streams, the client can issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with error code CANCEL. Upon receipt, the server MUST stop sending on this stream immediately (this is an Abrupt termination).
     1825      </p>
     1826      <p id="rfc.section.4.3.2.p.6">To cancel all server push streams related to a request, the client may issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with error code CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames
    17671827         for any streams with in-association-to for the original stream.
    17681828      </p>
    1769       <p id="rfc.section.3.3.2.p.7">If the server sends a HEADER frame containing duplicate headers with a previous HEADERS frame for the same stream, the client
    1770          must issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;2.4.2</a>) with error code PROTOCOL ERROR.
    1771       </p>
    1772       <p id="rfc.section.3.3.2.p.8">If the server sends a HEADERS frame after sending a data frame for the same stream, the client MAY ignore the HEADERS frame.
     1829      <p id="rfc.section.4.3.2.p.7">If the server sends a HEADER frame containing duplicate headers with a previous HEADERS frame for the same stream, the client
     1830         must issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section&nbsp;3.4.2</a>) with error code PROTOCOL ERROR.
     1831      </p>
     1832      <p id="rfc.section.4.3.2.p.8">If the server sends a HEADERS frame after sending a data frame for the same stream, the client MAY ignore the HEADERS frame.
    17731833         Ignoring the HEADERS frame after a data frame prevents handling of HTTP's trailing headers (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.40).
    17741834      </p>
    1775       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;Design Rationale and Notes
     1835      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;Design Rationale and Notes
    17761836      </h1>
    1777       <p id="rfc.section.4.p.1">Authors' notes: The notes in this section have no bearing on the HTTP/2.0 protocol as specified within this document, and
     1837      <p id="rfc.section.5.p.1">Authors' notes: The notes in this section have no bearing on the HTTP/2.0 protocol as specified within this document, and
    17781838         none of these notes should be considered authoritative about how the protocol works. However, these notes may prove useful
    17791839         in future debates about how to resolve protocol ambiguities or how to evolve the protocol going forward. They may be removed
    17801840         before the final draft.
    17811841      </p>
    1782       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Separation of Framing Layer and Application Layer
    1783       </h2>
    1784       <p id="rfc.section.4.1.p.1">Readers may note that this specification sometimes blends the framing layer (<a href="#FramingLayer" title="HTTP/2.0 Framing Layer">Section&nbsp;2</a>) with requirements of a specific application - HTTP (<a href="#HTTPLayer" title="HTTP Layering over HTTP/2.0">Section&nbsp;3</a>). This is reflected in the request/response nature of the streams, the definition of the HEADERS and compression contexts
     1842      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;Separation of Framing Layer and Application Layer
     1843      </h2>
     1844      <p id="rfc.section.5.1.p.1">Readers may note that this specification sometimes blends the framing layer (<a href="#FramingLayer" title="HTTP/2.0 Framing Layer">Section&nbsp;3</a>) with requirements of a specific application - HTTP (<a href="#HTTPLayer" title="HTTP Layering over HTTP/2.0">Section&nbsp;4</a>). This is reflected in the request/response nature of the streams, the definition of the HEADERS and compression contexts
    17851845         which are very similar to HTTP, and other areas as well.
    17861846      </p>
    1787       <p id="rfc.section.4.1.p.2">This blending is intentional - the primary goal of this protocol is to create a low-latency protocol for use with HTTP. Isolating
     1847      <p id="rfc.section.5.1.p.2">This blending is intentional - the primary goal of this protocol is to create a low-latency protocol for use with HTTP. Isolating
    17881848         the two layers is convenient for description of the protocol and how it relates to existing HTTP implementations. However,
    17891849         the ability to reuse the HTTP/2.0 framing layer is a non goal.
    17901850      </p>
    1791       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;Error handling - Framing Layer
    1792       </h2>
    1793       <p id="rfc.section.4.2.p.1">Error handling at the HTTP/2.0 layer splits errors into two groups: Those that affect an individual HTTP/2.0 stream, and those
     1851      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;Error handling - Framing Layer
     1852      </h2>
     1853      <p id="rfc.section.5.2.p.1">Error handling at the HTTP/2.0 layer splits errors into two groups: Those that affect an individual HTTP/2.0 stream, and those
    17941854         that do not.
    17951855      </p>
    1796       <p id="rfc.section.4.2.p.2">When an error is confined to a single stream, but general framing is in tact, HTTP/2.0 attempts to use the RST_STREAM as a
     1856      <p id="rfc.section.5.2.p.2">When an error is confined to a single stream, but general framing is in tact, HTTP/2.0 attempts to use the RST_STREAM as a
    17971857         mechanism to invalidate the stream but move forward without aborting the connection altogether.
    17981858      </p>
    1799       <p id="rfc.section.4.2.p.3">For errors occuring outside of a single stream context, HTTP/2.0 assumes the entire session is hosed. In this case, the endpoint
     1859      <p id="rfc.section.5.2.p.3">For errors occuring outside of a single stream context, HTTP/2.0 assumes the entire session is hosed. In this case, the endpoint
    18001860         detecting the error should initiate a connection close.
    18011861      </p>
    1802       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;One Connection Per Domain
    1803       </h2>
    1804       <p id="rfc.section.4.3.p.1">HTTP/2.0 attempts to use fewer connections than other protocols have traditionally used. The rationale for this behavior is
     1862      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;One Connection Per Domain
     1863      </h2>
     1864      <p id="rfc.section.5.3.p.1">HTTP/2.0 attempts to use fewer connections than other protocols have traditionally used. The rationale for this behavior is
    18051865         because it is very difficult to provide a consistent level of service (e.g. TCP slow-start), prioritization, or optimal compression
    18061866         when the client is connecting to the server through multiple channels.
    18071867      </p>
    1808       <p id="rfc.section.4.3.p.2">Through lab measurements, we have seen consistent latency benefits by using fewer connections from the client. The overall
     1868      <p id="rfc.section.5.3.p.2">Through lab measurements, we have seen consistent latency benefits by using fewer connections from the client. The overall
    18091869         number of packets sent by HTTP/2.0 can be as much as 40% less than HTTP. Handling large numbers of concurrent connections
    18101870         on the server also does become a scalability problem, and HTTP/2.0 reduces this load.
    18111871      </p>
    1812       <p id="rfc.section.4.3.p.3">The use of multiple connections is not without benefit, however. Because HTTP/2.0 multiplexes multiple, independent streams
     1872      <p id="rfc.section.5.3.p.3">The use of multiple connections is not without benefit, however. Because HTTP/2.0 multiplexes multiple, independent streams
    18131873         onto a single stream, it creates a potential for head-of-line blocking problems at the transport level. In tests so far, the
    18141874         negative effects of head-of-line blocking (especially in the presence of packet loss) is outweighed by the benefits of compression
    18151875         and prioritization.
    18161876      </p>
    1817       <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;Fixed vs Variable Length Fields
    1818       </h2>
    1819       <p id="rfc.section.4.4.p.1">HTTP/2.0 favors use of fixed length 32bit fields in cases where smaller, variable length encodings could have been used. To
     1877      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;Fixed vs Variable Length Fields
     1878      </h2>
     1879      <p id="rfc.section.5.4.p.1">HTTP/2.0 favors use of fixed length 32bit fields in cases where smaller, variable length encodings could have been used. To
    18201880         some, this seems like a tragic waste of bandwidth. HTTP/2.0 choses the simple encoding for speed and simplicity.
    18211881      </p>
    1822       <p id="rfc.section.4.4.p.2">The goal of HTTP/2.0 is to reduce latency on the network. The overhead of HTTP/2.0 frames is generally quite low. Each data
     1882      <p id="rfc.section.5.4.p.2">The goal of HTTP/2.0 is to reduce latency on the network. The overhead of HTTP/2.0 frames is generally quite low. Each data
    18231883         frame is only an 8 byte overhead for a 1452 byte payload (~0.6%). At the time of this writing, bandwidth is already plentiful,
    18241884         and there is a strong trend indicating that bandwidth will continue to increase. With an average worldwide bandwidth of 1Mbps,
    … …  
    18281888         this is completely mitigated.
    18291889      </p>
    1830       <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;Compression Context(s)
    1831       </h2>
    1832       <p id="rfc.section.4.5.p.1">When isolating the compression contexts used for communicating with multiple origins, we had a few choices to make. We could
     1890      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;Compression Context(s)
     1891      </h2>
     1892      <p id="rfc.section.5.5.p.1">When isolating the compression contexts used for communicating with multiple origins, we had a few choices to make. We could
    18331893         have maintained a map (or list) of compression contexts usable for each origin. The basic case is easy - each HEADERS frame
    18341894         would need to identify the context to use for that frame. However, compression contexts are not cheap, so the lifecycle of
    … …  
    18381898         ultimately we decided that such a mechanism creates too many problems to solve.
    18391899      </p>
    1840       <p id="rfc.section.4.5.p.2">Alternatively, we've chosen the simple approach, which is to simply provide a flag for resetting the compression context.
     1900      <p id="rfc.section.5.5.p.2">Alternatively, we've chosen the simple approach, which is to simply provide a flag for resetting the compression context.
    18411901         For the common case (no proxy), this fine because most requests are to the same origin and we never need to reset the context.
    18421902         For cases where we are using two different origins over a single HTTP/2.0 session, we simply reset the compression state between
    18431903         each transition.
    18441904      </p>
    1845       <h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a>&nbsp;Unidirectional streams
    1846       </h2>
    1847       <p id="rfc.section.4.6.p.1">Many readers notice that unidirectional streams are both a bit confusing in concept and also somewhat redundant. If the recipient
     1905      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;Unidirectional streams
     1906      </h2>
     1907      <p id="rfc.section.5.6.p.1">Many readers notice that unidirectional streams are both a bit confusing in concept and also somewhat redundant. If the recipient
    18481908         of a stream doesn't wish to send data on a stream, it could simply send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL
    18491909         is, therefore, not necessary.
    18501910      </p>
    1851       <p id="rfc.section.4.6.p.2">It is true that we don't need the UNIDIRECTIONAL markings. It is added because it avoids the recipient of pushed streams from
     1911      <p id="rfc.section.5.6.p.2">It is true that we don't need the UNIDIRECTIONAL markings. It is added because it avoids the recipient of pushed streams from
    18521912         needing to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which otherwise serve no purpose.
    18531913      </p>
    1854       <h2 id="rfc.section.4.7"><a href="#rfc.section.4.7">4.7</a>&nbsp;Data Compression
    1855       </h2>
    1856       <p id="rfc.section.4.7.p.1">Generic compression of data portion of the streams (as opposed to compression of the headers) without knowing the content
     1914      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;Data Compression
     1915      </h2>
     1916      <p id="rfc.section.5.7.p.1">Generic compression of data portion of the streams (as opposed to compression of the headers) without knowing the content
    18571917         of the stream is redundant. There is no value in compressing a stream which is already compressed. Because of this, HTTP/2.0
    18581918         does allow data compression to be optional. We included it because study of existing websites shows that many sites are not
    … …  
    18601920         administrators could simply force compression - it is better to compress twice than to not compress.
    18611921      </p>
    1862       <p id="rfc.section.4.7.p.2">Overall, however, with this feature being optional and sometimes redundant, it is unclear if it is useful at all. We will
     1922      <p id="rfc.section.5.7.p.2">Overall, however, with this feature being optional and sometimes redundant, it is unclear if it is useful at all. We will
    18631923         likely remove it from the specification.
    18641924      </p>
    1865       <h2 id="rfc.section.4.8"><a href="#rfc.section.4.8">4.8</a>&nbsp;Server Push
    1866       </h2>
    1867       <p id="rfc.section.4.8.p.1">A subtle but important point is that server push streams must be declared before the associated stream is closed. The reason
     1925      <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;Server Push
     1926      </h2>
     1927      <p id="rfc.section.5.8.p.1">A subtle but important point is that server push streams must be declared before the associated stream is closed. The reason
    18681928         for this is so that proxies have a lifetime for which they can discard information about previous streams. If a pushed stream
    18691929         could associate itself with an already-closed stream, then endpoints would not have a specific lifecycle for when they could
    18701930         disavow knowledge of the streams which went before.
    18711931      </p>
    1872       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;Security Considerations
     1932      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;Security Considerations
    18731933      </h1>
    1874       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;Use of Same-origin constraints
    1875       </h2>
    1876       <p id="rfc.section.5.1.p.1">This specification uses the <a href="#RFC6454">same-origin policy</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.4">[RFC6454]</cite> in all cases where verification of content is required.
    1877       </p>
    1878       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;HTTP Headers and HTTP/2.0 Headers
    1879       </h2>
    1880       <p id="rfc.section.5.2.p.1">At the application level, HTTP uses name/value pairs in its headers. Because HTTP/2.0 merges the existing HTTP headers with
     1934      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;Use of Same-origin constraints
     1935      </h2>
     1936      <p id="rfc.section.6.1.p.1">This specification uses the <a href="#RFC6454">same-origin policy</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.4">[RFC6454]</cite> in all cases where verification of content is required.
     1937      </p>
     1938      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;HTTP Headers and HTTP/2.0 Headers
     1939      </h2>
     1940      <p id="rfc.section.6.2.p.1">At the application level, HTTP uses name/value pairs in its headers. Because HTTP/2.0 merges the existing HTTP headers with
    18811941         HTTP/2.0 headers, there is a possibility that some HTTP applications already use a particular header name. To avoid any conflicts,
    18821942         all headers introduced for layering HTTP over HTTP/2.0 are prefixed with ":". ":" is not a valid sequence in HTTP header naming,
    18831943         preventing any possible conflict.
    18841944      </p>
    1885       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;Cross-Protocol Attacks
    1886       </h2>
    1887       <p id="rfc.section.5.3.p.1">By utilizing TLS, we believe that HTTP/2.0 introduces no new cross-protocol attacks. TLS encrypts the contents of all transmission
     1945      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;Cross-Protocol Attacks
     1946      </h2>
     1947      <p id="rfc.section.6.3.p.1">By utilizing TLS, we believe that HTTP/2.0 introduces no new cross-protocol attacks. TLS encrypts the contents of all transmission
    18881948         (except the handshake itself), making it difficult for attackers to control the data which could be used in a cross-protocol
    18891949         attack.
    18901950      </p>
    1891       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;Server Push Implicit Headers
    1892       </h2>
    1893       <p id="rfc.section.5.4.p.1">Pushed resources do not have an associated request. In order for existing HTTP cache control validations (such as the Vary
     1951      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;Server Push Implicit Headers
     1952      </h2>
     1953      <p id="rfc.section.6.4.p.1">Pushed resources do not have an associated request. In order for existing HTTP cache control validations (such as the Vary
    18941954         header) to work, however, all cached resources must have a set of request headers. For this reason, browsers MUST be careful
    18951955         to inherit request headers from the associated stream for the push. This includes the 'Cookie' header.
    18961956      </p>
    1897       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;Privacy Considerations
     1957      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;Privacy Considerations
    18981958      </h1>
    1899       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;Long Lived Connections
    1900       </h2>
    1901       <p id="rfc.section.6.1.p.1">HTTP/2.0 aims to keep connections open longer between clients and servers in order to reduce the latency when a user makes
     1959      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;Long Lived Connections
     1960      </h2>
     1961      <p id="rfc.section.7.1.p.1">HTTP/2.0 aims to keep connections open longer between clients and servers in order to reduce the latency when a user makes
    19021962         a request. The maintenance of these connections over time could be used to expose private information. For example, a user
    19031963         using a browser hours after the previous user stopped using that browser may be able to learn about what the previous user
    … …  
    19051965         risk.
    19061966      </p>
    1907       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;SETTINGS frame
    1908       </h2>
    1909       <p id="rfc.section.6.2.p.1">The HTTP/2.0 SETTINGS frame allows servers to store out-of-band transmitted information about the communication between client
     1967      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;SETTINGS frame
     1968      </h2>
     1969      <p id="rfc.section.7.2.p.1">The HTTP/2.0 SETTINGS frame allows servers to store out-of-band transmitted information about the communication between client
    19101970         and server on the client. Although this is intended only to be used to reduce latency, renegade servers could use it as a
    19111971         mechanism to store identifying information about the client in future requests.
    19121972      </p>
    1913       <p id="rfc.section.6.2.p.2">Clients implementing privacy modes, such as Google Chrome's "incognito mode", may wish to disable client-persisted SETTINGS
     1973      <p id="rfc.section.7.2.p.2">Clients implementing privacy modes, such as Google Chrome's "incognito mode", may wish to disable client-persisted SETTINGS
    19141974         storage.
    19151975      </p>
    1916       <p id="rfc.section.6.2.p.3">Clients MUST clear persisted SETTINGS information when clearing the cookies.</p>
    1917       <p id="rfc.section.6.2.p.4">TODO: Put range maximums on each type of setting to limit inappropriate uses.</p>
    1918       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;Requirements Notation
     1976      <p id="rfc.section.7.2.p.3">Clients MUST clear persisted SETTINGS information when clearing the cookies.</p>
     1977      <p id="rfc.section.7.2.p.4">TODO: Put range maximums on each type of setting to limit inappropriate uses.</p>
     1978      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;Requirements Notation
    19191979      </h1>
    1920       <p id="rfc.section.7.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     1980      <p id="rfc.section.8.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    19211981         in this document are to be interpreted as described in <a href="#RFC2119">RFC 2119</a> <cite title="Key words for use in RFCs to Indicate Requirement Levels" id="rfc.xref.RFC2119.1">[RFC2119]</cite>.
    19221982      </p>
    1923       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;Acknowledgements
     1983      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;Acknowledgements
    19241984      </h1>
    1925       <p id="rfc.section.8.p.1">Prior to being used as the basis for HTTP/2.0, the following individuals contributed to the design and evolution of SPDY:
     1985      <p id="rfc.section.9.p.1">Prior to being used as the basis for HTTP/2.0, the following individuals contributed to the design and evolution of SPDY:
    19261986         Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe
    19271987         Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton.
    19281988      </p>
    1929       <h1 id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> Normative References
     1989      <h1 id="rfc.references"><a href="#rfc.section.10" id="rfc.section.10">10.</a> Normative References
    19301990      </h1>
    19311991      <table>                           
    … …  
    19331993            <td class="reference"><b id="ASCII">[ASCII]</b></td>
    19341994            <td class="top">“US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.”.</td>
     1995         </tr>
     1996         <tr>
     1997            <td class="reference"><b id="HTTP-p1">[HTTP-p1]</b></td>
     1998            <td class="top">Fielding, R. and J. Reschke, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-21 (work in progress), October&nbsp;2012.
     1999            </td>
     2000         </tr>
     2001         <tr>
     2002            <td class="reference"><b id="HTTP-p2">[HTTP-p2]</b></td>
     2003            <td class="top">Fielding, R. and J. Reschke, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-21 (work in progress), October&nbsp;2012.
     2004            </td>
    19352005         </tr>
    19362006         <tr>
    … …  
    19552025         </tr>
    19562026         <tr>
    1957             <td class="reference"><b id="RFC2285">[RFC2285]</b></td>
    1958             <td class="top">Mandeville, R., “<a href="http://tools.ietf.org/html/rfc2285">Benchmarking Terminology for LAN Switching Devices</a>”, RFC&nbsp;2285, February&nbsp;1998.
    1959             </td>
    1960          </tr>
    1961          <tr>
    19622027            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    19632028            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
    … …  
    19672032            <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
    19682033            <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
    1969             </td>
    1970          </tr>
    1971          <tr>
    1972             <td class="reference"><b id="RFC4366">[RFC4366]</b></td>
    1973             <td class="top">Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “<a href="http://tools.ietf.org/html/rfc4366">Transport Layer Security (TLS) Extensions</a>”, RFC&nbsp;4366, April&nbsp;2006.
    19742034            </td>
    19752035         </tr>
    … …  
    20172077      <p id="rfc.section.A.1.p.3">Changed INTERNAL_ERROR on GOAWAY to have a value of 2 &lt;<a href="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU">https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU</a>&gt;.
    20182078      </p>
     2079      <p id="rfc.section.A.1.p.4">Replaced abstract and introduction.</p>
     2080      <p id="rfc.section.A.1.p.5">Added section on starting HTTP/2.0, including upgrade mechanism.</p>
     2081      <p id="rfc.section.A.1.p.6">Removed unused references.</p>
    20192082      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.since.draft-mbelshe-httpbis-spdy-00" href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></h2>
    20202083      <p id="rfc.section.A.2.p.1">Adopted as base for draft-ietf-httpbis-http2.</p>
    … …  
    20222085      <p id="rfc.section.A.2.p.3">Added status note.</p>
    20232086      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    2024       <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a>
     2087      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a>
    20252088      </p>
    20262089      <div class="print2col">
    20272090         <ul class="ind">
    20282091            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    2029                   <li><em>ASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.ASCII.1">2.6.10</a>, <a href="#ASCII"><b>9</b></a></li>
     2092                  <li><em>ASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.ASCII.1">3.6.10</a>, <a href="#ASCII"><b>10</b></a></li>
     2093               </ul>
     2094            </li>
     2095            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
     2096                  <li><em>HTTP-p1</em>&nbsp;&nbsp;<a href="#rfc.xref.HTTP-p1.1">1</a>, <a href="#rfc.xref.HTTP-p1.2">2.1</a>, <a href="#HTTP-p1"><b>10</b></a></li>
     2097                  <li><em>HTTP-p2</em>&nbsp;&nbsp;<a href="#rfc.xref.HTTP-p2.1">2.2</a>, <a href="#HTTP-p2"><b>10</b></a></li>
    20302098               </ul>
    20312099            </li>
    20322100            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    2033                   <li><em>RFC0793</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC0793.1">2.1</a>, <a href="#RFC0793"><b>9</b></a></li>
    2034                   <li><em>RFC1738</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1738.1">3.2.1</a>, <a href="#rfc.xref.RFC1738.2">3.2.1</a>, <a href="#RFC1738"><b>9</b></a></li>
    2035                   <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">2.6.10.1</a>, <a href="#RFC1950"><b>9</b></a></li>
    2036                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">7</a>, <a href="#RFC2119"><b>9</b></a></li>
    2037                   <li><em>RFC2285</em>&nbsp;&nbsp;<a href="#RFC2285"><b>9</b></a></li>
    2038                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">3</a>, <a href="#RFC2616"><b>9</b></a></li>
    2039                   <li><em>RFC2617</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.1">3.2.3</a>, <a href="#RFC2617"><b>9</b></a></li>
    2040                   <li><em>RFC4366</em>&nbsp;&nbsp;<a href="#RFC4366"><b>9</b></a></li>
    2041                   <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">3.2.3</a>, <a href="#RFC4559"><b>9</b></a></li>
    2042                   <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.6.9</a>, <a href="#RFC5246"><b>9</b></a><ul>
    2043                         <li><em>Section 4.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.6.9</a></li>
     2101                  <li><em>RFC0793</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC0793.1">3.1</a>, <a href="#RFC0793"><b>10</b></a></li>
     2102                  <li><em>RFC1738</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1738.1">4.2.1</a>, <a href="#rfc.xref.RFC1738.2">4.2.1</a>, <a href="#RFC1738"><b>10</b></a></li>
     2103                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">3.6.10.1</a>, <a href="#RFC1950"><b>10</b></a></li>
     2104                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">8</a>, <a href="#RFC2119"><b>10</b></a></li>
     2105                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4</a>, <a href="#RFC2616"><b>10</b></a></li>
     2106                  <li><em>RFC2617</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.1">4.2.3</a>, <a href="#RFC2617"><b>10</b></a></li>
     2107                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">4.2.3</a>, <a href="#RFC4559"><b>10</b></a></li>
     2108                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">3.6.9</a>, <a href="#RFC5246"><b>10</b></a><ul>
     2109                        <li><em>Section 4.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">3.6.9</a></li>
    20442110                     </ul>
    20452111                  </li>
    2046                   <li><em>RFC6454</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6454.1">2.6.4</a>, <a href="#rfc.xref.RFC6454.2">3.1</a>, <a href="#rfc.xref.RFC6454.3">3.3</a>, <a href="#rfc.xref.RFC6454.4">5.1</a>, <a href="#RFC6454"><b>9</b></a></li>
     2112                  <li><em>RFC6454</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6454.1">3.6.4</a>, <a href="#rfc.xref.RFC6454.2">4.1</a>, <a href="#rfc.xref.RFC6454.3">4.3</a>, <a href="#rfc.xref.RFC6454.4">6.1</a>, <a href="#RFC6454"><b>10</b></a></li>
    20472113               </ul>
    20482114            </li>
    20492115            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    2050                   <li><em>TLSNPN</em>&nbsp;&nbsp;<a href="#TLSNPN"><b>9</b></a></li>
     2116                  <li><em>TLSNPN</em>&nbsp;&nbsp;<a href="#rfc.xref.TLSNPN.1">2.1</a>, <a href="#TLSNPN"><b>10</b></a></li>
    20512117               </ul>
    20522118            </li>
    20532119            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    2054                   <li><em>UDELCOMPRESSION</em>&nbsp;&nbsp;<a href="#rfc.xref.UDELCOMPRESSION.1">2.6.10.1</a>, <a href="#UDELCOMPRESSION"><b>9</b></a></li>
     2120                  <li><em>UDELCOMPRESSION</em>&nbsp;&nbsp;<a href="#rfc.xref.UDELCOMPRESSION.1">3.6.10.1</a>, <a href="#UDELCOMPRESSION"><b>10</b></a></li>
    20552121               </ul>
    20562122            </li>

  • draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.xml

    r2124 r2125  
    6565<abstract>
    6666  <t>
    67     This document describes HTTP/2.0, a protocol designed for low-latency transport of content over
    68     the World Wide Web.  HTTP/2.0 introduces two layers of protocol.  The lower layer is a general
    69     purpose framing layer which can be used atop a reliable transport (likely TCP) for multiplexed,
    70     prioritized, and compressed data communication of many concurrent streams.  The upper layer of
    71     the protocol provides HTTP-like <xref target="RFC2616">RFC2616</xref> semantics for
    72     compatibility with existing HTTP application servers.
     67    This document describes an optimised expression of the semantics of the HTTP protocol.  The
     68    HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing
     69    compressed headers, simultaneous requests, and unsolicted push of resources from server to
     70    client.
     71  </t>
     72  <t>
     73    This document is an alternative to, but does not obsolete RFC{http-p1}.  The HTTP protocol
     74    semantics described in RFC{http-p2..p7} are unmodified.
    7375  </t>
    7476</abstract>
    … …  
    103105
    104106  <middle>
    105     <section anchor="intro" title="Overview">
    106 <t>One of the bottlenecks of HTTP implementations is that HTTP relies on multiple connections for concurrency. This causes several problems, including additional round trips for connection setup, slow-start delays, and connection rationing by the client, where it tries to avoid opening too many connections to any single server.  HTTP pipelining helps some, but only achieves partial multiplexing.  In addition, pipelining has proven non-deployable in existing browsers due to intermediary interference.</t>
    107 
    108 <t>HTTP/2.0 adds a framing layer for multiplexing multiple, concurrent streams across a single TCP connection (or any reliable transport stream).  The framing layer is optimized for HTTP-like request-response streams, such that applications which run over HTTP today can work over HTTP/2.0 with little or no change on behalf of the web application writer.</t>
    109 
    110 <t>The HTTP/2.0 session offers four improvements over HTTP:
    111 <list>
    112 <t>Multiplexed requests: There is no limit to the number of requests that can be issued concurrently over a single HTTP/2.0 connection.</t>
    113 <t>Prioritized requests: Clients can request certain resources to be delivered first.  This avoids the problem of congesting the network channel with non-critical resources when a high-priority request is pending.</t>
    114 <t>Compressed headers:  Clients today send a significant amount of redundant data in the form of HTTP headers.  Because a single web page may require 50 or 100 subrequests, this data is significant.</t>
    115 <t>Server pushed streams:  Server Push enables content to be pushed from servers to clients without a request.</t>
    116 </list>
    117 </t>
    118 
    119 <t>HTTP/2.0 attempts to preserve the existing semantics of HTTP. All features such as cookies, ETags, Vary headers, Content-Encoding negotiations, etc work as they do with HTTP; HTTP/2.0 only replaces the way the data is written to the network.</t>
     107    <section anchor="intro" title="Introduction">
     108<t>
     109  HTTP is a wildly successful protocol.  <xref target="HTTP-p1">HTTP/1.1
     110  message encapsulation</xref> is optimized for implementation simplicity and accessibility, not
     111  application performance.  As such it has several characteristics that have a negative overall
     112  effect on application performance.
     113</t>
     114<t>
     115  The HTTP/1.1 encapsulation ensures that only one request can be delivered at a time on a given
     116  connection.  HTTP/1.1 pipelining, which is not widely deployed, only partially addresses these
     117  concerns.  Clients that need to make multiple requests therefore use commonly multiple connections
     118  to a server or servers in order to reduce the overall latency of those requests.
     119</t>
     120<t>
     121  Furthermore, HTTP/1.1 headers are represented in an inefficient fashion, which, in addition to
     122  generating more or larger network packets, can cause the small initial TCP window to fill more
     123  quickly than is ideal.  This results in excessive latency where multiple requests are made on a
     124  new TCP connection.
     125</t>
     126<t>
     127  This document defines an optimized mapping of the HTTP semantics to a TCP connection.  This
     128  optimization reduces the latency costs of HTTP by allowing parallel requests on the same
     129  connection and by using an efficient coding for HTTP headers.  Prioritization of requests lets
     130  more important requests complete faster, further improving application performance.
     131</t>
     132<t>
     133  HTTP/2.0 applications have an improved impact on network congestion due to the use of fewer TCP
     134  connections to achieve the same effect.  Fewer TCP connections compete more fairly with other
     135  flows.  Long-lived connections are also more able to take better advantage of the available
     136  network capacity, rather than operating in the slow start phase of TCP.
     137</t>
     138<t>
     139  The HTTP/2.0 encapsulation also enables more efficient processing of messages by providing
     140  efficient message framing.  Processing of headers in HTTP/2.0 messages is more efficient (for
     141  entities that process many messages).
     142</t>
    120143
    121144      <section title="Document Organization">
    122 <t>The HTTP/2.0 Specification is split into two parts: <xref target="FramingLayer">a framing layer</xref>, which multiplexes a TCP connection into independent, length-prefixed frames, and <xref target="HTTPLayer">an HTTP layer</xref>, which specifies the mechanism for overlaying HTTP request/response pairs on top of the framing layer. While some of the framing layer concepts are isolated from the HTTP layer, building a generic framing layer has not been a goal. The framing layer is tailored to the needs of the HTTP protocol and server push.</t>
     145<t>The HTTP/2.0 Specification is split into three parts: <xref target="starting">starting HTTP/2.0</xref>, which covers how a HTTP/2.0 is started; <xref target="FramingLayer">a framing layer</xref>, which multiplexes a TCP connection into independent, length-prefixed frames; and <xref target="HTTPLayer">an HTTP layer</xref>, which specifies the mechanism for overlaying HTTP request/response pairs on top of the framing layer. While some of the framing layer concepts are isolated from the HTTP layer, building a generic framing layer has not been a goal. The framing layer is tailored to the needs of the HTTP protocol and server push.</t>
    123146      </section>
    124147      <section title="Definitions">
    … …  
    137160</t>
    138161      </section>
     162    </section>
     163
     164<section anchor="starting" title="Starting HTTP/2.0">
     165<t>
     166  Just as HTTP/1.1 does, HTTP/2.0 uses the "http:" and "https:" URI schemes.  An HTTP/2.0-capable
     167  client is therefore required to discover whether a server (or intermediary) supports HTTP/2.0.
     168</t>
     169<t>
     170  Different discovery mechanisms are defined for "http:" and "https:" URIs.  Discovery for "http:"
     171  URIs is described in <xref target="discover-http"/>; discovery for "https:" URIs is described in
     172  <xref target="discover-https"/>.
     173</t>
     174
     175<section anchor="versioning" title="HTTP/2.0 Version Identification">
     176<t>
     177  HTTP/2.0 is identified in using the string "HTTP/2.0".  This identification is used in the
     178  HTTP/1.1 Upgrade header, in the <xref target="TLSNPN">TLS-NPN</xref> [[TBD]] field and other
     179  places where protocol identification is required.
     180</t>
     181<t>
     182  [[Editor's Note: please remove the following text prior to the publication of a final version of
     183  this document.]]
     184</t>
     185<t>
     186  Only implementations of the final, published RFC can identify themselves as "HTTP/2.0".  Until
     187  such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0".
     188</t>
     189<t>
     190  Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial
     191  convenience only.  Implementations of draft versions MUST NOT identify using this string.
     192</t>
     193<t>
     194  Implementations of draft versions of the protocol MUST add the corresponding draft number to the
     195  identifier before the separator ('/').  For example, draft-ietf-httpbis-http2-03 is identified
     196  using the string "HTTP-03/2.0".
     197</t>
     198<t>
     199  Non-compatible experiments that are based on these draft versions MUST include a further
     200  identifier.  For example, an experimental implementation of packet mood-based encoding based on
     201  draft-ietf-httpbis-http2-07 might identify itself as "HTTP-07-emo/2.0".  Note that any label MUST
     202  conform with the "token" syntax defined in Section 3.2.4 of <xref target="HTTP-p1"/>.
     203  Experimenters are encouraged to coordinate their experiments on the ietf-http-wg@w3.org mailing
     204  list.
     205</t>
     206</section>
     207<section anchor="discover-http" title="Starting HTTP/2.0 for &quot;http:&quot; URIs">
     208<t>
     209  A client that makes a request to an "http:" URI without prior knowledge about support for HTTP/2.0
     210  uses the HTTP Upgrade mechanism <xref target="HTTP-p2"/>.  The client makes an HTTP/1.1 request
     211  that includes an Upgrade header field identifying HTTP/2.0.
     212</t>
     213<t>
     214For example:
     215</t>
     216<figure><artwork><![CDATA[
     217   GET /default.htm HTTP/1.1
     218   Host: server.example.com
     219   Connection: Upgrade
     220   Upgrade: HTTP/2.0
     221]]></artwork></figure>
     222<t>
     223  A server that does not support HTTP/2.0 can respond to the request as though the Upgrade header
     224  field were absent:
     225</t>
     226<figure><artwork><![CDATA[
     227   HTTP/1.1 200 OK
     228   Content-length: 243
     229   Content-type: text/html
     230      ...
     231]]></artwork></figure>
     232<t>
     233  A server that supports HTTP/2.0 can accept the upgrade with a 101 (Switching Protocols) status
     234  code.  After the empty line that terminates the 101 response, the server can begin sending
     235  HTTP/2.0 frames.  These frames MUST include a response to the request that initiated the Upgrade.
     236</t>
     237<figure><artwork><![CDATA[
     238   HTTP/1.1 101 Switching Protocols
     239   Connection: Upgrade
     240   Upgrade: HTTP/2.0
     241
     242   [ HTTP/2.0 frames ...
     243]]></artwork></figure>
     244<t>
     245  A client can learn that a particular server supports HTTP/2.0 by other means.  A client MAY
     246  immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0.  [[Open Issue:
     247  This is not definite.  We may yet choose to perform negotiation for every connection.  Reasons
     248  include intermediaries; phased upgrade of load-balanced server farms; etc...]] [[Open Issue: We
     249  need to enumerate the ways that clients can learn of HTTP/2.0 support.]]
     250</t>
     251</section>
     252<section anchor="discover-https" title="Starting HTTP/2.0 for &quot;https:&quot; URIs">
     253<t>
     254  [[TBD, maybe NPN]]
     255</t>
     256</section>
     257     
    139258    </section>
    140259
    … …  
    12611380    </reference>
    12621381
    1263     <reference anchor='RFC2285'>
    1264       <front>
    1265         <title abbrev='Benchmarking Terminology'>Benchmarking Terminology for LAN Switching Devices</title>
    1266         <author initials='R.' surname='Mandeville' fullname='Robert Mandeville'>
    1267           <organization>European Network Laboratories (ENL)</organization>
    1268         </author>
    1269         <date year='1998' month='February' />
    1270       </front>
    1271       <seriesInfo name='RFC' value='2285' />
    1272     </reference>
    1273 
    12741382    <reference anchor="RFC2616">
    12751383      <front>
    … …  
    13411449      </front>
    13421450      <seriesInfo name="RFC" value="2617"/>
    1343     </reference>
    1344 
    1345     <reference anchor="RFC4366">
    1346       <front>
    1347         <title>Transport Layer Security (TLS) Extensions</title>
    1348         <author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wilson"/>
    1349         <author initials="M." surname="Nystrom" fullname="M. Nystrom"/>
    1350         <author initials="D." surname="Hopwood" fullname="D. Hopwood"/>
    1351         <author initials="J." surname="Mikkelsen" fullname="J. Mikkelsen"/>
    1352         <author initials="T." surname="Wright" fullname="T. Wright"/>
    1353         <date year="2006" month="April"/>
    1354       </front>
    1355       <seriesInfo name="RFC" value="4366"/>
    13561451    </reference>
    13571452
    … …  
    14111506        <date/>
    14121507      </front>
     1508    </reference>
     1509    <reference anchor='HTTP-p1'>
     1510      <front>
     1511        <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
     1512        <author initials='R.' surname='Fielding' fullname='Roy Fielding'></author>
     1513        <author initials='J.' surname='Reschke' fullname='Julian Reschke'></author>
     1514        <date month='October' day='4' year='2012' />
     1515        <abstract><t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems.  HTTP has been in use by the World Wide Web global information initiative since 1990.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.</t></abstract>
     1516      </front>
     1517      <seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-p1-messaging-21' />
     1518      <format type='TXT'
     1519              target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-21.txt' />
    14131520    </reference>
    1414     </references>
     1521    <reference anchor='HTTP-p2'>
     1522      <front>
     1523        <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
     1524        <author initials='R.' surname='Fielding' fullname='Roy Fielding'></author>
     1525        <author initials='J.' surname='Reschke' fullname='Julian Reschke'></author>
     1526        <date month='October' day='4' year='2012' />
     1527        <abstract><t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
     1528      </front>
     1529      <seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-p2-semantics-21' />
     1530      <format type='TXT'
     1531              target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-21.txt' />
     1532    </reference>
     1533  </references>
    14151534
    14161535<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
    … …  
    14251544<t>
    14261545  Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <eref target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>.
     1546</t>
     1547<t>
     1548  Replaced abstract and introduction.
     1549</t>
     1550<t>
     1551  Added section on starting HTTP/2.0, including upgrade mechanism.
     1552</t>
     1553<t>
     1554  Removed unused references.
    14271555</t>
    14281556</section>
Note: See TracChangeset for help on using the changeset viewer.