Changeset 2125 for draft-ietf-httpbis-http2/latest
- Timestamp:
- 16/01/13 19:23:08 (10 years ago)
- 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 428 428 <link rel="Copyright" href="#rfc.copyrightnotice"> 429 429 <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"> 439 440 <link rel="Appendix" title="A Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.A"> 440 441 <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/"> … … 447 448 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-http2-latest"> 448 449 <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."> 451 452 </head> 452 453 <body onload="init();"> … … 493 494 <p class="title">Hypertext Transfer Protocol version 2.0<br><span class="filename">draft-ietf-httpbis-http2-latest</span></p> 494 495 <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. 499 502 </p> 500 503 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> … … 529 532 <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> 530 533 <ul class="toc"> 531 <li><a href="#rfc.section.1">1.</a> <a href="#intro"> Overview</a><ul>534 <li><a href="#rfc.section.1">1.</a> <a href="#intro">Introduction</a><ul> 532 535 <li><a href="#rfc.section.1.1">1.1</a> <a href="#rfc.section.1.1">Document Organization</a></li> 533 536 <li><a href="#rfc.section.1.2">1.2</a> <a href="#rfc.section.1.2">Definitions</a></li> 534 537 </ul> 535 538 </li> 536 <li><a href="#rfc.section.2">2.</a> <a href="#FramingLayer">HTTP/2.0 Framing Layer</a><ul> 537 <li><a href="#rfc.section.2.1">2.1</a> <a href="#rfc.section.2.1">Session (Connections)</a></li> 538 <li><a href="#rfc.section.2.2">2.2</a> <a href="#rfc.section.2.2">Framing</a><ul> 539 <li><a href="#rfc.section.2.2.1">2.2.1</a> <a href="#ControlFrames">Control frames</a></li> 540 <li><a href="#rfc.section.2.2.2">2.2.2</a> <a href="#DataFrames">Data frames</a></li> 539 <li><a href="#rfc.section.2">2.</a> <a href="#starting">Starting HTTP/2.0</a><ul> 540 <li><a href="#rfc.section.2.1">2.1</a> <a href="#versioning">HTTP/2.0 Version Identification</a></li> 541 <li><a href="#rfc.section.2.2">2.2</a> <a href="#discover-http">Starting HTTP/2.0 for "http:" URIs</a></li> 542 <li><a href="#rfc.section.2.3">2.3</a> <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> <a href="#FramingLayer">HTTP/2.0 Framing Layer</a><ul> 546 <li><a href="#rfc.section.3.1">3.1</a> <a href="#rfc.section.3.1">Session (Connections)</a></li> 547 <li><a href="#rfc.section.3.2">3.2</a> <a href="#rfc.section.3.2">Framing</a><ul> 548 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#ControlFrames">Control frames</a></li> 549 <li><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#DataFrames">Data frames</a></li> 541 550 </ul> 542 551 </li> 543 <li><a href="#rfc.section. 2.3">2.3</a> <a href="#rfc.section.2.3">Streams</a><ul>544 <li><a href="#rfc.section. 2.3.1">2.3.1</a> <a href="#StreamFrames">Stream frames</a></li>545 <li><a href="#rfc.section. 2.3.2">2.3.2</a> <a href="#StreamCreation">Stream creation</a><ul>546 <li><a href="#rfc.section. 2.3.2.1">2.3.2.1</a> <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> <a href="#rfc.section.2.3.2.2">Bidirectional streams</a></li>552 <li><a href="#rfc.section.3.3">3.3</a> <a href="#rfc.section.3.3">Streams</a><ul> 553 <li><a href="#rfc.section.3.3.1">3.3.1</a> <a href="#StreamFrames">Stream frames</a></li> 554 <li><a href="#rfc.section.3.3.2">3.3.2</a> <a href="#StreamCreation">Stream creation</a><ul> 555 <li><a href="#rfc.section.3.3.2.1">3.3.2.1</a> <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> <a href="#rfc.section.3.3.2.2">Bidirectional streams</a></li> 548 557 </ul> 549 558 </li> 550 <li><a href="#rfc.section. 2.3.3">2.3.3</a> <a href="#StreamPriority">Stream priority</a></li>551 <li><a href="#rfc.section. 2.3.4">2.3.4</a> <a href="#rfc.section.2.3.4">Stream headers</a></li>552 <li><a href="#rfc.section. 2.3.5">2.3.5</a> <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> <a href="#StreamHalfClose">Stream half-close</a></li>554 <li><a href="#rfc.section. 2.3.7">2.3.7</a> <a href="#StreamClose">Stream close</a></li>559 <li><a href="#rfc.section.3.3.3">3.3.3</a> <a href="#StreamPriority">Stream priority</a></li> 560 <li><a href="#rfc.section.3.3.4">3.3.4</a> <a href="#rfc.section.3.3.4">Stream headers</a></li> 561 <li><a href="#rfc.section.3.3.5">3.3.5</a> <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> <a href="#StreamHalfClose">Stream half-close</a></li> 563 <li><a href="#rfc.section.3.3.7">3.3.7</a> <a href="#StreamClose">Stream close</a></li> 555 564 </ul> 556 565 </li> 557 <li><a href="#rfc.section. 2.4">2.4</a> <a href="#rfc.section.2.4">Error Handling</a><ul>558 <li><a href="#rfc.section. 2.4.1">2.4.1</a> <a href="#SessionErrorHandler">Session Error Handling</a></li>559 <li><a href="#rfc.section. 2.4.2">2.4.2</a> <a href="#StreamErrorHandler">Stream Error Handling</a></li>566 <li><a href="#rfc.section.3.4">3.4</a> <a href="#rfc.section.3.4">Error Handling</a><ul> 567 <li><a href="#rfc.section.3.4.1">3.4.1</a> <a href="#SessionErrorHandler">Session Error Handling</a></li> 568 <li><a href="#rfc.section.3.4.2">3.4.2</a> <a href="#StreamErrorHandler">Stream Error Handling</a></li> 560 569 </ul> 561 570 </li> 562 <li><a href="#rfc.section. 2.5">2.5</a> <a href="#rfc.section.2.5">Data flow</a></li>563 <li><a href="#rfc.section. 2.6">2.6</a> <a href="#rfc.section.2.6">Control frame types</a><ul>564 <li><a href="#rfc.section. 2.6.1">2.6.1</a> <a href="#SYN_STREAM">SYN_STREAM</a></li>565 <li><a href="#rfc.section. 2.6.2">2.6.2</a> <a href="#SYN_REPLY">SYN_REPLY</a></li>566 <li><a href="#rfc.section. 2.6.3">2.6.3</a> <a href="#RST_STREAM">RST_STREAM</a></li>567 <li><a href="#rfc.section. 2.6.4">2.6.4</a> <a href="#SETTINGS">SETTINGS</a></li>568 <li><a href="#rfc.section. 2.6.5">2.6.5</a> <a href="#PING">PING</a></li>569 <li><a href="#rfc.section. 2.6.6">2.6.6</a> <a href="#GOAWAY">GOAWAY</a></li>570 <li><a href="#rfc.section. 2.6.7">2.6.7</a> <a href="#HEADERS">HEADERS</a></li>571 <li><a href="#rfc.section. 2.6.8">2.6.8</a> <a href="#WINDOW_UPDATE">WINDOW_UPDATE</a></li>572 <li><a href="#rfc.section. 2.6.9">2.6.9</a> <a href="#CREDENTIAL">CREDENTIAL</a></li>573 <li><a href="#rfc.section. 2.6.10">2.6.10</a> <a href="#HeaderBlock">Name/Value Header Block</a><ul>574 <li><a href="#rfc.section. 2.6.10.1">2.6.10.1</a> <a href="#Compression">Compression</a></li>571 <li><a href="#rfc.section.3.5">3.5</a> <a href="#rfc.section.3.5">Data flow</a></li> 572 <li><a href="#rfc.section.3.6">3.6</a> <a href="#rfc.section.3.6">Control frame types</a><ul> 573 <li><a href="#rfc.section.3.6.1">3.6.1</a> <a href="#SYN_STREAM">SYN_STREAM</a></li> 574 <li><a href="#rfc.section.3.6.2">3.6.2</a> <a href="#SYN_REPLY">SYN_REPLY</a></li> 575 <li><a href="#rfc.section.3.6.3">3.6.3</a> <a href="#RST_STREAM">RST_STREAM</a></li> 576 <li><a href="#rfc.section.3.6.4">3.6.4</a> <a href="#SETTINGS">SETTINGS</a></li> 577 <li><a href="#rfc.section.3.6.5">3.6.5</a> <a href="#PING">PING</a></li> 578 <li><a href="#rfc.section.3.6.6">3.6.6</a> <a href="#GOAWAY">GOAWAY</a></li> 579 <li><a href="#rfc.section.3.6.7">3.6.7</a> <a href="#HEADERS">HEADERS</a></li> 580 <li><a href="#rfc.section.3.6.8">3.6.8</a> <a href="#WINDOW_UPDATE">WINDOW_UPDATE</a></li> 581 <li><a href="#rfc.section.3.6.9">3.6.9</a> <a href="#CREDENTIAL">CREDENTIAL</a></li> 582 <li><a href="#rfc.section.3.6.10">3.6.10</a> <a href="#HeaderBlock">Name/Value Header Block</a><ul> 583 <li><a href="#rfc.section.3.6.10.1">3.6.10.1</a> <a href="#Compression">Compression</a></li> 575 584 </ul> 576 585 </li> … … 579 588 </ul> 580 589 </li> 581 <li><a href="#rfc.section. 3">3.</a> <a href="#HTTPLayer">HTTP Layering over HTTP/2.0</a><ul>582 <li><a href="#rfc.section. 3.1">3.1</a> <a href="#rfc.section.3.1">Connection Management</a><ul>583 <li><a href="#rfc.section. 3.1.1">3.1.1</a> <a href="#rfc.section.3.1.1">Use of GOAWAY</a></li>590 <li><a href="#rfc.section.4">4.</a> <a href="#HTTPLayer">HTTP Layering over HTTP/2.0</a><ul> 591 <li><a href="#rfc.section.4.1">4.1</a> <a href="#rfc.section.4.1">Connection Management</a><ul> 592 <li><a href="#rfc.section.4.1.1">4.1.1</a> <a href="#rfc.section.4.1.1">Use of GOAWAY</a></li> 584 593 </ul> 585 594 </li> 586 <li><a href="#rfc.section. 3.2">3.2</a> <a href="#rfc.section.3.2">HTTP Request/Response</a><ul>587 <li><a href="#rfc.section. 3.2.1">3.2.1</a> <a href="#rfc.section.3.2.1">Request</a></li>588 <li><a href="#rfc.section. 3.2.2">3.2.2</a> <a href="#rfc.section.3.2.2">Response</a></li>589 <li><a href="#rfc.section. 3.2.3">3.2.3</a> <a href="#Authentication">Authentication</a><ul>590 <li><a href="#rfc.section. 3.2.3.1">3.2.3.1</a> <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> <a href="#rfc.section.3.2.3.2">Stateful Authentication</a></li>595 <li><a href="#rfc.section.4.2">4.2</a> <a href="#rfc.section.4.2">HTTP Request/Response</a><ul> 596 <li><a href="#rfc.section.4.2.1">4.2.1</a> <a href="#rfc.section.4.2.1">Request</a></li> 597 <li><a href="#rfc.section.4.2.2">4.2.2</a> <a href="#rfc.section.4.2.2">Response</a></li> 598 <li><a href="#rfc.section.4.2.3">4.2.3</a> <a href="#Authentication">Authentication</a><ul> 599 <li><a href="#rfc.section.4.2.3.1">4.2.3.1</a> <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> <a href="#rfc.section.4.2.3.2">Stateful Authentication</a></li> 592 601 </ul> 593 602 </li> 594 603 </ul> 595 604 </li> 596 <li><a href="#rfc.section. 3.3">3.3</a> <a href="#rfc.section.3.3">Server Push Transactions</a><ul>597 <li><a href="#rfc.section. 3.3.1">3.3.1</a> <a href="#rfc.section.3.3.1">Server implementation</a></li>598 <li><a href="#rfc.section. 3.3.2">3.3.2</a> <a href="#rfc.section.3.3.2">Client implementation</a></li>605 <li><a href="#rfc.section.4.3">4.3</a> <a href="#rfc.section.4.3">Server Push Transactions</a><ul> 606 <li><a href="#rfc.section.4.3.1">4.3.1</a> <a href="#rfc.section.4.3.1">Server implementation</a></li> 607 <li><a href="#rfc.section.4.3.2">4.3.2</a> <a href="#rfc.section.4.3.2">Client implementation</a></li> 599 608 </ul> 600 609 </li> 601 610 </ul> 602 611 </li> 603 <li><a href="#rfc.section. 4">4.</a> <a href="#rfc.section.4">Design Rationale and Notes</a><ul>604 <li><a href="#rfc.section. 4.1">4.1</a> <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> <a href="#rfc.section.4.2">Error handling - Framing Layer</a></li>606 <li><a href="#rfc.section. 4.3">4.3</a> <a href="#rfc.section.4.3">One Connection Per Domain</a></li>607 <li><a href="#rfc.section. 4.4">4.4</a> <a href="#rfc.section.4.4">Fixed vs Variable Length Fields</a></li>608 <li><a href="#rfc.section. 4.5">4.5</a> <a href="#rfc.section.4.5">Compression Context(s)</a></li>609 <li><a href="#rfc.section. 4.6">4.6</a> <a href="#rfc.section.4.6">Unidirectional streams</a></li>610 <li><a href="#rfc.section. 4.7">4.7</a> <a href="#rfc.section.4.7">Data Compression</a></li>611 <li><a href="#rfc.section. 4.8">4.8</a> <a href="#rfc.section.4.8">Server Push</a></li>612 <li><a href="#rfc.section.5">5.</a> <a href="#rfc.section.5">Design Rationale and Notes</a><ul> 613 <li><a href="#rfc.section.5.1">5.1</a> <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> <a href="#rfc.section.5.2">Error handling - Framing Layer</a></li> 615 <li><a href="#rfc.section.5.3">5.3</a> <a href="#rfc.section.5.3">One Connection Per Domain</a></li> 616 <li><a href="#rfc.section.5.4">5.4</a> <a href="#rfc.section.5.4">Fixed vs Variable Length Fields</a></li> 617 <li><a href="#rfc.section.5.5">5.5</a> <a href="#rfc.section.5.5">Compression Context(s)</a></li> 618 <li><a href="#rfc.section.5.6">5.6</a> <a href="#rfc.section.5.6">Unidirectional streams</a></li> 619 <li><a href="#rfc.section.5.7">5.7</a> <a href="#rfc.section.5.7">Data Compression</a></li> 620 <li><a href="#rfc.section.5.8">5.8</a> <a href="#rfc.section.5.8">Server Push</a></li> 612 621 </ul> 613 622 </li> 614 <li><a href="#rfc.section. 5">5.</a> <a href="#rfc.section.5">Security Considerations</a><ul>615 <li><a href="#rfc.section. 5.1">5.1</a> <a href="#rfc.section.5.1">Use of Same-origin constraints</a></li>616 <li><a href="#rfc.section. 5.2">5.2</a> <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> <a href="#rfc.section.5.3">Cross-Protocol Attacks</a></li>618 <li><a href="#rfc.section. 5.4">5.4</a> <a href="#rfc.section.5.4">Server Push Implicit Headers</a></li>623 <li><a href="#rfc.section.6">6.</a> <a href="#rfc.section.6">Security Considerations</a><ul> 624 <li><a href="#rfc.section.6.1">6.1</a> <a href="#rfc.section.6.1">Use of Same-origin constraints</a></li> 625 <li><a href="#rfc.section.6.2">6.2</a> <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> <a href="#rfc.section.6.3">Cross-Protocol Attacks</a></li> 627 <li><a href="#rfc.section.6.4">6.4</a> <a href="#rfc.section.6.4">Server Push Implicit Headers</a></li> 619 628 </ul> 620 629 </li> 621 <li><a href="#rfc.section. 6">6.</a> <a href="#rfc.section.6">Privacy Considerations</a><ul>622 <li><a href="#rfc.section. 6.1">6.1</a> <a href="#rfc.section.6.1">Long Lived Connections</a></li>623 <li><a href="#rfc.section. 6.2">6.2</a> <a href="#rfc.section.6.2">SETTINGS frame</a></li>630 <li><a href="#rfc.section.7">7.</a> <a href="#rfc.section.7">Privacy Considerations</a><ul> 631 <li><a href="#rfc.section.7.1">7.1</a> <a href="#rfc.section.7.1">Long Lived Connections</a></li> 632 <li><a href="#rfc.section.7.2">7.2</a> <a href="#rfc.section.7.2">SETTINGS frame</a></li> 624 633 </ul> 625 634 </li> 626 <li><a href="#rfc.section. 7">7.</a> <a href="#rfc.section.7">Requirements Notation</a></li>627 <li><a href="#rfc.section. 8">8.</a> <a href="#rfc.section.8">Acknowledgements</a></li>628 <li><a href="#rfc.section. 9">9.</a> <a href="#rfc.references">Normative References</a></li>635 <li><a href="#rfc.section.8">8.</a> <a href="#rfc.section.8">Requirements Notation</a></li> 636 <li><a href="#rfc.section.9">9.</a> <a href="#rfc.section.9">Acknowledgements</a></li> 637 <li><a href="#rfc.section.10">10.</a> <a href="#rfc.references">Normative References</a></li> 629 638 <li><a href="#rfc.authors">Authors' Addresses</a></li> 630 639 <li><a href="#rfc.section.A">A.</a> <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul> … … 635 644 <li><a href="#rfc.index">Index</a></li> 636 645 </ul> 637 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <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> <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). 660 668 </p> 661 669 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> Document Organization 662 670 </h2> 663 <p id="rfc.section.1.1.p.1">The HTTP/2.0 Specification is split into t wo parts: a framing layer (<a href="#FramingLayer" title="HTTP/2.0 Framing Layer">Section 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 3</a>), which specifies the mechanism for overlaying HTTP request/response pairs on top of the framing layer. While some of the671 <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 2</a>), which covers how a HTTP/2.0 is started; a framing layer (<a href="#FramingLayer" title="HTTP/2.0 Framing Layer">Section 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 4</a>), which specifies the mechanism for overlaying HTTP request/response pairs on top of the framing layer. While some of the 664 672 framing layer concepts are isolated from the HTTP layer, building a generic framing layer has not been a goal. The framing 665 673 layer is tailored to the needs of the HTTP protocol and server push. … … 679 687 <li>stream error: An error on an individual HTTP/2.0 stream.</li> 680 688 </ul> 681 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <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> 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> <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 "http:" URIs">Section 2.2</a>; discovery for "https:" URIs is described in <a href="#discover-https" title="Starting HTTP/2.0 for "https:" URIs">Section 2.3</a>. 694 </p> 695 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <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> <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> <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> <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> 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 687 747 pages referencing a connection, or until the server closes the connection. Servers are encouraged to leave connections open 688 748 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 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> Framing692 </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 2.2.1</a>) and data frames (<a href="#DataFrames" title="Data frames">Section 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 version749 connection, it MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section 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> 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 3.2.1</a>) and data frames (<a href="#DataFrames" title="Data frames">Section 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 696 756 number, a frame type, flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried 697 757 after the common header. The simple header is designed to make reading and writing of frames easy. 698 758 </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 of759 <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 700 760 types in dynamically sized frames. 701 761 </p> 702 <h3 id="rfc.section. 2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <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> <a id="ControlFrames" href="#ControlFrames">Control frames</a></h3> 763 <div id="rfc.figure.u.4"></div> <pre>+----------------------------------+ 704 764 |C| Version(15bits) | Type(16bits) | 705 765 +----------------------------------+ … … 708 768 | Data | 709 769 +----------------------------------+ 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 always770 </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 711 771 1. 712 772 </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> 719 779 <ul class="empty"> 720 780 <li>Note that full length control frames (16MB) can be large for implementations running on resource-limited hardware. In such … … 723 783 </li> 724 784 </ul> 725 <h3 id="rfc.section. 2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> <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> <a id="DataFrames" href="#DataFrames">Data frames</a></h3> 786 <div id="rfc.figure.u.5"></div> <pre>+----------------------------------+ 727 787 |C| Stream-ID (31bits) | 728 788 +----------------------------------+ … … 731 791 | Data | 732 792 +----------------------------------+ 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> 736 796 <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 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 3.3.7</a>) below. 738 798 </li> 739 799 <li>0x02 = FLAG_COMPRESS - indicates that the data in this frame has been compressed.</li> 740 800 </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 is801 <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 742 802 8 bytes + length. It is valid to have a zero-length data frame. 743 803 </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> 746 806 <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 2.6.6</a>) frame, it MUST send issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 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 3.6.6</a>) frame, it MUST send issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 3.4.2</a>) with the error code INVALID_STREAM for the stream-id. 748 808 </li> 749 809 <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 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 3.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id. 751 811 </li> 752 812 <li>Implementors note: If an endpoint receives multiple data frames for invalid stream-ids, it MAY close the session.</li> … … 760 820 </li> 761 821 </ul> 762 <h2 id="rfc.section. 2.3"><a href="#rfc.section.2.3">2.3</a> Streams763 </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> 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> 765 825 <ul class="empty"> 766 826 <li>Streams may be created by either the client or server.</li> … … 769 829 <li>Streams may be cancelled.</li> 770 830 </ul> 771 <h3 id="rfc.section. 2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <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> <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> 773 833 <ul class="empty"> 774 834 <li>SYN_STREAM - Open a new stream</li> … … 776 836 <li>RST_STREAM - Close a stream</li> 777 837 </ul> 778 <h3 id="rfc.section. 2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <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 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-ID838 <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <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 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 780 840 must be odd. 0 is not a valid Stream-ID. Stream-IDs from each side of the connection must increase monotonically as new streams 781 841 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 782 842 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. 783 843 </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 than785 any previously received SYN_STREAM, it MUST issue a session error (<a href="#SessionErrorHandler" title="Session Error Handling">Section 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 the788 same stream, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 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 2.4.2</a>) with the error code REFUSED_STREAM. Note, however, that the creating endpoint may have already sent additional frames for844 <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 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 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 3.4.2</a>) with the error code REFUSED_STREAM. Note, however, that the creating endpoint may have already sent additional frames for 791 851 that stream which cannot be immediately stopped. 792 852 </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 wait853 <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 794 854 for the recipient to acknowledge. 795 855 </p> 796 <h4 id="rfc.section. 2.3.2.1"><a href="#rfc.section.2.3.2.1">2.3.2.1</a> Unidirectional streams856 <h4 id="rfc.section.3.3.2.1"><a href="#rfc.section.3.3.2.1">3.3.2.1</a> Unidirectional streams 797 857 </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 creating799 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 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> Bidirectional streams858 <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 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> Bidirectional streams 802 862 </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 on863 <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 804 864 a bi-directional stream. 805 865 </p> 806 <h3 id="rfc.section. 2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <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 represents866 <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <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 808 868 the highest priority and 7 represents the lowest priority. 809 869 </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> Stream headers870 <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> Stream headers 812 872 </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 2.3.7</a>) or half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 2.3.6</a>), each side may send HEADERS frame(s) containing the header data. Header data can be sent in multiple HEADERS frames, and873 <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 3.3.7</a>) or half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 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 815 875 HEADERS frames may be interleaved with data frames. 816 876 </p> 817 <h3 id="rfc.section. 2.3.5"><a href="#rfc.section.2.3.5">2.3.5</a> Stream data exchange877 <h3 id="rfc.section.3.3.5"><a href="#rfc.section.3.3.5">3.3.5</a> Stream data exchange 818 878 </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 frames820 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 2.6.1</a>), SYN_REPLY (<a href="#SYN_REPLY" title="SYN_REPLY">Section 2.6.2</a>), HEADERS (<a href="#HEADERS" title="HEADERS">Section 2.6.7</a>) or a DATA (<a href="#DataFrames" title="Data frames">Section 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> <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 sender879 <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 3.6.1</a>), SYN_REPLY (<a href="#SYN_REPLY" title="SYN_REPLY">Section 3.6.2</a>), HEADERS (<a href="#HEADERS" title="HEADERS">Section 3.6.7</a>) or a DATA (<a href="#DataFrames" title="Data frames">Section 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> <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 824 884 of the FLAG_FIN MUST NOT send further frames on that stream. When both sides have half-closed, the stream is closed. 825 885 </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 received886 <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 827 887 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. 828 888 </p> 829 <h3 id="rfc.section. 2.3.7"><a href="#rfc.section.2.3.7">2.3.7</a> <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> <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> 831 891 <ul class="empty"> 832 892 <li>Normal termination: Normal stream termination occurs when both sender and recipient have half-closed the stream by sending … … 837 897 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, 838 898 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 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 3.4.2</a>) 840 900 </li> 841 901 <li>TCP connection teardown: If the TCP connection is torn down while un-closed streams exist, then the endpoint must assume that … … 843 903 </li> 844 904 </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> Error Handling847 </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 specification849 to "issue a session error" refers to <a href="#SessionErrorHandler" title="Session Error Handling">Section 2.4.1</a>. Any reference to "issue a stream error" refers to <a href="#StreamErrorHandler" title="Stream Error Handling">Section 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> <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 compression853 state. When a session error occurs, the endpoint encountering the error MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section 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 session905 <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> 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 3.4.1</a>. Any reference to "issue a stream error" refers to <a href="#StreamErrorHandler" title="Stream Error Handling">Section 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> <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 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 854 914 is terminating. After sending the GOAWAY frame, the endpoint MUST close the TCP connection. 855 915 </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 endpoint916 <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 857 917 partially processes a frame containing compressed data without updating compression state properly, future control frames 858 918 which use compression will be always be errored. Implementations SHOULD always try to process compressed data so that errors 859 919 which could be handled as stream errors do not become session errors. 860 920 </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 received921 <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 862 922 by the receiving endpoint. It is a best-effort attempt to communicate with the remote about why the session is going down. 863 923 </p> 864 <h3 id="rfc.section. 2.4.2"><a href="#rfc.section.2.4.2">2.4.2</a> <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 framing866 layer. Upon a stream error, the endpoint MUST send a RST_STREAM (<a href="#RST_STREAM" title="RST_STREAM">Section 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. After924 <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a> <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 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 867 927 sending the RST_STREAM, the stream is closed to the sending endpoint. After sending the RST_STREAM, if the sender receives 868 928 any frames other than a RST_STREAM for that stream id, it will result in sending additional RST_STREAM frames. An endpoint … … 870 930 does not cause the HTTP/2.0 session to be closed. 871 931 </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 MAY932 <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 873 933 coalesce them into a single RST_STREAM frame. (This can happen if a stream is closed, but the remote sends multiple data frames. 874 934 There is no reason to send a RST_STREAM for each frame in succession). 875 935 </p> 876 <h2 id="rfc.section. 2.5"><a href="#rfc.section.2.5">2.5</a> Data flow877 </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 must936 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> 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 879 939 intelligently interleave data messages for concurrent sessions. 880 940 </p> 881 <h2 id="rfc.section. 2.6"><a href="#rfc.section.2.6">2.6</a> Control frame types882 </h2> 883 <h3 id="rfc.section. 2.6.1"><a href="#rfc.section.2.6.1">2.6.1</a> <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 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> Control frame types 942 </h2> 943 <h3 id="rfc.section.3.6.1"><a href="#rfc.section.3.6.1">3.6.1</a> <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 3.3.2</a>) 945 </p> 946 <div id="rfc.figure.u.6"></div> <pre>+------------------------------------+ 887 947 |1| version | 1 | 888 948 +------------------------------------+ … … 906 966 +------------------------------------+ | 907 967 | (repeats) | <+ 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> 909 969 <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 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 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 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 3.3.6</a>) state. 913 973 </li> 914 974 </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 bytes975 <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 916 976 plus the length of the compressed Name/Value block. 917 977 </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 independent978 <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 920 980 of all other streams, it should be 0. 921 981 </p> 922 <p id="rfc.section. 2.6.1.p.7">Priority: A 3-bit priority (<a href="#StreamPriority" title="Stream priority">Section 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 used926 for this request. see CREDENTIAL frame (<a href="#CREDENTIAL" title="CREDENTIAL">Section 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 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 error931 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 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> <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 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 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 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 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> <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>+------------------------------------+ 936 996 |1| version | 2 | 937 997 +------------------------------------+ … … 951 1011 +------------------------------------+ | 952 1012 | (repeats) | <+ 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> 954 1014 <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 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 3.3.6</a>) state. 956 1016 </li> 957 1017 </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 bytes1018 <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 959 1019 plus the length of the compressed Name/Value block. 960 1020 </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 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 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 error967 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 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> <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 creator1021 <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 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 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 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> <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 971 1031 wishes to cancel the stream. When sent by the recipient of a stream, it indicates an error or that the recipient did not want 972 1032 to accept the stream, so the stream should be closed. 973 1033 </p> 974 <div id="rfc.figure.u. 5"></div> <pre>+----------------------------------+1034 <div id="rfc.figure.u.8"></div> <pre>+----------------------------------+ 975 1035 |1| version | 3 | 976 1036 +----------------------------------+ … … 981 1041 | Status code | 982 1042 +----------------------------------+ 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, this1043 </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 985 1045 value is always 8. 986 1046 </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> 989 1049 <ul class="empty"> 990 1050 <li>1 - PROTOCOL_ERROR. This is a generic error, and should only be used if a more specific error is not available.</li> … … 1008 1068 <li>Note: 0 is not a valid status code for a RST_STREAM.</li> 1009 1069 </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 moves1070 <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 1011 1071 into the closed state. 1012 1072 </p> 1013 <h3 id="rfc.section. 2.6.4"><a href="#rfc.section.2.6.4">2.6.4</a> <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> <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. 1015 1075 SETTINGS frames can be sent at any time by either endpoint, are optionally sent, and are fully asynchronous. When the server 1016 1076 is the sender, the sender can request that configuration data be persisted by the client across HTTP/2.0 sessions and returned 1017 1077 to the server in future communications. 1018 1078 </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 port1079 <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 1020 1080 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 1021 1081 the persisted settings on future connections to the same origin AND IP address and TCP port. Clients MUST NOT request servers 1022 1082 to use the persistence features of the SETTINGS frames, and servers MUST ignore persistence related flags sent by a client. 1023 1083 </p> 1024 <div id="rfc.figure.u. 6"></div> <pre>+----------------------------------+1084 <div id="rfc.figure.u.9"></div> <pre>+----------------------------------+ 1025 1085 |1| version | 4 | 1026 1086 +----------------------------------+ … … 1031 1091 | ID/Value Pairs | 1032 1092 | ... | 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. 1037 1097 If this frame contains ID/Value pairs with the FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its existing, 1038 1098 persisted settings, and then persist the values with the flag set which are contained within this frame. Because persistence 1039 1099 is only implemented on the client, this flag can only be used when the sender is the server. 1040 1100 </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 frame1101 <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 1042 1102 is 8 bytes + length. 1043 1103 </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> 1046 1106 <ul class="empty"> 1047 1107 <li>ID.flags: … … 1087 1147 </li> 1088 1148 </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 sender1149 <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 1091 1151 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 1092 1152 ID/value pairs are sent, they should be sent in order of lowest id to highest id. A single SETTINGS frame MUST not contain … … 1094 1154 all values except the first one. 1095 1155 </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, the1156 <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 1097 1157 most recent value overrides any previously sent values. If the server sends IDs 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE 1098 1158 in a first SETTINGS frame, and then sends IDs 4 and 5 with the FLAG_SETTINGS_PERSIST_VALUE, when the client returns the persisted 1099 1159 state on its next SETTINGS frame, it SHOULD send all 5 settings (1, 2, 3, 4, and 5 in this example) to the server. 1100 1160 </p> 1101 <h3 id="rfc.section. 2.6.5"><a href="#rfc.section.2.6.5">2.6.5</a> <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 client1161 <h3 id="rfc.section.3.6.5"><a href="#rfc.section.3.6.5">3.6.5</a> <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 1103 1163 or the server. Recipients of a PING frame should send an identical frame to the sender as soon as possible (if there is other 1104 1164 pending data waiting to be sent, PING should take highest priority). Each ping sent by a sender should use a unique ID. 1105 1165 </p> 1106 <div id="rfc.figure.u. 7"></div> <pre>+----------------------------------+1166 <div id="rfc.figure.u.10"></div> <pre>+----------------------------------+ 1107 1167 |1| version | 6 | 1108 1168 +----------------------------------+ … … 1111 1171 | 32-bit ID | 1112 1172 +----------------------------------+ 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 odd1173 </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 1118 1178 numbered ID. When the server initiates a ping, it must use an even numbered ping. Use of odd/even IDs is required in order 1119 1179 to avoid accidental looping on PINGs (where each side initiates an identical PING at the same time). 1120 1180 </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 odd1181 <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 1123 1183 numbered PING which it did not initiate, it must ignore the PING. 1124 1184 </p> 1125 <h3 id="rfc.section. 2.6.6"><a href="#rfc.section.2.6.6">2.6.6</a> <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> <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. 1127 1187 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. 1128 1188 Recipients of a GOAWAY frame must not send additional streams on this session, although a new session can be established for … … 1130 1190 or maintenance), while still finishing processing of previously established streams. 1131 1191 </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 deal1192 <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 1133 1193 with this case, the GOAWAY contains a last-stream-id indicating the stream-id of the last stream which was created on the 1134 1194 sending endpoint in this session. If the receiver of the GOAWAY sent new SYN_STREAMs for sessions after this last-stream-id, … … 1136 1196 the receiver may want to re-create the stream later on a new session). 1137 1197 </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 has1198 <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 1139 1199 been partially processed or not. (For example, if an HTTP client sends a POST at the same time that a server closes a connection, 1140 1200 the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate 1141 1201 where it stopped working). 1142 1202 </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>+----------------------------------+ 1145 1205 |1| version | 7 | 1146 1206 +----------------------------------+ … … 1151 1211 | Status code | 1152 1212 +----------------------------------+ 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 the1213 </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 1158 1218 GOAWAY message. If no streams were replied to, this value MUST be 0. 1159 1219 </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> 1161 1221 <ul class="empty"> 1162 1222 <li>0 - OK. This is a normal session teardown.</li> … … 1166 1226 </li> 1167 1227 </ul> 1168 <h3 id="rfc.section. 2.6.7"><a href="#rfc.section.2.6.7">2.6.7</a> <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> <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. 1170 1230 Specific application of the headers in this frame is application-dependent. The name/value header block within this frame 1171 1231 is compressed. 1172 1232 </p> 1173 <div id="rfc.figure.u. 9"></div> <pre>+------------------------------------+1233 <div id="rfc.figure.u.12"></div> <pre>+------------------------------------+ 1174 1234 |1| version | 8 | 1175 1235 +------------------------------------+ … … 1189 1249 +------------------------------------+ | 1190 1250 | (repeats) | <+ 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> 1192 1252 <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 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 3.3.6</a>) state. 1194 1254 </li> 1195 1255 </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 length1256 <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 1197 1257 field is 4 (when the number of name value pairs is 0). 1198 1258 </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 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> <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 per1259 <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 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> <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 1204 1264 hop, that is, only between the two endpoints of a HTTP/2.0 connection. If there are one or more intermediaries between the 1205 1265 client and the origin server, flow control signals are not explicitly forwarded by the intermediaries. (However, throttling 1206 1266 of data transfer by any recipient may have the effect of indirectly propagating flow control information upstream back to 1207 1267 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 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 window1268 If a recipient fails to buffer an entire control frame, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 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 1211 1271 is a simple uint32 that indicates how many bytes of data the sender can transmit. After a stream is created, but before any 1212 1272 data frames have been transmitted, the sender begins with the initial window size. This window size is a measure of the buffering … … 1217 1277 to receive more data. 1218 1278 </p> 1219 <div id="rfc.figure.u.1 0"></div> <pre>+----------------------------------+1279 <div id="rfc.figure.u.13"></div> <pre>+----------------------------------+ 1220 1280 |1| version | 9 | 1221 1281 +----------------------------------+ … … 1226 1286 |X| Delta-Window-Size (31-bits) | 1227 1287 +----------------------------------+ 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. 1234 1294 The legal range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes. 1235 1295 </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 sender1296 <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 1237 1297 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 1238 1298 to terminate the stream. 1239 1299 </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 can1300 <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 1241 1301 use the SETTINGS control frame to adjust the initial window size for the connection. That is, its peer can start out using 1242 1302 the 64KB default initial window size when sending data frames before receiving the SETTINGS. Because SETTINGS is asynchronous, … … 1252 1312 </li> 1253 1313 </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, 1255 1315 if the recipient sets the initial window size to be 16KB, and the sender sends 64KB immediately on connection establishment, 1256 1316 the sender will discover its window size is -48KB on receipt of the SETTINGS. As the recipient consumes the first 16KB, it … … 1258 1318 again, and it can resume transmitting data frames. 1259 1319 </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_UPDATE1320 <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 1261 1321 frames as it consumes the last data frame. A sender should ignore all the WINDOW_UPDATE frames associated with the stream 1262 1322 after it send the last frame for the stream. 1263 1323 </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 to1324 <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 1265 1325 each other. This property allows a recipient to aggressively update the window size kept by the sender to prevent the stream 1266 1326 from stalling. 1267 1327 </p> 1268 <h3 id="rfc.section. 2.6.9"><a href="#rfc.section.2.6.9">2.6.9</a> <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 client1328 <h3 id="rfc.section.3.6.9"><a href="#rfc.section.3.6.9">3.6.9</a> <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 1270 1330 may decide to send requests for resources from different origins on the same HTTP/2.0 session if it decides that that server 1271 1331 handles both origins. For example if the IP address associated with both hostnames matches and the SSL server certificate … … 1273 1333 client certificate, the client needs a mechanism to send additional client certificates to the server. 1274 1334 </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 needs1335 <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 1276 1336 to send a client certificate to the server, it will send a CREDENTIAL frame that specifies the index of the slot in which 1277 1337 to store the certificate as well as proof that the client posesses the corresponding private key. The initial size of this … … 1283 1343 slots as possible. 1284 1344 </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, 1286 1346 imagine that the client has 2 requests outstanding to the server for two different pages (in different tabs). When the renegotiation 1287 1347 + client certificate request comes in, the browser is unable to determine which resource triggered the client certificate 1288 1348 request, in order to prompt the user accordingly. 1289 1349 </p> 1290 <div id="rfc.figure.u.1 1"></div> <pre>+----------------------------------+1350 <div id="rfc.figure.u.14"></div> <pre>+----------------------------------+ 1291 1351 |1|000000000000001|0000000000001011| 1292 1352 +----------------------------------+ … … 1303 1363 | Certificate | | 1304 1364 +----------------------------------+ <+ 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 certificate1365 </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 1306 1366 stored at this index, it will be overwritten. The index is one based, not zero based; zero is an invalid slot index. 1307 1367 </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 is1368 <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 1309 1369 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 1310 1370 type used in TLS 1.0 connections can not be correctly encoded in a digitally-signed element, SHA1 must be used when MD5+SHA1 … … 1314 1374 For a 1024-bit RSA key, the CREDENTIAL message would be ~500 bytes. 1315 1375 </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, 1317 1377 followed by a DER encoded certificate. The certificate must be of the same type (RSA, ECDSA, etc) as the client certificate 1318 1378 associated with the SSL connection. 1319 1379 </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 with1380 <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 1321 1381 a RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon receipt of a RST_STREAM frame with INVALID_CREDENTIALS, 1322 1382 the client should initiate a new stream directly to the requested origin and resend the request. Note, HTTP/2.0 does not allow 1323 1383 the server to request different client authentication for different resources in the same origin. 1324 1384 </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> <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.1 2"></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> <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>+------------------------------------+ 1329 1389 | Number of Name/Value pairs (int32) | 1330 1390 +------------------------------------+ … … 1338 1398 +------------------------------------+ 1339 1399 | (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> 1342 1402 <ul class="empty"> 1343 1403 <li>Length of Name: a 32-bit value containing the number of octets in the name field. Note that in practice, this length must … … 1350 1410 <li>Value: 0 or more octets, 8-bit sequences of data, excluding 0.</li> 1351 1411 </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 issue1353 a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 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 values1412 <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 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 1356 1416 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, 1357 1417 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 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> <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 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> <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. 1362 1422 This block is always compressed using zlib compression. Within this specification, any reference to 'zlib' is referring to 1363 1423 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.1 3"></div> <pre class="ccmarker cct"><span><CODE BEGINS></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><CODE BEGINS></span></pre><pre class="text">const unsigned char http2_dictionary_txt[] = { 1367 1427 0x00, 0x00, 0x00, 0x07, 0x6f, 0x70, 0x74, 0x69, \\ - - - - o p t i 1368 1428 0x6f, 0x6e, 0x73, 0x00, 0x00, 0x00, 0x04, 0x68, \\ o n s - - - - h … … 1544 1604 0x2c, 0x65, 0x6e, 0x71, 0x3d, 0x30, 0x2e \\ - e n q - 0 - 1545 1605 }; 1546 </pre><pre class="ccmarker ccb"><span><CODE ENDS></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 value1606 </pre><pre class="ccmarker ccb"><span><CODE ENDS></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 1547 1607 pairs in one direction on a connection. HTTP/2.0 uses a SYNC_FLUSH between each compressed frame. 1548 1608 </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 use1609 <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 1550 1610 and CPU consumption. Because header blocks are generally small, implementors may want to reduce the window-size of the compression 1551 1611 engine from the default 15bits (a 32KB window) to more like 11bits (a 2KB window). The exact setting is chosen by the compressor, 1552 1612 the decompressor will work with any setting. 1553 1613 </p> 1554 <h1 id="rfc.section. 3"><a href="#rfc.section.3">3.</a> <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 perspective1614 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <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 1556 1616 of the server business logic or application API, the features of HTTP are unchanged. To achieve this, all of the application 1557 1617 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> Connection Management1561 </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 streams1618 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> 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 1565 1625 have finished), while another HTTP/2.0 session is starting. 1566 1626 </p> 1567 <h3 id="rfc.section. 3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> Use of GOAWAY1627 <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> Use of GOAWAY 1568 1628 </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 a1629 <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 1570 1630 server GOAWAY message, HTTP has a race condition where the client sends a request (a new SYN_STREAM) just as the server is 1571 1631 closing the connection, and the client cannot know if the server received the stream or not. By using the last-stream-id in 1572 1632 the GOAWAY, servers can indicate to the client if a request was processed or not. 1573 1633 </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 active1634 <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 1575 1635 streams to finish. The client will be able to determine this because HTTP/2.0 streams are determinstically closed. This abrupt 1576 1636 termination will force the client to heuristically decide whether to retry the pending requests. Clients always need to be … … 1578 1638 as the server never having sent a GOAWAY. 1579 1639 </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 time1640 <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 1581 1641 for the active streams to finish before terminating the connection. 1582 1642 </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-push1643 <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 1584 1644 streams were received by the client. 1585 1645 </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-id1646 <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 1587 1647 of 0. 1588 1648 </p> 1589 <h2 id="rfc.section. 3.2"><a href="#rfc.section.3.2">3.2</a> HTTP Request/Response1590 </h2> 1591 <h3 id="rfc.section. 3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> Request1649 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> HTTP Request/Response 1650 </h2> 1651 <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> Request 1592 1652 </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 frame1653 <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 1594 1654 MUST set the FLAG_FIN, indicating that the client intends to send no further data on this stream. For requests which do contain 1595 1655 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. 1596 1656 The last DATA frame will set the FLAG_FIN to indicate the end of the body. 1597 1657 </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 header1658 <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 1599 1659 block in HTTP/2.0 is mostly unchanged from today's HTTP header block, with the following differences: 1600 1660 </p> … … 1633 1693 </li> 1634 1694 </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, 1636 1696 it should attempt to raise the priority of that resource. Resources such as images, SHOULD generally use the lowest priority. 1637 1697 </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 with1698 <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 1639 1699 a HTTP 400 Bad Request reply. 1640 1700 </p> 1641 <h3 id="rfc.section. 3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> Response1701 <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a> Response 1642 1702 </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 send1703 <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 1644 1704 data after the SYN_REPLY frame via a series of DATA frames, and the last data frame will contain the FLAG_FIN to indicate 1645 1705 successful end-of-stream. If a response (like a 202 or 204 response) contains no body, the SYN_REPLY frame may contain the 1646 1706 FLAG_FIN flag to indicate no further data will be sent on the stream. 1647 1707 </p> 1648 <p id="rfc.section. 3.2.2.p.2"> </p>1708 <p id="rfc.section.4.2.2.p.2"> </p> 1649 1709 <ul class="empty"> 1650 1710 <li>The response status line is unfolded into name/value pairs like other HTTP headers and must be present: … … 1661 1721 </li> 1662 1722 </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 frame1723 <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 1664 1724 indicating a PROTOCOL ERROR. 1665 1725 </p> 1666 <h3 id="rfc.section. 3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <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> <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" 1668 1728 response, and include a WWW-Authenticate challenge header that defines the authentication scheme to be used. The client then 1669 1729 retries the request with an Authorization header appropriate to the specified authentication scheme. 1670 1730 </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 defined1731 <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 1672 1732 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. 1673 1733 </p> 1674 <h4 id="rfc.section. 3.2.3.1"><a href="#rfc.section.3.2.3.1">3.2.3.1</a> Stateless Authentication1734 <h4 id="rfc.section.4.2.3.1"><a href="#rfc.section.4.2.3.1">4.2.3.1</a> Stateless Authentication 1675 1735 </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 concurrently1736 <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 1677 1737 sent to a single server, each will authenticate independently, similar to how two HTTP connections would independently authenticate 1678 1738 to a proxy server. 1679 1739 </p> 1680 <h4 id="rfc.section. 3.2.3.2"><a href="#rfc.section.3.2.3.2">3.2.3.2</a> Stateful Authentication1740 <h4 id="rfc.section.4.2.3.2"><a href="#rfc.section.4.2.3.2">4.2.3.2</a> Stateful Authentication 1681 1741 </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 violates1742 <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 1683 1743 RFC2617 - they do not include a "realm" as part of the request. This is problematic in HTTP/2.0 because it makes it impossible 1684 1744 for a client to disambiguate two concurrent server authentication challenges. 1685 1745 </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> 1687 1747 <ul class="empty"> 1688 1748 <li>Servers can add a "realm=<desired realm>" header so that the two authentication requests can be disambiguated and run concurrently. … … 1695 1755 </li> 1696 1756 </ul> 1697 <h2 id="rfc.section. 3.3"><a href="#rfc.section.3.3">3.3</a> Server Push Transactions1698 </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 that1757 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> 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 1700 1760 sometimes a server knows that it will need to send multiple resources in response to a single request. Without server push 1701 1761 features, the client must first download the primary resource, then discover the secondary resource(s), and request them. … … 1704 1764 the performance benefit. 1705 1765 </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 pushed1766 <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 1709 1769 response in same way that it would cache any other response. This means validating the response headers and inserting into 1710 1770 the disk cache. 1711 1771 </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.01772 <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 1713 1773 pushed streams contain an "associated-stream-id" which indicates the requested stream for which the pushed stream is related. 1714 1774 The pushed stream inherits all of the headers from the associated-stream-id with the exception of ":host", ":scheme", and … … 1716 1776 request headers with the cached resource. 1717 1777 </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 or1778 <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 1719 1779 resources to the user-agent. Browsers MUST implement throttles to protect against unreasonable push attacks. 1720 1780 </p> 1721 <h3 id="rfc.section. 3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> Server implementation1781 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> Server implementation 1722 1782 </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. 1724 1784 The SYN_STREAM MUST include an Associated-To-Stream-ID, and MUST set the FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST include 1725 1785 headers for ":scheme", ":host", ":path", which represent the URL for the resource being pushed. Subsequent headers may follow … … 1728 1788 user-agent would not be able to differentiate the requests. 1729 1789 </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 clear1790 <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 1731 1791 endpoint for pushed content. If the user-agent requested a resource on stream 11, the server replies on stream 11. It can 1732 1792 push any number of additional streams to the client before sending a FLAG_FIN on stream 11. However, once the originating … … 1734 1794 before the originating stream is closed, they only need to be created before the originating stream closes. 1735 1795 </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 content1796 <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 1738 1798 which could allow the client to discover the pushed resource and request it. 1739 1799 </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 frame1800 <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 1742 1802 for the pushed resource, it may later use an additional HEADERS frame to augment the name/value pairs to be associated with 1743 1803 the pushed stream. The subsequent HEADERS frame(s) must not contain a header for ':host', ':scheme', or ':path' (e.g. the … … 1746 1806 any data frames on the stream. 1747 1807 </p> 1748 <h3 id="rfc.section. 3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> Client implementation1808 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> Client implementation 1749 1809 </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> 1751 1811 <ul class="empty"> 1752 1812 <li>the resource is not being pushed</li> … … 1754 1814 <li>the resource is being pushed, and the data has started to arrive</li> 1755 1815 </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 requests1816 <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 1757 1817 for the resource in the pushed stream, and instead wait for the pushed stream to arrive. 1758 1818 </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 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/Value1819 <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 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 1762 1822 section, it MUST reply with a RST_STREAM with error code HTTP_PROTOCOL_ERROR. 1763 1823 </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 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 2.4.2</a>) with error code CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames1824 <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 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 3.4.2</a>) with error code CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames 1767 1827 for any streams with in-association-to for the original stream. 1768 1828 </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 client1770 must issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 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 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. 1773 1833 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). 1774 1834 </p> 1775 <h1 id="rfc.section. 4"><a href="#rfc.section.4">4.</a> Design Rationale and Notes1835 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Design Rationale and Notes 1776 1836 </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, and1837 <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 1778 1838 none of these notes should be considered authoritative about how the protocol works. However, these notes may prove useful 1779 1839 in future debates about how to resolve protocol ambiguities or how to evolve the protocol going forward. They may be removed 1780 1840 before the final draft. 1781 1841 </p> 1782 <h2 id="rfc.section. 4.1"><a href="#rfc.section.4.1">4.1</a> Separation of Framing Layer and Application Layer1783 </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 2</a>) with requirements of a specific application - HTTP (<a href="#HTTPLayer" title="HTTP Layering over HTTP/2.0">Section 3</a>). This is reflected in the request/response nature of the streams, the definition of the HEADERS and compression contexts1842 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> 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 3</a>) with requirements of a specific application - HTTP (<a href="#HTTPLayer" title="HTTP Layering over HTTP/2.0">Section 4</a>). This is reflected in the request/response nature of the streams, the definition of the HEADERS and compression contexts 1785 1845 which are very similar to HTTP, and other areas as well. 1786 1846 </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. Isolating1847 <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 1788 1848 the two layers is convenient for description of the protocol and how it relates to existing HTTP implementations. However, 1789 1849 the ability to reuse the HTTP/2.0 framing layer is a non goal. 1790 1850 </p> 1791 <h2 id="rfc.section. 4.2"><a href="#rfc.section.4.2">4.2</a> Error handling - Framing Layer1792 </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 those1851 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> 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 1794 1854 that do not. 1795 1855 </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 a1856 <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 1797 1857 mechanism to invalidate the stream but move forward without aborting the connection altogether. 1798 1858 </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 endpoint1859 <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 1800 1860 detecting the error should initiate a connection close. 1801 1861 </p> 1802 <h2 id="rfc.section. 4.3"><a href="#rfc.section.4.3">4.3</a> One Connection Per Domain1803 </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 is1862 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> 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 1805 1865 because it is very difficult to provide a consistent level of service (e.g. TCP slow-start), prioritization, or optimal compression 1806 1866 when the client is connecting to the server through multiple channels. 1807 1867 </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 overall1868 <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 1809 1869 number of packets sent by HTTP/2.0 can be as much as 40% less than HTTP. Handling large numbers of concurrent connections 1810 1870 on the server also does become a scalability problem, and HTTP/2.0 reduces this load. 1811 1871 </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 streams1872 <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 1813 1873 onto a single stream, it creates a potential for head-of-line blocking problems at the transport level. In tests so far, the 1814 1874 negative effects of head-of-line blocking (especially in the presence of packet loss) is outweighed by the benefits of compression 1815 1875 and prioritization. 1816 1876 </p> 1817 <h2 id="rfc.section. 4.4"><a href="#rfc.section.4.4">4.4</a> Fixed vs Variable Length Fields1818 </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. To1877 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> 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 1820 1880 some, this seems like a tragic waste of bandwidth. HTTP/2.0 choses the simple encoding for speed and simplicity. 1821 1881 </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 data1882 <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 1823 1883 frame is only an 8 byte overhead for a 1452 byte payload (~0.6%). At the time of this writing, bandwidth is already plentiful, 1824 1884 and there is a strong trend indicating that bandwidth will continue to increase. With an average worldwide bandwidth of 1Mbps, … … 1828 1888 this is completely mitigated. 1829 1889 </p> 1830 <h2 id="rfc.section. 4.5"><a href="#rfc.section.4.5">4.5</a> 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 could1890 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> 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 1833 1893 have maintained a map (or list) of compression contexts usable for each origin. The basic case is easy - each HEADERS frame 1834 1894 would need to identify the context to use for that frame. However, compression contexts are not cheap, so the lifecycle of … … 1838 1898 ultimately we decided that such a mechanism creates too many problems to solve. 1839 1899 </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. 1841 1901 For the common case (no proxy), this fine because most requests are to the same origin and we never need to reset the context. 1842 1902 For cases where we are using two different origins over a single HTTP/2.0 session, we simply reset the compression state between 1843 1903 each transition. 1844 1904 </p> 1845 <h2 id="rfc.section. 4.6"><a href="#rfc.section.4.6">4.6</a> Unidirectional streams1846 </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 recipient1905 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> 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 1848 1908 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 1849 1909 is, therefore, not necessary. 1850 1910 </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 from1911 <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 1852 1912 needing to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which otherwise serve no purpose. 1853 1913 </p> 1854 <h2 id="rfc.section. 4.7"><a href="#rfc.section.4.7">4.7</a> Data Compression1855 </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 content1914 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> 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 1857 1917 of the stream is redundant. There is no value in compressing a stream which is already compressed. Because of this, HTTP/2.0 1858 1918 does allow data compression to be optional. We included it because study of existing websites shows that many sites are not … … 1860 1920 administrators could simply force compression - it is better to compress twice than to not compress. 1861 1921 </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 will1922 <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 1863 1923 likely remove it from the specification. 1864 1924 </p> 1865 <h2 id="rfc.section. 4.8"><a href="#rfc.section.4.8">4.8</a> Server Push1866 </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 reason1925 <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a> 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 1868 1928 for this is so that proxies have a lifetime for which they can discard information about previous streams. If a pushed stream 1869 1929 could associate itself with an already-closed stream, then endpoints would not have a specific lifecycle for when they could 1870 1930 disavow knowledge of the streams which went before. 1871 1931 </p> 1872 <h1 id="rfc.section. 5"><a href="#rfc.section.5">5.</a> Security Considerations1932 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> Security Considerations 1873 1933 </h1> 1874 <h2 id="rfc.section. 5.1"><a href="#rfc.section.5.1">5.1</a> Use of Same-origin constraints1875 </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> HTTP Headers and HTTP/2.0 Headers1879 </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 with1934 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> 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> 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 1881 1941 HTTP/2.0 headers, there is a possibility that some HTTP applications already use a particular header name. To avoid any conflicts, 1882 1942 all headers introduced for layering HTTP over HTTP/2.0 are prefixed with ":". ":" is not a valid sequence in HTTP header naming, 1883 1943 preventing any possible conflict. 1884 1944 </p> 1885 <h2 id="rfc.section. 5.3"><a href="#rfc.section.5.3">5.3</a> Cross-Protocol Attacks1886 </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 transmission1945 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> 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 1888 1948 (except the handshake itself), making it difficult for attackers to control the data which could be used in a cross-protocol 1889 1949 attack. 1890 1950 </p> 1891 <h2 id="rfc.section. 5.4"><a href="#rfc.section.5.4">5.4</a> Server Push Implicit Headers1892 </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 Vary1951 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> 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 1894 1954 header) to work, however, all cached resources must have a set of request headers. For this reason, browsers MUST be careful 1895 1955 to inherit request headers from the associated stream for the push. This includes the 'Cookie' header. 1896 1956 </p> 1897 <h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> Privacy Considerations1957 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> Privacy Considerations 1898 1958 </h1> 1899 <h2 id="rfc.section. 6.1"><a href="#rfc.section.6.1">6.1</a> Long Lived Connections1900 </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 makes1959 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> 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 1902 1962 a request. The maintenance of these connections over time could be used to expose private information. For example, a user 1903 1963 using a browser hours after the previous user stopped using that browser may be able to learn about what the previous user … … 1905 1965 risk. 1906 1966 </p> 1907 <h2 id="rfc.section. 6.2"><a href="#rfc.section.6.2">6.2</a> SETTINGS frame1908 </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 client1967 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> 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 1910 1970 and server on the client. Although this is intended only to be used to reduce latency, renegade servers could use it as a 1911 1971 mechanism to store identifying information about the client in future requests. 1912 1972 </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 SETTINGS1973 <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 1914 1974 storage. 1915 1975 </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> Requirements Notation1976 <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> Requirements Notation 1919 1979 </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" 1921 1981 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>. 1922 1982 </p> 1923 <h1 id="rfc.section. 8"><a href="#rfc.section.8">8.</a> Acknowledgements1983 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> Acknowledgements 1924 1984 </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: 1926 1986 Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe 1927 1987 Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton. 1928 1988 </p> 1929 <h1 id="rfc.references"><a href="#rfc.section. 9" id="rfc.section.9">9.</a> Normative References1989 <h1 id="rfc.references"><a href="#rfc.section.10" id="rfc.section.10">10.</a> Normative References 1930 1990 </h1> 1931 1991 <table> … … 1933 1993 <td class="reference"><b id="ASCII">[ASCII]</b></td> 1934 1994 <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 draft-ietf-httpbis-p1-messaging-21 (work in progress), October 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 draft-ietf-httpbis-p2-semantics-21 (work in progress), October 2012. 2004 </td> 1935 2005 </tr> 1936 2006 <tr> … … 1955 2025 </tr> 1956 2026 <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 2285, February 1998.1959 </td>1960 </tr>1961 <tr>1962 2027 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 1963 2028 <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 2616, June 1999. … … 1967 2032 <td class="reference"><b id="RFC2617">[RFC2617]</b></td> 1968 2033 <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 2617, June 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 4366, April 2006.1974 2034 </td> 1975 2035 </tr> … … 2017 2077 <p id="rfc.section.A.1.p.3">Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <<a href="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU">https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU</a>>. 2018 2078 </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> 2019 2082 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <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> 2020 2083 <p id="rfc.section.A.2.p.1">Adopted as base for draft-ietf-httpbis-http2.</p> … … 2022 2085 <p id="rfc.section.A.2.p.3">Added status note.</p> 2023 2086 <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> 2025 2088 </p> 2026 2089 <div class="print2col"> 2027 2090 <ul class="ind"> 2028 2091 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 2029 <li><em>ASCII</em> <a href="#rfc.xref.ASCII.1">2.6.10</a>, <a href="#ASCII"><b>9</b></a></li> 2092 <li><em>ASCII</em> <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> <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> <a href="#rfc.xref.HTTP-p2.1">2.2</a>, <a href="#HTTP-p2"><b>10</b></a></li> 2030 2098 </ul> 2031 2099 </li> 2032 2100 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 2033 <li><em>RFC0793</em> <a href="#rfc.xref.RFC0793.1">2.1</a>, <a href="#RFC0793"><b>9</b></a></li> 2034 <li><em>RFC1738</em> <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> <a href="#rfc.xref.RFC1950.1">2.6.10.1</a>, <a href="#RFC1950"><b>9</b></a></li> 2036 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">7</a>, <a href="#RFC2119"><b>9</b></a></li> 2037 <li><em>RFC2285</em> <a href="#RFC2285"><b>9</b></a></li> 2038 <li><em>RFC2616</em> <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> <a href="#rfc.xref.RFC2617.1">3.2.3</a>, <a href="#RFC2617"><b>9</b></a></li> 2040 <li><em>RFC4366</em> <a href="#RFC4366"><b>9</b></a></li> 2041 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">3.2.3</a>, <a href="#RFC4559"><b>9</b></a></li> 2042 <li><em>RFC5246</em> <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> <a href="#rfc.xref.RFC5246.1">2.6.9</a></li> 2101 <li><em>RFC0793</em> <a href="#rfc.xref.RFC0793.1">3.1</a>, <a href="#RFC0793"><b>10</b></a></li> 2102 <li><em>RFC1738</em> <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> <a href="#rfc.xref.RFC1950.1">3.6.10.1</a>, <a href="#RFC1950"><b>10</b></a></li> 2104 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">8</a>, <a href="#RFC2119"><b>10</b></a></li> 2105 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">4</a>, <a href="#RFC2616"><b>10</b></a></li> 2106 <li><em>RFC2617</em> <a href="#rfc.xref.RFC2617.1">4.2.3</a>, <a href="#RFC2617"><b>10</b></a></li> 2107 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">4.2.3</a>, <a href="#RFC4559"><b>10</b></a></li> 2108 <li><em>RFC5246</em> <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> <a href="#rfc.xref.RFC5246.1">3.6.9</a></li> 2044 2110 </ul> 2045 2111 </li> 2046 <li><em>RFC6454</em> <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> <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> 2047 2113 </ul> 2048 2114 </li> 2049 2115 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 2050 <li><em>TLSNPN</em> <a href="# TLSNPN"><b>9</b></a></li>2116 <li><em>TLSNPN</em> <a href="#rfc.xref.TLSNPN.1">2.1</a>, <a href="#TLSNPN"><b>10</b></a></li> 2051 2117 </ul> 2052 2118 </li> 2053 2119 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 2054 <li><em>UDELCOMPRESSION</em> <a href="#rfc.xref.UDELCOMPRESSION.1"> 2.6.10.1</a>, <a href="#UDELCOMPRESSION"><b>9</b></a></li>2120 <li><em>UDELCOMPRESSION</em> <a href="#rfc.xref.UDELCOMPRESSION.1">3.6.10.1</a>, <a href="#UDELCOMPRESSION"><b>10</b></a></li> 2055 2121 </ul> 2056 2122 </li> -
draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.xml
r2124 r2125 65 65 <abstract> 66 66 <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. 73 75 </t> 74 76 </abstract> … … 103 105 104 106 <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> 120 143 121 144 <section title="Document Organization"> 122 <t>The HTTP/2.0 Specification is split into t wo 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> 123 146 </section> 124 147 <section title="Definitions"> … … 137 160 </t> 138 161 </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 "http:" 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> 214 For 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 "https:" URIs"> 253 <t> 254 [[TBD, maybe NPN]] 255 </t> 256 </section> 257 139 258 </section> 140 259 … … 1261 1380 </reference> 1262 1381 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 1274 1382 <reference anchor="RFC2616"> 1275 1383 <front> … … 1341 1449 </front> 1342 1450 <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"/>1356 1451 </reference> 1357 1452 … … 1411 1506 <date/> 1412 1507 </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' /> 1413 1520 </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> 1415 1534 1416 1535 <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> … … 1425 1544 <t> 1426 1545 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. 1427 1555 </t> 1428 1556 </section>
Note: See TracChangeset
for help on using the changeset viewer.