Changeset 2074 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

Dec 31, 2012, 3:51:04 AM (7 years ago)

Author:

fielding@…

Message:

(editorial) that vs which

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (21 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1437 +1437 @@
          the result.
       </p>
-      <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>).
-      </p>
-      <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.
+      <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).
+      </p>
+      <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>).
       </p>
       <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).
       </p>
-      <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
-         or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
+      <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
+         will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
          related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
          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>
       <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)
-         which is separate from the URIs identifying each particular version (different resources that at one point shared the same
+         that is separate from the URIs identifying each particular version (different resources that at one point shared the same
          state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
          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.
       </p>
-      <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.
+      <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.
       </p>
       <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>
@@ -1642 +1642 @@
       <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>
       <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
-         to trace a request which appears to be failing or looping mid-chain.
+         to trace a request that appears to be failing or looping mid-chain.
       </p>
       <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>
       <ul>
-         <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.
+         <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.
          </li>
          <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>
       <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
-         which matches that type. For example,
+         that matches the type. For example,
       </p>
       <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>
       <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
-         is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
+         is a closed system that cannot interact with other rendering agents, this default set ought to be configurable by the user.
       </p>
       <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.
          This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability
-         to an origin server which is capable of representing documents in those charsets.
+         to an origin server that is capable of representing documents in those charsets.
       </p>
       <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>
       <div id="rfc.figure.u.29"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
-</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
+</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
          Accept-Charset field. If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field
          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> ] )
   <a href="#header.accept-encoding" class="smpl">codings</a>          = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*"
-</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>.
+</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>.
       </p>
       <p id="rfc.section.5.3.4.p.4">For example,</p>
@@ -1974 +1974 @@
   <a href="#header.accept-language" class="smpl">language-range</a>  = 
             &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;
-</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
-         languages specified by that range, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>. For example,
+</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
+         specified by that range, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>. For example,
       </p>
       <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>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
       <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
-         within the response's Upgrade header field immediately after the empty line which terminates the 101 response.
+         within the response's Upgrade header field immediately after the empty line that terminates the 101 response.
       </p>
       <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>
       <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>
-      <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.
+      <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.
       </p>
       <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>
       <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
-         being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the origin server
+         being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server
          might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely
          contain information useful for merging the differences based on the revision history.
@@ -2731 +2731 @@
       <div id="rfc.iref.75"></div>
       <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>
-      <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.
+      <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.
       </p>
       <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.
       </p>
-      <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
-         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
+      <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
+         security hole. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
          no better mechanism.
       </p>
@@ -3835 +3835 @@
       </p>
       <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>
-      <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
-         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
+      <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
+         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents that offer
          the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
          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
          be conservative in offering accept header field configuration options to end users. As an extreme privacy measure, proxies
-         could filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header
+         could filter the accept header fields in relayed requests. General purpose user agents that provide a high degree of header
          field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
       </p>
@@ -4090 +4090 @@
          over HTTP.
       </p>
-      <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
-         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.
+      <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.
       </p>
       <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>
       <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>
-      <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
+      <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
          fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
          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.