rfc9110v1.xml   rfc9110.xml 
skipping to change at line 116 skipping to change at line 116
<abstract> <abstract>
<t> <t>
The Hypertext Transfer Protocol (HTTP) is a stateless application-l evel The Hypertext Transfer Protocol (HTTP) is a stateless application-l evel
protocol for distributed, collaborative, hypertext information syst ems. protocol for distributed, collaborative, hypertext information syst ems.
This document describes the overall architecture of HTTP, establish es common This document describes the overall architecture of HTTP, establish es common
terminology, and defines aspects of the protocol that are shared by all terminology, and defines aspects of the protocol that are shared by all
versions. In this definition are core protocol elements, extensibil ity versions. In this definition are core protocol elements, extensibil ity
mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) mechanisms, and the "http" and "https" Uniform Resource Identifier (URI)
schemes. schemes.
</t> </t>
<!--[rfced] *AD - We note that the Abstract states that this document
updates "portions" of RFC 7230. Section 1.4 mentions that
[HTTP/1.1] obsoletes the other parts of RFC 7230. However, the
header of the document indicates that RFC 7230 is obsoleted by
this document. Please review.-->
<t> <t>
This document updates RFC 3864 and This document updates RFC 3864 and
obsoletes RFCs 2818, 7231, 7232, 7233, obsoletes RFCs 2818, 7231, 7232, 7233,
7235, 7538, 7615, 7694, and portions of 7230. 7235, 7538, 7615, 7694, and portions of 7230.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" title="Introduction">
skipping to change at line 3239 skipping to change at line 3233
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> modify the "absolute-path" and "que ry" parts of the A proxy <bcp14>MUST NOT</bcp14> modify the "absolute-path" and "que ry" parts of the
received target URI when forwarding it to the next inbound server e xcept received target URI when forwarding it to the next inbound server e xcept
as required by that forwarding protocol. For example, a proxy forwa rding as required by that forwarding protocol. For example, a proxy forwa rding
a request to an origin server via HTTP/1.1 will replace an empty pa th with a request to an origin server via HTTP/1.1 will replace an empty pa th with
"/" (<xref target="RFC9112" section="3.2.1"/>) or "*" (<xref target ="RFC9112" section="3.2.4"/>), "/" (<xref target="RFC9112" section="3.2.1"/>) or "*" (<xref target ="RFC9112" section="3.2.4"/>),
depending on the request method. depending on the request method.
</t> </t>
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> transform the content (<xref target ="content"/>) of a message that A proxy <bcp14>MUST NOT</bcp14> transform the content (<xref target ="content"/>) of a message that
contains a no-transform Cache-Control response directive (<xref tar get="RFC9111" section="5.2"/>). contains a "no-transform" Cache-Control response directive (<xref t arget="RFC9111" section="5.2"/>).
Note that this does not include changes to the message body that do not affect Note that this does not include changes to the message body that do not affect
the content, such as transfer codings (<xref target="RFC9112" secti on="7"/>). the content, such as transfer codings (<xref target="RFC9112" secti on="7"/>).
</t> </t>
<t> <t>
A proxy <bcp14>MAY</bcp14> transform the content of a message A proxy <bcp14>MAY</bcp14> transform the content of a message
that does not contain a no-transform Cache-Control directive. that does not contain a no-transform Cache-Control directive.
A proxy that transforms the content of a <xref target="status.200" format="none">200 (OK)</xref> response A proxy that transforms the content of a <xref target="status.200" format="none">200 (OK)</xref> response
can inform downstream recipients that a transformation has been can inform downstream recipients that a transformation has been
applied by changing the response status code to applied by changing the response status code to
<xref target="status.203" format="none">203 (Non-Authoritative Info rmation)</xref> (<xref target="status.203"/>). <xref target="status.203" format="none">203 (Non-Authoritative Info rmation)</xref> (<xref target="status.203"/>).
skipping to change at line 4922 skipping to change at line 4916
<t> <t>
For example, if the target resource is configured to always have a For example, if the target resource is configured to always have a
<xref target="field.content-type" format="none">Content-Type</xref> of "text/html" and the representation being PUT <xref target="field.content-type" format="none">Content-Type</xref> of "text/html" and the representation being PUT
has a Content-Type of "image/jpeg", the origin server ought to do o ne of: has a Content-Type of "image/jpeg", the origin server ought to do o ne of:
</t> </t>
<ol type="a"> <ol type="a">
<li>reconfigure the target resource to reflect the n ew media type;</li> <li>reconfigure the target resource to reflect the n ew media type;</li>
<li>transform the PUT representation to a format con sistent with that <li>transform the PUT representation to a format con sistent with that
of the resource before saving it as the new resource state; or, </li> of the resource before saving it as the new resource state; or, </li>
<li>reject the request with a <xref target="status.4 15" format="none">415 (Unsupported Media Type)</xref> <li>reject the request with a <xref target="status.4 15" format="none">415 (Unsupported Media Type)</xref>
response indicating that the target resource is limited to "tex t/html", response 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.</li> suitable target for the new representation.</li>
</ol> </ol>
<t> <t>
HTTP does not define exactly how a PUT method affects the state 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 of an origin server beyond what can be expressed by the intent of
the user agent request and the semantics of the origin server respo nse. the user agent request and the semantics of the origin server respo nse.
It does not define what a resource might be, in any sense of that It does not define what a resource might be, in any sense of that
word, beyond the interface provided via HTTP. It does not define word, beyond the interface provided via HTTP. It does not define
how resource state is "stored", nor how such storage might change how resource state is "stored", nor how such storage might change
skipping to change at line 8230 skipping to change at line 8224
<t> <t>
Implementation Notes: Implementation Notes:
</t> </t>
<ol> <ol>
<li>Additional CRLFs might precede the first boundary s tring in the body.</li> <li>Additional CRLFs might precede the first boundary s tring in the body.</li>
<li>Although <xref target="RFC2046"/> permits the bound ary string to be <li>Although <xref target="RFC2046"/> permits the bound ary string to be
quoted, some existing implementations handle a quoted boundary quoted, some existing implementations handle a quoted boundary
string incorrectly.</li> string incorrectly.</li>
<li>A number of clients and servers were coded to an ea rly draft <li>A number of clients and servers were coded to an ea rly draft
of the byteranges specification that used a media type of of the byteranges specification that used a media type of
multipart/x-byteranges<iref item="multipart/x-byteranges Media T ype"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, "multipart/x-byteranges"<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>,
which is almost (but not quite) compatible with this type.</li> which is almost (but not quite) compatible with this type.</li>
</ol> </ol>
<t> <t>
Despite the name, the "multipart/byteranges" media type is not limi ted to Despite the name, the multipart/byteranges media type is not limite d to
byte ranges. The following example uses an "exampleunit" range unit : byte ranges. The following example uses an "exampleunit" range unit :
</t> </t>
<sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Part ial Content <sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Part ial 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
skipping to change at line 8754 skipping to change at line 8748
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 ...
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="partial.multipart" title="Multiple Par ts"> <section anchor="partial.multipart" title="Multiple Par ts">
<t> <t>
If multiple parts are being transferred, the server generating the 206 If multiple parts are being transferred, the server generating the 206
response <bcp14>MUST</bcp14> generate "multipart/byteranges" conten t, as defined response <bcp14>MUST</bcp14> generate multipart/byteranges content, as defined
in <xref target="multipart.byteranges"/>, and a in <xref target="multipart.byteranges"/>, and a
<xref target="field.content-type" format="none">Content-Type</xref> header field containing the <xref target="field.content-type" format="none">Content-Type</xref> 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 <bcp14>MUST NOT</bcp14> generate To avoid confusion with single-part responses, a server <bcp14>MUST NOT</bcp14> generate
a <xref target="field.content-range" format="none">Content-Range</x ref> header field in the HTTP header section of a a <xref target="field.content-range" format="none">Content-Range</x ref> header field in the HTTP header section of a
multiple part response (this field will be sent in each part instea d). multiple part response (this field will be sent in each part instea d).
</t> </t>
<t> <t>
Within the header area of each body part in the multipart content, the Within the header area of each body part in the multipart content, the
server <bcp14>MUST</bcp14> generate a <xref target="field.content-r ange" format="none">Content-Range</xref> header field server <bcp14>MUST</bcp14> generate a <xref target="field.content-r ange" format="none">Content-Range</xref> header field
skipping to change at line 9981 skipping to change at line 9975
which it occurs has explicit freshness information; however, which it occurs has explicit freshness information; however,
a status code defined as heuristically cacheable is allowed to a status code defined as heuristically cacheable is allowed to
be cached without explicit freshness information. be cached without explicit freshness information.
--> -->
<t> <t>
The definition of a new final status code ought to specify whether or not it is The definition of a new final status code ought to specify whether or not it is
heuristically cacheable. Note that all final status codes can be ca ched if the response they heuristically cacheable. Note that all final status codes can be ca ched if the response they
occur in has explicit freshness information; however, those status codes that are occur in has explicit freshness information; however, those status codes that are
defined as being heuristically cacheable are allowed to be cached w ithout explicit defined as being heuristically cacheable are allowed to be cached w ithout explicit
freshness information. Likewise, the definition of a status code ca n place freshness information. Likewise, the definition of a status code ca n place
constraints upon cache behavior if the 'must-understand' cache dire ctive is used. See <xref target="RFC9111"/> for more information. constraints upon cache behavior if the "must-understand" cache dire ctive is used. See <xref target="RFC9111"/> for more information.
</t> </t>
<t> <t>
Finally, the definition of a new status code ought to indicate whet her the Finally, the definition of a new status code ought to indicate whet her the
content has any implied association with an identified resource (<x ref target="identifying.content"/>). content has any implied association with an identified resource (<x ref target="identifying.content"/>).
</t> </t>
</section> </section>
</section> </section>
<section anchor="fields.extensibility" title="Field Extensibi lity"> <section anchor="fields.extensibility" title="Field Extensibi lity">
<t> <t>
HTTP's most widely used extensibility point is the definition of new header and HTTP's most widely used extensibility point is the definition of new header and
skipping to change at line 10046 skipping to change at line 10040
Registration requests consist of the following information: Registration requests consist of the following information:
</t> </t>
<dl newline="true"> <dl newline="true">
<dt>Field name:</dt> <dt>Field name:</dt>
<dd> <dd>
The requested field name. It <bcp14>MUST</bcp14> conform to the The requested field name. It <bcp14>MUST</bcp14> conform to the
field-name syntax defined in <xref target="fields.names"/>, and it <bcp14>SHOULD</bcp14> be field-name syntax defined in <xref target="fields.names"/>, and it <bcp14>SHOULD</bcp14> be
restricted to just letters, digits, and hyphen ('-') restricted to just letters, digits, and hyphen ('-')
characters, with the first character being a letter. characters, with the first character being a letter.
</dd> </dd>
<!-- [rfced] [AD] Section 16.3.1. FYI We have updated the
registration template for field names with the following based on
IANA's discussion with the authors. *AD, please review and let us
know if you approve.
Original:
Status:
"permanent" or "provisional".
Current:
Status:
"permanent", "provisional", "deprecated", or "obsoleted".
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>
"permanent", "provisional", "deprecated", or "obsoleted". "permanent", "provisional", "deprecated", or "obsoleted".
</dd> </dd>
<dt>Specification document(s):</dt> <dt>Specification document(s):</dt>
<dd> <dd>
Reference to the document that specifies Reference to the document that specifies
the field, preferably including a URI that can be used to retrieve the field, preferably including a URI that can be used to retrieve
a copy of the document. Optional but encouraged for provisional re gistrations. a copy of the document. Optional but encouraged for provisional re gistrations.
An indication of the relevant section(s) can also be included, but is not required. An indication of the relevant section(s) can also be included, but is not required.
skipping to change at line 11510 skipping to change at line 11490
</section> </section>
<section anchor="field.name.registration" title="Field Name R egistration"> <section anchor="field.name.registration" title="Field Name R egistration">
<t> <t>
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 <xref target="RFC3864"/>. registration procedures for message header fields defined in <xref target="RFC3864"/>.
It replaces the old procedures as they relate to HTTP by defining a new It replaces the old procedures as they relate to HTTP by defining a new
registration procedure and moving HTTP field definitions into a sep arate registration procedure and moving HTTP field definitions into a sep arate
registry. registry.
</t> </t>
<t> <t>
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 <xref target="fields.regis (HTTP)
try"/>. Field Name Registry" as outlined in <xref target="fields.registry"/
>.
</t> </t>
<!--[rfced] Might it be helpful to the reader to include links to the <t>
following registries?
Original:
After creating the registry, all entries in the Permanent and
Provisional Message Header Registries with the protocol 'http' are
to
be moved to it, with the following changes applied:
Current:
IANA has moved all entries in the "Permanent Message Header Field
Names" and "Provisional Message Header Field Names" registries with
the protocol 'http' to this registry and has applied the following
changes:
Perhaps:
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 (see Names" and "Provisional Message Header Field Names" registries (see
<https://www.iana.org/assignments/message-headers/>) with the <eref target="https://www.iana.org/assignments/message-headers/"
protocol 'http' to this registry and has applied the following brackets="angle"/>) with the
changes: protocol 'http' to this registry and has applied the following chan
ges:
<t>
IANA has moved all entries in the "Permanent Message Header Field N
ames"
and "Provisional Message Header Field Names"
registries with the protocol 'http' to this registry
and has applied the following changes:
</t> </t>
<!-- [rfced] Section 18.4. The "Hypertext Transfer Protocol (HTTP)
Field Name Registry"
<https://www.iana.org/assignments/http-fields/>, which has been
created by this section, contains a column labeled "Template",
which is not described in this document. Please let us know how
we may update this section to provide information on this column.
<ol> <ol>
<li>The 'Applicable Protocol' field has been omitted.</ li> <li>The 'Applicable Protocol' field has been omitted.</ li>
<li>Entries that had a status of 'standard', 'experimen tal', 'reserved', or <li>Entries that had a status of 'standard', 'experimen tal', 'reserved', or
'informational' have been made to have a status of 'permanent'.</li > 'informational' have been made to have a status of 'permanent'.</li >
<li>Provisional entries without a status have been made to have a status of <li>Provisional entries without a status have been made to have a status of
'provisional'.</li> 'provisional'.</li>
<li>Permanent entries without a status (after confirmat ion that the <li>Permanent entries without a status (after confirmat ion that the
registration document did not define one) have been made to have a status of registration document did not define one) have been made to have a status of
'provisional'. The expert(s) can choose to update the entries' stat us if there is 'provisional'. The expert(s) can choose to update the entries' stat us if there is
evidence that another is more appropriate.</li> evidence that another is more appropriate.</li>
</ol> </ol>
<t> <t>
IANA has annotated the "Permanent Message Header Field Names" and " IANA has annotated the "Permanent Message Header Field
Provisional Message Header Field Names" registries Names" and "Provisional Message Header Field Names" registries with
with the following note to the
indicate that HTTP field name registrations have moved: following note to indicate that HTTP field name registrations have
moved:
</t> </t>
<aside><t><strong>Note</strong> <aside>
HTTP field name registrations have been moved to [https://www.iana <t>
.org/assignments/http-fields] <strong>Note</strong>
per [RFC9110]. </t>
<t>
HTTP field name registrations have been moved to
[<eref target="https://www.iana.org/assignments/http-fields" brack
ets="none"/>] per
[RFC9110].
</t> </t>
</aside> </aside>
<t> <t>
IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name
Registry" with the Registry"
field names listed in the following table. with the field names listed in the following table.
</t> </t>
<!--AUTOGENERATED FROM extract-header-defs.xslt, do not ed
<!-- [auth] AUTOGENERATED FROM extract-header-defs.xslt, d it manually-->
o not edit manually-->
<table align="left" anchor="iana.header.registration.table "> <table align="left" anchor="iana.header.registration.table ">
<thead> <thead>
<tr> <tr>
<th>Field Name</th> <th>Field Name</th>
<th>Status</th> <th>Status</th>
<th>Ref.</th> <th>Ref.</th>
<th>Comments</th> <th>Comments</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>Accept</td> <td>Accept</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept" format="counter"/> <xref target="field.accept" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Charset</td> <td>Accept-Charset</td>
<td>deprecated</td> <td>deprecated</td>
<td> <td>
<xref target="field.accept-charset" format="co unter"/> <xref target="field.accept-charset" format="co unter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Encoding</td> <td>Accept-Encoding</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept-encoding" format="c ounter"/> <xref target="field.accept-encoding" format="c ounter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Language</td> <td>Accept-Language</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept-language" format="c ounter"/> <xref target="field.accept-language" format="c ounter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Accept-Ranges</td> <td>Accept-Ranges</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.accept-ranges" format="cou nter"/> <xref target="field.accept-ranges" format="cou nter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Allow</td> <td>Allow</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.allow" format="counter"/> <xref target="field.allow" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Authentication-Info</td> <td>Authentication-Info</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.authentication-info" forma t="counter"/> <xref target="field.authentication-info" forma t="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Authorization</td> <td>Authorization</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.authorization" format="cou nter"/> <xref target="field.authorization" format="cou nter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Connection</td> <td>Connection</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.connection" format="counte r"/> <xref target="field.connection" format="counte r"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Encoding</td> <td>Content-Encoding</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-encoding" format=" counter"/> <xref target="field.content-encoding" format=" counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Language</td> <td>Content-Language</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-language" format=" counter"/> <xref target="field.content-language" format=" counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Length</td> <td>Content-Length</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-length" format="co unter"/> <xref target="field.content-length" format="co unter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Location</td> <td>Content-Location</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-location" format=" counter"/> <xref target="field.content-location" format=" counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Range</td> <td>Content-Range</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-range" format="cou nter"/> <xref target="field.content-range" format="cou nter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Content-Type</td> <td>Content-Type</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.content-type" format="coun ter"/> <xref target="field.content-type" format="coun ter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Date</td> <td>Date</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.date" format="counter"/> <xref target="field.date" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>ETag</td> <td>ETag</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.etag" format="counter"/> <xref target="field.etag" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Expect</td> <td>Expect</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.expect" format="counter"/> <xref target="field.expect" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>From</td> <td>From</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.from" format="counter"/> <xref target="field.from" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Host</td> <td>Host</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.host" format="counter"/> <xref target="field.host" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Match</td> <td>If-Match</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-match" format="counter" /> <xref target="field.if-match" format="counter" />
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Modified-Since</td> <td>If-Modified-Since</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-modified-since" format= "counter"/> <xref target="field.if-modified-since" format= "counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-None-Match</td> <td>If-None-Match</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-none-match" format="cou nter"/> <xref target="field.if-none-match" format="cou nter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Range</td> <td>If-Range</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-range" format="counter" /> <xref target="field.if-range" format="counter" />
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>If-Unmodified-Since</td> <td>If-Unmodified-Since</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.if-unmodified-since" forma t="counter"/> <xref target="field.if-unmodified-since" forma t="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Last-Modified</td> <td>Last-Modified</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.last-modified" format="cou nter"/> <xref target="field.last-modified" format="cou nter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Location</td> <td>Location</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.location" format="counter" /> <xref target="field.location" format="counter" />
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Max-Forwards</td> <td>Max-Forwards</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.max-forwards" format="coun ter"/> <xref target="field.max-forwards" format="coun ter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Proxy-Authenticate</td> <td>Proxy-Authenticate</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.proxy-authenticate" format ="counter"/> <xref target="field.proxy-authenticate" format ="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Proxy-Authentication-Info</td> <td>Proxy-Authentication-Info</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.proxy-authentication-info" format="counter"/> <xref target="field.proxy-authentication-info" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Proxy-Authorization</td> <td>Proxy-Authorization</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.proxy-authorization" forma t="counter"/> <xref target="field.proxy-authorization" forma t="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Range</td> <td>Range</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.range" format="counter"/> <xref target="field.range" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Referer</td> <td>Referer</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.referer" format="counter"/ > <xref target="field.referer" format="counter"/ >
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Retry-After</td> <td>Retry-After</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.retry-after" format="count er"/> <xref target="field.retry-after" format="count er"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Server</td> <td>Server</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.server" format="counter"/> <xref target="field.server" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>TE</td> <td>TE</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.te" format="counter"/> <xref target="field.te" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Trailer</td> <td>Trailer</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.trailer" format="counter"/ > <xref target="field.trailer" format="counter"/ >
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Upgrade</td> <td>Upgrade</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.upgrade" format="counter"/ > <xref target="field.upgrade" format="counter"/ >
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>User-Agent</td> <td>User-Agent</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.user-agent" format="counte r"/> <xref target="field.user-agent" format="counte r"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Vary</td> <td>Vary</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.vary" format="counter"/> <xref target="field.vary" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>Via</td> <td>Via</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.via" format="counter"/> <xref target="field.via" format="counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>WWW-Authenticate</td> <td>WWW-Authenticate</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.www-authenticate" format=" counter"/> <xref target="field.www-authenticate" format=" counter"/>
</td> </td>
<td/> <td/>
</tr> </tr>
<tr> <tr>
<td>*</td> <td>*</td>
<td>standard</td> <td>permanent</td>
<td> <td>
<xref target="field.vary" format="counter"/> <xref target="field.vary" format="counter"/>
</td> </td>
<td>(reserved)</td> <td>(reserved)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<!-- [auth] (END)--> <!--(END)-->
<t anchor="field.asterisk"> <t anchor="field.asterisk">
<iref primary="true" item="Fields" subitem="*"/> <iref primary="true" item="Fields" subitem="*"/>
The field name "*" is reserved because using that name as The field name "*" is reserved because using that name as
an HTTP header field might conflict with its special semantics in t he an HTTP header field might conflict with its special semantics in t he
<xref target="field.vary" format="none">Vary</xref> header field (< xref target="field.vary"/>). <xref target="field.vary" format="none">Vary</xref> header field (< xref target="field.vary"/>).
</t> </t>
<t> <t>
<iref primary="true" item="Fields" subitem="Content-MD5 "/> <iref primary="true" item="Fields" subitem="Content-MD5 "/>
<iref primary="true" item="Header Fields" subitem="Cont ent-MD5"/> <iref primary="true" item="Header Fields" subitem="Cont ent-MD5"/>
skipping to change at line 11972 skipping to change at line 11928
</section> </section>
<section anchor="content.coding.registration" <section anchor="content.coding.registration"
title="Content Coding Registration"> title="Content Coding Registration">
<t> <t>
IANA has updated the "HTTP Content Coding Registry" at IANA has updated the "HTTP Content Coding Registry" at
<eref target="https://www.iana.org/assignments/http-parameters/" <eref target="https://www.iana.org/assignments/http-parameters/"
brackets="angle"/> brackets="angle"/>
with the registration procedure of <xref target="content.coding.reg istry"/> with the registration procedure of <xref target="content.coding.reg istry"/>
and the content coding names summarized in the table below. and the content coding names summarized in the table below.
</t> </t>
<!-- [rfced] We will remove the parentheses around the citations in
the "deflate" entry of the "HTTP Content Coding Registry" to
match the use of other citations in that table, and we will
communicate that change to IANA unless we hear objection.
Original:
| deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2
|
| | inside the "zlib" data format ([RFC1950]) |
|
Perhaps:
| deflate | "deflate" compressed data [RFC1951] | 8.4.1.2
|
| | inside the "zlib" data format [RFC1950] |
|
<table align="left" anchor="iana.content.coding.registrati on.table"> <table align="left" anchor="iana.content.coding.registrati on.table">
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Description</th> <th>Description</th>
<th>Ref.</th> <th>Ref.</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>compress</td> <td>compress</td>
<td>UNIX "compress" data format <xref target="Wel ch"/> <td>UNIX "compress" data format <xref target="Wel ch"/>
</td> </td>
<td> <td>
<xref target="compress.coding" format="counter "/> <xref target="compress.coding" format="counter "/>
</td> </td>
</tr> </tr>
<tr> <tr>
<td>deflate</td> <td>deflate</td>
<td>"deflate" compressed data (<xref target="RFC1 <td>"deflate" compressed data <xref target="RFC19
951"/>) inside 51"/> inside
the "zlib" data format (<xref target="RFC1950"/>)</td> the "zlib" data format <xref target="RFC1950"/>
</td>
<td> <td>
<xref target="deflate.coding" format="counter" /> <xref target="deflate.coding" format="counter" />
</td> </td>
</tr> </tr>
<tr> <tr>
<td>gzip</td> <td>gzip</td>
<td>GZIP file format <xref target="RFC1952"/> <td>GZIP file format <xref target="RFC1952"/>
</td> </td>
<td> <td>
<xref target="gzip.coding" format="counter"/> <xref target="gzip.coding" format="counter"/>
skipping to change at line 12407 skipping to change at line 12349
</front> </front>
<refcontent>Doctoral Dissertation, University of Califo rnia, Irvine</refcontent> <refcontent>Doctoral Dissertation, University of Califo rnia, Irvine</refcontent>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.1919.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.1919.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.1945.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.1945.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2047.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2047.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2068.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2068.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2145.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2145.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2295.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2295.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.2324.xml"/> <!-- long way to include the Day attribute because this is an April 1s
t RFC -->
<reference anchor="RFC2324" target="https://www.rfc-editor.org/info/rf
c2324">
<front>
<title>
Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
</title>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization/>
</author>
<date year="1998" month="April" day="1"/>
</front>
<seriesInfo name="RFC" value="2324"/>
<seriesInfo name="DOI" value="10.17487/RFC2324"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2557.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2557.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2616.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2616.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2617.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2617.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2774.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2774.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2818.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2818.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2978.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.2978.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.3040.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.3040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.4033.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.4559.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.4559.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.4918.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.4918.xml"/>
skipping to change at line 12917 skipping to change at line 12874
The use of the <xref target="field.content-range" format="none">Con tent-Range</xref> header field The use of the <xref target="field.content-range" format="none">Con tent-Range</xref> header field
(<xref target="field.content-range"/>) as a request modifier on PUT is allowed (<xref target="field.content-range"/>) as a request modifier on PUT is allowed
(<xref target="PUT"/>). (<xref target="PUT"/>).
</t> </t>
<t> <t>
A superfluous requirement about setting <xref target="field.content -length" format="none">Content-Length</xref> A superfluous requirement about setting <xref target="field.content -length" format="none">Content-Length</xref>
has been removed from the description of the OPTIONS method has been removed from the description of the OPTIONS method
(<xref target="OPTIONS"/>). (<xref target="OPTIONS"/>).
</t> </t>
<t> <t>
The normative requirement to use the "message/http" media type in The normative requirement to use the message/http media type in
TRACE responses has been removed TRACE responses has been removed
(<xref target="TRACE"/>). (<xref target="TRACE"/>).
</t> </t>
<t> <t>
List-based grammar for <xref target="field.expect" format="none">Ex pect</xref> has been restored for compatibility with List-based grammar for <xref target="field.expect" format="none">Ex pect</xref> has been restored for compatibility with
RFC 2616 RFC 2616
(<xref target="field.expect"/>). (<xref target="field.expect"/>).
</t> </t>
<t> <t>
<xref target="field.accept" format="none">Accept</xref> and <xref t arget="field.accept-encoding" format="none">Accept-Encoding</xref> are allowed in response <xref target="field.accept" format="none">Accept</xref> and <xref t arget="field.accept-encoding" format="none">Accept-Encoding</xref> are allowed in response
 End of changes. 63 change blocks. 
142 lines changed or deleted 100 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/