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

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
Received on Tue Jul 08 2014 - 06:09:57 MDT