Hmm, unfortunately disabling the vary headers did not work :(
I will also keep looking if some other plugin is causing this.
Thank you once again for all your help.
Regards,
-Gokce
On 11/07/2011 09:53 AM, Gokce Toykuyu wrote:
Hello Leif,
Thank you for your reply. I appreciate it.
I am attaching the logs to this email. I am sorry I had to clear it a
bit to remove my company specific lines - I hope they were not related.
But the interesting log lines start at 150 to 277 when it is evaluating
the alternates.
And how do I disable the vary on headers? Would I just have to set the
CONFIG proxy.config.http.cache.enable_default_vary_headers INT 1
to
CONFIG proxy.config.http.cache.enable_default_vary_headers INT 0
I will try this and get back to you.
Thank you once again.
Regards,
-Gokce
On 11/04/2011 06:06 PM, Leif Hedstrom wrote:
On 11/4/11 11:44 AM, Gokce Toykuyu wrote:
Hello,
We are trying to utilize TS cache for the responses from our web
service. We seem to have either a configuration issue or an HTTP header
mismatch or..well, we need your help:) basically, in the below
scenario, if I change the Accept: header to include "application/*" or
specifically "application/json" (e.g. Accept: text/*, text/html,
application/json) then it becomes a cache hit on TS and the origin
server is not called. I tried setting the vary headers and alternates
but nothing worked. Unfortunately, we don't have control over the
calling server, which is a middle man between the end user and us, and
it sends the Accept: header in the request but our response is
application/json which gets transmitted through this middle man back to
the caller.
Well, besides that "middle layer" being kinda nutty, why not just turn off
the Vary header in your origin response? Does that not "work" ? I'm not
entirely sure as to why this "breaks" anyways, you are Vary'ing on
Accept-Encoding, which is not the same as "Accept". I'm guessing some logic
here prevents us from accidentally serving out a cache alternate with
certainty that we're doing it right.
-- Leif
