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

(editorial) that vs which

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/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
Note: See TracChangeset for help on using the changeset viewer.