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

(editorial) that vs which

Location:
draft-ietf-httpbis/latest
Files:
10 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2072 r2074  
    919919      <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
    920920         response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response
    921          from O (via C) for a request which has not been cached by UA or A.
     921         from O (via C) for a request that has not been cached by UA or A.
    922922      </p>
    923923      <div id="rfc.figure.u.5"></div><pre class="drawing">            &gt;             &gt;
     
    18811881      <div id="rfc.figure.u.54"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    18821882</pre><p id="rfc.section.5.7.1.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    1883          by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
     1883         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values.
    18841884      </p>
    18851885      <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a id="message.transformations" href="#message.transformations">Transformations</a></h3>
     
    19651965      </p>
    19661966      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistence</a></h2>
    1967       <p id="rfc.section.6.3.p.1">HTTP/1.1 defaults to the use of "<dfn>persistent connections</dfn>", which allow multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will not persist after the current request/response. HTTP implementations <em class="bcp14">SHOULD</em> support persistent connections.
     1967      <p id="rfc.section.6.3.p.1">HTTP/1.1 defaults to the use of "<dfn>persistent connections</dfn>", allowing multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will not persist after the current request/response. HTTP implementations <em class="bcp14">SHOULD</em> support persistent connections.
    19681968      </p>
    19691969      <p id="rfc.section.6.3.p.2">A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version
     
    19931993      <p id="rfc.section.6.3.1.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
    19941994      </p>
    1995       <p id="rfc.section.6.3.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
     1995      <p id="rfc.section.6.3.1.p.2">Clients that assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    19961996      </p>
    19971997      <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2072 r2074  
    575575   applicable to that request. The following illustrates the resulting
    576576   chain if B has a cached copy of an earlier response from O (via C)
    577    for a request which has not been cached by UA or A.
     577   for a request that has not been cached by UA or A.
    578578</t>
    579579<figure><artwork type="drawing">
     
    25962596   Senders &SHOULD-NOT; combine multiple entries unless they are all
    25972597   under the same organizational control and the hosts have already been
    2598    replaced by pseudonyms. Senders &MUST-NOT; combine entries which
     2598   replaced by pseudonyms. Senders &MUST-NOT; combine entries that
    25992599   have different received-protocol values.
    26002600</t>
     
    27832783<t>
    27842784   HTTP/1.1 defaults to the use of "<x:dfn>persistent connections</x:dfn>",
    2785    which allow multiple requests and responses to be carried over a single
     2785   allowing multiple requests and responses to be carried over a single
    27862786   connection. The "<x:ref>close</x:ref>" connection-option is used to signal
    27872787   that a connection will not persist after the current request/response.
     
    28472847</t>
    28482848<t>
    2849    Clients which assume persistent connections and pipeline immediately
     2849   Clients that assume persistent connections and pipeline immediately
    28502850   after connection establishment &SHOULD; be prepared to retry their
    28512851   connection if the first pipelined attempt fails. If a client does
  • 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.
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2073 r2074  
    13401340</t>
    13411341<t>
    1342    If one or more resources has been created on the origin server, the response
    1343    &SHOULD; be <x:ref>201 (Created)</x:ref>, contain a representation which
    1344    describes the status of the request and refers to the new resource(s), and
    1345    include a <x:ref>Location</x:ref> header field that provides an identifier
    1346    for the primary resource created (see <xref target="header.location"/>).
     1342   If one or more resources has been created on the origin server, the origin
     1343   server &SHOULD; send a <x:ref>201 (Created)</x:ref> response containing a
     1344   <x:ref>Location</x:ref> header field that provides an identifier for the
     1345   primary resource created (<xref target="header.location"/>) and a
     1346   representation that describes the status of the request and refers to the
     1347   new resource(s).
    13471348</t>
    13481349<t>
    13491350   Responses to POST requests are only cacheable when they include explicit
    1350    freshness information (see &p6-explicit;). A cached POST response with a
    1351    <x:ref>Content-Location</x:ref> header field (see
    1352    &header-content-location;) whose value is the effective Request URI &MAY;
    1353    be used to satisfy subsequent GET and HEAD (not POST) requests.
     1351   freshness information (see &p6-explicit;). A cache &MUST-NOT; use a cached
     1352   POST response to satisfy a subsequent GET or HEAD request unless the
     1353   response contains a <x:ref>Content-Location</x:ref> header field with the
     1354   same value as the POST's effective request URI (&header-content-location;).
    13541355</t>
    13551356<t>
     
    13931394<t>
    13941395   An origin server &SHOULD; verify that the PUT representation is
    1395    consistent with any constraints which the server has for the target
     1396   consistent with any constraints the server has for the target
    13961397   resource that cannot or will not be changed by the PUT.  This is
    13971398   particularly important when the origin server uses internal
     
    14601461   A PUT request applied to the target resource &MAY; have side-effects
    14611462   on other resources.  For example, an article might have a URI for
    1462    identifying "the current version" (a resource) which is separate
     1463   identifying "the current version" (a resource) that is separate
    14631464   from the URIs identifying each particular version (different
    14641465   resources that at one point shared the same state as the current version
     
    16001601</t>
    16011602<t>
    1602    An origin server which receives a CONNECT request for itself &MAY;
     1603   An origin server that receives a CONNECT request for itself &MAY;
    16031604   respond with a <x:ref>2xx</x:ref> status code to indicate that a connection
    16041605   is established.  However, most origin servers do not implement CONNECT.
     
    17411742   methods to limit the number of times that the request is forwarded by
    17421743   proxies. This can be useful when the client is attempting to
    1743    trace a request which appears to be failing or looping mid-chain.
     1744   trace a request that appears to be failing or looping mid-chain.
    17441745</t>
    17451746<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
     
    18601861   Requirements for HTTP/1.1 origin servers:
    18611862  <list style="symbols">
    1862     <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
     1863    <t> Upon receiving a request that includes an <x:ref>Expect</x:ref> header
    18631864        field with the "100-continue" expectation, an origin server &MUST;
    18641865        either respond with <x:ref>100 (Continue)</x:ref> status code and
     
    20992100   The media type quality factor associated with a given type is
    21002101   determined by finding the media range with the highest precedence
    2101    which matches that type. For example,
     2102   that matches the type. For example,
    21022103</t>
    21032104<figure><artwork type="example">
     
    21202121   &Note; A user agent might be provided with a default set of quality
    21212122   values for certain media ranges. However, unless the user agent is
    2122    a closed system which cannot interact with other rendering agents,
     2123   a closed system that cannot interact with other rendering agents,
    21232124   this default set ought to be configurable by the user.
    21242125</t>
     
    21332134   This field allows user agents capable of understanding more comprehensive
    21342135   or special-purpose charsets to signal that capability to an origin server
    2135    which is capable of representing documents in those charsets.
     2136   that is capable of representing documents in those charsets.
    21362137</t>
    21372138<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
     
    21492150<t>
    21502151   The special value "*", if present in the Accept-Charset field,
    2151    matches every charset which is not mentioned elsewhere in the
     2152   matches every charset that is not mentioned elsewhere in the
    21522153   Accept-Charset field. If no "*" is present in an Accept-Charset field,
    21532154   then any charsets not explicitly mentioned in the field are
     
    21872188</artwork></figure>
    21882189<t>
    2189    Each codings value &MAY; be given an associated quality value which
    2190    represents the preference for that encoding, as defined in &qvalue;.
     2190   Each codings value &MAY; be given an associated quality value
     2191   representing the preference for that encoding, as defined in &qvalue;.
    21912192</t>
    21922193<t>
     
    22582259</artwork></figure>
    22592260<t>
    2260    Each language-range can be given an associated quality value which
    2261    represents an estimate of the user's preference for the languages
     2261   Each language-range can be given an associated quality value
     2262   representing an estimate of the user's preference for the languages
    22622263   specified by that range, as defined in &qvalue;. For example,
    22632264</t>
     
    26652666   a change in the application protocol being used on this connection. The
    26662667   server will switch to the protocol(s) indicated within the response's
    2667    Upgrade header field immediately after the empty line which terminates the
     2668   Upgrade header field immediately after the empty line that terminates the
    26682669   101 response.
    26692670</t>
     
    32043205<t>
    32053206   The <x:dfn>406 (Not Acceptable)</x:dfn> status code indicates that the
    3206    <x:ref>target resource</x:ref> does not have a current representation which
     3207   <x:ref>target resource</x:ref> does not have a current representation that
    32073208   would be acceptable to the user agent, according to the
    32083209   <x:ref>proactive negotiation</x:ref> header fields received in the request
     
    32523253   Conflicts are most likely to occur in response to a PUT request. For
    32533254   example, if versioning were being used and the representation being PUT
    3254    included changes to a resource which conflict with those made by an
     3255   included changes to a resource that conflict with those made by an
    32553256   earlier (third-party) request, the origin server might use a 409 response
    32563257   to indicate that it can't complete the request. In this case, the response
     
    34033404<t>
    34043405   The <x:dfn>500 (Internal Server Error)</x:dfn> status code indicates that
    3405    the server encountered an unexpected condition which prevented it from
     3406   the server encountered an unexpected condition that prevented it from
    34063407   fulfilling the request.
    34073408</t>
     
    47614762   The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or
    47624763   <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields can
    4763    sometimes be used to determine that a specific client or server has a
    4764    particular security hole which might be exploited. Unfortunately, this same
     4764   sometimes be used to determine if a specific client or server is more
     4765   likely to be vulnerable to a known security hole. Unfortunately, this same
    47654766   information is often used for other valuable purposes for which HTTP
    47664767   currently has no better mechanism.
     
    48344835<t>
    48354836   Accept header fields can reveal information about the user to all
    4836    servers which are accessed. The <x:ref>Accept-Language</x:ref> header field
     4837   servers that are accessed. The <x:ref>Accept-Language</x:ref> header field
    48374838   in particular can reveal information the user would consider to be of a
    48384839   private nature, because the understanding of particular languages is often
    48394840   strongly correlated to the membership of a particular ethnic group.
    4840    User agents which offer the option to configure the contents of an
     4841   User agents that offer the option to configure the contents of an
    48414842   Accept-Language header field to be sent in every request are strongly
    48424843   encouraged to let the configuration process include a message which
     
    48644865   header field configuration options to end users. As an extreme privacy
    48654866   measure, proxies could filter the accept header fields in relayed requests.
    4866    General purpose user agents which provide a high degree of header field
     4867   General purpose user agents that provide a high degree of header field
    48674868   configurability &SHOULD; warn users about the loss of privacy which can
    48684869   be involved.
     
    56485649   environment &SHOULD; translate all line breaks within the text media
    56495650   types described in <xref target="canonicalization.and.text.defaults"/>
    5650    of this document to the RFC 2049 canonical form of CRLF. Note, however, that
     5651   of this document to the RFC 2049 canonical form of CRLF. Note, however,
    56515652   this might be complicated by the presence of a <x:ref>Content-Encoding</x:ref>
    56525653   and by the fact that HTTP allows the use of some charsets
    5653    which do not use octets 13 and 10 to represent CR and LF, respectively.
     5654   that do not use octets 13 and 10 to represent CR and LF, respectively.
    56545655</t>
    56555656<t>
     
    57075708<section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
    57085709<t>
    5709    HTTP implementations which share code with MHTML <xref target="RFC2557"/> implementations
     5710   HTTP implementations that share code with MHTML <xref target="RFC2557"/> implementations
    57105711   need to be aware of MIME line length limitations. Since HTTP does not
    57115712   have this limitation, HTTP does not fold long lines. MHTML messages
  • draft-ietf-httpbis/latest/p4-conditional.html

    r2069 r2074  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 3, 2013";
     451       content: "Expires July 4, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-30">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
     
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: July 3, 2013</td>
    520                <td class="right">December 30, 2012</td>
     519               <td class="left">Expires: July 4, 2013</td>
     520               <td class="right">December 31, 2012</td>
    521521            </tr>
    522522         </tbody>
     
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on July 3, 2013.</p>
     547      <p>This Internet-Draft will expire on July 4, 2013.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    10121012      <ol>
    10131013         <li>If the request would normally result in anything other than a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> status code, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date
    1014             which is later than the server's current time is invalid.
     1014            that is later than the server's current time is invalid.
    10151015         </li>
    10161016         <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for
     
    10571057      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h2>
    10581058      <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
    1059          to transfer a representation of the target resource because the request indicates that the client which made the request conditional
    1060          already has a valid representation; the server is therefore redirecting that client to make use of that stored representation
    1061          as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
     1059         to transfer a representation of the target resource because the request indicates that the client, which made the request
     1060         conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored
     1061         representation as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    10621062      </p>
    10631063      <p id="rfc.section.4.1.p.2">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2069 r2074  
    830830         <x:ref>200 (OK)</x:ref> status code, or if the passed If-Modified-Since date is
    831831         invalid, the response is exactly the same as for a normal GET.
    832          A date which is later than the server's current time is
     832         A date that is later than the server's current time is
    833833         invalid.</t>
    834834
     
    934934   In other words, there is no need for the server to transfer a
    935935   representation of the target resource because the request indicates that
    936    the client which made the request conditional already has a valid
    937    representation; the server is therefore redirecting that client to make
     936   the client, which made the request conditional, already has a valid
     937   representation; the server is therefore redirecting the client to make
    938938   use of that stored representation as if it were the payload of a
    939939   <x:ref>200 (OK)</x:ref> response.
  • draft-ietf-httpbis/latest/p6-cache.html

    r2073 r2074  
    10171017      <p id="rfc.section.4.1.3.p.15"> </p>
    10181018      <ul>
    1019          <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve
    1020             the "year 2000" problem).
     1019         <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date appearing to be more than 50 years in the future is in fact in the past (this helps solve the
     1020            "year 2000" problem).
    10211021         </li>
    10221022         <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2073 r2074  
    767767  <list style="symbols">
    768768     <t>Recipients &SHOULD; assume that an RFC-850 date
    769         which appears to be more than 50 years in the future is in fact
     769        appearing to be more than 50 years in the future is in fact
    770770        in the past (this helps solve the "year 2000" problem).</t>
    771771
  • draft-ietf-httpbis/latest/p7-auth.html

    r2069 r2074  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 3, 2013";
     451       content: "Expires July 4, 2013";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-12-30">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
     
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">December 30, 2012</td>
     519               <td class="right">December 31, 2012</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: July 3, 2013</td>
     522               <td class="left">Expires: July 4, 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
     
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire on July 3, 2013.</p>
     548      <p>This Internet-Draft will expire on July 4, 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    623623         Authentication" (<a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>).
    624624      </p>
    625       <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to
     625      <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms that can be used by a server to challenge a client request and by a client to
    626626         provide authentication information. The "basic" and "digest" authentication schemes continue to be specified in <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.
    627627      </p>
     
    699699      <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
    700700         on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
    701          database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific
     701         database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific
    702702         to the authentication scheme. Note that there can be multiple challenges with the same auth-scheme but different realms.
    703703      </p>
     
    770770               response directive, within the scope of the request they appear in.
    771771            </p>
    772             <p>Therefore, new authentication schemes which choose not to carry credentials in the <a href="#header.authorization" class="smpl">Authorization</a> header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of
     772            <p>Therefore, new authentication schemes that choose not to carry credentials in the <a href="#header.authorization" class="smpl">Authorization</a> header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of
    773773               either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
    774774            </p>
     
    815815      <div id="rfc.iref.p.3"></div>
    816816      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2>
    817       <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy which requires authentication.
     817      <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication.
    818818         Its value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of
    819819         the resource being requested.
     
    942942      </p>
    943943      <ul>
    944          <li>Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt
     944         <li>Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt
    945945            the user for credentials.
    946946         </li>
    947          <li>Applications which include a session termination indication (such as a "logout" or "commit" button on a page) after which
    948             the server side of the application "knows" that there is no further reason for the client to retain the credentials.
     947         <li>Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the
     948            server side of the application "knows" that there is no further reason for the client to retain the credentials.
    949949         </li>
    950950      </ul>
    951951      <p id="rfc.section.6.1.p.2">This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the
    952          use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent
    953          in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism
     952         use of password protection in screen savers, idle time-outs, and other methods that mitigate the security problems inherent
     953         in this problem. In particular, user agents that cache credentials are encouraged to provide a readily accessible mechanism
    954954         for discarding cached credentials under user control.
    955955      </p>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2069 r2074  
    120120<t>
    121121   HTTP provides several &OPTIONAL; challenge-response authentication
    122    mechanisms which can be used by a server to challenge a client request and
     122   mechanisms that can be used by a server to challenge a client request and
    123123   by a client to provide authentication information. The "basic" and "digest"
    124124   authentication schemes continue to be specified in
     
    290290   partitioned into a set of protection spaces, each with its own
    291291   authentication scheme and/or authorization database. The realm value
    292    is a string, generally assigned by the origin server, which can have
     292   is a string, generally assigned by the origin server, that can have
    293293   additional semantics specific to the authentication scheme. Note that
    294294   there can be multiple challenges with the same auth-scheme but
     
    408408    </t>
    409409    <t>
    410       Therefore, new authentication schemes which choose not to carry
     410      Therefore, new authentication schemes that choose not to carry
    411411      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
    412412      header field) will need to explicitly disallow caching, by mandating the use of
     
    524524<t>
    525525   The "Proxy-Authorization" header field allows the client to
    526    identify itself (or its user) to a proxy which requires
     526   identify itself (or its user) to a proxy that requires
    527527   authentication. Its value consists of
    528528   credentials containing the authentication information of the user
     
    694694   application's security model include but are not limited to:
    695695  <list style="symbols">
    696      <t>Clients which have been idle for an extended period following
    697         which the server might wish to cause the client to reprompt the
     696     <t>Clients that have been idle for an extended period, following
     697        which the server might wish to cause the client to re-prompt the
    698698        user for credentials.</t>
    699699
    700      <t>Applications which include a session termination indication
     700     <t>Applications that include a session termination indication
    701701        (such as a "logout" or "commit" button on a page) after which
    702702        the server side of the application "knows" that there is no
     
    708708   to parts of this problem, and we encourage the use of
    709709   password protection in screen savers, idle time-outs, and other
    710    methods which mitigate the security problems inherent in this
    711    problem. In particular, user agents which cache credentials are
     710   methods that mitigate the security problems inherent in this
     711   problem. In particular, user agents that cache credentials are
    712712   encouraged to provide a readily accessible mechanism for discarding
    713713   cached credentials under user control.
Note: See TracChangeset for help on using the changeset viewer.