On Thu, 8 Sep 2005, Matus UHLAR - fantomas wrote:
simply trying showed that the server is not able to understand
Cache-Control: max-age=259200 and refuses the request.
Confirmed.
$ telnet www.evangel.org.sg 80
Trying 203.127.19.66...
Connected to www.evangel.org.sg.
Escape character is '^]'.
GET / HTTP/1.0
Host: www.evangel.org.sg
Cache-Control: max-age=259200
HTTP/1.1 403 Forbidden
Date: Sat, 10 Sep 2005 22:12:54 GMT
Server: Apache/2.0.49 (Unix) DAV/2 mod_fastcgi/2.4.2 mod_ssl/2.0.49 OpenSSL/0.9.6i
Seems there is something (most likely a broken reverse-proxy/accelerator)
at this server mis-reading the max-age Cache-Control directive, denying
the request if max-age is too high. A extremely odd (and broken) thing to
do as max-age works the other way around only requiring special action if
too small.. (and never by a web server anyway).
You can work around this broken web server by using a refresh_pattern
assigning a quite small max-age to objects fetched from this site, at the
expense of less caching of this site.
Add the following to the top of your squid.conf (before any other
refresh_patter rule):
refresh_pattern -i ^http://www.evangel.org.sg 0 30 0
this effectively disables caching of the site. It may be possible to use a
higer max-age but as the exact nature of this server bug is not known I
can not guarantee that doing so won't cause problems with other requests
to the same site.
The index page today accepted a max-age up to 16500 somewhere, increasing
by the second. Why I suspect some kind of reverse-proxy/accelerator
beingthe culpit is because while the max-age limit is increasing by the
second making it somehow tied to the objects age at the server it does not
match the modification age of the document as reported by last-modified.
Regards
Henrik
