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

Timestamp:

31/12/12 11:51:04 (10 years ago)

Author:

fielding@…

Message:

(editorial) that vs which

File:

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

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

@@ -1340 +1340 @@
 </t>
 <t>
-   If one or more resources has been created on the origin server, the response
-   &SHOULD; be <x:ref>201 (Created)</x:ref>, contain a representation which
-   describes the status of the request and refers to the new resource(s), and
-   include a <x:ref>Location</x:ref> header field that provides an identifier
-   for the primary resource created (see <xref target="header.location"/>).
+   If one or more resources has been created on the origin server, the origin
+   server &SHOULD; send a <x:ref>201 (Created)</x:ref> response containing a
+   <x:ref>Location</x:ref> header field that provides an identifier for the
+   primary resource created (<xref target="header.location"/>) and a
+   representation that describes the status of the request and refers to the
+   new resource(s).
 </t>
 <t>
    Responses to POST requests are only cacheable when they include explicit
-   freshness information (see &p6-explicit;). A cached POST response with a
-   <x:ref>Content-Location</x:ref> header field (see
-   &header-content-location;) whose value is the effective Request URI &MAY;
-   be used to satisfy subsequent GET and HEAD (not POST) requests.
+   freshness information (see &p6-explicit;). A cache &MUST-NOT; use a cached
+   POST response to satisfy a subsequent GET or HEAD request unless the
+   response contains a <x:ref>Content-Location</x:ref> header field with the
+   same value as the POST's effective request URI (&header-content-location;).
 </t>
 <t>
@@ -1393 +1394 @@
 <t>
    An origin server &SHOULD; verify that the PUT representation is
-   consistent with any constraints which the server has for the target
+   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
@@ -1460 +1461 @@
    A PUT request applied to the target resource &MAY; have side-effects
    on other resources.  For example, an article might have a URI for
-   identifying "the current version" (a resource) which is separate
+   identifying "the current version" (a resource) that is separate
    from the URIs identifying each particular version (different
    resources that at one point shared the same state as the current version
@@ -1600 +1601 @@
 </t>
 <t>
-   An origin server which receives a CONNECT request for itself &MAY;
+   An origin server that receives a CONNECT request for itself &MAY;
    respond with a <x:ref>2xx</x:ref> status code to indicate that a connection
    is established.  However, most origin servers do not implement CONNECT.
@@ -1741 +1742 @@
    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.
+   trace a request that appears to be failing or looping mid-chain.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
@@ -1860 +1861 @@
    Requirements for HTTP/1.1 origin servers:
   <list style="symbols">
-    <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
+    <t> Upon receiving a request that includes an <x:ref>Expect</x:ref> header
         field with the "100-continue" expectation, an origin server &MUST;
         either respond with <x:ref>100 (Continue)</x:ref> status code and
@@ -2099 +2100 @@
    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,
 </t>
 <figure><artwork type="example">
@@ -2120 +2121 @@
    &Note; 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,
+   a closed system that cannot interact with other rendering agents,
    this default set ought to be configurable by the user.
 </t>
@@ -2133 +2134 @@
    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.
+   that is capable of representing documents in those charsets.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
@@ -2149 +2150 @@
 <t>
    The special value "*", if present in the Accept-Charset field,
-   matches every charset which is not mentioned elsewhere in the
+   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
@@ -2187 +2188 @@
 </artwork></figure>
 <t>
-   Each codings value &MAY; be given an associated quality value which
-   represents the preference for that encoding, as defined in &qvalue;.
+   Each codings value &MAY; be given an associated quality value
+   representing the preference for that encoding, as defined in &qvalue;.
 </t>
 <t>
@@ -2258 +2259 @@
 </artwork></figure>
 <t>
-   Each language-range can be given an associated quality value which
-   represents an estimate of the user's preference for the languages
+   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 &qvalue;. For example,
 </t>
@@ -2665 +2666 @@
    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
+   Upgrade header field immediately after the empty line that terminates the
    101 response.
 </t>
@@ -3204 +3205 @@
 <t>
    The <x:dfn>406 (Not Acceptable)</x:dfn> status code indicates that the
-   <x:ref>target resource</x:ref> does not have a current representation which
+   <x:ref>target resource</x:ref> does not have a current representation that
    would be acceptable to the user agent, according to the
    <x:ref>proactive negotiation</x:ref> header fields received in the request
@@ -3252 +3253 @@
    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
+   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
@@ -3403 +3404 @@
 <t>
    The <x:dfn>500 (Internal Server Error)</x:dfn> status code indicates that
-   the server encountered an unexpected condition which prevented it from
+   the server encountered an unexpected condition that prevented it from
    fulfilling the request.
 </t>
@@ -4761 +4762 @@
    The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or
    <x:ref>Server</x:ref> (<xref target="header.server"/>) 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
+   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.
@@ -4834 +4835 @@
 <t>
    Accept header fields can reveal information about the user to all
-   servers which are accessed. The <x:ref>Accept-Language</x:ref> header field
+   servers that are accessed. The <x:ref>Accept-Language</x:ref> 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 the option to configure the contents of an
+   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
@@ -4864 +4865 @@
    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 field
+   General purpose user agents that provide a high degree of header field
    configurability &SHOULD; warn users about the loss of privacy which can
    be involved.
@@ -5648 +5649 @@
    environment &SHOULD; translate all line breaks within the text media
    types described in <xref target="canonicalization.and.text.defaults"/>
-   of this document to the RFC 2049 canonical form of CRLF. Note, however, that
+   of this document to the RFC 2049 canonical form of CRLF. Note, however,
    this might be complicated by the presence of a <x:ref>Content-Encoding</x:ref>
    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.
+   that do not use octets 13 and 10 to represent CR and LF, respectively.
 </t>
 <t>
@@ -5707 +5708 @@
 <section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
 <t>
-   HTTP implementations which share code with MHTML <xref target="RFC2557"/> implementations
+   HTTP implementations that share code with MHTML <xref target="RFC2557"/> 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