Re: Authoritative caches

[ Sorry for the previous post.  I temporarily forgot how to use my
mail reader. ]

I wrote:

>> Section 2.4.4 refers to the `asynchronous nature' of HTTP messages.
>> This description is confusing, seeing as HTTP is a synchronous,
>> pipelined protocol.  Also, it isn't really clear when it is
>> permissible for a client to ignore the server's caching directives
>> or why this is necessary.

Martin responds:

  [ new text from the latest WD... ]

> Note that it is impossible for a client to accurately predict the
> amount of latency that may affect an HTTP request. Thus, if the policy
> reference file covering a request is going to expire soon, clients MAY
> wish to consider warning their users and/or revalidating the policy
> reference file before continuing with the request.


The new text is certainly an improvement, but the original questions
are still relevant.  It seems that the goal is to ensure that the user
agent doesn't take action based on an expired policy, but it's unclear
what constitutes `going to expire soon' in a lot of cases.

Making Expires: a SHOULD NOT helps to a degree, since clients
connecting directly to the origin server will stay reasonably well
synchronized.  A more reliable strategy (given the current protocol)
that doesn't introduce massive overhead might be:

  * Servers SHOULD NOT use absolute lifetimes (Servers accepting
    absolute times in configuration files is a UI issue and
    need not be implemented on the wire.)

  * Servers SHOULD make the lifetime of reference files <=
    the lifetime of associated resources

  * Clients SHOULD use conditional GET to refresh 
    policy reference files

  * Clients SHOULD maximally pipeline policy reference file
    requests

  * Clients MAY choose to refresh the policy reference file
    before it has expired

Assuming that the policy reference file is on the same server as the
content, the common case (in which the policy has not changed), the
latency of the request isn't increased by much if the the client
agressively pipelines requests.[1] This strategy also ensures that the
client will see any changes in the policy reference file `in time.'

This strategy will perform poorly if the URL of the policy reference
file points to a redirection.  I don't see any prohibition against
this in section 2 of the latest WD.  Is this intentional?

^L

[1] Note that this suggestion is based on prior experience (looking at
the latency introduced by stylesheets) and _not_ measurements of any
P3P implementations.  But the positive effects of pipelining on
latency in the general case have been well documented in
http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html.

If existing implementations of P3P have been profiled, this should
probably be discussed in the spec somewhere.


P.S. As a side note, if the P3P protocol required the client to send a
header or cookie acking acceptance of the site's policy, this entire
discussion would be rendered moot, since the server would be able to
notify the client of policy changes.

Received on Wednesday, 3 May 2000 17:09:25 UTC