On 12/07/2013 3:20 a.m., Eliezer Croitoru wrote:
On 07/11/2013 05:03 PM, Amos Jeffries wrote:
On 11/07/2013 11:40 p.m., Eliezer Croitoru wrote:
I have been testing quite some time some urls for cachability.
It seems like there are different methods to request the same file which
leads to different reaction in squid and I want to make sure 100% what
is the cause to the *problem* before I am running to a conclusion since
I am not 100% sure.
Please take your *free* time to read it and see if there is something I
probably missed with hope to understand the issue in hands.\
As you probably noticed from the final diagnois of the last weird case
you brought up it can be important to consider both pairs of
request/reply between both client-squid and squid-server. Either side of
Squid can affect the overall transaction behaviour...
Can you state exactly what the problem is up front? that is a little
unclear from your text.
Sorry about it.
The problem is that admins and me analyse the access.log and consider a
X_HIT response to be a valid HIT response.
I think that the way cache admin analyse the log and understand what the
log means is different from admin to admin.
I wanted to explain in a more detailed way the logic I was explaining
before but since I am not always full of words about it I can describe
it in couple ways and not touch the other admin.
I wanted to make sure that:
1. there is or there isn't a bug related to Vary headers.
2. make sure I understand where in plain view without digging into the
code I understand the bugs and squid behaviour.
3. not just talk without a more detailed debug logs.
4. prove\show squid 3.2\3 changes that you have mentioned about the
no-cache directive which should be documented in a more detailed way.
Since admins dosn't understand it in many cases like I wasn't sure and
pretty confused about it I believe that it helped and will help others
understand the issue.
I think that now that the ignore-no-cache was removed there is might be
a need to add a Warning message while parsing squid.conf that will tell
admins about the new behaviour of refresh_pattern.
There is. You see it with -k parse.
There is the "Removed option ignore-no-cache. Its commonly desired
behaviour is obsoleted by correct HTTP/1.1 Cache-Control:no-cache handling."
But It took me pretty while to actually notice it was there and
understand the meaning of it.
Do you have any better wording?
Amos
