Diff: rfc9113v2.txt - rfc9113.txt

	rfc9113v2.txt	rfc9113.txt

	Internet Engineering Task Force (IETF) M. Thomson, Ed.	Internet Engineering Task Force (IETF) M. Thomson, Ed.
	Request for Comments: 9113 Mozilla	Request for Comments: 9113 Mozilla
	Obsoletes: 7540, 8740 C. Benfield, Ed.	Obsoletes: 7540, 8740 C. Benfield, Ed.
	Category: Standards Track Apple Inc.	Category: Standards Track Apple Inc.

	ISSN: 2070-1721 March 2022	ISSN: 2070-1721 June 2022

	HTTP/2	HTTP/2

	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.

	skipping to change at line 2762 ¶	skipping to change at line 2762 ¶
	Promised requests MUST be safe (see Section 9.2.1 of [HTTP]) and	Promised requests MUST be safe (see Section 9.2.1 of [HTTP]) and
	cacheable (see Section 9.2.3 of [HTTP]). Promised requests cannot	cacheable (see Section 9.2.3 of [HTTP]). Promised requests cannot
	include any content or a trailer section. Clients that receive a	include any content or a trailer section. Clients that receive a
	promised request that is not cacheable, that is not known to be safe,	promised request that is not cacheable, that is not known to be safe,
	or that indicates the presence of request content MUST reset the	or that indicates the presence of request content MUST reset the
	promised stream with a stream error (Section 5.4.2) of type	promised stream with a stream error (Section 5.4.2) of type
	PROTOCOL_ERROR. Note that this could result in the promised stream	PROTOCOL_ERROR. Note that this could result in the promised stream
	being reset if the client does not recognize a newly defined method	being reset if the client does not recognize a newly defined method
	as being safe.	as being safe.


	Pushed responses that are cacheable (see Section 3 of [CACHE]) can be	Pushed responses that are cacheable (see Section 3 of [CACHING]) can
	stored by the client, if it implements an HTTP cache. Pushed	be stored by the client, if it implements an HTTP cache. Pushed
	responses are considered successfully validated on the origin server	responses are considered successfully validated on the origin server
	(e.g., if the "no-cache" cache response directive is present; see	(e.g., if the "no-cache" cache response directive is present; see

	Section 5.2.2.4 of [CACHE]) while the stream identified by the	Section 5.2.2.4 of [CACHING]) while the stream identified by the
	promised stream identifier is still open.	promised stream identifier is still open.

	Pushed responses that are not cacheable MUST NOT be stored by any	Pushed responses that are not cacheable MUST NOT be stored by any
	HTTP cache. They MAY be made available to the application	HTTP cache. They MAY be made available to the application
	separately.	separately.

	The server MUST include a value in the ":authority" pseudo-header	The server MUST include a value in the ":authority" pseudo-header
	field for which the server is authoritative (see Section 10.1). A	field for which the server is authoritative (see Section 10.1). A
	client MUST treat a PUSH_PROMISE for which the server is not	client MUST treat a PUSH_PROMISE for which the server is not
	authoritative as a stream error (Section 5.4.2) of type	authoritative as a stream error (Section 5.4.2) of type

	skipping to change at line 3665 ¶	skipping to change at line 3665 ¶
	(HTTP/2)	(HTTP/2)

	Expected Version Tokens: None	Expected Version Tokens: None

	Reference: Section 3.1 of this document	Reference: Section 3.1 of this document

	12. References	12. References

	12.1. Normative References	12.1. Normative References


	[CACHE] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,	[CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Caching", RFC 9111, DOI 10.17487/RFC9111, March	Ed., "HTTP Caching", STD 98, RFC 9111,
	2022, <https://www.rfc-editor.org/info/rfc9111>.	DOI 10.17487/RFC9111, June 2022,
		<https://www.rfc-editor.org/info/rfc9111>.

	[COMPRESSION]	[COMPRESSION]
	Peon, R. and H. Ruellan, "HPACK: Header Compression for	Peon, R. and H. Ruellan, "HPACK: Header Compression for
	HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,	HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
	<https://www.rfc-editor.org/info/rfc7541>.	<https://www.rfc-editor.org/info/rfc7541>.

	[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,	[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,	DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.	<https://www.rfc-editor.org/info/rfc6265>.

	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,

	Ed., "HTTP Semantics", RFC 9110, DOI 10.17487/RFC9110,	Ed., "HTTP Semantics", STD 97, RFC 9110,
	March 2022, <https://www.rfc-editor.org/info/rfc9110>.	DOI 10.17487/RFC9110, June 2022,
		<https://www.rfc-editor.org/info/rfc9110>.

	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,	Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,	DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.	<https://www.rfc-editor.org/info/rfc9000>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	skipping to change at line 3764 ¶	skipping to change at line 3766 ¶
	<https://breachattack.com/resources/	<https://breachattack.com/resources/
	BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.	BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.

	[DNS-TERMS]	[DNS-TERMS]
	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.	January 2019, <https://www.rfc-editor.org/info/rfc8499>.

	[HTTP-PRIORITY]	[HTTP-PRIORITY]
	Oku, K. and L. Pardue, "Extensible Prioritization Scheme	Oku, K. and L. Pardue, "Extensible Prioritization Scheme

	for HTTP", RFC 9218, DOI 10.17487/RFC9218, March 2022,	for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022,
	<https://www.rfc-editor.org/info/rfc9218>.	<https://www.rfc-editor.org/info/rfc9218>.


	[HTTP/1.1] Fielding, R. T., Ed., Nottingham, M., Ed., and J. Reschke,	[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP/1.1", RFC 9112, DOI 10.17487/RFC9112, March	Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
	2022, <https://www.rfc-editor.org/info/rfc9112>.	June 2022, <https://www.rfc-editor.org/info/rfc9112>.

	[NFLX-2019-002]	[NFLX-2019-002]
	Netflix, "HTTP/2 Denial of Service Advisory", 13 August	Netflix, "HTTP/2 Denial of Service Advisory", 13 August
	2019, <https://github.com/Netflix/security-	2019, <https://github.com/Netflix/security-
	bulletins/blob/master/advisories/third-party/2019-002.md>.	bulletins/blob/master/advisories/third-party/2019-002.md>.

	[PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,	[PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy	Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973,	Considerations for Internet Protocols", RFC 6973,
	DOI 10.17487/RFC6973, July 2013,	DOI 10.17487/RFC6973, July 2013,

End of changes. 7 change blocks.
	13 lines changed or deleted	15 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/