Changeset 2074 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 31/12/12 11:51:04 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2073 r2074 1437 1437 the result. 1438 1438 </p> 1439 <p id="rfc.section.4.3.3.p.4">If one or more resources has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a>, contain a representation which describes the status of the request and refers to the new resource(s), and include a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.2</a>).1440 </p> 1441 <p id="rfc.section.4.3.3.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 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cache d 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.2" title="Content-Location">Section 3.1.4.2</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD (not POST) requests.1439 <p id="rfc.section.4.3.3.p.4">If one or more resources has been created on the origin server, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.201" class="smpl">201 (Created)</a> response containing a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (<a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.2</a>) and a representation that describes the status of the request and refers to the new resource(s). 1440 </p> 1441 <p id="rfc.section.4.3.3.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 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cache <em class="bcp14">MUST NOT</em> use a cached POST response to satisfy a subsequent GET or HEAD request unless the response contains a <a href="#header.content-location" class="smpl">Content-Location</a> header field with the same value as the POST's effective request URI (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 3.1.4.2</a>). 1442 1442 </p> 1443 1443 <p id="rfc.section.4.3.3.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. … … 1457 1457 <p id="rfc.section.4.3.4.p.3">An origin server <em class="bcp14">SHOULD</em> ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state). 1458 1458 </p> 1459 <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot1460 orwill not be changed by the PUT. This is particularly important when the origin server uses internal configuration information1459 <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or 1460 will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information 1461 1461 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent 1462 1462 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 … … 1493 1493 </p> 1494 1494 <p id="rfc.section.4.3.4.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) 1495 whichis separate from the URIs identifying each particular version (different resources that at one point shared the same1495 that is separate from the URIs identifying each particular version (different resources that at one point shared the same 1496 1496 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new 1497 1497 version resource in addition to changing the state of the target resource, and might also cause links to be added between … … 1562 1562 undelivered, that data will be discarded. 1563 1563 </p> 1564 <p id="rfc.section.4.3.6.p.11">An origin server whichreceives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.1564 <p id="rfc.section.4.3.6.p.11">An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1565 1565 </p> 1566 1566 <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> … … 1642 1642 <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3> 1643 1643 <p id="rfc.section.5.1.1.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 1644 to trace a request whichappears to be failing or looping mid-chain.1644 to trace a request that appears to be failing or looping mid-chain. 1645 1645 </p> 1646 1646 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.17"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a> … … 1697 1697 <p id="rfc.section.5.1.2.1.p.6">Requirements for HTTP/1.1 origin servers: </p> 1698 1698 <ul> 1699 <li>Upon receiving a request whichincludes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request.1699 <li>Upon receiving a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request. 1700 1700 </li> 1701 1701 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility … … 1861 1861 </ol> 1862 1862 <p id="rfc.section.5.3.2.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 1863 which matches thattype. For example,1863 that matches the type. For example, 1864 1864 </p> 1865 1865 <div id="rfc.figure.u.27"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, … … 1903 1903 </div> 1904 1904 <p id="rfc.section.5.3.2.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent 1905 is a closed system whichcannot interact with other rendering agents, this default set ought to be configurable by the user.1905 is a closed system that cannot interact with other rendering agents, this default set ought to be configurable by the user. 1906 1906 </p> 1907 1907 <div id="rfc.iref.a.2"></div> … … 1909 1909 <p id="rfc.section.5.3.3.p.1">The "Accept-Charset" header field can be sent by a user agent to indicate what charsets are acceptable in a selected representation. 1910 1910 This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability 1911 to an origin server whichis capable of representing documents in those charsets.1911 to an origin server that is capable of representing documents in those charsets. 1912 1912 </p> 1913 1913 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#charset" class="smpl">charset</a> / "*" ) [ <a href="#quality.values" class="smpl">weight</a> ] ) … … 1915 1915 </p> 1916 1916 <div id="rfc.figure.u.29"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 1917 </pre><p id="rfc.section.5.3.3.p.5">The special value "*", if present in the Accept-Charset field, matches every charset whichis not mentioned elsewhere in the1917 </pre><p id="rfc.section.5.3.3.p.5">The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the 1918 1918 Accept-Charset field. If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field 1919 1919 are considered "not acceptable" to the client. … … 1933 1933 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#quality.values" class="smpl">weight</a> ] ) 1934 1934 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 1935 </pre><p id="rfc.section.5.3.4.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which representsthe preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section 5.3.1</a>.1935 </pre><p id="rfc.section.5.3.4.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value representing the preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section 5.3.1</a>. 1936 1936 </p> 1937 1937 <p id="rfc.section.5.3.4.p.4">For example,</p> … … 1974 1974 <a href="#header.accept-language" class="smpl">language-range</a> = 1975 1975 <language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>> 1976 </pre><p id="rfc.section.5.3.5.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the1977 languagesspecified by that range, as defined in <a href="#quality.values" title="Quality Values">Section 5.3.1</a>. For example,1976 </pre><p id="rfc.section.5.3.5.p.3">Each language-range can be given an associated quality value representing an estimate of the user's preference for the languages 1977 specified by that range, as defined in <a href="#quality.values" title="Quality Values">Section 5.3.1</a>. For example, 1978 1978 </p> 1979 1979 <div id="rfc.figure.u.33"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 … … 2394 2394 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 2395 2395 <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch to the protocol(s) indicated 2396 within the response's Upgrade header field immediately after the empty line whichterminates the 101 response.2396 within the response's Upgrade header field immediately after the empty line that terminates the 101 response. 2397 2397 </p> 2398 2398 <p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching … … 2644 2644 <div id="rfc.iref.74"></div> 2645 2645 <h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 2646 <p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation whichwould be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section 5.3</a>), and the server is unwilling to supply a default representation.2646 <p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation that would be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section 5.3</a>), and the server is unwilling to supply a default representation. 2647 2647 </p> 2648 2648 <p id="rfc.section.6.5.6.p.2">The server <em class="bcp14">SHOULD</em> generate a payload containing a list of available representation characteristics and corresponding resource identifiers from … … 2664 2664 </p> 2665 2665 <p id="rfc.section.6.5.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation 2666 being PUT included changes to a resource whichconflict with those made by an earlier (third-party) request, the origin server2666 being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server 2667 2667 might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely 2668 2668 contain information useful for merging the differences based on the revision history. … … 2731 2731 <div id="rfc.iref.75"></div> 2732 2732 <h3 id="rfc.section.6.6.1"><a href="#rfc.section.6.6.1">6.6.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h3> 2733 <p id="rfc.section.6.6.1.p.1">The <dfn>500 (Internal Server Error)</dfn> status code indicates that the server encountered an unexpected condition whichprevented it from fulfilling the request.2733 <p id="rfc.section.6.6.1.p.1">The <dfn>500 (Internal Server Error)</dfn> status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. 2734 2734 </p> 2735 2735 <div id="rfc.iref.75"></div> … … 3799 3799 of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information. 3800 3800 </p> 3801 <p id="rfc.section.9.3.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 5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might3802 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has3801 <p id="rfc.section.9.3.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 5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields can sometimes be used to determine if a specific client or server is more likely to be vulnerable to a known 3802 security hole. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 3803 3803 no better mechanism. 3804 3804 </p> … … 3835 3835 </p> 3836 3836 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <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> 3837 <p id="rfc.section.9.7.p.1">Accept header fields can reveal information about the user to all servers whichare 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 understanding3838 of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents whichoffer3837 <p id="rfc.section.9.7.p.1">Accept header fields can reveal information about the user to all servers that 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 3838 of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents that offer 3839 3839 the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged 3840 3840 to let the configuration process include a message which makes the user aware of the loss of privacy involved. … … 3850 3850 also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to 3851 3851 be conservative in offering accept header field configuration options to end users. As an extreme privacy measure, proxies 3852 could filter the accept header fields in relayed requests. General purpose user agents whichprovide a high degree of header3852 could filter the accept header fields in relayed requests. General purpose user agents that provide a high degree of header 3853 3853 field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved. 3854 3854 </p> … … 4090 4090 over HTTP. 4091 4091 </p> 4092 <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 3.1.1.3</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of 4093 a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some charsets which do not use octets 13 and 10 to represent CR and LF, respectively. 4092 <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 3.1.1.3</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, 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 charsets that do not use octets 13 and 10 to represent CR and LF, respectively. 4094 4093 </p> 4095 4094 <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 … … 4114 4113 </p> 4115 4114 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> 4116 <p id="rfc.section.A.6.p.1">HTTP implementations whichshare code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not4115 <p id="rfc.section.A.6.p.1">HTTP implementations that share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not 4117 4116 fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations 4118 4117 and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section 3.1.1.4</a>) and does not interpret the content or any MIME header lines that might be contained therein.
Note: See TracChangeset
for help on using the changeset viewer.