Actually, the Date content header is quite well defined in HTTP/1.1 [0], and should not be manipulated nilly-willy by intermediates. If you're having problems with proxies caching your requests, even if you're asking non-cached content [1], then you're never going to be able to get an accurate time from anywhere since any request might be cached, and no solution would work anyway.
It's not quite a "hacky" solution, I would guesstimate it would work 95% of the time rather than 80%, but even 80% is a great solution for the amount of work involved, the tradeoffs, and the fact that we're talking about a clock displayed on a website.
Or, you know, you could spend £15.000 taxpayers' money over 3 months for something I'm not even sure would be more flexible/maintainable/performant.
Comments
Actually, the Date content header is quite well defined in HTTP/1.1 [0], and should not be manipulated nilly-willy by intermediates. If you're having problems with proxies caching your requests, even if you're asking non-cached content [1], then you're never going to be able to get an accurate time from anywhere since any request might be cached, and no solution would work anyway.
It's not quite a "hacky" solution, I would guesstimate it would work 95% of the time rather than 80%, but even 80% is a great solution for the amount of work involved, the tradeoffs, and the fact that we're talking about a clock displayed on a website.
Or, you know, you could spend £15.000 taxpayers' money over 3 months for something I'm not even sure would be more flexible/maintainable/performant.
[0]: http://tools.ietf.org/html/rfc2616#section-14.18
[1]: E.g. URL's with random number in the query