Source: https://trac.ietf.org/trac/httpbis/changeset/1740/draft-ietf-httpbis/latest/p2-semantics.html
Timestamp: 2019-11-20 19:38:31
Document Index: 11654664

Matched Legal Cases: ['art6', 'art6', 'art 6', 'art6', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1']

Changeset 1740 for draft-ietf-httpbis/latest/p2-semantics.html – Hypertext Transfer Protocol Wiki
Changeset 1740 for draft-ietf-httpbis/latest/p2-semantics.html
Jul 8, 2012, 11:15:03 AM (7 years ago)
draft-ietf-httpbis/latest/p2-semantics.html (modified) (46 diffs)
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>.
<p id="rfc.section.2.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
<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
<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
<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>).
<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.
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
consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response
indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would
be a suitable target for the new representation.
<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:
<li>reconfigure the target resource to reflect the new media type;</li>
<li>transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state;
<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
would be a suitable target for the new representation.
<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
<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.
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
<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.
<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
<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>).
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
<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
(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.
<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>.
<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.
<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).
<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).
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,
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,
<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.
<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).
<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.
not acceptable according to the Accept and Accept-* header fields sent in the request.
<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.
<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
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
<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
<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.
<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>.
<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>
<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
<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
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
<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
asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
<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
<p id="rfc.section.8.1.p.3">Server-driven negotiation has disadvantages: </p>
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
<div class="note" id="rfc.section.8.1.p.7">
<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.
<td class="left">reserved (synonym for "no encoding" in <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> header field)
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.
be abused if user details are not separated from the information contained in the Referer. Even when the personal information
has been removed, the Referer header field might indicate a private document's URI whose publication would be inappropriate.
<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.
<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
<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
<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
<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.
<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
<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
in the final request, it might be visible to the user agent through other means, such as scripting.
<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>
<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
<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
<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
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
LF, respectively, as is the case for some multi-byte character encodings.
<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.
<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.
<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
Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform a function equivalent to Content-Encoding.
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>)