Doesn't work if there's a proxy server caching old versions between the user and the server. Not to mention that according to the RFC standard intermediary servers are allowed to manipulate/remove/alter any non-restricted header (including Date).
Yes you can come up with a hacky solution that works 80% of the time quickly, but if you want a 99% solution you need to put the work in to do it right.
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
Doesn't work if there's a proxy server caching old versions between the user and the server. Not to mention that according to the RFC standard intermediary servers are allowed to manipulate/remove/alter any non-restricted header (including Date).
Yes you can come up with a hacky solution that works 80% of the time quickly, but if you want a 99% solution you need to put the work in to do it right.
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