On 12.05.2017 07:54, Amos Jeffries wrote:
Also going through the process to deprecate cache directive formally
might be worth beginning - most old uses should be a straight rename
to store_miss, but some will be send_hit or a mix of the two. Just
adding a debugs statement to that effect on startup, reconfigure, and
-k parse should do for a while.
If there are plans about deprecating 'cache' directive, good, but it is a
possibly a future work which is unrelated here. BTW, I think we can't
simply
'rename' it to 'store_miss' or a mix of the two directives because 'cache'
directive supports both fast and slow checks, but both 'store_miss' and
'send_hit' only fast ones. Probably I miss or do_not_understand something
important.
On 12.05.2017 17:32, Amos Jeffries wrote:
That r14984 was itself carefully designed to _revert_ unintentional
side effects hostVerify had on cache directive behaviour. Your patch
is reverting those DUNNO occurances back to the code which had many,
many complaints.
I looked through bug 3940 discussion but have not found any connection
between
ACCESS_DUNNO/ACCESS_AUTH_REQUIRED/checkNoCacheDone() and
hostHeaderVerify()/hostHeaderVerifyFailed() methods. Yes, all these methods
may change RequestFlags flags, and that what
fix of r14984 is about, but how, roughly, hostHeaderVerifyFailed() may cause
ACCESS_DUNNO? In other words, I have not found any hints about your primary
change ACCESS_ALLOWED into ACCESS_DENIED: no in the patch preamble, no
in the bug discussion. I assume there are another threads/bugs where
this change
probably was discussed. If so, could you please post such references here?
Eduard.
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
