Ignore:
Timestamp:
Dec 31, 2012, 3:51:04 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) that vs which

File:
1 edited

Legend:

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

    r2073 r2074  
    14371437         the result.
    14381438      </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&nbsp;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 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.2" title="Content-Location">Section&nbsp;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&nbsp;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&nbsp;3.1.4.2</a>).
    14421442      </p>
    14431443      <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.
     
    14571457      <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).
    14581458      </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 cannot
    1460          or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
     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 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
    14611461         related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
    14621462         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
     
    14931493      </p>
    14941494      <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          which is separate from the URIs identifying each particular version (different resources that at one point shared the same
     1495         that is separate from the URIs identifying each particular version (different resources that at one point shared the same
    14961496         state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
    14971497         version resource in addition to changing the state of the target resource, and might also cause links to be added between
     
    15621562         undelivered, that data will be discarded.
    15631563      </p>
    1564       <p id="rfc.section.4.3.6.p.11">An origin server which 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.
     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.
    15651565      </p>
    15661566      <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
     
    16421642      <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3>
    16431643      <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&nbsp;4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;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 which appears to be failing or looping mid-chain.
     1644         to trace a request that appears to be failing or looping mid-chain.
    16451645      </p>
    16461646      <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>
     
    16971697      <p id="rfc.section.5.1.2.1.p.6">Requirements for HTTP/1.1 origin servers: </p>
    16981698      <ul>
    1699          <li>Upon receiving a request which 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.
     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.
    17001700         </li>
    17011701         <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
     
    18611861      </ol>
    18621862      <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 that type. For example,
     1863         that matches the type. For example,
    18641864      </p>
    18651865      <div id="rfc.figure.u.27"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     
    19031903      </div>
    19041904      <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 which cannot 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.
    19061906      </p>
    19071907      <div id="rfc.iref.a.2"></div>
     
    19091909      <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.
    19101910         This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability
    1911          to an origin server which is capable of representing documents in those charsets.
     1911         to an origin server that is capable of representing documents in those charsets.
    19121912      </p>
    19131913      <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> ] )
     
    19151915      </p>
    19161916      <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 which is not mentioned elsewhere in the
     1917</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
    19181918         Accept-Charset field. If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field
    19191919         are considered "not acceptable" to the client.
     
    19331933      <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> ] )
    19341934  <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 represents the preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;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&nbsp;5.3.1</a>.
    19361936      </p>
    19371937      <p id="rfc.section.5.3.4.p.4">For example,</p>
     
    19741974  <a href="#header.accept-language" class="smpl">language-range</a>  =
    19751975            &lt;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>&gt;
    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 the
    1977          languages specified by that range, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;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&nbsp;5.3.1</a>. For example,
    19781978      </p>
    19791979      <div id="rfc.figure.u.33"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     
    23942394      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    23952395      <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 which terminates the 101 response.
     2396         within the response's Upgrade header field immediately after the empty line that terminates the 101 response.
    23972397      </p>
    23982398      <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
     
    26442644      <div id="rfc.iref.74"></div>
    26452645      <h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;<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 which 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&nbsp;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&nbsp;5.3</a>), and the server is unwilling to supply a default representation.
    26472647      </p>
    26482648      <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
     
    26642664      </p>
    26652665      <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 which conflict with those made by an earlier (third-party) request, the origin server
     2666         being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server
    26672667         might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely
    26682668         contain information useful for merging the differences based on the revision history.
     
    27312731      <div id="rfc.iref.75"></div>
    27322732      <h3 id="rfc.section.6.6.1"><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;<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 which prevented 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.
    27342734      </p>
    27352735      <div id="rfc.iref.75"></div>
     
    37993799         of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information.
    38003800      </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&nbsp;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&nbsp;7.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
    3802          be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
     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&nbsp;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&nbsp;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
    38033803         no better mechanism.
    38043804      </p>
     
    38353835      </p>
    38363836      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</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>
    3837       <p id="rfc.section.9.7.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
    3838          of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
     3837      <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
    38393839         the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
    38403840         to let the configuration process include a message which makes the user aware of the loss of privacy involved.
     
    38503850         also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
    38513851         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 which provide a high degree of header
     3852         could filter the accept header fields in relayed requests. General purpose user agents that provide a high degree of header
    38533853         field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
    38543854      </p>
     
    40904090         over HTTP.
    40914091      </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&nbsp;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&nbsp;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.
    40944093      </p>
    40954094      <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
     
    41144113      </p>
    41154114      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<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 which 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
     4115      <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
    41174116         fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
    41184117         and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;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.