What would be the right path for bug 3221? ICAP date header related issue.

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
Received on Mon Jul 07 2014 - 20:36:30 MDT