http://bugs.squid-cache.org/show_bug.cgi?id=3221

On the bug report there is a description of squid denying the ICAP server due to some logic of wrong Date header. Since squid and ICAP server times are too far apart the service cannot be considered reliable for use.

The effect can be for example on an ICAP service that provides time based which would note make any sense if squid has the wrong time or the ICAP service has the wrong time. Another effect is that ICAP service often helps to alter the response and also can affect the Date headers of the object. In any case squid time should be as accurate as it can to provide accurate and valid cache.

At this point I am looking for another opinions and options\scenarios which this issue effect can be understood properly.

(One example of a service that doesn't tolerate time "glitches" is dovecot which recognizes that the server is too far behind or too far ahead and stops functioning in couple scenarios.)

Leaving the report by itself:
Can we define what would a good behavior be from squid side?
If for example the ICAP server is far ahead 20 years from the squid server, should it be considered right?

The basic scenario of ICAP servers with different times is for now on the 24 hours clockwise due to the fact that a ICAP service can sit in one place on earth while the proxy is in another or the two servers local time is configured using a local NTP and with the local time and not UTC\GMT etc related.

I did not reviewed the relevant code yet and hence I do not know the exact reason for that but once we will have a basic idea of what is right and wrong we can decide on the right path for a solution.

Thanks,
Eliezer

Reply via email to