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
Received on Sat Sep 10 2005 - 16:40:20 MDT
This archive was generated by hypermail pre-2.1.9 : Sat Oct 01 2005 - 12:00:03 MDT