Amos Jeffries wrote:
negative_ttl wins.
That seems a violation of the intent of section 13.4 of rfc2616,
specifically the "unless" clause of the following sentence which applies
to "any other status code" (despite the limitation of examples to 302
and 307):
# A response received with any other status code (e.g. status codes 302
# and 307) MUST NOT be returned in a reply to a subsequent request
# unless there are cache-control directives or another header(s) that
# explicitly allow it. For example, these include the following: an
# Expires header (section 14.21); a "max-age", "s-maxage", "must-
# revalidate", "proxy-revalidate", "public" or "private" cache-control
# directive (section 14.9).
Or am I missing some other relevant section?
It should be set to "0 seconds" in any case to retain HTTP standards.
This has been fixed in recent squid releases, though older squid
contains a bad default of more than 0.
Yes, "0 seconds" is required by HTTP/1.1 in the absence of other
headers. However, I think the above implies 'Expires' and other caching
directive headers allow any response to be cacheable for a specified time.
- Gordon @ IA
Mark Nottingham wrote:
What version of Squid are you using?
This changed somewhat in 2.7; IIRC in 2.6 negative_ttl overrides
response freshness, whereas in 2.7 response freshness (i.e., expires
or cache-control) has precedence.
Cheers,
On 02/10/2008, at 3:56 PM, Gordon Mohr wrote:
Using 2.6.14-1ubuntu2 in an reverse/accelerator setup.
My backend/parent is by design setting explicit 'Expires' headers 1
day into the future, even on 404/403/302 response codes.
I'm seeing the 4XX responses later served as TCP_NEGATIVE_HITs, which
is good.
It appears, from my testing, that they are sometimes cached a bit
longer than 'negative_ttl', but they are not cached as long as the
Expires header suggests, even with plentiful cache space.
What is the designed intent of Squid -- should the 'negative_ttl' or
the Expires header be definitive?
- Gordon @ IA
--
Mark Nottingham mnot@xxxxxxxxxxxxx
negative_ttl wins.
It should be set to "0 seconds" in any case to retain HTTP standards.
This has been fixed in recent squid releases, though older squid
contains a bad default of more than 0.
Amos
