On Wed, 2 Aug 2000, ARATech Cache Team wrote:
> Hi there,
>
> We are running polymix-3 test recently.
> Everything seems to be working fine, except reload request.
> Polygraph 2.5.x handles reload request as inserting following
> fileds into HTTP request header.
> "Pragma: no-cache"
> "Cache-control: no-cache"
>
> When our cache cache encounters above header, it validates
> the object and serve cached copy if valid.
> So our cache serve cached copy when reload request, which yields
> error report in polymix-3.
>
> Is our approach incorrect?
>
>
> HTTP 1.1 specification indicates that
> * Cache-control: no-cache
> -> revalidation must occur before serving object (a)
I believe thats for 'no-cache' in a response, rather than a request.
> * Pragma: no-cache
> -> application(cache) should forward the request to the server
> even if cached object exists (b)
> -> same semantic as Cache-control: no-cache when appeared at
> request header (c)
I think the relevant part of RFC 2616 is:
End-to-end reload
The request includes a "no-cache" cache-control directive or, for
compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
names MUST NOT be included with the no-cache directive in a
request. The server MUST NOT use a cached copy when responding to
such a request.
I believe it is a violation of HTTP to simply validate your
cached copy for an end-to-end reload. You must get the
entire response from the origin server, even if it will
be the same.
The proper way to cause a validation of a cached response is to
include "cache-control: max-age=0" (Specific end-to-end revalidation).
I could be wrong, its just my interpretation. HTTP sure is
confusing.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:14 MDT