Nice explanation. Thank you very much.<br>This really clear some of my though about some vcl function.<br>Thanks<br>Jewel<br><br><div class="gmail_quote">On Thu, Feb 23, 2012 at 4:22 PM, Michael Alger <span dir="ltr"><<a href="mailto:varnish@mm.quex.org">varnish@mm.quex.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Feb 23, 2012 at 03:29:42PM +0900, Jewel Nuruddin wrote:<br>
> in my VCL configuration<br>
><br>
> sub vcl_recv {<br>
><br>
> ### pass if http hearder response is "SMARTPHONE:1"<br>
> if (req.http.SMARTPHONE ~ "1") {<br>
> return (pass);<br>
> }<br>
> }<br>
><br>
> in my page I set the above header response so if the responses match it<br>
> will not cache<br>
> but it always cache? can some one help me why ?<br>
<br>
</div>The "req" object refers to the headers sent in the client request.<br>
It's unlikely the browser on any device sends a header named<br>
"SMARTPHONE", so that's the reason it won't be matching.<br>
<div class="im"><br>
> One more question, can varnish identified for caching or not caching both<br>
> in http header "response" and "request"?<br>
<br>
</div>Yes it can. The response object is generally called "beresp". However<br>
you can't access it in vcl_recv, since vcl_recv is called when the<br>
client request is initially received - there hasn't been a response<br>
from the backend at this point. vcl_recv is used to rewrite the<br>
request and tell Varnish whether it should try to look up the object<br>
in cache or go direct to the server, as well as selecting which<br>
backend to use. When you return (lookup) you instruct Varnish to look<br>
the object up in its cache, and if it fails to try to fetch it from<br>
the backend.<br>
<br>
You'll therefore want to make your determination as to whether or not<br>
to cache the response in vcl_fetch, which is called immediately after<br>
Varnish has fetched an object from the backend server. From here you<br>
can access the "beresp" object and decide whether or not you want to<br>
cache the response based on any attribute of it, including the<br>
response HTTP headers.<br>
<br>
However:<br>
<br>
It will still be possible for smartphones to have a page served to<br>
them from the cache. For example if the index page of <a href="http://www.example.com" target="_blank">www.example.com</a><br>
returns different content based on the user-agent, if a regular<br>
(non-smartphone) browser accesses the site, Varnish will cache the<br>
response. If a phone then requests it, Varnish will just serve the<br>
previously generated response from its cache. This is because you<br>
haven't told Varnish that requests from "smartphones" need to be<br>
treated differently - only that responses sent to a device the backend<br>
identified as a smartphone should not be cached.<br>
<br>
If you're able to, I'd suggest moving whatever logic the backend uses<br>
to determine if a device is a smartphone out of the backend and into<br>
Varnish, using VCL if possible. This way, Varnish can determine what<br>
it's supposed to do with the request, serving everything it can from<br>
cache and only going to the backend if it really needs to.<br>
<br>
If the determination can _only_ happen on the backend, then you're<br>
going to be forced to send every request that might _possibly_ be from<br>
a smartphone or other "special" device back to the backend, largely<br>
negating the benefits of having Varnish in the first place.<br>
<br>
_______________________________________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org">varnish-misc@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
</blockquote></div><br>