Re: refresh.cc question

> So the meaning of request->flags.nocache_hack is really: "(a) this is
> a reload request, and (b) the configuration file either has at least
> one refresh_pattern with ignore-reload or reload-into-ims, or it has
> reload_into_ims on."

Correct, and this activates a sub-optimal code path capable of dealing
with all these overrides.

> And Squid gets a "Cache-Control: nocache" request for http://
> localhost:3128/index.html. The nocache_hack flag will be true for
> this request, just because of the existence of another refresh_pattern.

Correct, as it needs to query the refresh_pattern to know if the
override is there or not..

> Now I know the refresh.cc snippet quoted in my last email (sort of)
> corrects this in the final else clause by setting the nocache flag,

it's meant to correct all cases.. any differences in the code paths when
no overrides is in effect for the request is bugs and should get
corrected.

> but I think there may still be a problem if anything (specifically
> client_side_reply.cc) relies on nocache_hack meaning anything apart
> from "this is a reload request", since that's the only thing it
> guarantees.

Well, that is the meaning of the flag.

> PS. One tiny bug I've stumbled upon: refresh_nocache_hack isn't reset
> on reconfigure. So if you remove refresh_pattern flags and then
> reconfigure, refresh_nocache_hack is still true. Is something this
> small worth raising a bugzilla for?

Not really. It's harmless.

Should be fixed in Squid-3 now.

REgards
Henrik