You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Gokce Toykuyu <go...@yahoo-inc.com> on 2011/11/04 18:44:49 UTC
Cant cache when response Content-Type does not match request Accept
header
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.
Here are some excerpts from TS logs..
Here is the incoming request after it's mapped by TS:
+++++++++ Incoming Request +++++++++
-- State Machine Id: 307
User-Agent: curl/7.21.2 (x86_64-unknown-linux-gnu) libcurl/7.21.2
OpenSSL/1.0.0c zlib/1.2.5 libidn/1.15 libssh2/1.2.7
Host: xxx.com
Accept: text/*, text/html
and it finds bunch of alternates after this point, but it doesn't return
any of them.. and here is the response from the origin server:
+++++++++ Incoming O.S. Response +++++++++
-- State Machine Id: 307
HTTP/1.1 200 OK
Date: Thu, 03 Nov 2011 23:33:45 GMT
Content-Length: 1003
Cache-Control: public,max-age=565
Vary: Accept-Encoding
Connection: close
Content-Type: application/json; charset=UTF-8
and, if the incoming request had "Accept: text/*, text/html, application/*",
then TS returns a cache hit rather than contacting origin server.
Is there a way to force caching even if the "Accept:" header does not
contain the response "Content-Type" or may be something is not
configured correct?
Thank you for all your help.
-Gokce
Re: Cant cache when response Content-Type does not match request
Accept header
Posted by Gokce Toykuyu <go...@yahoo-inc.com>.
I understand. What's funny is, we also don't put the "Vary" header in
our origin response, but some apache plugin must be causing it :) Things
are just running out of control on their own.. :)
I will try to remove the header, and get back with the results.
Thank you for your prompt reply, I appreciate it.
Have a nice week.
-Gokce
On 11/07/2011 10:17 AM, Leif Hedstrom wrote:
> On 11/7/11 11:12 AM, Gokce Toykuyu wrote:
>> 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.
>>
> You should remove the Vary header from the Origin. That settings in ATS will
> not eliminate the Vary: headers. If your origin sends a Vary on some
> headers, ATS will honor it (it really has to).
>
> You could filter out the Vary: header from the origin response in an ATS
> plugin (header_filter in SVN), but, I'd highly recommend against this. If
> you control the origin, fix it.
>
> -- Leif
>
>
Re: Cant cache when response Content-Type does not match request
Accept header
Posted by Leif Hedstrom <zw...@apache.org>.
On 11/7/11 11:12 AM, Gokce Toykuyu wrote:
> 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.
>
You should remove the Vary header from the Origin. That settings in ATS will
not eliminate the Vary: headers. If your origin sends a Vary on some
headers, ATS will honor it (it really has to).
You could filter out the Vary: header from the origin response in an ATS
plugin (header_filter in SVN), but, I'd highly recommend against this. If
you control the origin, fix it.
-- Leif
Re: Cant cache when response Content-Type does not match request
Accept header
Posted by Gokce Toykuyu <go...@yahoo-inc.com>.
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
>>
Re: Cant cache when response Content-Type does not match request
Accept header
Posted by Gokce Toykuyu <go...@yahoo-inc.com>.
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
>
Re: Cant cache when response Content-Type does not match request
Accept header
Posted by Leif Hedstrom <zw...@apache.org>.
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