On 2014-07-08 08:33, Eliezer Croitoru wrote:
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.
That depends on where the Date header is.
* Date header in the ICAP headers is a bit of a problem. But I think we
can work around it my noting the offset and reporting an error for the
admin to fix.
* Date header in the produced HTTP request/reply headers is kind of
bad. It will screw up the HTTP caching algorithms, - BUT we already have
a prescribed way of handling this in HTTP.
Simply be pessimistic and use the oldest of the available Date values
in the cache algorithm. Worst-case regardless of future or past Date
value is early expiry.
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.
When being pessimistic with time/Date this does not matter. Worst case
is early expiry and request gets passed to the backend server earlier
than expected.
If ICAP is presenting a Reply headers with wrong Date the same
pessimistic output causes the downstream recipient to act pessimistic as
well, or handle the timing error properly if it can.
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
