Ignore:
Timestamp:
Jul 8, 2012, 11:15:03 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1739 r1740  
    859859         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    860860         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    861          the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
    862          of error recovery could lead to dangerous consequences.
     861         the <a href="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
     862         could lead to dangerous consequences.
    863863      </p>
    864864      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     
    890890      </p>
    891891      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#methods" class="smpl">method</a>         = <a href="#core.rules" class="smpl">token</a>
    892 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
    893          set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
     892</pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
     893         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not
     894            Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
    894895      </p>
    895896      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
     
    954955      </p>
    955956      <p id="rfc.section.2.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
    956       <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then
    957          the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
    958          to HTTP might use the OPTIONS body to make more detailed queries on the server.
     957      <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
     958         body to make more detailed queries on the server.
    959959      </p>
    960960      <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
     
    966966         with that resource.
    967967      </p>
    968       <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,
    969          Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
     968      <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
    970969         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
    971970      </p>
    972       <p id="rfc.section.2.3.1.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
     971      <p id="rfc.section.2.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
    973972      </p>
    974973      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="GET" href="#GET">GET</a></h3>
     
    10231022         the result.
    10241023      </p>
    1025       <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a Location header
    1026          field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
    1027       </p>
    1028       <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1024      <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
     1025      </p>
     1026      <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    10291027      </p>
    10301028      <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
     
    10491047         related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
    10501048         with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an
    1051          appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on Content-Type values.
    1052       </p>
    1053       <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being
    1054          PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format
    1055          consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response
    1056          indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would
    1057          be a suitable target for the new representation.
    1058       </p>
     1049         appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values.
     1050      </p>
     1051      <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of:
     1052      </p>
     1053      <ol class="la">
     1054         <li>reconfigure the target resource to reflect the new media type;</li>
     1055         <li>transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state;
     1056            or,
     1057         </li>
     1058         <li>reject the request with a <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> response indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that
     1059            would be a suitable target for the new representation.
     1060         </li>
     1061      </ol>
    10591062      <p id="rfc.section.2.3.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent
    10601063         of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in
     
    11081111      <div id="rfc.iref.t.1"></div>
    11091112      <div id="rfc.iref.m.7"></div>
    1110       <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a Max-Forwards value of zero (0) in
    1111          the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
     1113      <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    11121114      </p>
    11131115      <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1114          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    1115          client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    1116          infinite loop.
    1117       </p>
    1118       <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1116         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
     1117         messages in an infinite loop.
     1118      </p>
     1119      <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    11191120      </p>
    11201121      <div id="rfc.iref.c.2"></div>
     
    11831184         double quotes will likely cause unnecessary confusion.
    11841185      </p>
    1185       <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;9.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
     1186      <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;9.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
    11861187         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
    11871188         it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section&nbsp;5.5</a>).
     
    14001401         </li>
    14011402      </ul>
    1402       <p id="rfc.section.4.p.4">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's
    1403          media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;9.9</a>).
     1403      <p id="rfc.section.4.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;9.9</a>).
    14041404      </p>
    14051405      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
     
    17051705      <p id="rfc.section.4.4.2.p.1">The request has been fulfilled and has resulted in one or more new resources being created.</p>
    17061706      <p id="rfc.section.4.4.2.p.2">Newly created resources are typically linked to from the response payload, with the most relevant URI also being carried in
    1707          the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information
    1708          can be omitted (e.g., in the case of a response to a PUT request).
     1707         the <a href="#header.location" class="smpl">Location</a> header field. If the newly created resource's URI is the same as the Effective Request URI, this information can be omitted
     1708         (e.g., in the case of a response to a PUT request).
    17091709      </p>
    17101710      <p id="rfc.section.4.4.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
    17111711      </p>
    17121712      <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
    1713          the Location header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
     1713         the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    17141714      </p>
    17151715      <div id="rfc.iref.27"></div>
     
    17751775      <ol>
    17761776         <li>
    1777             <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the Location header
    1778                field. In this specification, the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> fall under this category.
     1777            <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the <a href="#header.location" class="smpl">Location</a> header field. In this specification, the status codes <a href="#status.301" class="smpl">301
     1778                 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> fall under this category.
    17791779            </p>
    17801780         </li>
     
    18011801         </p>
    18021802      </div>
    1803       <p id="rfc.section.4.5.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;9.13</a>.
     1803      <p id="rfc.section.4.5.p.4">A <a href="#header.location" class="smpl">Location</a> header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;9.13</a>.
    18041804      </p>
    18051805      <p id="rfc.section.4.5.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was
     
    18231823         choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
    18241824      </p>
    1825       <p id="rfc.section.4.5.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.
     1825      <p id="rfc.section.4.5.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the <a href="#header.location" class="smpl">Location</a> field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.
    18261826      </p>
    18271827      <p id="rfc.section.4.5.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.
     
    18351835      <p id="rfc.section.4.5.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
    18361836      </p>
    1837       <p id="rfc.section.4.5.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
    1838          the new URI(s).
     1837      <p id="rfc.section.4.5.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s).
    18391838      </p>
    18401839      <div class="note" id="rfc.section.4.5.2.p.4">
     
    18471846      <p id="rfc.section.4.5.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    18481847      </p>
    1849       <p id="rfc.section.4.5.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
    1850          the new URI(s).
     1848      <p id="rfc.section.4.5.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s).
    18511849      </p>
    18521850      <div class="note" id="rfc.section.4.5.3.p.3">
     
    18581856      <h3 id="rfc.section.4.5.4"><a href="#rfc.section.4.5.4">4.5.4</a>&nbsp;<a id="status.303" href="#status.303">303 See Other</a></h3>
    18591857      <p id="rfc.section.4.5.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI
    1860          in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy
    1861          the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further,
     1858         in the <a href="#header.location" class="smpl">Location</a> header field, that is intended to provide an indirect response to the original request. In order to satisfy the original request,
     1859         a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further,
    18621860         and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is
    18631861         not considered equivalent to the effective request URI.
     
    18681866      </p>
    18691867      <p id="rfc.section.4.5.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
    1870          transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such
    1871          that the follow-on representation might be useful to recipients without implying that it adequately represents the target
    1872          resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might
    1873          be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
    1874       </p>
    1875       <p id="rfc.section.4.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI.
     1868         transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> URI indicates a resource that is descriptive of the target resource, such that the follow-on representation might be useful
     1869         to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what
     1870         can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP
     1871         and thus entirely determined by the URI owner(s).
     1872      </p>
     1873      <p id="rfc.section.4.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the <a href="#header.location" class="smpl">Location</a> URI.
    18761874      </p>
    18771875      <div id="rfc.iref.36"></div>
     
    18891887      <p id="rfc.section.4.5.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    18901888      </p>
    1891       <p id="rfc.section.4.5.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
    1892          the new URI(s).
     1889      <p id="rfc.section.4.5.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s).
    18931890      </p>
    18941891      <div class="note" id="rfc.section.4.5.7.p.3">
     
    19341931      <div id="rfc.iref.s.26"></div>
    19351932      <h3 id="rfc.section.4.6.5"><a href="#rfc.section.4.6.5">4.6.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    1936       <p id="rfc.section.4.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource.
     1933      <p id="rfc.section.4.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an <a href="#header.allow" class="smpl">Allow</a> header field containing a list of valid methods for the requested resource.
    19371934      </p>
    19381935      <div id="rfc.iref.45"></div>
     
    19401937      <h3 id="rfc.section.4.6.6"><a href="#rfc.section.4.6.6">4.6.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
    19411938      <p id="rfc.section.4.6.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    1942          not acceptable according to the Accept and Accept-* header fields sent in the request.
     1939         not acceptable according to the <a href="#header.accept" class="smpl">Accept</a> and Accept-* header fields sent in the request.
    19431940      </p>
    19441941      <p id="rfc.section.4.6.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user
     
    19991996         to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.
    20001997      </p>
    2001       <p id="rfc.section.4.6.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
     1998      <p id="rfc.section.4.6.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
    20021999      </p>
    20032000      <div id="rfc.iref.51"></div>
     
    20192016      <div id="rfc.iref.s.35"></div>
    20202017      <h3 id="rfc.section.4.6.14"><a href="#rfc.section.4.6.14">4.6.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
    2021       <p id="rfc.section.4.6.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
     2018      <p id="rfc.section.4.6.14.p.1">The expectation given in an <a href="#header.expect" class="smpl">Expect</a> header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
    20222019         not be met by the next-hop server.
    20232020      </p>
     
    20662063      <p id="rfc.section.4.7.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p>
    20672064      <p id="rfc.section.4.7.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the
    2068          delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;9.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
     2065         delay <em class="bcp14">MAY</em> be indicated in a <a href="#header.retry-after" class="smpl">Retry-After</a> header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;9.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a <a href="#status.500" class="smpl">500 (Internal
     2066            Server Error)</a> response.
    20692067      </p>
    20702068      <div class="note" id="rfc.section.4.7.4.p.3">
     
    22012199         Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry.
    22022200      </p>
    2203       <p id="rfc.section.5.3.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
    2204          token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter
    2205          value of the charset parameter can be quoted.
     2201      <p id="rfc.section.5.3.p.5">HTTP uses charset in two contexts: within an <a href="#header.accept-charset" class="smpl">Accept-Charset</a> request header field (in which the charset value is an unquoted token) and as the value of a parameter in a <a href="#header.content-type" class="smpl">Content-Type</a> header field (within a request or response), in which case the parameter value of the charset parameter can be quoted.
    22062202      </p>
    22072203      <p id="rfc.section.5.3.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
     
    22142210      </p>
    22152211      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#core.rules" class="smpl">token</a>
    2216 </pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;9.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;9.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
     2212</pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;9.3</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;9.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
    22172213         mechanism will be required to remove the encoding.
    22182214      </p>
     
    22512247      </p>
    22522248      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
    2253       <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;9.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;9.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
     2249      <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;9.9</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;9.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
    22542250      </p>
    22552251      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
     
    23052301      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="language.tags" href="#language.tags">Language Tags</a></h2>
    23062302      <p id="rfc.section.5.6.p.1">A language tag, as defined in <a href="#RFC5646" id="rfc.xref.RFC5646.1"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to
    2307          other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language
    2308          fields.
     2303         other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the <a href="#header.accept-language" class="smpl">Accept-Language</a> and <a href="#header.content-language" class="smpl">Content-Language</a> fields.
    23092304      </p>
    23102305      <p id="rfc.section.5.6.p.2">In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series
     
    23672362         (request or response), the request method, the response status code, and the representation metadata. For example, the above
    23682363         semantic is true for the representation in any <a href="#status.200" class="smpl">200 (OK)</a> response to GET and for the representation in any PUT request. A 200 response to PUT, in contrast, contains either a representation
    2369          that describes the successful action or a representation of the target resource, with the latter indicated by a Content-Location
    2370          header field with the same value as the effective request URI. Likewise, response messages with an error status code usually
     2364         that describes the successful action or a representation of the target resource, with the latter indicated by a <a href="#header.content-location" class="smpl">Content-Location</a> header field with the same value as the effective request URI. Likewise, response messages with an error status code usually
    23712365         contain a representation that describes the error and what next steps are suggested for resolving it.
    23722366      </p>
     
    23902384         <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
    23912385         </li>
    2392          <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
    2393             is a representation of the target resource.
    2394          </li>
    2395          <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response
    2396             asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
    2397             cannot be trusted unless it can be verified by other means (not defined by HTTP).
     2386         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is the same as the effective request URI, the response payload is a representation of the target
     2387            resource.
     2388         </li>
     2389         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation
     2390            of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified
     2391            by other means (not defined by HTTP).
    23982392         </li>
    23992393         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
     
    24682462         the representation metadata header fields.
    24692463      </p>
    2470       <p id="rfc.section.7.3.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
    2471          a two-layer, ordered encoding model:
     2464      <p id="rfc.section.7.3.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model:
    24722465      </p>
    24732466      <div id="rfc.figure.u.23"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
    2474 </pre><p id="rfc.section.7.3.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
     2467</pre><p id="rfc.section.7.3.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
    24752468         body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown
    24762469         to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
     
    24842477         such "content sniffing" when it is used.
    24852478      </p>
    2486       <p id="rfc.section.7.3.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
    2487          that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond
    2488          that defined by the Content-Type.
     2479      <p id="rfc.section.7.3.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
     2480         are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that
     2481         defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field.
    24892482      </p>
    24902483      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
     
    25212514         to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
    25222515         (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    2523          improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.
     2516         improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response.
    25242517      </p>
    25252518      <p id="rfc.section.8.1.p.3">Server-driven negotiation has disadvantages: </p>
     
    25432536      </p>
    25442537      <p id="rfc.section.8.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    2545          and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;9.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;9.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;9.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;9.4</a>), and User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;9.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
     2538         and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;9.1</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;9.2</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;9.3</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;9.4</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;9.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    25462539         within extension header fields not defined by this specification.
    25472540      </p>
    25482541      <div class="note" id="rfc.section.8.1.p.7">
    2549          <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
     2542         <p> <b>Note:</b> In practice, <a href="#header.user-agent" class="smpl">User-Agent</a> based negotiation is fragile, because new clients might not be recognized.
    25502543         </p>
    25512544      </div>
     
    27912784      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    27922785      <p id="rfc.section.9.6.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
    2793          in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the
    2794          Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the
    2795          identity of its underlying media type.
     2786         in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of
     2787         its underlying media type.
    27962788      </p>
    27972789      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.41"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
     
    28072799         would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin
    28082800         server might choose to publish the same payload data as multiple representations that differ only in whether the coding is
    2809          defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each
    2810          response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content).
     2801         defined as part of <a href="#header.content-type" class="smpl">Content-Type</a> or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save
     2802         as ..." dialog instead of automatic decompression and rendering of content).
    28112803      </p>
    28122804      <p id="rfc.section.9.6.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;9.6</a>) that lists the content-coding(s) applied.
     
    29992991      </p>
    30002992      <div class="note" id="rfc.section.9.13.p.9">
    3001          <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
     2993         <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    30022994            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    30032995         </p>
     
    35913583               <tr>
    35923584                  <td class="left">identity</td>
    3593                   <td class="left">reserved (synonym for "no encoding" in Accept-Encoding header field)</td>
     3585                  <td class="left">reserved (synonym for "no encoding" in <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> header field)
     3586                  </td>
    35943587                  <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section&nbsp;9.3</a>
    35953588                  </td>
     
    36073600         a priori method of determining the sensitivity of any particular piece of information within the context of any given request.
    36083601         Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth
    3609          special mention in this context: Server, Via, Referer and From.
     3602         special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>.
    36103603      </p>
    36113604      <p id="rfc.section.11.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    3612          against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option.
     3605         against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the <a href="#header.server" class="smpl">Server</a> header field a configurable option.
    36133606      </p>
    36143607      <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
    36153608         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
    36163609      </p>
    3617       <p id="rfc.section.11.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its
    3618          power can be abused if user details are not separated from the information contained in the Referer. Even when the personal
    3619          information has been removed, the Referer header field might indicate a private document's URI whose publication would be
    3620          inappropriate.
    3621       </p>
    3622       <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
    3623          hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
     3610      <p id="rfc.section.11.1.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can
     3611         be abused if user details are not separated from the information contained in the Referer. Even when the personal information
     3612         has been removed, the Referer header field might indicate a private document's URI whose publication would be inappropriate.
     3613      </p>
     3614      <p id="rfc.section.11.1.p.5">The information sent in the <a href="#header.from" class="smpl">From</a> field might conflict with the user's privacy interests or their site's security policy, and hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
    36243615      </p>
    36253616      <p id="rfc.section.11.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
    3626          of From and Referer information.
    3627       </p>
    3628       <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;9.18</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;9.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
     3617         of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information.
     3618      </p>
     3619      <p id="rfc.section.11.1.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;9.18</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;9.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
    36293620         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
    36303621         no better mechanism.
    36313622      </p>
    3632       <p id="rfc.section.11.1.p.8">Furthermore, the User-Agent header field might contain enough entropy to be used, possibly in conjunction with other material,
    3633          to uniquely identify the user.
     3623      <p id="rfc.section.11.1.p.8">Furthermore, the <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the
     3624         user.
    36343625      </p>
    36353626      <p id="rfc.section.11.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;2.3.7</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
     
    36383629      <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
    36393630      <p id="rfc.section.11.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
    3640          recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could
    3641          have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From
    3642          information.
    3643       </p>
    3644       <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
     3631         recommended that the user be able to select whether or not the <a href="#header.referer" class="smpl">Referer</a> field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively
     3632         enable/disable the sending of Referer and From information.
     3633      </p>
     3634      <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a <a href="#header.referer" class="smpl">Referer</a> header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
    36453635      </p>
    36463636      <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
     
    36493639      </p>
    36503640      <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    3651       <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
    3652          to make sure that they do not attempt to invalidate resources over which they have no authority.
    3653       </p>
    3654       <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak
    3655          confidential information to the target server — although the fragment identifier is not transmitted in the final request,
    3656          it might be visible to the user agent through other means, such as scripting.
     3641      <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of <a href="#header.location" class="smpl">Location</a> and <a href="#header.content-location" class="smpl">Content-Location</a> header fields in responses that are generated under control of said organizations to make sure that they do not attempt to
     3642         invalidate resources over which they have no authority.
     3643      </p>
     3644      <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a <a href="#header.location" class="smpl">Location</a> header field might leak confidential information to the target server — although the fragment identifier is not transmitted
     3645         in the final request, it might be visible to the user agent through other means, such as scripting.
    36573646      </p>
    36583647      <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;Security Considerations for CONNECT
     
    36623651      </p>
    36633652      <h2 id="rfc.section.11.5"><a href="#rfc.section.11.5">11.5</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    3664       <p id="rfc.section.11.5.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field
    3665          in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
    3666          languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
    3667          to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged to let the
    3668          configuration process include a message which makes the user aware of the loss of privacy involved.
     3653      <p id="rfc.section.11.5.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding
     3654         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
     3655         the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
     3656         to let the configuration process include a message which makes the user aware of the loss of privacy involved.
    36693657      </p>
    36703658      <p id="rfc.section.11.5.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
     
    39123900      </p>
    39133901      <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;5.5.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of
    3914          a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10
    3915          to represent CR and LF, respectively, as is the case for some multi-byte character encodings.
     3902         a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10 to represent CR and
     3903         LF, respectively, as is the case for some multi-byte character encodings.
    39163904      </p>
    39173905      <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in
     
    39193907      </p>
    39203908      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
    3921       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section&nbsp;5.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     3909      <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section&nbsp;5.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any <a href="#header.date" class="smpl">Date</a> header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    39223910      </p>
    39233911      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
    3924       <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on
    3925          the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some
    3926          experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;"
    3927          to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
     3912      <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's <a href="#header.content-encoding" class="smpl">Content-Encoding</a> header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the <a href="#header.content-type" class="smpl">Content-Type</a> header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for
     3913         Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform a function equivalent to Content-Encoding.
     3914         However, this parameter is not part of the MIME standards).
    39283915      </p>
    39293916      <div id="rfc.iref.c.11"></div>
     
    39713958      </p>
    39723959      <p id="rfc.section.C.p.8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through
    3973          the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient was expected to repeat
    3974          this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
     3960         the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The Location field gave the URI of the proxy. The recipient was expected to repeat this single request via the proxy.
     3961         (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
    39753962      </p>
    39763963      <p id="rfc.section.C.p.9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
     
    39783965      <p id="rfc.section.C.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    39793966      </p>
    3980       <p id="rfc.section.C.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
    3981          on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.5</a>)
    3982       </p>
    3983       <p id="rfc.section.C.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified
    3984          (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;9.11</a>)
    3985       </p>
    3986       <p id="rfc.section.C.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
    3987          symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    3988          (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;9.13</a>)
    3989       </p>
    3990       <p id="rfc.section.C.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.14</a>)
    3991       </p>
    3992       <p id="rfc.section.C.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.15</a>)
    3993       </p>
    3994       <p id="rfc.section.C.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    3995          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.60"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.17</a>)
     3967      <p id="rfc.section.C.p.11">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents
     3968         of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.5</a>)
     3969      </p>
     3970      <p id="rfc.section.C.p.12">The ABNF for the <a href="#header.expect" class="smpl">Expect</a> header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing
     3971         semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;9.11</a>)
     3972      </p>
     3973      <p id="rfc.section.C.p.13">Correct syntax of <a href="#header.location" class="smpl">Location</a> header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't
     3974         what was expected, and add some clarifications as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;9.13</a>)
     3975      </p>
     3976      <p id="rfc.section.C.p.14">Restrict <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.14</a>)
     3977      </p>
     3978      <p id="rfc.section.C.p.15">Allow <a href="#header.referer" class="smpl">Referer</a> field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.15</a>)
     3979      </p>
     3980      <p id="rfc.section.C.p.16">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.60"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.17</a>)
    39963981      </p>
    39973982      <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;5.3</a>)
     
    40073992         and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    40083993      </p>
    4009       <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section&nbsp;9.2</a>)
    4010       </p>
    4011       <p id="rfc.section.C.p.23">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
    4012          servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking
    4013          relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;9.8</a>)
     3994      <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in <a href="#header.accept-charset" class="smpl">Accept-Charset</a>. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section&nbsp;9.2</a>)
     3995      </p>
     3996      <p id="rfc.section.C.p.23">Remove base URI setting semantics for <a href="#header.content-location" class="smpl">Content-Location</a> due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,
     3997         and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;9.8</a>)
    40143998      </p>
    40153999      <p id="rfc.section.C.p.24">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
Note: See TracChangeset for help on using the changeset viewer.