draft-ietf-httpbis-http2bis-05.txt   draft-ietf-httpbis-http2bis-latest.txt 
HTTPbis Working Group M. Thomson, Ed. HTTPbis Working Group M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Obsoletes: 7540, 8740 (if approved) C. Benfield, Ed. Obsoletes: 7540, 8740 (if approved) C. Benfield, Ed.
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: March 30, 2022 September 26, 2021 Expires: April 5, 2022 October 2, 2021
Hypertext Transfer Protocol Version 2 (HTTP/2) Hypertext Transfer Protocol Version 2 (HTTP/2)
draft-ietf-httpbis-http2bis-05 draft-ietf-httpbis-http2bis-latest
Abstract Abstract
This specification describes an optimized expression of the semantics This specification describes an optimized expression of the semantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
version 2 (HTTP/2). HTTP/2 enables a more efficient use of network version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
resources and a reduced latency by introducing field compression and resources and a reduced latency by introducing field compression and
allowing multiple concurrent exchanges on the same connection. allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFC 7540 and RFC 8740. This document obsoletes RFC 7540 and RFC 8740.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2022. This Internet-Draft will expire on April 5, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 6, line 43 skipping to change at page 6, line 43
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
All numeric values are in network byte order. Values are unsigned All numeric values are in network byte order. Values are unsigned
unless otherwise indicated. Literal values are provided in decimal unless otherwise indicated. Literal values are provided in decimal
or hexadecimal as appropriate. Hexadecimal literals are prefixed or hexadecimal as appropriate. Hexadecimal literals are prefixed
with 0x to distinguish them from decimal literals. with "0x" to distinguish them from decimal literals.
This specification describes binary formats using the convention This specification describes binary formats using the convention
described in RFC 9000 [QUIC]. Note that this format uses network described in RFC 9000 [QUIC]. Note that this format uses network
byte order and high-valued bits are listed before low-valued bits. byte order and high-valued bits are listed before low-valued bits.
The following terms are used: The following terms are used:
client: The endpoint that initiates an HTTP/2 connection. Clients client: The endpoint that initiates an HTTP/2 connection. Clients
send HTTP requests and receive HTTP responses. send HTTP requests and receive HTTP responses.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
In HTTP/2, each endpoint is required to send a connection preface as In HTTP/2, each endpoint is required to send a connection preface as
a final confirmation of the protocol in use and to establish the a final confirmation of the protocol in use and to establish the
initial settings for the HTTP/2 connection. The client and server initial settings for the HTTP/2 connection. The client and server
each send a different connection preface. each send a different connection preface.
The client connection preface starts with a sequence of 24 octets, The client connection preface starts with a sequence of 24 octets,
which in hex notation is: which in hex notation is:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
That is, the connection preface starts with the string PRI * That is, the connection preface starts with the string "PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n. This sequence MUST be followed by a HTTP/2.0\r\n\r\nSM\r\n\r\n". This sequence MUST be followed by a
SETTINGS frame (Section 6.5), which MAY be empty. The client sends SETTINGS frame (Section 6.5), which MAY be empty. The client sends
the client connection preface as the first application data octets of the client connection preface as the first application data octets of
a connection. a connection.
| Note: The client connection preface is selected so that a large | Note: The client connection preface is selected so that a large
| proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries | proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries
| do not attempt to process further frames. Note that this does | do not attempt to process further frames. Note that this does
| not address the concerns raised in [TALKING]. | not address the concerns raised in [TALKING].
The server connection preface consists of a potentially empty The server connection preface consists of a potentially empty
 End of changes. 5 change blocks. 
6 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/