draft-ietf-httpbis-binary-message-03.txt   draft-ietf-httpbis-binary-message-latest.txt 
HTTP Working Group M. Thomson HTTP Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track C. Wood Intended status: Standards Track C. Wood
Expires: November 11, 2022 Cloudflare Expires: November 13, 2022 Cloudflare
May 10, 2022 May 12, 2022
Binary Representation of HTTP Messages Binary Representation of HTTP Messages
draft-ietf-httpbis-binary-message-03 draft-ietf-httpbis-binary-message-latest
Abstract Abstract
This document defines a binary format for representing HTTP messages. This document defines a binary format for representing HTTP messages.
About This Document About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Status information for this document may be found at Status information for this document may be found at
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 November 11, 2022. This Internet-Draft will expire on November 13, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 14, line 41 skipping to change at page 14, line 41
o carrying reason phrases in responses (Section 4 of [MESSAGING]) o carrying reason phrases in responses (Section 4 of [MESSAGING])
o header compression ([HPACK], [QPACK]) o header compression ([HPACK], [QPACK])
o framing of responses that depends on the corresponding request o framing of responses that depends on the corresponding request
(such as HEAD) or the value of the status code (such as 204 or (such as HEAD) or the value of the status code (such as 204 or
304); these responses use the same framing as all other messages 304); these responses use the same framing as all other messages
Some of these features are also absent in HTTP/2 and HTTP/3. Some of these features are also absent in HTTP/2 and HTTP/3.
Unlike HTTP/2 and HTTP/3, this format uses a a fixed format for Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control
control data rather than using pseudo-fields. Messages are invalid data rather than using pseudo-fields. Messages are invalid
(Section 4) if they contain fields named ":method", ":scheme", (Section 4) if they contain fields named ":method", ":scheme",
":authority", ":path", or ":status". Other pseudo-fields that are ":authority", ":path", or ":status". Other pseudo-fields that are
defined by protocol extensions MAY be included; pseudo-fields cannot defined by protocol extensions MAY be included; pseudo-fields cannot
be included in trailers (see Section 8.1 of [H2]). Field lines be included in trailers (see Section 8.1 of [H2]). Field lines
containing pseudo-fields MUST precede other field lines. A message containing pseudo-fields MUST precede other field lines. A message
that contains a pseudo-field after any other field is invalid; see that contains a pseudo-field after any other field is invalid; see
Section 4. Section 4.
Note that while some messages - CONNECT or upgrade requests in Note that while some messages - CONNECT or upgrade requests in
particular - can be represented using this format, doing so serves no particular - can be represented using this format, doing so serves no
 End of changes. 4 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/