Since there is no clear consensus on this issue, I assume
we should leave 'miss_access' as is. I am still speculating
what to do with 'cache', because there are unanswered
questions in my previous post. Amos, what do you
think about them?
Eduard.
On 12.05.2017 20:24, Eduard Bagdasaryan wrote:
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
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
