rfc9110.txt		rfc9110-to-be.txt
	skipping to change at line 4120 ¶		skipping to change at line 4120 ¶
	For example, if the target resource is configured to always have a		For example, if the target resource is configured to always have a
	Content-Type of "text/html" and the representation being PUT has a		Content-Type of "text/html" and the representation being PUT has a
	Content-Type of "image/jpeg", the origin server ought to do one of:		Content-Type of "image/jpeg", the origin server ought to do one of:
	a. reconfigure the target resource to reflect the new media type;		a. reconfigure the target resource to reflect the new media type;
	b. transform the PUT representation to a format consistent with that		b. transform the PUT representation to a format consistent with that
	of the resource before saving it as the new resource state; or,		of the resource before saving it as the new resource state; or,
	c. reject the request with a 415 (Unsupported Media Type) response		c. reject the request with a 415 (Unsupported Media Type) response
	indicating that the target resource is limited to text/html,		indicating that the target resource is limited to "text/html",
	perhaps including a link to a different resource that would be a		perhaps including a link to a different resource that would be a
	suitable target for the new representation.		suitable target for the new representation.
	HTTP does not define exactly how a PUT method affects the state of an		HTTP does not define exactly how a PUT method affects the state of an
	origin server beyond what can be expressed by the intent of the user		origin server beyond what can be expressed by the intent of the user
	agent request and the semantics of the origin server response. It		agent request and the semantics of the origin server response. It
	does not define what a resource might be, in any sense of that word,		does not define what a resource might be, in any sense of that word,
	beyond the interface provided via HTTP. It does not define how		beyond the interface provided via HTTP. It does not define how
	resource state is "stored", nor how such storage might change as a		resource state is "stored", nor how such storage might change as a
	result of a change in resource state, nor how the origin server		result of a change in resource state, nor how the origin server
	skipping to change at line 6688 ¶		skipping to change at line 6688 ¶
	Implementation Notes:		Implementation Notes:
	1. Additional CRLFs might precede the first boundary string in the		1. Additional CRLFs might precede the first boundary string in the
	body.		body.
	2. Although [RFC2046] permits the boundary string to be quoted, some		2. Although [RFC2046] permits the boundary string to be quoted, some
	existing implementations handle a quoted boundary string		existing implementations handle a quoted boundary string
	incorrectly.		incorrectly.
	3. A number of clients and servers were coded to an early draft of		3. A number of clients and servers were coded to an early draft of
	the byteranges specification that used a media type of		the byteranges specification that used a media type of multipart/
	"multipart/x-byteranges", which is almost (but not quite)		x-byteranges, which is almost (but not quite) compatible with
	compatible with this type.		this type.
	Despite the name, the multipart/byteranges media type is not limited		Despite the name, the "multipart/byteranges" media type is not
	to byte ranges. The following example uses an "exampleunit" range		limited to byte ranges. The following example uses an "exampleunit"
	unit:		range unit:
	HTTP/1.1 206 Partial Content		HTTP/1.1 206 Partial Content
	Date: Tue, 14 Nov 1995 06:25:24 GMT		Date: Tue, 14 Nov 1995 06:25:24 GMT
	Last-Modified: Tue, 14 July 04:58:08 GMT		Last-Modified: Tue, 14 July 04:58:08 GMT
	Content-Length: 2331785		Content-Length: 2331785
	Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES		Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
	--THIS_STRING_SEPARATES		--THIS_STRING_SEPARATES
	Content-Type: video/example		Content-Type: video/example
	Content-Range: exampleunit 1.2-4.3/25		Content-Range: exampleunit 1.2-4.3/25
	skipping to change at line 7096 ¶		skipping to change at line 7096 ¶
	Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT		Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
	Content-Range: bytes 21010-47021/47022		Content-Range: bytes 21010-47021/47022
	Content-Length: 26012		Content-Length: 26012
	Content-Type: image/gif		Content-Type: image/gif
	... 26012 bytes of partial image data ...		... 26012 bytes of partial image data ...
	15.3.7.2. Multiple Parts		15.3.7.2. Multiple Parts
	If multiple parts are being transferred, the server generating the		If multiple parts are being transferred, the server generating the
	206 response MUST generate multipart/byteranges content, as defined		206 response MUST generate "multipart/byteranges" content, as defined
	in Section 14.6, and a Content-Type header field containing the		in Section 14.6, and a Content-Type header field containing the
	multipart/byteranges media type and its required boundary parameter.		multipart/byteranges media type and its required boundary parameter.
	To avoid confusion with single-part responses, a server MUST NOT		To avoid confusion with single-part responses, a server MUST NOT
	generate a Content-Range header field in the HTTP header section of a		generate a Content-Range header field in the HTTP header section of a
	multiple part response (this field will be sent in each part		multiple part response (this field will be sent in each part
	instead).		instead).
	Within the header area of each body part in the multipart content,		Within the header area of each body part in the multipart content,
	the server MUST generate a Content-Range header field corresponding		the server MUST generate a Content-Range header field corresponding
	to the range being enclosed in that body part. If the selected		to the range being enclosed in that body part. If the selected
	skipping to change at line 9102 ¶		skipping to change at line 9102 ¶
	This specification updates the HTTP-related aspects of the existing		This specification updates the HTTP-related aspects of the existing
	registration procedures for message header fields defined in		registration procedures for message header fields defined in
	[RFC3864]. It replaces the old procedures as they relate to HTTP by		[RFC3864]. It replaces the old procedures as they relate to HTTP by
	defining a new registration procedure and moving HTTP field		defining a new registration procedure and moving HTTP field
	definitions into a separate registry.		definitions into a separate registry.
	IANA has created a new registry titled "Hypertext Transfer Protocol		IANA has created a new registry titled "Hypertext Transfer Protocol
	(HTTP) Field Name Registry" as outlined in Section 16.3.1.		(HTTP) Field Name Registry" as outlined in Section 16.3.1.
	IANA has moved all entries in the "Permanent Message Header Field		IANA has moved all entries in the "Permanent Message Header Field
	Names" and "Provisional Message Header Field Names" registries with		Names" and "Provisional Message Header Field Names" registries (see
	the protocol 'http' to this registry and has applied the following		<https://www.iana.org/assignments/message-headers/>) with the
			protocol 'http' to this registry and has applied the following
	changes:		changes:
	1. The 'Applicable Protocol' field has been omitted.		1. The 'Applicable Protocol' field has been omitted.
	2. Entries that had a status of 'standard', 'experimental',		2. Entries that had a status of 'standard', 'experimental',
	'reserved', or 'informational' have been made to have a status of		'reserved', or 'informational' have been made to have a status of
	'permanent'.		'permanent'.
	3. Provisional entries without a status have been made to have a		3. Provisional entries without a status have been made to have a
	status of 'provisional'.		status of 'provisional'.
	skipping to change at line 9126 ¶		skipping to change at line 9127 ¶
	registration document did not define one) have been made to have		registration document did not define one) have been made to have
	a status of 'provisional'. The expert(s) can choose to update		a status of 'provisional'. The expert(s) can choose to update
	the entries' status if there is evidence that another is more		the entries' status if there is evidence that another is more
	appropriate.		appropriate.
	IANA has annotated the "Permanent Message Header Field Names" and		IANA has annotated the "Permanent Message Header Field Names" and
	"Provisional Message Header Field Names" registries with the		"Provisional Message Header Field Names" registries with the
	following note to indicate that HTTP field name registrations have		following note to indicate that HTTP field name registrations have
	moved:		moved:
	| *Note* HTTP field name registrations have been moved to		| *Note*
			|
			| HTTP field name registrations have been moved to
	| [https://www.iana.org/assignments/http-fields] per [RFC9110].		| [https://www.iana.org/assignments/http-fields] per [RFC9110].
	IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name		IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name
	Registry" with the field names listed in the following table.		Registry" with the field names listed in the following table.
	+===========================+============+========+============+		+===========================+============+========+============+
	| Field Name | Status | Ref. | Comments |		| Field Name | Status | Ref. | Comments |
	+===========================+============+========+============+		+===========================+============+========+============+
	| Accept | permanent | 12.5.1 | |		| Accept | permanent | 12.5.1 | |
	+---------------------------+------------+--------+------------+		+---------------------------+------------+--------+------------+
	skipping to change at line 9247 ¶		skipping to change at line 9250 ¶
	http-authschemes> with the registration procedure of Section 16.4.1.		http-authschemes> with the registration procedure of Section 16.4.1.
	No authentication schemes are defined in this document.		No authentication schemes are defined in this document.
	18.6. Content Coding Registration		18.6. Content Coding Registration
	IANA has updated the "HTTP Content Coding Registry" at		IANA has updated the "HTTP Content Coding Registry" at
	<https://www.iana.org/assignments/http-parameters/> with the		<https://www.iana.org/assignments/http-parameters/> with the
	registration procedure of Section 16.6.1 and the content coding names		registration procedure of Section 16.6.1 and the content coding names
	summarized in the table below.		summarized in the table below.
	+============+===========================================+=========+		+============+=========================================+=========+
	| Name | Description | Ref. |		| Name | Description | Ref. |
	+============+===========================================+=========+		+============+=========================================+=========+
	| compress | UNIX "compress" data format [Welch] | 8.4.1.1 |		| compress | UNIX "compress" data format [Welch] | 8.4.1.1 |
	+------------+-------------------------------------------+---------+		+------------+-----------------------------------------+---------+
	| deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2 |		| deflate | "deflate" compressed data [RFC1951] | 8.4.1.2 |
	| | inside the "zlib" data format ([RFC1950]) | |		| | inside the "zlib" data format [RFC1950] | |
	+------------+-------------------------------------------+---------+		+------------+-----------------------------------------+---------+
	| gzip | GZIP file format [RFC1952] | 8.4.1.3 |		| gzip | GZIP file format [RFC1952] | 8.4.1.3 |
	+------------+-------------------------------------------+---------+		+------------+-----------------------------------------+---------+
	| identity | Reserved | 12.5.3 |		| identity | Reserved | 12.5.3 |
	+------------+-------------------------------------------+---------+		+------------+-----------------------------------------+---------+
	| x-compress | Deprecated (alias for compress) | 8.4.1.1 |		| x-compress | Deprecated (alias for compress) | 8.4.1.1 |
	+------------+-------------------------------------------+---------+		+------------+-----------------------------------------+---------+
	| x-gzip | Deprecated (alias for gzip) | 8.4.1.3 |		| x-gzip | Deprecated (alias for gzip) | 8.4.1.3 |
	+------------+-------------------------------------------+---------+		+------------+-----------------------------------------+---------+
	Table 10		Table 10
	18.7. Range Unit Registration		18.7. Range Unit Registration
	IANA has updated the "HTTP Range Unit Registry" at		IANA has updated the "HTTP Range Unit Registry" at
	<https://www.iana.org/assignments/http-parameters/> with the		<https://www.iana.org/assignments/http-parameters/> with the
	registration procedure of Section 16.5.1 and the range unit names		registration procedure of Section 16.5.1 and the range unit names
	summarized in the table below.		summarized in the table below.
	+=================+==================================+========+		+=================+==================================+========+
	| Range Unit Name | Description | Ref. |		| Range Unit Name | Description | Ref. |
	skipping to change at line 9540 ¶		skipping to change at line 9543 ¶
	[RFC2145] Mogul, J. C., Fielding, R., Gettys, J., and H. Frystyk,		[RFC2145] Mogul, J. C., Fielding, R., Gettys, J., and H. Frystyk,
	"Use and Interpretation of HTTP Version Numbers",		"Use and Interpretation of HTTP Version Numbers",
	RFC 2145, DOI 10.17487/RFC2145, May 1997,		RFC 2145, DOI 10.17487/RFC2145, May 1997,
	<https://www.rfc-editor.org/info/rfc2145>.		<https://www.rfc-editor.org/info/rfc2145>.
	[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation		[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
	in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,		in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
	<https://www.rfc-editor.org/info/rfc2295>.		<https://www.rfc-editor.org/info/rfc2295>.
	[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol		[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
	(HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, 1 April		(HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1998,
	1998, <https://www.rfc-editor.org/info/rfc2324>.		<https://www.rfc-editor.org/info/rfc2324>.
	[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME		[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
	Encapsulation of Aggregate Documents, such as HTML		Encapsulation of Aggregate Documents, such as HTML
	(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,		(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
	<https://www.rfc-editor.org/info/rfc2557>.		<https://www.rfc-editor.org/info/rfc2557>.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616,		Transfer Protocol -- HTTP/1.1", RFC 2616,
	DOI 10.17487/RFC2616, June 1999,		DOI 10.17487/RFC2616, June 1999,
	skipping to change at line 10034 ¶		skipping to change at line 10037 ¶
	The fact that request bodies on GET, HEAD, and DELETE are not		The fact that request bodies on GET, HEAD, and DELETE are not
	interoperable has been clarified (Sections 9.3.1, 9.3.2, and 9.3.5).		interoperable has been clarified (Sections 9.3.1, 9.3.2, and 9.3.5).
	The use of the Content-Range header field (Section 14.4) as a request		The use of the Content-Range header field (Section 14.4) as a request
	modifier on PUT is allowed (Section 9.3.4).		modifier on PUT is allowed (Section 9.3.4).
	A superfluous requirement about setting Content-Length has been		A superfluous requirement about setting Content-Length has been
	removed from the description of the OPTIONS method (Section 9.3.7).		removed from the description of the OPTIONS method (Section 9.3.7).
	The normative requirement to use the message/http media type in TRACE		The normative requirement to use the "message/http" media type in
	responses has been removed (Section 9.3.8).		TRACE responses has been removed (Section 9.3.8).
	List-based grammar for Expect has been restored for compatibility		List-based grammar for Expect has been restored for compatibility
	with RFC 2616 (Section 10.1.1).		with RFC 2616 (Section 10.1.1).
	Accept and Accept-Encoding are allowed in response messages; the		Accept and Accept-Encoding are allowed in response messages; the
	latter was introduced by [RFC7694] (Section 12.3).		latter was introduced by [RFC7694] (Section 12.3).
	"Accept Parameters" (accept-params and accept-ext ABNF production)		"Accept Parameters" (accept-params and accept-ext ABNF production)
	have been removed from the definition of the Accept field		have been removed from the definition of the Accept field
	(Section 12.5.1).		(Section 12.5.1).
End of changes. 10 change blocks.
	32 lines changed or deleted		35 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/