From pinakee at waltzz.com Wed Jun 1 07:09:19 2016 From: pinakee at waltzz.com (Pinakee BIswas) Date: Wed, 1 Jun 2016 10:39:19 +0530 Subject: Cache Invalidation In-Reply-To: References: Message-ID: Hi Dridi, Thanks for your response. I am new to Varnish. Could you please provide an example (detailed one would be nice) for the following approach you suggested? > A different strategy could be to have a "short" TTL, a virtually > infinite grace period (you can also set it via Cache-Control) and make > use of Last-Modified/Etag headers. > > This way Varnish will frequently ask your backend (short TTL) but will > probably serve most requests from cache (high grace) and hammer your > backend more often. The last point can be cheap if you implement IMS > properly in your backend. > > This way you don't need to involve more teams, the people responsible > for the backend's Cache-Control can now handle grace and conditional > requests. > > Cheers Thanks, Pinakee From dridi at varni.sh Wed Jun 1 08:22:05 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 1 Jun 2016 08:22:05 +0200 Subject: Cache Invalidation In-Reply-To: References: Message-ID: > I am new to Varnish. Could you please provide an example (detailed one would > be nice) for the following approach you suggested? I can't give you a detailed example, but I suggest you have a look at the documentation for the grace [1] mode, how to set it [2] via Cache-Control. The Varnish Book also covers HTTP [3] in one chapter, you'll learn more about conditional requests. Cheers [1] https://www.varnish-cache.org/docs/4.1/users-guide/vcl-grace.html [2] https://www.varnish-cache.org/docs/4.1/whats-new/changes.html?highlight=grace#other-noteworthy-small-changes [3] http://book.varnish-software.com/4.0/chapters/HTTP.html From pada at posteo.de Thu Jun 2 21:52:04 2016 From: pada at posteo.de (Daniel Parthey) Date: Thu, 02 Jun 2016 21:52:04 +0200 Subject: Verbose Backend Fetch Error - possible? Message-ID: <51070F7C-8DE7-4C7F-84A4-98B75900EE33@posteo.de> Hi, is there any way in varnish 4.1 to get the FetchError string from VSL (for example: first byte read failed) into a synthesized error message on backend fetch error, so that it does not only show "Backend fetch failed" to the user, but the detailed reason, because there are a lot of reasons why the backend fetch could have failed (connection refused, DNS lookup in named director failed, first byte timeout expired, etc.) I would to generate a (maybe encrypted or obfuscated) verbose message, which the client user can provide to the sysadmin if the backend fails. The sysadmin will then be able to decrypt the message and immediately sees the detailed fetch error, without having to reproduce the issue or having to dig into varnish VSL. Regards Daniel From pinakee at waltzz.com Fri Jun 3 15:12:35 2016 From: pinakee at waltzz.com (Pinakee BIswas) Date: Fri, 3 Jun 2016 18:42:35 +0530 Subject: Doubt regarding ESI and Set-Cookie Message-ID: <48b4d16b-557c-5778-9843-42f797008d01@waltzz.com> Hi, We are using varnish in our production. I have a doubt regarding ESI: In web page, there is esi as follows: /main.html ................... .............. In the above code, the varnish VCL is as follows: sub vcl_recv { if (req.method == "GET") { if ((req.url !~ "^/esi-url") && unset req.http.cookie; # strip the cookies - we don't need them } } } sub vcl_backend_response { if (bereq.method == "GET") { set beresp.do_esi = true; if ((bereq.url !~ "^/esi-url") && { unset beresp.http.Set-Cookie; } } } When browser sends a HTTP request for main.html to varnish, varnish delivers the non-ESI portion from cache and fetches the esi-url from backend. Now for esi-url, backend sets csrf-token in Set-Cookie. My query is : Will varnish pass on the Set-Cookie in HTTP response? I couldn't see it in my setup. Varnish is not passing the Set-Cookie in HTTP response to the Browser. Is there a way for Varnish to pass the Set-Cookie in ESI response? The esi portion could be a form containing a csrf token. Would appreciate clarifications on the above... Thanks, Pinakee From dridi at varni.sh Fri Jun 3 15:55:41 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 3 Jun 2016 15:55:41 +0200 Subject: Doubt regarding ESI and Set-Cookie In-Reply-To: <48b4d16b-557c-5778-9843-42f797008d01@waltzz.com> References: <48b4d16b-557c-5778-9843-42f797008d01@waltzz.com> Message-ID: > My query is : Will varnish pass on the Set-Cookie in HTTP response? Unfortunately not, ESI processing happens during the body fetch so by the time you get the include's Set-Cookie it's already too late. The top response headers have already been sent to the client. From wido at widodh.nl Wed Jun 8 13:21:37 2016 From: wido at widodh.nl (Wido den Hollander) Date: Wed, 8 Jun 2016 13:21:37 +0200 (CEST) Subject: IPv6 for repo.varnish-cache.org Message-ID: <1668709725.1560.1465384897956@ox.pcextreme.nl> Hi, I just noticed that repo.varnish-cache.org is no longer available over IPv6. Does anybody why this is? I have multiple IPv6-only machines which need to install Varnish and I currently am using a proxy to enable them to download the Varnish packages. This might have been forgotten with a recent migration? I'm almost certain it had IPv6 in the past. Thanks! Wido From sujithnss at gmail.com Thu Jun 9 18:44:15 2016 From: sujithnss at gmail.com (sujith pv) Date: Thu, 9 Jun 2016 22:14:15 +0530 Subject: Fwd: Varnish Cache In-Reply-To: References: Message-ID: Hi Team I'm a newbie to Varnish Cache. I have a very basic question around the same. - I'm making a search query for example like http://test.com?query=apple,orange&store=1234 and the same is fetched and cached in Varnish - Now again Im making the same request it gets served from Cache with out a backend fetch - Now if I just pass http://test.com?query=orange,apple&store=1234 , here i just swapped the search keywords. So I'm doubtful, if this query url is unique with previous one or it will be a new backend fetch. Or is there a way we can manipulate the request to match the cached value. Any help will be great... Best Regards Sujith P V -------------- next part -------------- An HTML attachment was scrubbed... URL: From pprocacci at datapipe.com Thu Jun 9 19:20:28 2016 From: pprocacci at datapipe.com (Paul A. Procacci) Date: Thu, 9 Jun 2016 13:20:28 -0400 Subject: Fwd: Varnish Cache In-Reply-To: References: Message-ID: <20160609172028.GA90177@workvm.myhome> It'll fetch from the backend again, by-passing the cache. You can fetch the same contents from ram again by normalizing the parameters to the query. https://info.varnish-software.com/blog/essential-vmods-all-varnish-users-should-know-about The above url describes "their favorite" as being boltsort, but there there others if you desire. ~Paul On Thu, Jun 09, 2016 at 10:14:15PM +0530, sujith pv wrote: > Hi Team > I'm a newbie to Varnish Cache. I have a very basic question around the > same. > > - I'm making a search query for example > like [1]http://test.com?query=apple,orange&store=1234 and the same is > fetched and cached in Varnish > - Now again Im making the same request it gets served from Cache with > out a backend fetch > - Now if I just pass [2]http://test.com?query=orange,apple&store=1234 , > here i just swapped the search keywords. So I'm doubtful, if this query > url is unique with previous one or it will be a new backend fetch. Or > is there a way we can manipulate the request to match the cached value. > Any help will be great... > Best Regards > Sujith P V > > References > > 1. http://test.com/?query=apple,orange&store=1234 > 2. http://test.com/?query=orange,apple&store=1234 > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From pprocacci at datapipe.com Thu Jun 9 19:24:26 2016 From: pprocacci at datapipe.com (Paul A. Procacci) Date: Thu, 9 Jun 2016 13:24:26 -0400 Subject: Fwd: Varnish Cache In-Reply-To: References: Message-ID: <20160609172426.GB90177@workvm.myhome> > Hi Team > I'm a newbie to Varnish Cache. I have a very basic question around the > same. > > - I'm making a search query for example > like [1]http://test.com?query=apple,orange&store=1234 and the same is > fetched and cached in Varnish > - Now again Im making the same request it gets served from Cache with > out a backend fetch > - Now if I just pass [2]http://test.com?query=orange,apple&store=1234 , > here i just swapped the search keywords. So I'm doubtful, if this query > url is unique with previous one or it will be a new backend fetch. Or > is there a way we can manipulate the request to match the cached value. > Any help will be great... > Best Regards > Sujith P V Further to my previous email, boltsort wouldn't change the behavior of: "query=orange,apple" vs "query=apple,orange". For this you can either write embedded C or find a vmod that splits the values based on ',' and sorts those values alphebetically. ~Paul From perbu at varnish-software.com Thu Jun 9 23:17:57 2016 From: perbu at varnish-software.com (Per Buer) Date: Thu, 9 Jun 2016 23:17:57 +0200 Subject: Fwd: Varnish Cache In-Reply-To: <20160609172028.GA90177@workvm.myhome> References: <20160609172028.GA90177@workvm.myhome> Message-ID: Hi, Since that blog post was written we've managed to convince PHK to accept query string sorting into the std vmod - which is bundled with Varnish itself. Now you just do "import std;" and then you can call std.querysort(req.url) to sort the querystring. Per. On Thu, Jun 9, 2016 at 7:20 PM, Paul A. Procacci wrote: > It'll fetch from the backend again, by-passing the cache. > > You can fetch the same contents from ram again by normalizing the > parameters to the query. > > > https://info.varnish-software.com/blog/essential-vmods-all-varnish-users-should-know-about > > The above url describes "their favorite" as being boltsort, but there there > others if you desire. > > ~Paul > > On Thu, Jun 09, 2016 at 10:14:15PM +0530, sujith pv wrote: > > Hi Team > > I'm a newbie to Varnish Cache. I have a very basic question around the > > same. > > > > - I'm making a search query for example > > like [1]http://test.com?query=apple,orange&store=1234 and the same is > > fetched and cached in Varnish > > - Now again Im making the same request it gets served from Cache with > > out a backend fetch > > - Now if I just pass [2]http://test.com?query=orange,apple&store=1234 > , > > here i just swapped the search keywords. So I'm doubtful, if this > query > > url is unique with previous one or it will be a new backend fetch. Or > > is there a way we can manipulate the request to match the cached > value. > > Any help will be great... > > Best Regards > > Sujith P V > > > > References > > > > 1. http://test.com/?query=apple,orange&store=1234 > > 2. http://test.com/?query=orange,apple&store=1234 > > > _______________________________________________ > > varnish-misc mailing list > > varnish-misc at varnish-cache.org > > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- *Per Buer* CTO | Varnish Software AS Cell: +47 95839117 We Make Websites Fly! www.varnish-software.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pprocacci at datapipe.com Thu Jun 9 23:47:31 2016 From: pprocacci at datapipe.com (Paul A. Procacci) Date: Thu, 9 Jun 2016 17:47:31 -0400 Subject: Fwd: Varnish Cache In-Reply-To: References: <20160609172028.GA90177@workvm.myhome> Message-ID: <20160609214730.GC90177@workvm.myhome> On Thu, Jun 09, 2016 at 11:17:57PM +0200, Per Buer wrote: > Hi, > Since that blog post was written we've managed to convince PHK to > accept query string sorting into the std vmod - which is bundled with > Varnish itself. > Now you just do "import std;" and then you can call > std.querysort(req.url) to sort the querystring. > Per. Now that you mention it, I do recall see'ing it in the std vmod. Thanks for reminding me. ~Paul From sujithnss at gmail.com Fri Jun 10 11:18:17 2016 From: sujithnss at gmail.com (sujith pv) Date: Fri, 10 Jun 2016 14:48:17 +0530 Subject: Fwd: Varnish Cache In-Reply-To: <20160609214730.GC90177@workvm.myhome> References: <20160609172028.GA90177@workvm.myhome> <20160609214730.GC90177@workvm.myhome> Message-ID: Thanks all for the help....Sorry for raising one more question as given below I have a scenario around multiple instance of Varnish and trying to build a fail over. For example lets say I have three instances of Varnish for example Varnish A, Varnish B and Varnish C and all are serving the requests. Suppose servers B and C are down, then I need to identify that only Server A is available and it wont be able to serve my traffic. So in this context I will plan some logic in my application to do a fail over and talk directly to the Back end system for some time until Varnish is Up and running. So I'm doubtful how we can track the failures in Varnish, do we have any of the varnishstats indicates us that it has problem and can not serve the traffic or any other way Any help on this.... Best Regards Sujith P V On Fri, Jun 10, 2016 at 3:17 AM, Paul A. Procacci wrote: > On Thu, Jun 09, 2016 at 11:17:57PM +0200, Per Buer wrote: > > Hi, > > Since that blog post was written we've managed to convince PHK to > > accept query string sorting into the std vmod - which is bundled with > > Varnish itself. > > Now you just do "import std;" and then you can call > > std.querysort(req.url) to sort the querystring. > > Per. > > Now that you mention it, I do recall see'ing it in the std vmod. > Thanks for reminding me. > > ~Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Fri Jun 10 11:43:09 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Fri, 10 Jun 2016 11:43:09 +0200 Subject: Fwd: Varnish Cache In-Reply-To: References: <20160609172028.GA90177@workvm.myhome> <20160609214730.GC90177@workvm.myhome> Message-ID: On Fri, Jun 10, 2016 at 11:18 AM, sujith pv wrote: > > So I'm doubtful how we can track the failures in Varnish, do we have any > of the varnishstats indicates us that it has problem and can not serve the > traffic or any other way > That question is actually yours to answer :-) You could use an extra varnish in front of the other and use it as load-balancer, this way you can use the probes to say where to send the request (varnish tier or backend tier). -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujithnss at gmail.com Fri Jun 10 12:11:06 2016 From: sujithnss at gmail.com (sujith pv) Date: Fri, 10 Jun 2016 15:41:06 +0530 Subject: Fwd: Varnish Cache In-Reply-To: References: <20160609172028.GA90177@workvm.myhome> <20160609214730.GC90177@workvm.myhome> Message-ID: Thanks for the reply :-) But I'm trying a monitoring framework called Riemann and we have riemann agents installed across the Varnish servers so that these agents sends the stats to Riemann . These agents are basic ruby clients which reads the varnishstats only. So that I will get all the stats at Riemann end. So I'm confused which stat I can use to decide if Varnish is down or in error. On Fri, Jun 10, 2016 at 3:13 PM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > On Fri, Jun 10, 2016 at 11:18 AM, sujith pv wrote: > >> >> So I'm doubtful how we can track the failures in Varnish, do we have any >> of the varnishstats indicates us that it has problem and can not serve the >> traffic or any other way >> > > That question is actually yours to answer :-) > > You could use an extra varnish in front of the other and use it as > load-balancer, this way you can use the probes to say where to send the > request (varnish tier or backend tier). > > -- > Guillaume Quintard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujithnss at gmail.com Mon Jun 13 16:18:17 2016 From: sujithnss at gmail.com (sujith pv) Date: Mon, 13 Jun 2016 15:18:17 +0100 Subject: Varnishstat In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "sujith pv" Date: 13-Jun-2016 7:27 pm Subject: Varnishstat To: Cc: Hi Team I have a very basic doubt around "varnishstat", suppose if I'm running Varnihstat its giving the aggregated result only. For example like I have some Cache Misses say count 10 between 10.00 AM to 10.10 AM....Now after that say if I check around 11.00 AM, still if it does not have any misses, the old aggregated value shows up as 10. Ideally I will be looking for that particular time value i.e. say I do not have any misses then my value would be 0 at 11.00 AM. But still varnishstat gets you the aggregated value of 10. So is there a way in varnishstat to get the time specific real time data instead of aggregated value as it will ease in plotting any graph and all. Any help please..... Best Regards Sujith P V -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Mon Jun 13 17:04:57 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Mon, 13 Jun 2016 17:04:57 +0200 Subject: Varnishstat In-Reply-To: References: Message-ID: Hi there, just to be clear: you'd want Varnish to hold the history of counter values in memory for you, right? It's not going to happen, simply because it's not Varnish role to do this, but rather a monitoring solution's. What varnish/varnishstat will give you is a snapshot of the counters, at the time you ask for them. So, if you want to get a value over a period, you'll need to ask for the values at the beginning and end of the period and do the subtraction. However, various tools can help you with that, for example collectd ( https://collectd.org/) works pretty well. I'm sure people on this list will have their own recommandations. Cheers -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From naresh5252003 at gmail.com Tue Jun 14 15:21:33 2016 From: naresh5252003 at gmail.com (Naresh Kumar) Date: Tue, 14 Jun 2016 14:21:33 +0100 Subject: Query: Varnish - Cache Message-ID: Hi Guys, I am new to varnish, We have configured the varnish-cache in our application. I have a query - Is there a way to fetch the cached key and value ? -- ------------------------------- With Regards, Penta Naresh Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From pprocacci at datapipe.com Tue Jun 14 19:32:35 2016 From: pprocacci at datapipe.com (Paul A. Procacci) Date: Tue, 14 Jun 2016 13:32:35 -0400 Subject: Query: Varnish - Cache In-Reply-To: References: Message-ID: <20160614173235.GA1225@workvm.myhome> > Hi Guys, > I am new to varnish, We have configured the varnish-cache in our > application. > I have a query - Is there a way to fetch the cached key and value ? You send a HTTP request to the port you have varnsish listening on. This is your key (unless the hash has been altered by your vcl). The response from that request is your value. ~Paul From lagged at gmail.com Tue Jun 14 19:39:58 2016 From: lagged at gmail.com (Andrei) Date: Tue, 14 Jun 2016 20:39:58 +0300 Subject: Custom TTLs Message-ID: Hi all, Excuse my likely noobish mistakes - still getting used to it all. I'm using vsthrottle in vcl_recv to force full cache hits instead of denying requests for request bursts, however I'm having some trouble setting a custom ttl in vcl_backend_response for those which trigger. Is there a way to perhaps set a header/cookie or mark the packet/object in vcl_recv, then set a different beresp.ttl if it exists? For example, I currently have this in vcl_recv: if (vsthrottle.is_denied(req.url, 50, 10s)) { unset req.http.Cookie; unset req.http.User-Agent; unset req.http.Pragma; unset req.http.Cache-Control; set req.http.Attack = "triggered"; return (hash); } Is it possible to trigger an action in vcl_backend_response based on the "Attack" header, or something similar? Any help is greatly appreciated! Best Regards, Andrei -------------- next part -------------- An HTML attachment was scrubbed... URL: From dariuszwu at yahoo.com Wed Jun 15 07:52:01 2016 From: dariuszwu at yahoo.com (Dariusz W) Date: Wed, 15 Jun 2016 05:52:01 +0000 (UTC) Subject: Malicious redirection in Varnish? References: <1520549204.2727831.1465969921294.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1520549204.2727831.1465969921294.JavaMail.yahoo@mail.yahoo.com> Hi, I've installed Varnish 4.1.2 about two weeks ago on Centos 6. A week later some of my domains, top levels only '/', became redirected to amazon site. Subdirectories don't seem to be affected.Flushing url removes redirection for day o two until the next time. Source code was scanned against any malicious code with no positives. As well I cannot find anything suspicious in logs, no varnish commands in syslog, not much in apache and varnish logs. Passwords were changed. The issue occurs on two different vps servers with exact the same source code. X-Forwarded-For and mod_remoteip are used to get client IPs. Before installing Varnish, all domains were online for about two years with no issues. Below are three requests from varnishlog showing affected domain. First is HEAD request from my script monitoring website, Age 0, returning status code 200.?The next one where status code was changed to 302 and redirects traffic to amazon site, Age 0.And the last one, my status monitoring HEAD request returning 302 and Age 17, which means page is delivered from cache. I got two opinions so far that such behaviour is not possible in Varnish level, and must be triggered by some software.After a week I have no idea what else I can do so any suggestions are appreciated. Thank you,Derek * ? << Request ?>> 1218382 ??- ? Begin ? ? ? ? ?req 1218381 rxreq- ? Timestamp ? ? ?Start: 1465944871.292117 0.000000 0.000000- ? Timestamp ? ? ?Req: 1465944871.292117 0.000000 0.000000- ? ReqStart ? ? ? 1.2.3.4 39668- ? ReqMethod ? ? ?HEAD- ? ReqURL ? ? ? ? /- ? ReqProtocol ? ?HTTP/1.1- ? ReqHeader ? ? ?User-Agent: Firefox- ? ReqHeader ? ? ?Host: www.example.com- ? ReqHeader ? ? ?Accept: */*- ? ReqHeader ? ? ?X-Forwarded-For: 1.2.3.4- ? VCL_call ? ? ? RECV- ? VCL_acl ? ? ? ?NO_MATCH forbidden_ip- ? ReqHeader ? ? ?X-Device: pc- ? ReqHeader ? ? ?Cookie:?- ? ReqUnset ? ? ? Cookie:?- ? ReqUnset ? ? ? Host: www.example.com- ? ReqHeader ? ? ?host: www.example.com- ? VCL_acl ? ? ? ?NO_MATCH allowed_ip- ? VCL_return ? ? hash- ? VCL_call ? ? ? HASH- ? VCL_return ? ? lookup- ? Debug ? ? ? ? ?"XXXX HIT-FOR-PASS"- ? HitPass ? ? ? ?1218341- ? VCL_call ? ? ? PASS- ? VCL_return ? ? fetch- ? Link ? ? ? ? ? bereq 1218383 pass- ? Timestamp ? ? ?Fetch: 1465944871.779680 0.487563 0.487563- ? RespProtocol ? HTTP/1.1- ? RespStatus ? ? 200- ? RespReason ? ? OK- ? RespHeader ? ? Date: Tue, 14 Jun 2016 22:54:31 GMT- ? RespHeader ? ? Server: Apache- ? RespHeader ? ? Set-Cookie: PHPSESSID=db67f651e1635d1163145b49622a1639; path=/- ? RespHeader ? ? Expires: Thu, 19 Nov 1981 08:52:00 GMT- ? RespHeader ? ? Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0- ? RespHeader ? ? Pragma: no-cache- ? RespHeader ? ? Content-Type: text/html; charset=utf-8- ? RespHeader ? ? X-Varnish: 1218382- ? RespHeader ? ? Age: 0- ? RespHeader ? ? Via: 1.1 varnish-v4- ? VCL_call ? ? ? DELIVER- ? VCL_return ? ? deliver- ? Timestamp ? ? ?Process: 1465944871.779733 0.487616 0.000054- ? RespHeader ? ? Accept-Ranges: bytes- ? Debug ? ? ? ? ?"RES_MODE 0"- ? RespHeader ? ? Connection: keep-alive- ? Timestamp ? ? ?Resp: 1465944871.779789 0.487672 0.000056- ? ReqAcct ? ? ? ?81 0 81 408 0 408- ? End ? ? ? ? ? ? * ? << Request ?>> 2296119 ??- ? Begin ? ? ? ? ?req 2296117 rxreq- ? Timestamp ? ? ?Start: 1465944914.191716 0.000000 0.000000- ? Timestamp ? ? ?Req: 1465944914.191716 0.000000 0.000000- ? ReqStart ? ? ? 100.43.91.12 48042- ? ReqMethod ? ? ?GET- ? ReqURL ? ? ? ? /- ? ReqProtocol ? ?HTTP/1.1- ? ReqHeader ? ? ?Host: www.example.com- ? ReqHeader ? ? ?Connection: Keep-Alive- ? ReqHeader ? ? ?user-agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)- ? ReqHeader ? ? ?from: support at search.yandex.ru- ? ReqHeader ? ? ?Accept-Encoding: gzip,deflate- ? ReqHeader ? ? ?Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01- ? ReqHeader ? ? ?Accept: */*- ? ReqHeader ? ? ?X-Forwarded-For: 100.43.91.12- ? VCL_call ? ? ? RECV- ? VCL_acl ? ? ? ?NO_MATCH forbidden_ip- ? ReqHeader ? ? ?X-Device: pc- ? ReqHeader ? ? ?Cookie:?- ? ReqUnset ? ? ? Cookie:?- ? ReqUnset ? ? ? Host: www.example.com- ? ReqHeader ? ? ?host: www.example.com- ? VCL_acl ? ? ? ?NO_MATCH allowed_ip- ? VCL_return ? ? hash- ? ReqUnset ? ? ? Accept-Encoding: gzip,deflate- ? ReqHeader ? ? ?Accept-Encoding: gzip- ? VCL_call ? ? ? HASH- ? VCL_return ? ? lookup- ? VCL_call ? ? ? MISS- ? VCL_return ? ? fetch- ? Link ? ? ? ? ? bereq 2296120 fetch- ? Timestamp ? ? ?Fetch: 1465944914.200088 0.008372 0.008372- ? RespProtocol ? HTTP/1.1- ? RespStatus ? ? 302- ? RespReason ? ? Found- ? RespHeader ? ? Date: Tue, 14 Jun 2016 22:55:14 GMT- ? RespHeader ? ? Server: Apache- ? RespHeader ? ? Cache-Control: max-age=2592000- ? RespHeader ? ? Expires: Thu, 14 Jul 2016 22:55:14 GMT- ? RespHeader ? ? Content-Length: 205- ? RespHeader ? ? Content-Type: text/html; charset=iso-8859-1- ? RespHeader ? ? Location: http://www.amazon.com- ? RespHeader ? ? X-Varnish: 2296119- ? RespHeader ? ? Age: 0- ? RespHeader ? ? Via: 1.1 varnish-v4- ? VCL_call ? ? ? DELIVER- ? VCL_return ? ? deliver- ? Timestamp ? ? ?Process: 1465944914.200132 0.008417 0.000044- ? Debug ? ? ? ? ?"RES_MODE 2"- ? RespHeader ? ? Connection: keep-alive- ? Timestamp ? ? ?Resp: 1465944914.200198 0.008483 0.000066- ? ReqAcct ? ? ? ?285 0 285 319 205 524- ? End ? ? ? ? ? ? * ? << Request ?>> 2296134 ??- ? Begin ? ? ? ? ?req 2296133 rxreq- ? Timestamp ? ? ?Start: 1465944930.719179 0.000000 0.000000- ? Timestamp ? ? ?Req: 1465944930.719179 0.000000 0.000000- ? ReqStart ? ? ? 70.27.178.167 39686- ? ReqMethod ? ? ?HEAD- ? ReqURL ? ? ? ? /- ? ReqProtocol ? ?HTTP/1.1- ? ReqHeader ? ? ?User-Agent: Firefox- ? ReqHeader ? ? ?Host: www.example.com- ? ReqHeader ? ? ?Accept: */*- ? ReqHeader ? ? ?X-Forwarded-For: 70.27.178.167- ? VCL_call ? ? ? RECV- ? VCL_acl ? ? ? ?NO_MATCH forbidden_ip- ? ReqHeader ? ? ?X-Device: pc- ? ReqHeader ? ? ?Cookie:?- ? ReqUnset ? ? ? Cookie:?- ? ReqUnset ? ? ? Host: www.example.com- ? ReqHeader ? ? ?host: www.example.com- ? VCL_acl ? ? ? ?NO_MATCH allowed_ip- ? VCL_return ? ? hash- ? VCL_call ? ? ? HASH- ? VCL_return ? ? lookup- ? Hit ? ? ? ? ? ?2296120- ? VCL_call ? ? ? HIT- ? VCL_return ? ? deliver- ? RespProtocol ? HTTP/1.1- ? RespStatus ? ? 302- ? RespReason ? ? Found- ? RespHeader ? ? Date: Tue, 14 Jun 2016 22:55:14 GMT- ? RespHeader ? ? Server: Apache- ? RespHeader ? ? Cache-Control: max-age=2592000- ? RespHeader ? ? Expires: Thu, 14 Jul 2016 22:55:14 GMT- ? RespHeader ? ? Content-Length: 205- ? RespHeader ? ? Content-Type: text/html; charset=iso-8859-1- ? RespHeader ? ? Location: http://www.amazon.com- ? RespHeader ? ? X-Varnish: 2296134 2296120- ? RespHeader ? ? Age: 17- ? RespHeader ? ? Via: 1.1 varnish-v4- ? VCL_call ? ? ? DELIVER- ? VCL_return ? ? deliver- ? Timestamp ? ? ?Process: 1465944930.719297 0.000118 0.000118- ? Debug ? ? ? ? ?"RES_MODE 0"- ? RespHeader ? ? Connection: keep-alive- ? Timestamp ? ? ?Resp: 1465944930.719347 0.000169 0.000051- ? ReqAcct ? ? ? ?81 0 81 328 0 328- ? End ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkarsten at varnish-software.com Wed Jun 15 15:13:31 2016 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Wed, 15 Jun 2016 15:13:31 +0200 Subject: Varnish Cache 4.1.3-beta1 out, please test. Message-ID: <20160615131330.GA18934@immer.varnish-software.com> Hi. I've just tagged 4.1.3-beta1 and uploaded the tarball to https://repo.varnish-cache.org/source/ The list of changes[1] since 4.1.2 is significant and I recommend anyone seeing issues with previous 4.1 releases to upgrade now. 4.1.3 final will be out in about two weeks unless something unexpected happens. Please give the code a go and let me know if you find any issues. 1: https://github.com/varnishcache/varnish-cache/blob/4.1/doc/changes.rst -- Lasse Karstensen Varnish Software AS From lkarsten at varnish-software.com Thu Jun 16 12:38:34 2016 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Thu, 16 Jun 2016 12:38:34 +0200 Subject: beta debs/rpms (Was: Re: Varnish Cache 4.1.3-beta1 out, please test.) In-Reply-To: <20160615131330.GA18934@immer.varnish-software.com> References: <20160615131330.GA18934@immer.varnish-software.com> Message-ID: <20160616103833.GA27108@immer.varnish-software.com> On Wed, Jun 15, 2016 at 03:13:31PM +0200, Lasse Karstensen wrote: > I've just tagged 4.1.3-beta1 and uploaded the tarball to > https://repo.varnish-cache.org/source/ I've updated the web page with links to the CI built debian and rpm packages of 4.1.3-beta1. https://www.varnish-cache.org/releases/index.html#current-and-older-releases This should make it easier to upgrade to the new code. Please test it! :-) -- Lasse Karstensen Varnish Software AS From A.Hongens at netmatch.nl Thu Jun 16 14:33:40 2016 From: A.Hongens at netmatch.nl (=?iso-8859-1?Q?Angelo_H=F6ngens?=) Date: Thu, 16 Jun 2016 12:33:40 +0000 Subject: Varnish caching and the X-Requested-With header Message-ID: <6A7ABA19243F1E4EADD8BB1563CDDCCB8A9D8CE0@TIL-EXCH-05.netmatch.local> While talking to other peeps at varnishcon here I remembered I hadn't answered this issue. I solved it on my side back in Januari by overriding this behavior in vcl_recv. No idea though why varnish decided they were uncacheable in the first place. sub vcl_recv { .. # By default varnish won't cache object with the X-Requested-With header, like # for AJAX requests. We will override this behaviour. NetMatch Ticket #43946 if(req.http.X-Requested-With == "XMLHttpRequest") { return (hash); } .. } Angelo. > Hi Angelo, > > Your first step should be to look at the varnishlog, find the relevant > request, and compare with what your vcl (and the builtin one) to understand > the behaviour. > > -- > Guillaume Quintard > > On Thu, Jan 14, 2016 at 8:55 PM, Angelo H?ngens > wrote: > >> Hey, I'm trying to debug varnish not caching some request. I see the >> uncacheable object has the request header X-Requested-With: XMLHttpRequest, >> and I guess that somehow make Varnish not cache the request. But I cannot >> find this anywhere in the documentation. Is this expected behavior? In >> which module (vcl_recv, vcl_deliver) can I undo this behavior? >> >> -- >> >> With kind regards, >> >> Angelo H?ngens >> Systems Administrator From albert.tollkuci at gmail.com Fri Jun 17 17:35:45 2016 From: albert.tollkuci at gmail.com (=?UTF-8?Q?Albert_Tollku=C3=A7i?=) Date: Fri, 17 Jun 2016 17:35:45 +0200 Subject: Error 503 Backend fetch failed - XID: 208396 Message-ID: Hello, I configured varnish a few weeks ago and things were running OK. Suddently yesterday it stopped working with the following error: *Error 503 Backend fetch failed* *Backend fetch failed* *Guru Meditation:* *XID: 208396* Here it's the result of varnishlog: ** << Request >> 65581* *- Begin req 2 rxreq* *- Timestamp Start: 1466080309.362022 0.000000 0.000000* *- Timestamp Req: 1466080309.362022 0.000000 0.000000* *- ReqStart 66.249.64.175 47813* *- ReqMethod GET* *- ReqURL /lajme/c66d2a2515/news.aspx* *- ReqProtocol HTTP/1.1* *- ReqHeader Host: time.ikub.al * *- ReqHeader Connection: Keep-alive* *- ReqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8* *- ReqHeader From: googlebot(at)googlebot.com * *- ReqHeader User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html )* *- ReqHeader Accept-Encoding: gzip,deflate,br* *- ReqHeader If-Modified-Since: Wed, 15 Jun 2016 07:10:05 UTC* *- ReqHeader X-Forwarded-For: 66.249.64.175* *- VCL_call RECV* *- ReqUnset Host: time.ikub.al * *- ReqHeader Host: time.ikub.al * *- ReqURL /lajme/c66d2a2515/news.aspx* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- VCL_return hash* *- ReqUnset Accept-Encoding: gzip,deflate,br* *- ReqHeader Accept-Encoding: gzip* *- VCL_call HASH* *- VCL_return lookup* *- Debug "XXXX MISS"* *- VCL_call MISS* *- ReqHeader x-state: MISS* *- VCL_return fetch* *- Link bereq 65582 fetch* *- Timestamp Fetch: 1466080309.362211 0.000190 0.000190* *- RespProtocol HTTP/1.1* *- ^C* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- ReqHeader Cookie:* *- ReqUnset Cookie:* *- VCL_return hash* *- ReqUnset Accept-Encoding: gzip,deflate,br* *- ReqHeader Accept-Encoding: gzip* *- VCL_call HASH* *- VCL_return lookup* *- Debug "XXXX MISS"* *- VCL_call MISS* *- ReqHeader x-state: MISS* *- VCL_return fetch* *- Link bereq 32810 fetch* *- Timestamp Fetch: 1466080311.215487 0.000181 0.000181* *- RespProtocol HTTP/1.1* *- RespStatus 503* *- RespReason Backend fetch failed* *- RespHeader Date: Thu, 16 Jun 2016 12:31:51 GMT* *- RespHeader Server: Varnish* *- RespHeader Content-Type: text/html; charset=utf-8* *- RespHeader Retry-After: 5* *- RespHeader X-Varnish: 32809* *- RespHeader Age: 0* *- RespHeader Via: 1.1 varnish-v4* *- VCL_call DELIVER* *- RespHeader X-Cache: MISS* *- RespHeader X-Cache-Hits: 0* *- RespUnset Server: Varnish* *- RespUnset X-Varnish: 32809* *- RespUnset Via: 1.1 varnish-v4* *- VCL_return deliver* *- Timestamp Process: 1466080311.215512 0.000206 0.000025* *- RespHeader Content-Length: 282* *- Debug "RES_MODE 2"* *- RespHeader Connection: keep-alive* *- Timestamp Resp: 1466080311.215539 0.000233 0.000027* *- Debug "XXX REF 1"* *- ReqAcct 389 0 389 215 282 497* I have tested the same page with: *curl time.ikub.al/lajme/c66d2a2515/news.aspx * and it's working fine. Headers from curl are: ** Trying 13.94.212.211...* ** Connected to time.ikub.al (13.94.212.211) port 80 (#0)* *> HEAD /lajme/c66d2a2515/news.aspx HTTP/1.1* *> Host: time.ikub.al * *> User-Agent: curl/7.43.0* *> Accept: */** *>* *< HTTP/1.1 200 OK* *HTTP/1.1 200 OK* *< Cache-Control: private* *Cache-Control: private* *< Content-Length: 93606* *Content-Length: 93606* *< Content-Type: text/html; charset=utf-8* *Content-Type: text/html; charset=utf-8* *< Last-Modified: Fri, 06 Sep 2013 11:50:00 GMT* *Last-Modified: Fri, 06 Sep 2013 11:50:00 GMT* *< Server: Microsoft-IIS/8.5* *Server: Microsoft-IIS/8.5* *< X-AspNet-Version: 2.0.50727* *X-AspNet-Version: 2.0.50727* *< X-Powered-By: ASP.NET * *X-Powered-By: ASP.NET * *< Date: Fri, 17 Jun 2016 15:31:24 GMT* *Date: Fri, 17 Jun 2016 15:31:24 GMT* Any idea what may be causing this? Thank you, Albert -- Web: http://www.tollkuci.com Follow me on: LinkedIn Google+ Facebook Twitter Career 2.0 ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.tollkuci at gmail.com Mon Jun 20 09:29:52 2016 From: albert.tollkuci at gmail.com (=?UTF-8?Q?Albert_Tollku=C3=A7i?=) Date: Mon, 20 Jun 2016 09:29:52 +0200 Subject: Error 503 Backend fetch failed - XID: 208396 In-Reply-To: References: Message-ID: Something else that I found out is that no request is actually being made to the backend server (at least nothing shows up in the log). It looks like varnish is not even trying to fetch the page... Albert On Fri, Jun 17, 2016 at 5:35 PM, Albert Tollku?i wrote: > Hello, > I configured varnish a few weeks ago and things were running OK. Suddently > yesterday it stopped working with the following error: > *Error 503 Backend fetch failed* > > *Backend fetch failed* > *Guru Meditation:* > > *XID: 208396* > Here it's the result of varnishlog: > > ** << Request >> 65581* > *- Begin req 2 rxreq* > *- Timestamp Start: 1466080309.362022 0.000000 0.000000* > *- Timestamp Req: 1466080309.362022 0.000000 0.000000* > *- ReqStart 66.249.64.175 47813* > *- ReqMethod GET* > *- ReqURL /lajme/c66d2a2515/news.aspx* > *- ReqProtocol HTTP/1.1* > *- ReqHeader Host: time.ikub.al * > *- ReqHeader Connection: Keep-alive* > *- ReqHeader Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8* > *- ReqHeader From: googlebot(at)googlebot.com > * > *- ReqHeader User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; > +http://www.google.com/bot.html )* > *- ReqHeader Accept-Encoding: gzip,deflate,br* > *- ReqHeader If-Modified-Since: Wed, 15 Jun 2016 07:10:05 UTC* > *- ReqHeader X-Forwarded-For: 66.249.64.175* > *- VCL_call RECV* > *- ReqUnset Host: time.ikub.al * > *- ReqHeader Host: time.ikub.al * > *- ReqURL /lajme/c66d2a2515/news.aspx* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- VCL_return hash* > *- ReqUnset Accept-Encoding: gzip,deflate,br* > *- ReqHeader Accept-Encoding: gzip* > *- VCL_call HASH* > *- VCL_return lookup* > *- Debug "XXXX MISS"* > *- VCL_call MISS* > *- ReqHeader x-state: MISS* > *- VCL_return fetch* > *- Link bereq 65582 fetch* > *- Timestamp Fetch: 1466080309.362211 0.000190 0.000190* > *- RespProtocol HTTP/1.1* > *- ^C* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- ReqHeader Cookie:* > *- ReqUnset Cookie:* > *- VCL_return hash* > *- ReqUnset Accept-Encoding: gzip,deflate,br* > *- ReqHeader Accept-Encoding: gzip* > *- VCL_call HASH* > *- VCL_return lookup* > *- Debug "XXXX MISS"* > *- VCL_call MISS* > *- ReqHeader x-state: MISS* > *- VCL_return fetch* > *- Link bereq 32810 fetch* > *- Timestamp Fetch: 1466080311.215487 0.000181 0.000181* > *- RespProtocol HTTP/1.1* > *- RespStatus 503* > *- RespReason Backend fetch failed* > *- RespHeader Date: Thu, 16 Jun 2016 12:31:51 GMT* > *- RespHeader Server: Varnish* > *- RespHeader Content-Type: text/html; charset=utf-8* > *- RespHeader Retry-After: 5* > *- RespHeader X-Varnish: 32809* > *- RespHeader Age: 0* > *- RespHeader Via: 1.1 varnish-v4* > *- VCL_call DELIVER* > *- RespHeader X-Cache: MISS* > *- RespHeader X-Cache-Hits: 0* > *- RespUnset Server: Varnish* > *- RespUnset X-Varnish: 32809* > *- RespUnset Via: 1.1 varnish-v4* > *- VCL_return deliver* > *- Timestamp Process: 1466080311.215512 0.000206 0.000025* > *- RespHeader Content-Length: 282* > *- Debug "RES_MODE 2"* > *- RespHeader Connection: keep-alive* > *- Timestamp Resp: 1466080311.215539 0.000233 0.000027* > *- Debug "XXX REF 1"* > *- ReqAcct 389 0 389 215 282 497* > > I have tested the same page with: > > > *curl time.ikub.al/lajme/c66d2a2515/news.aspx > * > > and it's working fine. Headers from curl are: > > ** Trying 13.94.212.211...* > ** Connected to time.ikub.al (13.94.212.211) port 80 > (#0)* > *> HEAD /lajme/c66d2a2515/news.aspx HTTP/1.1* > *> Host: time.ikub.al * > *> User-Agent: curl/7.43.0* > *> Accept: */** > *>* > *< HTTP/1.1 200 OK* > *HTTP/1.1 200 OK* > *< Cache-Control: private* > *Cache-Control: private* > *< Content-Length: 93606* > *Content-Length: 93606* > *< Content-Type: text/html; charset=utf-8* > *Content-Type: text/html; charset=utf-8* > *< Last-Modified: Fri, 06 Sep 2013 11:50:00 GMT* > *Last-Modified: Fri, 06 Sep 2013 11:50:00 GMT* > *< Server: Microsoft-IIS/8.5* > *Server: Microsoft-IIS/8.5* > *< X-AspNet-Version: 2.0.50727* > *X-AspNet-Version: 2.0.50727* > *< X-Powered-By: ASP.NET * > *X-Powered-By: ASP.NET * > *< Date: Fri, 17 Jun 2016 15:31:24 GMT* > *Date: Fri, 17 Jun 2016 15:31:24 GMT* > > Any idea what may be causing this? > > Thank you, > Albert > > > -- > Web: http://www.tollkuci.com > Follow me on: LinkedIn Google+ > Facebook > Twitter > Career 2.0 > > ------------------------------ > > -- Web: http://www.tollkuci.com Follow me on: LinkedIn Google+ Facebook Twitter Career 2.0 ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxcvbn4038 at gmail.com Tue Jun 21 17:46:02 2016 From: zxcvbn4038 at gmail.com (CJ Ess) Date: Tue, 21 Jun 2016 11:46:02 -0400 Subject: Doing gunzip for clients that don't support gzip encoding Message-ID: Does anyone have a vcl snippet for this? For requests to the backend I always want to have accept-coding gzip set so that the backend compresses the response and it is stored compressed in varnish. However, if a request comes in without accept-coding gzip then I want to dynamically uncompress the cached response and serve it to the user. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Tue Jun 21 18:55:47 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Tue, 21 Jun 2016 09:55:47 -0700 Subject: Error 503 Backend fetch failed - XID: 208396 In-Reply-To: References: Message-ID: Have you checked your probes? If the backend is recognized as sick, indeed Varnish won't even bother sending a request. -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From toscano.luca at gmail.com Tue Jun 21 19:27:43 2016 From: toscano.luca at gmail.com (Luca Toscano) Date: Tue, 21 Jun 2016 19:27:43 +0200 Subject: VSL Timeout and Varnishkafka Message-ID: Hi all, I am working on Varnishkafka (https://github.com/wikimedia/varnishkafka), happily supporting Varnish 4 and its new VSL API. Varnishkafka allows a user to insert the Start SLT_Timestamp or the Resp one into a logline, formatted following a custom strftime string, and only recently I got some reports of logs showing an empty value instead of the Resp timestamp. After a bit of research, I discovered that some particular requests (mostly long tar.gz downloads or Websocket Upgrade request) were missing the Resp timestamp and showing the following lines (grabbed from varnishlog): - VSL timeout - End synth I discovered from https://www.varnish-cache.org/docs/trunk/reference/vsl.html that the VSL tag is related to error/warnings using the VSL api, but nothing specific so I tried to dig a bit more into the code: - https://github.com/varnishcache/varnish-cache/blob/4.1/lib/libvarnishapi/vsl_arg.c#L350 - https://github.com/varnishcache/varnish-cache/blob/4.1/include/vapi/vapi_options.h#L80 - https://github.com/varnishcache/varnish-cache/blob/4.1/lib/libvarnishapi/vsl.c#L103 - https://github.com/varnishcache/varnish-cache/blob/4.1/lib/libvarnishapi/vsl_dispatch.c#L1342 I tried to simulate a backend fetch timeout with Varnish + Apache + PHP-FPM running a simple script sleeping for minutes, but I wasn't able to reproduce the VSL timeout (120 seconds by default as far as I understand). I am probably missing something trivial but I don't really know how to clearly identify where the issue comes from. My plan would be to add the "-T" parameter support to Varnishkafka but I'd prefer to have some explanation about what a VSL timeout is before proceeding. Thanks a lot in advance! Regards, Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Tue Jun 21 19:42:37 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Tue, 21 Jun 2016 10:42:37 -0700 Subject: Fwd: Varnish Cache In-Reply-To: References: <20160609172028.GA90177@workvm.myhome> <20160609214730.GC90177@workvm.myhome> Message-ID: Hum, you can look at the uptime, and see if it resets. You can also look at the dropped/failed sessions and backend failures. Best thing is probably to look at "man varnish-counters" and pick what makes sense. -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff at uplex.de Tue Jun 21 20:27:01 2016 From: geoff at uplex.de (Geoff Simmons) Date: Tue, 21 Jun 2016 20:27:01 +0200 Subject: VSL Timeout and Varnishkafka In-Reply-To: References: Message-ID: <4957aa32-dbc0-599b-c6fd-4593eff3bf2f@uplex.de> On 06/21/2016 07:27 PM, Luca Toscano wrote: > > - VSL timeout - End synth The timeout (-T arg of the VSL tools) starts when the Begin tag for a transaction is read from shared memory, and ticks until the End tag is read for that transaction. If End is not encountered before the timeout expires, you get the synthesized VSL record. So in your example, VSL isn't seeing End in the log before the timeout elapses, probably 120 seconds if you haven't changed the default. This could happen, for example, if you have a response that takes that long to complete. To set the timeout in a VSL client, you can use: VSL_Arg(vsl, 'T', timeout) ... where timeout is a string containing decimal digits. varnishevent is very similar to varnishkafka and supports -T, you can see some working code here: https://code.uplex.de/uplex-varnish/varnishevent/blob/master/src/varnishevent.c#L641 HTH, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From toscano.luca at gmail.com Wed Jun 22 11:59:35 2016 From: toscano.luca at gmail.com (Luca Toscano) Date: Wed, 22 Jun 2016 11:59:35 +0200 Subject: VSL Timeout and Varnishkafka In-Reply-To: <4957aa32-dbc0-599b-c6fd-4593eff3bf2f@uplex.de> References: <4957aa32-dbc0-599b-c6fd-4593eff3bf2f@uplex.de> Message-ID: 2016-06-21 20:27 GMT+02:00 Geoff Simmons : First of all thanks a lot for the answer! On 06/21/2016 07:27 PM, Luca Toscano wrote: > > > > - VSL timeout - End synth > > The timeout (-T arg of the VSL tools) starts when the Begin tag for a > transaction is read from shared memory, and ticks until the End tag is > read for that transaction. If End is not encountered before the > timeout expires, you get the synthesized VSL record. > > So in your example, VSL isn't seeing End in the log before the timeout > elapses, probably 120 seconds if you haven't changed the default. This > could happen, for example, if you have a response that takes that long > to complete. > My understanding is that a Varnish worker will flush all the tags related to a specific request only when it is done with it (this is what I got from https://info.varnish-software.com/blog/understanding-timeouts-varnish-cache). As written in my past email I tried to set up a basic backend timeout scenario but I wasn't able to reproduce the VSL error. More details: - Varnish -> Apache -> PHP-FPM <-> php script that sleeps for 200 seconds before emitting HTML - Varnish is configured with default parameters plus "-p first_byte_timeout=150" (note: bigger than the 120 seconds set by default for VSL timeout, the default one is 60) - a simple curl request for the URL that runs the PHP script correctly triggers a backend fetch timeout, but Begin|End SLT Timestamps are there. - I also tried with varnishlog -g request -T 5 to force a VSL Timeout, but didn't succeed. Is it possible that the VSL timeout is something related only to the data flow between SHM and varnishkafka (so not related to the time taken by a Varnish worker to serve a request) ? If this is completely false and incorrect, would you mind to give me a more specific example about how to trigger a VSL timeout? > > To set the timeout in a VSL client, you can use: > > VSL_Arg(vsl, 'T', timeout) > > ... where timeout is a string containing decimal digits. > > varnishevent is very similar to varnishkafka and supports -T, you can > see some working code here: > > > https://code.uplex.de/uplex-varnish/varnishevent/blob/master/src/varnishevent.c#L641 Thanks for the link, I implemented the -T exactly in the same way yesterday for Varnishkafka, really good to have a working example to confirm my code. Also, Varnishevent looks really awesome, nice work! Looking forward to test it :) Regards, Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From toscano.luca at gmail.com Wed Jun 22 13:04:42 2016 From: toscano.luca at gmail.com (Luca Toscano) Date: Wed, 22 Jun 2016 13:04:42 +0200 Subject: VSL Timeout and Varnishkafka In-Reply-To: References: <4957aa32-dbc0-599b-c6fd-4593eff3bf2f@uplex.de> Message-ID: 2016-06-22 11:59 GMT+02:00 Luca Toscano : > > > 2016-06-21 20:27 GMT+02:00 Geoff Simmons : > > First of all thanks a lot for the answer! > > On 06/21/2016 07:27 PM, Luca Toscano wrote: >> > >> > - VSL timeout - End synth >> >> The timeout (-T arg of the VSL tools) starts when the Begin tag for a >> transaction is read from shared memory, and ticks until the End tag is >> read for that transaction. If End is not encountered before the >> timeout expires, you get the synthesized VSL record. >> >> So in your example, VSL isn't seeing End in the log before the timeout >> elapses, probably 120 seconds if you haven't changed the default. This >> could happen, for example, if you have a response that takes that long >> to complete. >> > > My understanding is that a Varnish worker will flush all the tags related > to a specific request only when it is done with it (this is what I got from > https://info.varnish-software.com/blog/understanding-timeouts-varnish-cache). > As written in my past email I tried to set up a basic backend timeout > scenario but I wasn't able to reproduce the VSL error. More details: > > - Varnish -> Apache -> PHP-FPM <-> php script that sleeps for 200 seconds > before emitting HTML > - Varnish is configured with default parameters plus "-p > first_byte_timeout=150" (note: bigger than the 120 seconds set by default > for VSL timeout, the default one is 60) > - a simple curl request for the URL that runs the PHP script correctly > triggers a backend fetch timeout, but Begin|End SLT Timestamps are there. > - I also tried with varnishlog -g request -T 5 to force a VSL Timeout, but > didn't succeed. > > Is it possible that the VSL timeout is something related only to the data > flow between SHM and varnishkafka (so not related to the time taken by a > Varnish worker to serve a request) ? > > If this is completely false and incorrect, would you mind to give me a > more specific example about how to trigger a VSL timeout? > > >> >> To set the timeout in a VSL client, you can use: >> >> VSL_Arg(vsl, 'T', timeout) >> >> ... where timeout is a string containing decimal digits. >> >> varnishevent is very similar to varnishkafka and supports -T, you can >> see some working code here: >> >> >> https://code.uplex.de/uplex-varnish/varnishevent/blob/master/src/varnishevent.c#L641 > > > Thanks for the link, I implemented the -T exactly in the same way > yesterday for Varnishkafka, really good to have a working example to > confirm my code. Also, Varnishevent looks really awesome, nice work! > Looking forward to test it :) > > Nice test that I found in the Varnish codebase (meant to trigger a VSL timeout): https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishtest/tests/r01762.vtc#L29 Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff at uplex.de Wed Jun 22 13:33:22 2016 From: geoff at uplex.de (Geoff Simmons) Date: Wed, 22 Jun 2016 13:33:22 +0200 Subject: VSL Timeout and Varnishkafka In-Reply-To: References: <4957aa32-dbc0-599b-c6fd-4593eff3bf2f@uplex.de> Message-ID: <859f74be-ed95-5795-4e82-27342aadfca0@uplex.de> On 06/22/2016 01:04 PM, Luca Toscano wrote: > > Nice test that I found in the Varnish codebase (meant to trigger a > VSL timeout): > > https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishtest/tests/r01762.vtc#L29 That's > probably your best bet. Otherwise, triggering VSL timeouts can be tricky, because there are a lot of things going on that are hard to control. You said that your PHP script sleeps before emitting "HTML" -- if that's what you really meant, then your response probably sent headers, and then went to sleep before sending the body. In that case, there won't be a first_byte_timeout -- the timeout is until any part of the response arrives, including headers. You could try the same trick but with a large between_bytes_timeout. Or find a way to send nothing at all, not even headers, until the first_byte_timeout elapses. I have in fact seen VSL timeouts in production as a result of long-running responses, but if you want to reliably reproduce it that way, try making the time differences very large -- say timeouts=150s, and have your backend delay the response for five minutes. HTH, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dridi at varni.sh Wed Jun 22 14:16:44 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 22 Jun 2016 14:16:44 +0200 Subject: Doing gunzip for clients that don't support gzip encoding In-Reply-To: References: Message-ID: On Tue, Jun 21, 2016 at 5:46 PM, CJ Ess wrote: > Does anyone have a vcl snippet for this? It sounds like default behavior, Varnish will by default advertise gzip support to backends and gunzip on the fly for clients that don't. From zxcvbn4038 at gmail.com Wed Jun 22 21:19:13 2016 From: zxcvbn4038 at gmail.com (CJ Ess) Date: Wed, 22 Jun 2016 15:19:13 -0400 Subject: Doing gunzip for clients that don't support gzip encoding In-Reply-To: References: Message-ID: There we go, problem solved. ;) Thanks! On Wed, Jun 22, 2016 at 8:16 AM, Dridi Boukelmoune wrote: > On Tue, Jun 21, 2016 at 5:46 PM, CJ Ess wrote: > > Does anyone have a vcl snippet for this? > > It sounds like default behavior, Varnish will by default advertise > gzip support to backends and gunzip on the fly for clients that > don't. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toscano.luca at gmail.com Thu Jun 23 11:35:47 2016 From: toscano.luca at gmail.com (Luca Toscano) Date: Thu, 23 Jun 2016 11:35:47 +0200 Subject: VSL Timeout and Varnishkafka In-Reply-To: <859f74be-ed95-5795-4e82-27342aadfca0@uplex.de> References: <4957aa32-dbc0-599b-c6fd-4593eff3bf2f@uplex.de> <859f74be-ed95-5795-4e82-27342aadfca0@uplex.de> Message-ID: 2016-06-22 13:33 GMT+02:00 Geoff Simmons : > On 06/22/2016 01:04 PM, Luca Toscano wrote: > > > > Nice test that I found in the Varnish codebase (meant to trigger a > > VSL timeout): > > > > > https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishtest/tests/r01762.vtc#L29 > > That's > > > probably your best bet. Otherwise, triggering VSL timeouts can > be tricky, because there are a lot of things going on that are hard to > control. > > You said that your PHP script sleeps before emitting "HTML" -- if > that's what you really meant, then your response probably sent > headers, and then went to sleep before sending the body. In that case, > there won't be a first_byte_timeout -- the timeout is until any part > of the response arrives, including headers. > Sorry, what I meant to say was the whole request (headers included). > > You could try the same trick but with a large between_bytes_timeout. > Or find a way to send nothing at all, not even headers, until the > first_byte_timeout elapses. > > I have in fact seen VSL timeouts in production as a result of > long-running responses, but if you want to reliably reproduce it that > way, try making the time differences very large -- say timeouts=150s, > and have your backend delay the response for five minutes. > > Thanks to the Varnish devs on IRC I found a way to repro and also an explanation. Varnish workers write log tags to a buffer, that gets flushed to shmlog when it is full. A busy server might flush the buffer often, and it can happen that a Begin tag gets flushed to shmlog without the rest (including the End tag, for example, due to long backend processing). The VSL API will check in the Dispatch function that a Begin tag is not delayed more than what specified by the -T parameter (or by the default 120 seconds). This behavior is of course a bit difficult to reproduce, but the -p debug=+syncvsl helps forcing Varnish to make VSL synchronous. Thanks a lot for all the help! Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.tollkuci at gmail.com Thu Jun 23 18:04:47 2016 From: albert.tollkuci at gmail.com (=?UTF-8?Q?Albert_Tollku=C3=A7i?=) Date: Thu, 23 Jun 2016 18:04:47 +0200 Subject: Error 503 Backend fetch failed - XID: 208396 In-Reply-To: References: Message-ID: Thank you Guillaume, that was it. Probe was failing because of timeout and backend was marked sick. For anyone that may be in a similar position "varnishadm backend.list" will show you the backend status. Albert On Tue, Jun 21, 2016 at 6:55 PM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > Have you checked your probes? If the backend is recognized as sick, indeed > Varnish won't even bother sending a request. > > -- > Guillaume Quintard > -- Web: http://www.tollkuci.com Follow me on: LinkedIn Google+ Facebook Twitter Career 2.0 ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesho at outlook.com Fri Jun 24 21:06:02 2016 From: mahesho at outlook.com (Mahesh Ollalwar) Date: Fri, 24 Jun 2016 19:06:02 +0000 Subject: varnish core dump Message-ID: Can anyone help me on below error. looks like core dump is happening and child is getting restarted. This is happening recently without any change to the VCL and any system configuration. During this time the requests are getting terminated abruptly. Thanks in advance. Varnish version - varnish-4.0.2 Jun 24 23:49:30 Prod-CACHE2 abrt[32341]: Saved core dump of pid 26526 (/product/varnish/sbin/varnishd) to /var/spool/abrt/ccpp-2016-06-24-23:48:19-26526 (9034817536 bytes) Jun 24 23:49:30 Prod-CACHE2 abrtd: Directory 'ccpp-2016-06-24-23:48:19-26526' creation detected Jun 24 23:49:31 Prod-CACHE2 abrtd: Executable '/product/varnish/sbin/varnishd' doesn't belong to any package and ProcessUnpackaged is set to 'no' Jun 24 23:49:31 Prod-CACHE2 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2016-06-24-23:48:19-26526' exited with 1 Jun 24 23:49:31 Prod-CACHE2 abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2016-06-24-23:48:19-26526' Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) not responding to CLI, killing it. Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) not responding to CLI, killing it. Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) died signal=6 (core dumped) Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) Panic message:#012Assert error in cnt_lookup(), cache/cache_req_fsm.c line 430:#012 Condition((oc->exp_flags & (1<<7)) == 0) not true.#012thread = (cache-worker)#012ident = Linux,2.6.32-431.11.2.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x4310e5: pan_ic+0xc5#012 0x434c30: cnt_purge+0x0#012 0x436461: CNT_Request+0x241#012 0x42b73b: HTTP1_Session+0x53b#012 0x439f98: ses_req_pool_task+0x68#012 0x43a6d4: SES_pool_accept_task+0x2a4#012 0x433b87: Pool_Work_Thread+0x357#012 0x4467d9: wrk_thread_real+0xb9#012 0x3c25e079d1: /lib64/libpthread.so.0() [0x3c25e079d1]#012 0x3c25ae8b6d: /lib64/libc.so.6(clone+0x6d) [0x3c25ae8b6d]#012req = 0x7f83baaf2cb0 {#012 sp = 0x7f84dd71c430, vxid = 1108394165, step = R_STP_LOOKUP,#012 req_body = R_BODY_NONE,#012 restarts = 0, esi_level = 0#012 sp = 0x7f84dd71c430 {#012 fd = 64, vxid = 34652201,#012 client = 10.254.9.78 61217,#012 step = S_STP_WORKING,#012 },#012 worker = 0x7f8574c0cc40 {#012 ws = 0x7f8574c0ce58 {#012 id = "wrk",#012 {s,f,r,e} = {0x7f8574c0ac30,0x7f8574c0ac30,(nil),+8192},#012 },#012 VCL::method = 0x0,#012 VCL::return = deliver,#012 },#012 ws = 0x7f83baaf2e48 {#012 id = "req",#012 {s,f,r,e} = {0x7f83baaf4ca0,+1320,(nil),+57360},#012 },#012 http[req] = {#012 ws = 0x7f83baaf2e48[req]#012 "GET",#012 "/search-engine-web/SearchContents?action=SearchContents&moreFilters=series%3A3197&appVersion=5.2.2&query=*&startIndex=0&searchOrder=counter_week%20desc&maxResult=8&channel=ANDROID&type=CLIPS",#012 "HTTP/1.1",#012 "host: xxx.xxx.com",#012 "Accept-Encoding: gzip",#012 "Akamai-Origin-Hop: 4",#012 "True-Client-IP: 49.15.204.238",#012 "User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1; 1201 Build/LMY47I)",#012 "Via: 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 akamai.net(ghost) (AkamaiGHost)",#012 "X-Aka Jun 24 23:49:31 Prod-SEARCH-CACHE2 varnishd[26524]: child (1277) Started Jun 24 23:49:31 Prod-SEARCH-CACHE2 varnishd[26524]: Child (1277) said Child starts Thanks, Mahesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daghf at varnish-software.com Mon Jun 27 11:27:21 2016 From: daghf at varnish-software.com (Dag Haavi Finstad) Date: Mon, 27 Jun 2016 11:27:21 +0200 Subject: varnish core dump In-Reply-To: References: Message-ID: Hi I believe this might be #1539 [1], which is fixed in 4.0.3 and newer. Please upgrade to the latest release and file a bug if you still run into this. [1]: https://www.varnish-cache.org/trac/ticket/1539 On Fri, Jun 24, 2016 at 9:06 PM, Mahesh Ollalwar wrote: > Can anyone help me on below error. looks like core dump is happening and > child is getting restarted. This is happening recently without any change to > the VCL and any system configuration. > > During this time the requests are getting terminated abruptly. > > Thanks in advance. > > > Varnish version - varnish-4.0.2 > > > Jun 24 23:49:30 Prod-CACHE2 abrt[32341]: Saved core dump of pid 26526 > (/product/varnish/sbin/varnishd) to > /var/spool/abrt/ccpp-2016-06-24-23:48:19-26526 (9034817536 bytes) > Jun 24 23:49:30 Prod-CACHE2 abrtd: Directory > 'ccpp-2016-06-24-23:48:19-26526' creation detected > Jun 24 23:49:31 Prod-CACHE2 abrtd: Executable > '/product/varnish/sbin/varnishd' doesn't belong to any package and > ProcessUnpackaged is set to 'no' > Jun 24 23:49:31 Prod-CACHE2 abrtd: 'post-create' on > '/var/spool/abrt/ccpp-2016-06-24-23:48:19-26526' exited with 1 > Jun 24 23:49:31 Prod-CACHE2 abrtd: Deleting problem directory > '/var/spool/abrt/ccpp-2016-06-24-23:48:19-26526' > Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) not responding to > CLI, killing it. > Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) not responding to > CLI, killing it. > Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) died signal=6 > (core dumped) > Jun 24 23:49:31 Prod-CACHE2 varnishd[26524]: Child (26526) Panic > message:#012Assert error in cnt_lookup(), cache/cache_req_fsm.c line > 430:#012 Condition((oc->exp_flags & (1<<7)) == 0) not true.#012thread = > (cache-worker)#012ident = > Linux,2.6.32-431.11.2.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x4310e5: pan_ic+0xc5#012 0x434c30: cnt_purge+0x0#012 0x436461: > CNT_Request+0x241#012 0x42b73b: HTTP1_Session+0x53b#012 0x439f98: > ses_req_pool_task+0x68#012 0x43a6d4: SES_pool_accept_task+0x2a4#012 > 0x433b87: Pool_Work_Thread+0x357#012 0x4467d9: wrk_thread_real+0xb9#012 > 0x3c25e079d1: /lib64/libpthread.so.0() [0x3c25e079d1]#012 0x3c25ae8b6d: > /lib64/libc.so.6(clone+0x6d) [0x3c25ae8b6d]#012req = 0x7f83baaf2cb0 {#012 > sp = 0x7f84dd71c430, vxid = 1108394165, step = R_STP_LOOKUP,#012 req_body > = R_BODY_NONE,#012 restarts = 0, esi_level = 0#012 sp = 0x7f84dd71c430 > {#012 fd = 64, vxid = 34652201,#012 client = 10.254.9.78 61217,#012 > step = S_STP_WORKING,#012 },#012 worker = 0x7f8574c0cc40 {#012 ws = > 0x7f8574c0ce58 {#012 id = "wrk",#012 {s,f,r,e} = > {0x7f8574c0ac30,0x7f8574c0ac30,(nil),+8192},#012 },#012 VCL::method = > 0x0,#012 VCL::return = deliver,#012 },#012 ws = 0x7f83baaf2e48 {#012 > id = "req",#012 {s,f,r,e} = {0x7f83baaf4ca0,+1320,(nil),+57360},#012 > },#012 http[req] = {#012 ws = 0x7f83baaf2e48[req]#012 "GET",#012 > "/search-engine-web/SearchContents?action=SearchContents&moreFilters=series%3A3197&appVersion=5.2.2&query=*&startIndex=0&searchOrder=counter_week%20desc&maxResult=8&channel=ANDROID&type=CLIPS",#012 > "HTTP/1.1",#012 "host: xxx.xxx.com",#012 "Accept-Encoding: > gzip",#012 "Akamai-Origin-Hop: 4",#012 "True-Client-IP: > 49.15.204.238",#012 "User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1; > 1201 Build/LMY47I)",#012 "Via: 1.1 v1-akamaitech.net(ghost) > (AkamaiGHost), 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 > v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 akamai.net(ghost) > (AkamaiGHost)",#012 "X-Aka > Jun 24 23:49:31 Prod-SEARCH-CACHE2 varnishd[26524]: child (1277) Started > Jun 24 23:49:31 Prod-SEARCH-CACHE2 varnishd[26524]: Child (1277) said Child > starts > > > Thanks, > > Mahesh. > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -- Dag Haavi Finstad Software Developer | Varnish Software Mobile: +47 476 64 134 We Make Websites Fly! From morphey at morphey.org Tue Jun 28 12:15:30 2016 From: morphey at morphey.org (Christian Cantinelli) Date: Tue, 28 Jun 2016 12:15:30 +0200 Subject: Varnish bypass return(pass) with php session_id Message-ID: Hi, I have a problem with varnish 4.1.2. I have a setup like this: ++++++++++++ [...cut...] sub vcl_recv { set req.http.Host = regsub(req.http.Host, ":[0-9]+", ""); [...cut...] if (req.http.Host ~ "^dev.mytest.it") { return (pass); } [...cut....] } sub vcl_backend_response { if (beresp.ttl < 120s) { set beresp.ttl = 120s; unset beresp.http.Cache-Control; } if ( (!(bereq.url ~ "(wp-(login|admin)|login)")) || (bereq.method == "GET") ) { unset beresp.http.set-cookie; set beresp.ttl = 1h; } if (bereq.url ~ "(?i)\.(jpe?g|png|gif|tiff|ico|pdf|swf|gz|bz2|xz|tgz|tbz|mp3|ogg|ogv|avi|flv|mp4|mpe?g|webm|woff|eot|otf|ttf|txt|html?|css|js)(\?.*)?$") { unset beresp.http.set-cookie; set beresp.ttl = 1h; } else { set beresp.ttl = 4m; } } sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } set resp.http.Access-Control-Allow-Origin = "*"; } sub vcl_hit { if (req.method == "PURGE") { return(synth(200,"OK")); } } sub vcl_miss { if (req.method == "PURGE") { return(synth(404,"Not cached")); } } [...cut...] ++++++++++++ And I have a page with this content: ++++++++++++ session_id(): ".session_id()."
COOKIE: ".$_COOKIE["PHPSESSID"]; ++++++++++++ If I make a request from the web server, PHP creates a session properly and keeps it. If the request passes for varnish, PHP creates a session for each call without maintaining the previous. Inquiry for varnish, however, is marked as a MISS (so it should be completely bypassed). Has anyone had a problem like that? -- Chris Unix System Administrator - Network Administrator Programmer - Webdesigner - Webmaster From r at roze.lv Tue Jun 28 13:00:32 2016 From: r at roze.lv (Reinis Rozitis) Date: Tue, 28 Jun 2016 14:00:32 +0300 Subject: Varnish bypass return(pass) with php session_id In-Reply-To: References: Message-ID: <4F7DECFFA9B645B0A49C34AFBE1D3E19@MasterPC> > If the request passes for varnish, PHP creates a session for each call > without maintaining the previous. I would try to start with removing (commenting out) all the unset beresp.http.set-cookie; lines in your varnish config. For example: .. if ( (!(bereq.url ~ "(wp-(login|admin)|login)")) ||(bereq.method == "GET") ) { unset beresp.http.set-cookie; ... You delete the cookie comming from backend for any GET request so the php session can't be maintained. rr From morphey at morphey.org Tue Jun 28 14:02:17 2016 From: morphey at morphey.org (Christian Cantinelli) Date: Tue, 28 Jun 2016 14:02:17 +0200 Subject: Varnish bypass return(pass) with php session_id In-Reply-To: <4F7DECFFA9B645B0A49C34AFBE1D3E19@MasterPC> References: <4F7DECFFA9B645B0A49C34AFBE1D3E19@MasterPC> Message-ID: Hi @Reinis, tnks a lot. indeed it works perfectly. I see the configuration again. Thanks again. Chris Unix System Administrator - Network Administrator Programmer - Webdesigner - Webmaster Il 28/06/2016 13:00, Reinis Rozitis ha scritto: >> If the request passes for varnish, PHP creates a session for each call >> without maintaining the previous. > > I would try to start with removing (commenting out) all the unset > beresp.http.set-cookie; lines in your varnish config. > > For example: > > .. > if ( (!(bereq.url ~ "(wp-(login|admin)|login)")) ||(bereq.method > == "GET") ) { > unset beresp.http.set-cookie; > ... > > You delete the cookie comming from backend for any GET request so the > php session can't be maintained. > > > rr From sujithnss at gmail.com Wed Jun 29 08:37:50 2016 From: sujithnss at gmail.com (sujith pv) Date: Wed, 29 Jun 2016 12:07:50 +0530 Subject: Varnish Log - Logrotate issue Message-ID: Hi Team I'm facing an issue with Varnish log stops writing the log post the logrotate happens. varnish.log file becomes zero Kbs and nothing gets written onto it. Every time I ends up in killing the varnishlog process and redo it, Any help would be much appreciable... Best Regards Sujith P V -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tom.Anheyer at Berlinonline.de Wed Jun 29 10:00:21 2016 From: Tom.Anheyer at Berlinonline.de (Tom Anheyer) Date: Wed, 29 Jun 2016 10:00:21 +0200 Subject: Varnish Log - Logrotate issue In-Reply-To: References: Message-ID: <57738015.8050603@Berlinonline.de> Our logrotate conf: /var/log/varnish/*.log { daily maxage 7 missingok notifempty sharedscripts su root root postrotate /usr/bin/systemctl restart varnishlog endscript } tom Am 29.06.2016 um 08:37 schrieb sujith pv: > Hi Team > > I'm facing an issue with Varnish log stops writing the log post the > logrotate happens. varnish.log file becomes zero Kbs and nothing gets > written onto it. Every time I ends up in killing the varnishlog > process and redo it, > > Any help would be much appreciable... > > Best Regards > Sujith P V > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4266 bytes Desc: S/MIME Cryptographic Signature URL: From colas.delmas at gmail.com Wed Jun 29 11:39:48 2016 From: colas.delmas at gmail.com (Nicolas Delmas) Date: Wed, 29 Jun 2016 11:39:48 +0200 Subject: random 503 + FetchError: straight insufficient bytes Message-ID: Hello, We are using Apache 2.4 on the backend and Varnish 4.1.2. Randomly, users get 503 on some URL. 95% on time it's on an URL called by AJAX in POST method.: - BereqMethod POST - BereqURL /proxy.php?xdp_path=http%3A%2F%2Fmonsite.com%2Fcf_log.php or it could be the same without a proxy.php - BereqMethod POST - BereqURL monsite.com/cf_log.php With varnishlog I get this error : * << Request >> 41189403- FetchError straight insufficient bytes ** << BeReq >> 41189404-- FetchError req.body read error: 0 (Success) -- FetchError backend write error: 0 (Success) * << Request >> 41189403- FetchError Connection reset by peer - FetchError straight insufficient bytes ** << BeReq >> 41189404-- FetchError req.body read error: 11 (Resource temporarily unavailable) -- FetchError backend write error: 11 (Resource temporarily unavailable) I ran ngrep on Varnish an each time I get the error I have something like this : * client => varnish > header content [AP] > *client => varnish > ..[AR] and the data POST are not in the request When all works I get something like this * client => varnish header content[AP] *client => varnish header content[AF] And the last request contains the data POST. How can I avoid to get this errors which seem to be false positive ? Thank you *Nicolas Delmas* colas.delmas at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujithnss at gmail.com Wed Jun 29 13:30:02 2016 From: sujithnss at gmail.com (sujith pv) Date: Wed, 29 Jun 2016 17:00:02 +0530 Subject: Varnish Log - Logrotate issue In-Reply-To: <57738015.8050603@Berlinonline.de> References: <57738015.8050603@Berlinonline.de> Message-ID: Hi Actually I have installed Varnish from tar not as a RPM install. Also please find the below my logrotate file */u01/varnishapp/log/*.log { daily rotate 1 maxage 6 compress missingok notifempty copytruncate create 0664 svc_varnish svc_varnish }* Also I'm using the below command to manually start my log file /bin/varnishlog >> /log/varnish.log & On Wed, Jun 29, 2016 at 1:30 PM, Tom Anheyer wrote: > Our logrotate conf: > > /var/log/varnish/*.log { > daily > maxage 7 > missingok > notifempty > sharedscripts > su root root > postrotate > /usr/bin/systemctl restart varnishlog > endscript > } > > > tom > > > Am 29.06.2016 um 08:37 schrieb sujith pv: > >> Hi Team >> >> I'm facing an issue with Varnish log stops writing the log post the >> logrotate happens. varnish.log file becomes zero Kbs and nothing gets >> written onto it. Every time I ends up in killing the varnishlog process >> and redo it, >> >> Any help would be much appreciable... >> >> Best Regards >> Sujith P V >> >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lagged at gmail.com Wed Jun 29 17:17:52 2016 From: lagged at gmail.com (Andrei) Date: Wed, 29 Jun 2016 10:17:52 -0500 Subject: Question about variables Message-ID: Hello, I'm currently working on forcing cached results using vsthrottle vs dropping requests, but for some reason (I probably did it wrong :) I can't get var.get/var.set_duration to work. The vcl_recv snippet is as follows, any input is greatly appreciated: sub vcl_recv { if (vsthrottle.is_denied(req.http.Host, 500, 5s) || (var.get("block-" + req.http.Host))) { # The vsthrottle rate limit definitely triggers - confirmed later with "Attack" header unset req.http.Cookie; unset req.http.User-Agent; unset req.http.Pragma; unset req.http.Cache-Control; set req.http.Attack = "ByHost: " + req.http.Host; set req.ttl = 15m; var.set_duration("block-" + req.http.Host,15m); return (hash); } [..] } -------------- next part -------------- An HTML attachment was scrubbed... URL: From fortier at augsburg.edu Wed Jun 29 17:33:37 2016 From: fortier at augsburg.edu (Josef Fortier) Date: Wed, 29 Jun 2016 10:33:37 -0500 Subject: Varnish silently rewriting 301 redirect Message-ID: <20160629153337.GB13978@joe.augsburg.edu> It looks like if varnish sees: * A backend issue a redirect one one hostname to another * And varnish manages that back end as well * And the IP address of both match * Then varnish will silently rewrite the backend redirect to the original host address (which makes the redirect fail in our case) I'm curious if anyone can help me understand this better. If possible I'd like to know how to tell varnish to not do this. It's taken a chunk of yesterday to work this out. The trigger situation, I moved a URL shortener behind an existing varnish server. The existing setup has several IP addresses bound to it. If the redirector issued a 301 for an address also served by another host on that same IP, the redirect domain was silently re-written to the original (redirector) hostname. But if the redirect come in on a different IP, the backend 301 goes out unaltered. I ended up using vcl_synth redirects to the underlying server (with regex mangling of the path) to bypass varnish. But I'd like to understand this better. Thanks -- __________________________________________________________________________ Josef Fortier Systems Administrator fortier at augsburg.edu Phone: 612-330-1479 __________________________________________________________________________ From guillaume at varnish-software.com Wed Jun 29 17:59:50 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Wed, 29 Jun 2016 08:59:50 -0700 Subject: Varnish Log - Logrotate issue In-Reply-To: References: <57738015.8050603@Berlinonline.de> Message-ID: I'm by no mean a logrotate expert, but at the very least, you need to send a SIGUP1 signal to varnishlog to tell it to reopen the file (that should be specified with "-w"). Also, Tom, restarting maybe overkill, and you may miss transactions. -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Wed Jun 29 18:14:52 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Wed, 29 Jun 2016 09:14:52 -0700 Subject: Question about variables In-Reply-To: References: Message-ID: Hi, What do you mean by "work"? What's the expected result, and what is the actual result? -- Guillaume Quintard On Wed, Jun 29, 2016 at 8:17 AM, Andrei wrote: > Hello, > > I'm currently working on forcing cached results using vsthrottle vs > dropping requests, but for some reason (I probably did it wrong :) I can't > get var.get/var.set_duration to work. The vcl_recv snippet is as follows, > any input is greatly appreciated: > > sub vcl_recv { > if (vsthrottle.is_denied(req.http.Host, 500, 5s) || > (var.get("block-" + req.http.Host))) { > # The vsthrottle rate limit definitely triggers - > confirmed later with "Attack" header > unset req.http.Cookie; > unset req.http.User-Agent; > unset req.http.Pragma; > unset req.http.Cache-Control; > set req.http.Attack = "ByHost: " + req.http.Host; > set req.ttl = 15m; > var.set_duration("block-" + req.http.Host,15m); > return (hash); > } > [..] > } > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgelfand2 at gmail.com Wed Jun 29 18:15:44 2016 From: rgelfand2 at gmail.com (Roman Gelfand) Date: Wed, 29 Jun 2016 16:15:44 +0000 Subject: Debian Repository Message-ID: I am trying to install version 4.1 on Debian 8. It appears that debian is ignoring this repository when doing apt-get update. How can this be resolved? Thanks in advance -- Thanks, R. Gelfand -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Wed Jun 29 18:19:29 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Wed, 29 Jun 2016 09:19:29 -0700 Subject: Varnish silently rewriting 301 redirect In-Reply-To: <20160629153337.GB13978@joe.augsburg.edu> References: <20160629153337.GB13978@joe.augsburg.edu> Message-ID: Hi Josef, Can you reproduce the issue with a minimal VCL and share it? Or give us an anonymized VCL? This looks like a configuration error, Varnish has very little magic happening behind the scenes. -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgelfand2 at gmail.com Wed Jun 29 18:20:16 2016 From: rgelfand2 at gmail.com (Roman Gelfand) Date: Wed, 29 Jun 2016 16:20:16 +0000 Subject: Debian Repository In-Reply-To: References: Message-ID: I think I see the answer. It was built for 64bit machine. On Wed, Jun 29, 2016 at 12:15 PM Roman Gelfand wrote: > I am trying to install version 4.1 on Debian 8. It appears that debian > is ignoring this repository when doing apt-get update. > > How can this be resolved? > > Thanks in advance > -- > Thanks, > R. Gelfand > -- Thanks, R. Gelfand -------------- next part -------------- An HTML attachment was scrubbed... URL: From apj at mutt.dk Wed Jun 29 18:22:25 2016 From: apj at mutt.dk (Andreas Plesner) Date: Wed, 29 Jun 2016 18:22:25 +0200 Subject: Varnish silently rewriting 301 redirect In-Reply-To: <20160629153337.GB13978@joe.augsburg.edu> References: <20160629153337.GB13978@joe.augsburg.edu> Message-ID: <20160629162225.GF23724@nerd.dk> On Wed, Jun 29, 2016 at 10:33:37AM -0500, Josef Fortier wrote: > It looks like if varnish sees: > > * A backend issue a redirect one one hostname to another > * And varnish manages that back end as well > * And the IP address of both match > * Then varnish will silently rewrite the backend redirect to the > original host address (which makes the redirect fail in our case) Varnishlog? My guess is that this is your backend or your vcl at work. -- Andreas From guillaume at varnish-software.com Wed Jun 29 18:53:11 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Wed, 29 Jun 2016 09:53:11 -0700 Subject: random 503 + FetchError: straight insufficient bytes In-Reply-To: References: Message-ID: Isn't it because the client stops writing that post request? -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Wed Jun 29 18:55:54 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Wed, 29 Jun 2016 09:55:54 -0700 Subject: Debian Repository In-Reply-To: References: Message-ID: looks like a debian problem. Where did you put the repo definition? Does this file's name ends with ".list"? What happens when you run "aptitude update"? -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lagged at gmail.com Wed Jun 29 20:20:15 2016 From: lagged at gmail.com (Andrei) Date: Wed, 29 Jun 2016 13:20:15 -0500 Subject: Question about variables In-Reply-To: References: Message-ID: Hello, The expected result is to have variables such as "block-domain.com" set for 15min once vsthrottle triggers, then later checked if defined. The vsthrottle trigger works, but I'm not having any luck setting and checking for the variables - they're always blank. Example vcl: vcl_recv { if (client.ip ~ cloudflare) { var.set("ip",req.http.CF-Connecting-IP); var.set("src","cloud"); } elseif (client.ip ~ sucuri) { var.set("ip",req.http.X-Sucuri-ClientIP); var.set("src","sucuri"); } elseif (client.ip ~ incapsula) { var.set("ip",req.http.Incap-Client-IP); var.set("src","incapsula"); } else { var.set("ip",client.ip); var.set("src","direct"); } if (vsthrottle.is_denied(req.http.Host, 20, 5s) || (var.get("block-" + req.http.Host))) { # Here I'm trying to trigger on " block-domain.com", but it's not working unset req.http.Cookie; unset req.http.User-Agent; unset req.http.Pragma; unset req.http.Cache-Control; set req.http.Attack = "ByHost " + req.http.Host + " (" + var.get("src") + ")"; set req.ttl = 15m; var.set_duration("block-" + req.http.Host,15m); # This is where I'm trying to set the variable "block-domain.com" set req.http.Attack-Debug = var.get("block-" + req.http.Host); # And again here for some debugging return (hash); } } vcl_deliver { if (req.http.Attack) { set resp.http.Attack-Debug = req.http.Attack-Debug; set resp.http.Attack = req.http.Attack; } } however Attack-Debug is always blank, thoughts? * << Request >> 431527 - Begin req 431526 rxreq - Timestamp Start: 1467223441.362702 0.000000 0.000000 - Timestamp Req: 1467223441.362702 0.000000 0.000000 - ReqStart 11.22.33.44 62758 - ReqMethod HEAD - ReqURL / - ReqProtocol HTTP/1.1 - ReqHeader User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 - ReqHeader Accept: */* - ReqHeader Host: zhtest.com - ReqHeader X-Forwarded-For: 11.22.33.44 - VCL_call RECV - VCL_acl NO_MATCH cloudflare - VCL_acl NO_MATCH sucuri - VCL_acl NO_MATCH incapsula - ReqUnset User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 - ReqHeader Attack: ByHost zhtest.com (direct) - ReqHeader Attack-Debug: - VCL_return hash - VCL_call HASH - VCL_return lookup - Hit 329457 - VCL_call HIT - ReqHeader X-Cache-Keep: 300.000 - ReqHeader X-Cache-TTL-Remaining: 110.641 - ReqHeader X-Cache-Age: 189.359 - ReqHeader Cache: HIT - VCL_return deliver - RespProtocol HTTP/1.1 - RespStatus 200 - RespReason OK - RespHeader Date: Wed, 29 Jun 2016 18:03:51 GMT - RespHeader Server: Apache - RespHeader Link: ; rel=" https://api.w.org/" - RespHeader X-Frame-Options: SAMEORIGIN - RespHeader Strict-Transport-Security: max-age=31536000; includeSubDomains - RespHeader Content-Length: 7702 - RespHeader Content-Type: text/html; charset=UTF-8 - RespHeader x-url: / - RespHeader X-Varnish: 431527 329457 - RespHeader Age: 9 - RespHeader Via: 1.1 varnish-v4 - VCL_call DELIVER - RespUnset x-url: / - RespHeader Cache: HIT - RespHeader Cache-Hits: 1156 - RespHeader Attack-Debug: - RespHeader Attack: ByHost zhtest.com (direct) - RespUnset Server: Apache - RespUnset X-Varnish: 431527 329457 - RespUnset Via: 1.1 varnish-v4 - VCL_return deliver - Timestamp Process: 1467223441.362767 0.000065 0.000065 - RespHeader Accept-Ranges: bytes - Debug "RES_MODE 0" - RespHeader Connection: keep-alive - Timestamp Resp: 1467223441.362802 0.000100 0.000036 - ReqAcct 172 0 172 409 0 409 - End On Wed, Jun 29, 2016 at 11:14 AM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > Hi, > > What do you mean by "work"? What's the expected result, and what is the > actual result? > > -- > Guillaume Quintard > > On Wed, Jun 29, 2016 at 8:17 AM, Andrei wrote: > >> Hello, >> >> I'm currently working on forcing cached results using vsthrottle vs >> dropping requests, but for some reason (I probably did it wrong :) I can't >> get var.get/var.set_duration to work. The vcl_recv snippet is as follows, >> any input is greatly appreciated: >> >> sub vcl_recv { >> if (vsthrottle.is_denied(req.http.Host, 500, 5s) || >> (var.get("block-" + req.http.Host))) { >> # The vsthrottle rate limit definitely triggers - >> confirmed later with "Attack" header >> unset req.http.Cookie; >> unset req.http.User-Agent; >> unset req.http.Pragma; >> unset req.http.Cache-Control; >> set req.http.Attack = "ByHost: " + req.http.Host; >> set req.ttl = 15m; >> var.set_duration("block-" + req.http.Host,15m); >> return (hash); >> } >> [..] >> } >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dead_gardens_ at hotmail.com Thu Jun 30 16:18:17 2016 From: dead_gardens_ at hotmail.com (Dead) Date: Thu, 30 Jun 2016 14:18:17 +0000 Subject: ban.list without expression Message-ID: Hi! for some strange reason my varnish setup is adding stuff to the ban list but without expressions. >?ban.list 200 Present bans: 1467294760.786177 41873 C 1467294023.391572 20347 C 1467293872.929535 ? ?56 C 1467293820.521924 ? ?25 C 1467293481.720435 ?4911 How can I know from where is this coming from? Im running varnish-4.1.3-beta1 revision NOGIT, Linux,4.4.0-22-generic,x86_64,-junix,-sdeprecated_persistent,-smalloc,-hcritbit with persistent storage. NFILES=131072 MEMLOCK=82000 DAEMON_OPTS="-a :8000 \ ? ? ? ? ? ? ?-T localhost:2000 \ ? ? ? ? ? ? ?-f /etc/varnish/varnish.vcl \ ? ? ? ? ? ? ?-S /etc/varnish/secret \ ? ? ? ? ? ? ?-p thread_pool_min=600 \ ? ? ? ? ? ? ?-p thread_pool_max=5000 \ ? ? ? ? ? ? ?-s deprecated_persistent,/sdb1/persistent_100,100G" Thanks!