On 24/06/2012, at 8:18 PM, Julian Reschke wrote:
> P6, 2.3.3:
>
> If a cache receives a first-hand response (either an entire response,
> or a 304 (Not Modified) response) that it would normally forward to
> the requesting client, and the received response is no longer fresh,
> the cache can forward it to the requesting client without adding a
> new Warning (but without removing any existing Warning header
> fields). A cache shouldn't attempt to validate a response simply
> because that response became stale in transit.
>
> "shouldn't" -> "SHOULD NOT"
I think I prefer the "shouldn't" here; it's not a conformance requirement, but instead simply trying to explain how things work. I.e., this doesn't affect interop.
> P6, 2.4:
>
> Additionally, a cache can add an If-None-Match header field whose
> value is that of the ETag header field(s) from all responses stored
> for the requested URI, if present. However, if any of the stored
> responses contains only partial content, the cache shouldn't include
> its entity-tag in the If-None-Match header field unless the request
> is for a range that would be fully satisfied by that stored response.
>
> "shouldn't" -> "SHOULD NOT"
Again, this isn't really interop, it's just trying to explain how it works.
> P6, 3.2.3:
>
> For example, consider a hypothetical new response directive called
> "community" that acts as a modifier to the private directive. We
> define this new directive to mean that, in addition to any private
> cache, any cache that is shared only by members of the community
> named within its value may cache the response. An origin server
> wishing to allow the UCI community to use an otherwise private
> response in their shared cache(s) could do so by including
>
> "may" -> "can"
OK.
--
Mark Nottingham http://www.mnot.net/