Re: short-time client side caching and clock skew

tor 2010-05-27 klockan 13:29 +0200 skrev Jorrit Jongma:

> However, as I interpret it, due to how current_age is calculated in 13.2.3,
> short-period client-side caching is essentially impossible unless both
> server and client are NTP-synced.

Indeed. And this is due to legacy reasons in dealing with old HTTP/1.0
proxies not adding Age to their responses.

If you know that the response path is doing Age calculations correctly
then the parts relating to Date can be disregarded, using just

  corrected_initial_age =  age_value + (now - request_time)

and still stay within the spirit of the calculation. The authorative
calculations is the split out calculations, not the attempt in merging
these in one single formula. That single formula is very much an
approximation and do not reflect the text very well.

I think we have updated these calculations in HTTPbis. If not then that
should clearly be done. At a very minimum if needs to account for when
date_value > now (now - date_value should then result in 0, not a
negative number)


> In reverse, if
> the server clock is in front (and/)or the client clock is behind NTP time,
> the object will be cached way beyond it's intended freshness_lifetime.

How? I fail to see this.

I know there is broken implementations giving this result by just using
the simplified calculation, but not how you end up with this result if
actually following what is said, including the criterias that is not
reflected in the simplified calculation.

> (1) The Age header, if present, SHOULD override (now - date_value)

And you are allowed to by RFC2616 if you know that Age is correctly
sent. The combined calculation of age methods 1 & 2 is just a
suggestion.

> While this
> ignores transit time, I would say it is safe to assume that in most cases

You still need to add transit time to the age. Continue reading until
you have read the whole section.

> (2) Instead of using origin date to calculate the current_age, client
> receive date could be used.

No, but the time the client sent the request SHOULD be used.

> Both would only apply to HTTP/1.1 responses, as HTTP/1.0 servers do not send
> the Age header. I'm not sure if it is possible to have an HTTP/1.1 origin
> server, a HTTP/1.0 proxy, then a HTTP/1.1 proxy, and then receive a HTTP/1.1
> response, if so that could possibly pose a problem in this scenario.

The response SHOULD be HTTP/1.1 in such case, and is why it's generally
recommended to use the conservative approach of using max(now - date,
age).

But if the proxies are HTTP/1.1 compliant then Via can be used to detect
if there is any HTTP/1.0 paths, enabling you to select between the two
methods of calculating the age.

Regards
Henrik

Received on Thursday, 27 May 2010 22:54:13 UTC