Session issues when using Varnish

Chris Bloom chrisbloom7 at gmail.com
Thu Mar 17 16:59:59 CET 2011


FYI - I forwarded Ken's suggested solution to our Rackspace tech who updated
our config. This appears to have resolved our issue. Thanks!

Chris Bloom
Internet Application Developer


On Wed, Mar 16, 2011 at 6:58 PM, Ken Brownfield <kbrownfield at google.com>wrote:

> Or not set a header at all:
>
> if ( req.url ~
> "^[^\?]*?\.(js|gif|jpg|jpeg|png|ico|css|html|ehtml|shtml|swf)($|\?)" ) {
>      unset req.http.cookie
>     return(lookup);
> }
>
> Didn't test the regex with Varnish's regex handling.
> --
> kb
>
>
>
> On Wed, Mar 16, 2011 at 12:30, AD <straightflush at gmail.com> wrote:
>
>> You can remove the header so it doesnt get set
>>
>> set req.http.ext = regsub( req.url, "\?.+$", "" );
>>     set req.http.ext = regsub( req.http.ext, ".+\.([a-zA-Z]+)$", "\1" );
>>     if( req.http.ext ~
>> "^(js|gif|jpg|jpeg|png|ico|css|html|ehtml|shtml|swf)$" ) {
>>      * remove req.http.ext; *
>>       return(lookup);
>>     }
>>
>>
>>
>> On Wed, Mar 16, 2011 at 2:59 PM, Per Buer <perbu at varnish-software.com>wrote:
>>
>>> Hi David, List.
>>>
>>> I think I'll use this snipplet in the documentation if you don't mind.
>>> I need to work in more regsub calls there anyway.
>>>
>>> Cheers,
>>>
>>> Per.
>>>
>>> On Wed, Mar 16, 2011 at 7:51 PM, David Helkowski <dhelkowski at sbgnet.com>
>>> wrote:
>>> > The vcl you are showing may be standard, but as you have noticed it
>>> will not
>>> > work properly when
>>> > query strings end in a file extension. I encountered this same problem
>>> after
>>> > blindly copying from
>>> > example varnish configurations.
>>> > Before the check is done, the query parameter needs to be stripped from
>>> the
>>> > url.
>>> > Example of an alternate way to check the extensions:
>>> >
>>> > sub vcl_recv {
>>> >     ...
>>> >     set req.http.ext = regsub( req.url, "\?.+$", "" );
>>> >     set req.http.ext = regsub( req.http.ext, ".+\.([a-zA-Z]+)$", "\1"
>>> );
>>> >     if( req.http.ext ~
>>> > "^(js|gif|jpg|jpeg|png|ico|css|html|ehtml|shtml|swf)$" ) {
>>> >       return(lookup);
>>> >     }
>>> >     ...
>>> > }
>>> >
>>> > Doubtless others will say this approach is wrong for some reason or
>>> another.
>>> > I use it in a production
>>> > environment and it works fine though. Pass it along to your hosting
>>> provider
>>> > and request that they
>>> > consider changing their config.
>>> >
>>> > Note that the above code will cause the end user to receive a 'ext'
>>> header
>>> > with the file extension.
>>> > You can add a 'remove req.http.ext' after the code if you don't want
>>> that to
>>> > happen...
>>> >
>>> > Another thing to consider is that whether it this is a bug or not; it
>>> is a
>>> > common problem with varnish
>>> > configurations, and as such can be used on most varnish servers to
>>> force
>>> > them to return things
>>> > differently then they normally would. IE: if some backend script is a
>>> huge
>>> > request and eats up resources, sending
>>> > it a '?.jpg' could be used to hit it repeatedly and bring about a
>>> denial of
>>> > service.
>>> >
>>> > On 3/16/2011 11:55 AM, Chris Bloom wrote:
>>> >
>>> > Thank you, Bjorn, for your response.
>>> > Our hosting provider tells me that the following routines have been
>>> added to
>>> > the default config.
>>> > sub vcl_recv {
>>> >   # Cache things with these extensions
>>> >   if (req.url ~
>>> > "\.(js|css|JPG|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf)$") {
>>> >     unset req.http.cookie;
>>> >     return (lookup);
>>> >   }
>>> > }
>>> > sub vcl_fetch {
>>> >   # Cache things with these extensions
>>> >   if (req.url ~
>>> > "\.(js|css|JPG|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf)$") {
>>> >     unset req.http.set-cookie;
>>> >     set obj.ttl = 1h;
>>> >   }
>>> > }
>>> > Clearly the req.url variable contains the entire request URL, including
>>> the
>>> > querystring. Is there another variable that I should be using instead
>>> that
>>> > would only include the script name? If this is the default behavior,
>>> I'm
>>> > inclined to cry "bug".
>>> > You can test that other script for yourself by substituting
>>> > maxisavergroup.com for the domain in the example URLs I provided.
>>> > PS: We are using Varnish 2.0.6
>>> >
>>> > _______________________________________________
>>> > varnish-misc mailing list
>>> > varnish-misc at varnish-cache.org
>>> > http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>> >
>>> > _______________________________________________
>>> > varnish-misc mailing list
>>> > varnish-misc at varnish-cache.org
>>> > http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>> >
>>>
>>>
>>>
>>> --
>>> Per Buer, Varnish Software
>>> Phone: <%2B47%2021%2098%2092%2061>+47 21 98 92 61 / Mobile:
>>> <%2B47%20958%2039%20117>+47 958 39 117 / Skype: per.buer
>>> Varnish makes websites fly!
>>> Want to learn more about Varnish?
>>> http://www.varnish-software.com/whitepapers
>>>
>>> _______________________________________________
>>> varnish-misc mailing list
>>> varnish-misc at varnish-cache.org
>>> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>
>>
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20110317/101c0385/attachment-0003.html>


More information about the varnish-misc mailing list