labs-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From resc...@apache.org
Subject svn commit: r603222 [2/2] - /labs/webarch/trunk/http/draft-fielding-http/
Date Tue, 11 Dec 2007 12:19:57 GMT
Modified: labs/webarch/trunk/http/draft-fielding-http/p6-cache.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p6-cache.html?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p6-cache.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p6-cache.html Tue Dec 11 04:19:55 2007
@@ -782,7 +782,7 @@
          Hosts that use HTTP, but especially hosts running origin servers and caches, <em
class="bcp14">SHOULD</em> use NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite
title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>
or some similar protocol to synchronize their clocks to a globally accurate time standard.
       </p>
       <p id="rfc.section.2.2.3.p.3">HTTP/1.1 requires origin servers to send a Date
header, if possible, with every response, giving the time at which the response
-         was generated (see <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest"
title="Date">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
We use the term "date_value" to denote the value of the Date header, in a form appropriate
for arithmetic operations.
+         was generated (see <a href="p1-messaging.html#header.date" title="Date">Section
8.3</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part
1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). We use the
term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic
operations.
       </p>
       <p id="rfc.section.2.2.3.p.4">HTTP/1.1 uses the Age response-header to convey
the estimated age of the response message when obtained from a cache. The
          Age field value is the cache's estimate of the amount of time since the response
was generated or revalidated by the origin
@@ -904,7 +904,7 @@
          agent or proxy cache) makes a conditional request for a resource for which it has
a cache entry, it includes the associated
          validator in the request.
       </p>
-      <p id="rfc.section.2.3.p.3">The server then checks that validator against the
current validator for the entity, and, if they match (see <a href="http://tools.ietf.org/html/draft-fielding-p4-conditional-latest"
title="Weak and Strong Validators">Section 3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite
title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), it responds
with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
returns a full response
+      <p id="rfc.section.2.3.p.3">The server then checks that validator against the
current validator for the entity, and, if they match (see <a href="p4-conditional.html#weak.and.strong.validators"
title="Weak and Strong Validators">Section 3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite
title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), it responds
with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
returns a full response
          (including entity-body). Thus, we avoid transmitting the full response if the validator
matches, and we avoid an extra round
          trip if it does not match.
       </p>
@@ -930,7 +930,7 @@
          values is not sufficient, or where the origin server wishes to avoid certain paradoxes
that might arise from the use of modification
          dates.
       </p>
-      <p id="rfc.section.2.3.2.p.2">Entity Tags are described in <a href="http://tools.ietf.org/html/draft-fielding-p4-conditional-latest"
title="Entity Tags">Section 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite
title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
+      <p id="rfc.section.2.3.2.p.2">Entity Tags are described in <a href="p4-conditional.html#entity.tags"
title="Entity Tags">Section 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite
title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
       </p>
       <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a
id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h3>
       <p id="rfc.section.2.3.3.p.1">The principle behind entity tags is that only the
service author knows the semantics of a resource well enough to select an
@@ -952,7 +952,7 @@
          or privacy considerations. Certain cache-control directives are therefore provided
so that the server can indicate that certain
          resource entities, or portions thereof, are not to be cached regardless of other
considerations.
       </p>
-      <p id="rfc.section.2.4.p.3">Note that <a href="http://tools.ietf.org/html/draft-fielding-p7-auth-latest"
title="Authorization">Section 2.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite
title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a> normally prevents
a shared cache from saving and returning a response to a previous request if that request
included an Authorization
+      <p id="rfc.section.2.4.p.3">Note that <a href="p7-auth.html#header.authorization"
title="Authorization">Section 2.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite
title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a> normally prevents
a shared cache from saving and returning a response to a previous request if that request
included an Authorization
          header.
       </p>
       <p id="rfc.section.2.4.p.4">A response received with a status code of 200, 203,
206, 300, 301 or 410 <em class="bcp14">MAY</em> be stored by a cache and used
in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control
@@ -988,7 +988,7 @@
          <li>Upgrade</li>
       </ul>
       <p id="rfc.section.2.5.1.p.3">All other headers defined by HTTP/1.1 are end-to-end
headers.</p>
-      <p id="rfc.section.2.5.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em>
be listed in a Connection header (<a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest"
title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
+      <p id="rfc.section.2.5.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em>
be listed in a Connection header (<a href="p1-messaging.html#header.connection" title="Connection">Section
8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part
1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
       </p>
       <h3 id="rfc.section.2.5.2"><a href="#rfc.section.2.5.2">2.5.2</a>&nbsp;<a
id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h3>
       <p id="rfc.section.2.5.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.
@@ -1023,7 +1023,7 @@
             are introduced in later versions of HTTP. Such authentication mechanisms <em
class="bcp14">MAY</em> rely on the values of header fields not listed here.
          </dd>
       </dl>
-      <p id="rfc.section.2.5.2.p.7">The Content-Length field of a request or response
is added or deleted according to the rules in <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest"
title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a
href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Entity Length">Section
3.2.2</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1,
part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) of the
entity-body, although it <em class="bcp14">MAY</em> change the transfer-length
(<a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Message
Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite
title="HTTP/1.1, part 1: URIs, Connections, and
  Message Parsing">[Part1]</cite></a>).
+      <p id="rfc.section.2.5.2.p.7">The Content-Length field of a request or response
is added or deleted according to the rules in <a href="p1-messaging.html#message.length"
title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a
href="p3-payload.html#entity.length" title="Entity Length">Section 3.2.2</a> of <a
href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and
Content Negotiation">[Part3]</cite></a>) of the entity-body, although it <em
class="bcp14">MAY</em> change the transfer-length (<a href="p1-messaging.html#message.length"
title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
       </p>
       <h3 id="rfc.section.2.5.3"><a href="#rfc.section.2.5.3">2.5.3</a>&nbsp;<a
id="combining.headers" href="#combining.headers">Combining Headers</a></h3>
       <p id="rfc.section.2.5.3.p.1">When a cache makes a validating request to a server,
and the server provides a 304 (Not Modified) response or a 206 (Partial
@@ -1031,7 +1031,7 @@
       </p>
       <p id="rfc.section.2.5.3.p.2">If the status code is 304 (Not Modified), the cache
uses the entity-body stored in the cache entry as the entity-body of this
          outgoing response. If the status code is 206 (Partial Content) and the ETag or Last-Modified
headers match exactly, the cache <em class="bcp14">MAY</em> combine the contents
stored in the cache entry with the new contents received in the response and use the result
as the entity-body
-         of this outgoing response, (see <a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest"
title="Combining Byte Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite
title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).
+         of this outgoing response, (see <a href="p5-range.html#combining.byte.ranges"
title="Combining Byte Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite
title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).
       </p>
       <p id="rfc.section.2.5.3.p.3">The end-to-end headers stored in the cache entry
are used for the constructed response, except that </p>
       <ul>
@@ -1057,7 +1057,7 @@
          </dd>
       </dl>
       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a
id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated
Responses</a></h2>
-      <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest"
title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite
title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>),
as indicated by the presence of a Vary header field in a response, alters the conditions and
procedure by which a cache
+      <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation"
title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite
title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>),
as indicated by the presence of a Vary header field in a response, alters the conditions and
procedure by which a cache
          can use the response for subsequent requests. See <a href="#header.vary" id="rfc.xref.header.vary.1"
title="Vary">Section&nbsp;3.5</a> for use of the Vary header field by servers.
       </p>
       <p id="rfc.section.2.6.p.2">A server <em class="bcp14">SHOULD</em>
use the Vary header field to inform a cache of what request-header fields were used to select
among multiple representations
@@ -1071,7 +1071,7 @@
       <p id="rfc.section.2.6.p.4">The selecting request-headers from two requests are
defined to match if and only if the selecting request-headers in the first
          request can be transformed to the selecting request-headers in the second request
by adding or removing linear white space
          (LWS) at places where this is allowed by the corresponding BNF, and/or combining
multiple message-header fields with the same
-         field name following the rules about message headers in <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest"
title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
+         field name following the rules about message headers in <a href="p1-messaging.html#message.headers"
title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
       </p>
       <p id="rfc.section.2.6.p.5">A Vary header field-value of "*" always fails to
match and subsequent requests on that resource can only be properly interpreted
          by the origin server.
@@ -1098,7 +1098,7 @@
          place certain constraints on the operation of shared caches in order to prevent
loss of privacy or failure of access controls.
       </p>
       <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a
id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Errors
or Incomplete Response Cache Behavior</a></h2>
-      <p id="rfc.section.2.8.p.1">A cache that receives an incomplete response (for
example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em>
store the response. However, the cache <em class="bcp14">MUST</em> treat this
as a partial response. Partial responses <em class="bcp14">MAY</em> be combined
as described in <a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest" title="Combining
Byte Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite
title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>;
the result might be a full response or might still be partial. A cache <em class="bcp14">MUST
NOT</em> return a partial response to a client without explicitly marking it as such,
using the 206 (Partial Content) status code.
+      <p id="rfc.section.2.8.p.1">A cache that receives an incomplete response (for
example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em>
store the response. However, the cache <em class="bcp14">MUST</em> treat this
as a partial response. Partial responses <em class="bcp14">MAY</em> be combined
as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Byte Ranges">Section
5</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part
5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might
be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em>
return a partial response to a client without explicitly marking it as such, using the 206
(Partial Content) status code.
          A cache <em class="bcp14">MUST NOT</em> return a partial response using
a status code of 200 (OK).
       </p>
       <p id="rfc.section.2.8.p.2">If a cache receives a 5xx response while attempting
to revalidate an entry, it <em class="bcp14">MAY</em> either forward this response
to the requesting client, or act as if the server failed to respond. In the latter case, it
<em class="bcp14">MAY</em> return a previously received response unless the cached
entry includes the "must-revalidate" cache-control directive (see <a href="#header.cache-control"
id="rfc.xref.header.cache-control.8" title="Cache-Control">Section&nbsp;3.2</a>).
@@ -1110,7 +1110,7 @@
       </p>
       <p id="rfc.section.2.9.p.2">We note one exception to this rule: since some applications
have traditionally used GETs and HEADs with query URLs (those
          containing a "?" in the rel_path part) to perform operations with significant side
effects, caches <em class="bcp14">MUST NOT</em> treat responses to such URIs as
fresh unless the server provides an explicit expiration time. This specifically means that
-         responses from HTTP/1.0 servers for such URIs <em class="bcp14">SHOULD NOT</em>
be taken from a cache. See <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest"
title="Safe Methods">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite
title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for related
information.
+         responses from HTTP/1.0 servers for such URIs <em class="bcp14">SHOULD NOT</em>
be taken from a cache. See <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section
8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1,
part 2: Message Semantics">[Part2]</cite></a> for related information.
       </p>
       <h2 id="rfc.section.2.10"><a href="#rfc.section.2.10">2.10</a>&nbsp;<a
id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Invalidation
After Updates or Deletions</a></h2>
       <p id="rfc.section.2.10.p.1">The effect of certain methods performed on a resource
at the origin server might cause one or more existing cache entries
@@ -1258,7 +1258,7 @@
       </p>
       <dl class="empty">
          <dd>Indicates that the response <em class="bcp14">MAY</em> be
cached by any cache, even if it would normally be non-cacheable or cacheable only within a
non-shared cache. (See also
-            Authorization, <a href="http://tools.ietf.org/html/draft-fielding-p7-auth-latest"
title="Authorization">Section 2.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite
title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional
details.)
+            Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section
2.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part
7: Authentication">[Part7]</cite></a>, for additional details.)
          </dd>
       </dl>
       <p id="rfc.section.3.2.1.p.3"> <span id="rfc.iref.c.5"></span>  <span
id="rfc.iref.p.2"></span> private 
@@ -1509,7 +1509,7 @@
       <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that
the original resource will change or cease to exist at, before, or after
          that time.
       </p>
-      <p id="rfc.section.3.3.p.3">The format is an absolute date and time as defined
by HTTP-date in <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest"
title="Full Date">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite
title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>;
it <em class="bcp14">MUST</em> be in RFC 1123 date format:
+      <p id="rfc.section.3.3.p.3">The format is an absolute date and time as defined
by HTTP-date in <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a>
of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections,
and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em>
be in RFC 1123 date format:
       </p>
       <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span>
  Expires = "Expires" ":" HTTP-date
 </pre><p id="rfc.section.3.3.p.5">An example of its use is</p>

Modified: labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml Tue Dec 11 04:19:55 2007
@@ -2444,7 +2444,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p1-messaging-&ID-VERSION;"/>
-  <x:source href="p1-messaging.xml"/>
+  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
 </reference>
 
 <reference anchor="Part2">
@@ -2503,7 +2503,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p2-semantics-&ID-VERSION;"/>
-  <x:source href="p2-semantics.xml"/>
+  <x:source href="p2-semantics.xml" basename="p2-semantics"/>
 </reference>
 
 <reference anchor="Part3">
@@ -2562,7 +2562,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p3-payload-&ID-VERSION;"/>
-  <x:source href="p3-payload.xml"/>
+  <x:source href="p3-payload.xml" basename="p3-payload"/>
 </reference>
 
 <reference anchor="Part4">
@@ -2621,7 +2621,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p4-conditional-&ID-VERSION;"/>
-  <x:source href="p4-conditional.xml"/>
+  <x:source href="p4-conditional.xml" basename="p4-conditional"/>
 </reference>
 
 <reference anchor="Part5">
@@ -2680,7 +2680,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p5-range-&ID-VERSION;"/>
-  <x:source href="p5-range.xml"/>
+  <x:source href="p5-range.xml" basename="p5-range"/>
 </reference>
 
 <reference anchor="Part7">
@@ -2739,7 +2739,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p7-auth-&ID-VERSION;"/>
-  <x:source href="p7-auth.xml"/>
+  <x:source href="p7-auth.xml" basename="p7-auth"/>
 </reference>
 
 <reference anchor="RFC2047">

Modified: labs/webarch/trunk/http/draft-fielding-http/p7-auth.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p7-auth.html?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p7-auth.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p7-auth.html Tue Dec 11 04:19:55 2007
@@ -493,7 +493,7 @@
 </pre><p id="rfc.section.2.1.p.3">HTTP access authentication is described in
"HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.2"><cite
title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
If a request is authenticated and a realm specified, the same credentials <em class="bcp14">SHOULD</em>
be valid for all other requests within this realm (assuming that the authentication scheme
itself does not require otherwise,
          such as credentials that vary according to a challenge value or using synchronized
clocks).
       </p>
-      <p id="rfc.section.2.1.p.4">When a shared cache (see <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest"
title="Shared and Non-Shared Caches">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite
title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) receives a request containing
an Authorization field, it <em class="bcp14">MUST NOT</em> return the corresponding
response as a reply to any other request, unless one of the following specific exceptions
holds:
+      <p id="rfc.section.2.1.p.4">When a shared cache (see <a href="p6-cache.html#shared.and.non-shared.caches"
title="Shared and Non-Shared Caches">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite
title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) receives a request containing
an Authorization field, it <em class="bcp14">MUST NOT</em> return the corresponding
response as a reply to any other request, unless one of the following specific exceptions
holds:
       </p>
       <p id="rfc.section.2.1.p.5"> </p>
       <ol>

Modified: labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml Tue Dec 11 04:19:55 2007
@@ -415,7 +415,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p6-cache-&ID-VERSION;"/>
-  <x:source href="p6-cache.xml"/>
+  <x:source href="p6-cache.xml" basename="p6-cache"/>
 </reference>
 
 <reference anchor="RFC2616">



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org


Mime
View raw message