Changeset 172 for draft-ietf-httpbis/latest/p6-cache.html

Timestamp:

23/01/08 02:11:10 (14 years ago)

Author:

fielding@…

Message:

editorial: replace redundant "the HTTP protocol" phrases or rephrase

File:

• draft-ietf-httpbis/latest/p6-cache.html (modified) (4 diffs)

draft-ietf-httpbis/latest/p6-cache.html

@@ -934 +934 @@
          origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call
          this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if
-         the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the
-         HTTP/1.1 protocol supports the use of conditional methods.
+         the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, HTTP/1.1
+         supports the use of conditional methods.
       </p>
       <p id="rfc.section.4.p.2">The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server
@@ -1029 +1029 @@
       </p>
       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h2>
-      <p id="rfc.section.6.2.p.1">Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers.
-         A transparent proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.
+      <p id="rfc.section.6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent
+         proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.
       </p>
       <p id="rfc.section.6.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: 
@@ -1155 +1155 @@
          the origin server would return for a new request on that resource.
       </p>
-      <p id="rfc.section.11.p.2">There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request
-         that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However,
-         several rules help reduce the likelihood of erroneous behavior.
+      <p id="rfc.section.11.p.2">There is no way for HTTP to guarantee that all such cache entries are marked invalid. For example, the request that caused
+         the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules
+         help reduce the likelihood of erroneous behavior.
       </p>
       <p id="rfc.section.11.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from
@@ -1277 +1277 @@
 </pre><p id="rfc.section.15.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When
          such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest
-         of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol
-         might apply these directives to header fields not defined in HTTP/1.1.
+         of the request or response. This mechanism supports extensibility; implementations of future versions of HTTP might apply
+         these directives to header fields not defined in HTTP/1.1.
       </p>
       <p id="rfc.section.15.2.p.5">The cache-control directives can be broken down into these general categories: </p>