From eyz12315 at live.cn Mon Aug 12 05:41:06 2019 From: eyz12315 at live.cn (Yuan Zafir) Date: Mon, 12 Aug 2019 05:41:06 +0000 Subject: How to cache req.body and then use it in response for coming requests in varnish Message-ID: Hi?I am trying to configure varnish as a simple cache service, which means the content posted by clients could be cached as an object. The content chould be returned in responses for the coming GET requests(with same url...). I am not sure wether this can be realized by VCL configuration. Any recommendation for this situation? Thanks for any help! I was noticed vmod-bodyaccess can cache req.body and then it could be used in bereq(https://info.varnish-software.com/blog/caching-post-requests-with-varnish), but I do not know how to put it into responses for clients. thanks! Zafir ________________________________ eyz12315 at live.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Mon Aug 12 06:03:45 2019 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Sun, 11 Aug 2019 23:03:45 -0700 Subject: How to cache req.body and then use it in response for coming requests in varnish In-Reply-To: References: Message-ID: Hi, There are a few things to do here: - make sure that if req.method == "POST", you return(hash) from vcl_recv (otherwise, the builtin.vcl ( https://github.com/varnish/Varnish-Cache/blob/4.1/bin/varnishd/builtin.vcl#L63) will pass) - but before that, add 'set req.http.x-method = req.method' at the top of vcl_recv, and 'if (bereq.http.x-method == "POST") {set bereq.method = "POST"; }' at the top of vcl_backend_fetch, because for cacheable request, varnish will want to set the method to "GET", so we need to reset it back On top of that: - you can use req.hash_always_miss (man vcl) to push new content (and avoid just getting the cached response) - make sure you only cache when the response is OK, otherwise a wrong POST request will mask the previous valid ones - if you are acting upon the URL of the resource itself, I'd say it should be a PUT/PATCH, rather than a POST, but that's just pedantry at this point - realize that the content cached is the response returned by the backend, not the body of the request itself. They may be the same, but maybe not (there are ways to do it though) Hope that helps -- Guillaume Quintard On Sun, Aug 11, 2019 at 10:42 PM Yuan Zafir wrote: > Hi?I am trying to configure varnish as a simple cache service, which > means the content posted by clients could be cached as an object. The > content chould be returned in responses for the coming GET requests(with > same url...). I am not sure wether this can be realized by VCL > configuration. > > Any recommendation for this situation? Thanks for any help! > > I was noticed vmod-bodyaccess can cache req.body and then it could be used > in bereq( > https://info.varnish-software.com/blog/caching-post-requests-with-varnish), > but I do not know how to put it into responses for clients. > > thanks! > Zafir > ------------------------------ > eyz12315 at live.cn > _______________________________________________ > 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 eyz12315 at live.cn Mon Aug 12 07:57:45 2019 From: eyz12315 at live.cn (Yuan Zafir) Date: Mon, 12 Aug 2019 07:57:45 +0000 Subject: How to cache req.body and then use it in response for coming requests in varnish References: , Message-ID: hi Guillaume? Thanks for your reply. I think there should be ambiguity description about my question in my first mail. Actually what I want is to use varnish as a cache service *without backend servers*, clients can push/pull the resource to/from varnish cache storage using specific http method, such as POST/GET. For example, one client can send " POST /string1 "abcd" " to make a string-"abcd" cached into varnish, other clients could then use "GET /string1" request to get this string. If Get request miss the cache, a 404 error could be sent (through synth command in vcl_miss). I am not sure whether it's feasible to make the string-"abcd" cached into varnish. Do you have any recommendation for this requrement? Thanks again for your attention! Zafir Yuan ________________________________ eyz12315 at live.cn From: Guillaume Quintard Date: 2019-08-12 14:03 To: Yuan Zafir CC: varnish-misc Subject: Re: How to cache req.body and then use it in response for coming requests in varnish Hi, There are a few things to do here: - make sure that if req.method == "POST", you return(hash) from vcl_recv (otherwise, the builtin.vcl (https://github.com/varnish/Varnish-Cache/blob/4.1/bin/varnishd/builtin.vcl#L63) will pass) - but before that, add 'set req.http.x-method = req.method' at the top of vcl_recv, and 'if (bereq.http.x-method == "POST") {set bereq.method = "POST"; }' at the top of vcl_backend_fetch, because for cacheable request, varnish will want to set the method to "GET", so we need to reset it back On top of that: - you can use req.hash_always_miss (man vcl) to push new content (and avoid just getting the cached response) - make sure you only cache when the response is OK, otherwise a wrong POST request will mask the previous valid ones - if you are acting upon the URL of the resource itself, I'd say it should be a PUT/PATCH, rather than a POST, but that's just pedantry at this point - realize that the content cached is the response returned by the backend, not the body of the request itself. They may be the same, but maybe not (there are ways to do it though) Hope that helps -- Guillaume Quintard On Sun, Aug 11, 2019 at 10:42 PM Yuan Zafir > wrote: Hi?I am trying to configure varnish as a simple cache service, which means the content posted by clients could be cached as an object. The content chould be returned in responses for the coming GET requests(with same url...). I am not sure wether this can be realized by VCL configuration. Any recommendation for this situation? Thanks for any help! I was noticed vmod-bodyaccess can cache req.body and then it could be used in bereq(https://info.varnish-software.com/blog/caching-post-requests-with-varnish), but I do not know how to put it into responses for clients. thanks! Zafir ________________________________ eyz12315 at live.cn _______________________________________________ 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 guillaume at varnish-software.com Mon Aug 12 14:05:53 2019 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Mon, 12 Aug 2019 07:05:53 -0700 Subject: How to cache req.body and then use it in response for coming requests in varnish In-Reply-To: References: Message-ID: Hi, then you need something like https://docs.varnish-software.com/varnish-cache-plus/vmods/synthbackend/ (with the .mirror() function) which was created for this purpose, but it's a Varnish Plus feature. It may be possible usable with the new backend error mechanism in the next version, coupled with some vmod_bodyaccess feature (but you would need a blob instead of a string) -- Guillaume Quintard On Mon, Aug 12, 2019 at 12:57 AM Yuan Zafir wrote: > hi Guillaume? > > Thanks for your reply. > > I think there should be ambiguity description about my question in my > first mail. > Actually what I want is to use varnish as a cache service *without backend > servers*, clients can push/pull the resource to/from varnish cache storage > using specific http method, such as POST/GET. > For example, one client can send " POST /string1 "abcd" " to make a > string-"abcd" cached into varnish, other clients could then use "GET > /string1" request to get this string. If Get request miss the cache, a 404 > error could be sent (through synth command in vcl_miss). > > I am not sure whether it's feasible to make the string-"abcd" cached into > varnish. Do you have any recommendation for this requrement? > Thanks again for your attention! > > > Zafir Yuan > > ------------------------------ > eyz12315 at live.cn > > > *From:* Guillaume Quintard > *Date:* 2019-08-12 14:03 > *To:* Yuan Zafir > *CC:* varnish-misc > *Subject:* Re: How to cache req.body and then use it in response for > coming requests in varnish > Hi, > > There are a few things to do here: > - make sure that if req.method == "POST", you return(hash) from vcl_recv > (otherwise, the builtin.vcl ( > https://github.com/varnish/Varnish-Cache/blob/4.1/bin/varnishd/builtin.vcl#L63) > will pass) > - but before that, add 'set req.http.x-method = req.method' at the top of > vcl_recv, and 'if (bereq.http.x-method == "POST") {set bereq.method = > "POST"; }' at the top of vcl_backend_fetch, because for cacheable request, > varnish will want to set the method to "GET", so we need to reset it back > > On top of that: > - you can use req.hash_always_miss (man vcl) to push new content (and > avoid just getting the cached response) > - make sure you only cache when the response is OK, otherwise a wrong POST > request will mask the previous valid ones > - if you are acting upon the URL of the resource itself, I'd say it should > be a PUT/PATCH, rather than a POST, but that's just pedantry at this point > - realize that the content cached is the response returned by the backend, > not the body of the request itself. They may be the same, but maybe not > (there are ways to do it though) > > Hope that helps > -- > Guillaume Quintard > > > On Sun, Aug 11, 2019 at 10:42 PM Yuan Zafir wrote: > >> Hi?I am trying to configure varnish as a simple cache service, which >> means the content posted by clients could be cached as an object. The >> content chould be returned in responses for the coming GET requests(with >> same url...). I am not sure wether this can be realized by VCL >> configuration. >> >> Any recommendation for this situation? Thanks for any help! >> >> I was noticed vmod-bodyaccess can cache req.body and then it could be >> used in bereq( >> https://info.varnish-software.com/blog/caching-post-requests-with-varnish), >> but I do not know how to put it into responses for clients. >> >> thanks! >> Zafir >> ------------------------------ >> eyz12315 at live.cn >> _______________________________________________ >> 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 eyz12315 at live.cn Tue Aug 13 04:26:08 2019 From: eyz12315 at live.cn (Yuan Zafir) Date: Tue, 13 Aug 2019 04:26:08 +0000 Subject: How to cache req.body and then use it in response for coming requests in varnish References: , , , Message-ID: Thanks, Guillaume! Zafir Yuan ________________________________ eyz12315 at live.cn From: Guillaume Quintard Date: 2019-08-12 22:05 To: Yuan Zafir CC: varnish-misc Subject: Re: Re: How to cache req.body and then use it in response for coming requests in varnish Hi, then you need something like https://docs.varnish-software.com/varnish-cache-plus/vmods/synthbackend/ (with the .mirror() function) which was created for this purpose, but it's a Varnish Plus feature. It may be possible usable with the new backend error mechanism in the next version, coupled with some vmod_bodyaccess feature (but you would need a blob instead of a string) -- Guillaume Quintard On Mon, Aug 12, 2019 at 12:57 AM Yuan Zafir > wrote: hi Guillaume? Thanks for your reply. I think there should be ambiguity description about my question in my first mail. Actually what I want is to use varnish as a cache service *without backend servers*, clients can push/pull the resource to/from varnish cache storage using specific http method, such as POST/GET. For example, one client can send " POST /string1 "abcd" " to make a string-"abcd" cached into varnish, other clients could then use "GET /string1" request to get this string. If Get request miss the cache, a 404 error could be sent (through synth command in vcl_miss). I am not sure whether it's feasible to make the string-"abcd" cached into varnish. Do you have any recommendation for this requrement? Thanks again for your attention! Zafir Yuan ________________________________ eyz12315 at live.cn From: Guillaume Quintard Date: 2019-08-12 14:03 To: Yuan Zafir CC: varnish-misc Subject: Re: How to cache req.body and then use it in response for coming requests in varnish Hi, There are a few things to do here: - make sure that if req.method == "POST", you return(hash) from vcl_recv (otherwise, the builtin.vcl (https://github.com/varnish/Varnish-Cache/blob/4.1/bin/varnishd/builtin.vcl#L63) will pass) - but before that, add 'set req.http.x-method = req.method' at the top of vcl_recv, and 'if (bereq.http.x-method == "POST") {set bereq.method = "POST"; }' at the top of vcl_backend_fetch, because for cacheable request, varnish will want to set the method to "GET", so we need to reset it back On top of that: - you can use req.hash_always_miss (man vcl) to push new content (and avoid just getting the cached response) - make sure you only cache when the response is OK, otherwise a wrong POST request will mask the previous valid ones - if you are acting upon the URL of the resource itself, I'd say it should be a PUT/PATCH, rather than a POST, but that's just pedantry at this point - realize that the content cached is the response returned by the backend, not the body of the request itself. They may be the same, but maybe not (there are ways to do it though) Hope that helps -- Guillaume Quintard On Sun, Aug 11, 2019 at 10:42 PM Yuan Zafir > wrote: Hi?I am trying to configure varnish as a simple cache service, which means the content posted by clients could be cached as an object. The content chould be returned in responses for the coming GET requests(with same url...). I am not sure wether this can be realized by VCL configuration. Any recommendation for this situation? Thanks for any help! I was noticed vmod-bodyaccess can cache req.body and then it could be used in bereq(https://info.varnish-software.com/blog/caching-post-requests-with-varnish), but I do not know how to put it into responses for clients. thanks! Zafir ________________________________ eyz12315 at live.cn _______________________________________________ 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 eric.m.vandenhout at kpn.com Thu Aug 22 08:06:50 2019 From: eric.m.vandenhout at kpn.com (eric.m.vandenhout at kpn.com) Date: Thu, 22 Aug 2019 08:06:50 +0000 Subject: cli bans Message-ID: Hi, Just a smal question. Is it possible to temporarily send a specific http errorcode back (e.g. http 429) to an ip from varnish using the commandline client (or by any other means) without restarting varnish? Consider this scenario: A varnish cluster is running nicely. Among other things it also gives access to a set of developer api?s. Not all programmers are equally skilled so sometimes it happens that a programmer creates a loop that is flooding the platform. At this moment I use fail2ban to just block it in iptables and unblock it after 10 minutes. However I would prefer instead of blocking it that I can just reroute the requests of this ip temporarily to an errorpage which returns http 429 (which as statuscode also should be returned bij Varnish) Important with this is than that no varnish restarts are required. Any ideas? Met vriendelijke groet/Kind Regards Eric van den Hout Devops Engineer / Technical administrator Cluster Klant & Content / AAB [cid:image001.png at 01D558CE.2907C520] Stationsstraat 115 3811 MH Amersfoort Mofo: +31 6 83569993 Email: aab at kpn.com eric.m.vandenhout at kpn.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10891 bytes Desc: image001.png URL: From phk at phk.freebsd.dk Thu Aug 22 21:06:18 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 22 Aug 2019 21:06:18 +0000 Subject: cli bans In-Reply-To: References: Message-ID: <1786.1566507978@critter.freebsd.dk> -------- In message , eric.m.vandenhout at kpn.com writes: > Just a smal question. Is it possible to temporarily send a specific http > errorcode back (e.g. http 429) to an ip from varnish using the commandline > client (or by any other means) without restarting varnish? Yes. Add the necessary code to your VCL, switch to the new VCL. This is an instant operation which does not affect your cache content. Something like: vi/emacs/ed whatever_your.vcl then varnishadm vcl.load somename /full/path/to/whatever_your.vcl varnishadm vcl.use somename -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From eric.m.vandenhout at kpn.com Fri Aug 23 08:13:12 2019 From: eric.m.vandenhout at kpn.com (eric.m.vandenhout at kpn.com) Date: Fri, 23 Aug 2019 08:13:12 +0000 Subject: cli bans In-Reply-To: <1786.1566507978@critter.freebsd.dk> References: <1786.1566507978@critter.freebsd.dk> Message-ID: Thnx for you reply. Anther question that pops in mind then. Can vcl's include other files? Regards, Eric -----Oorspronkelijk bericht----- Van: Poul-Henning Kamp Verzonden: Thursday, 22 August 2019 23:06 Aan: Hout, Eric van den CC: varnish-misc at varnish-cache.org Onderwerp: Re: cli bans -------- In message , eric.m.vandenhout at kpn.com writes: > Just a smal question. Is it possible to temporarily send a specific > http errorcode back (e.g. http 429) to an ip from varnish using the > commandline client (or by any other means) without restarting varnish? Yes. Add the necessary code to your VCL, switch to the new VCL. This is an instant operation which does not affect your cache content. Something like: vi/emacs/ed whatever_your.vcl then varnishadm vcl.load somename /full/path/to/whatever_your.vcl varnishadm vcl.use somename -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Fri Aug 23 08:19:30 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 23 Aug 2019 08:19:30 +0000 Subject: cli bans In-Reply-To: References: <1786.1566507978@critter.freebsd.dk> Message-ID: <4348.1566548370@critter.freebsd.dk> -------- In message , eric.m.vandenhout at kpn.com writes : > Thnx for you reply. > Anther question that pops in mind then. Can vcl's include other files? Yes: include "path-to-file" ; works _anywhere_ in VCL. You can do strange things with it like: acl something { include "/some/where/acl_body"; } or even acl include "/some/where/name_of_acl"; { include "/some/where/acl_body"; } But that is probably not very useful :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From i.zachari at gmail.com Thu Aug 29 07:32:59 2019 From: i.zachari at gmail.com (Giannis Zach) Date: Thu, 29 Aug 2019 10:32:59 +0300 Subject: varnish health probe errors Message-ID: Hello all, a successful health probe will log this flags `4--X-RH` and from the documentation the flags are: 4 -- IPv4 connection established X -- Request transmit succeeded R -- Read response succeeded H -- Happy with the result The issue I'm facing is that sometimes the health probe returns the flags `4--X---` marking the backend as sick. Can someone please explain to me when a varnish health probe will not log an `R` (Read response succeeded)? Is this related to the health probe's timeout value? Does this mean that the TCP connection failed before the backend sent the response? The backend doesn't even log the request in its access log, so from my understanding, the backend never received that request, however, varnish says the request was successfully transmitted (the `X` flag). Thank you for your time. -- Giannis -------------- next part -------------- An HTML attachment was scrubbed... URL: From timkelty at gmail.com Thu Aug 29 13:57:47 2019 From: timkelty at gmail.com (Tim Kelty) Date: Thu, 29 Aug 2019 09:57:47 -0400 Subject: Purge with restart when using =?utf-8?Q?xkey=E2=80=A6possible=3F?= In-Reply-To: <82ab9f1c-61e7-4705-b7a1-70563f8ca8b6@Spark> References: <3f3dd1ed-9eda-4b54-98e4-f18d66dc5ddb@Spark> <82ab9f1c-61e7-4705-b7a1-70563f8ca8b6@Spark> Message-ID: With a normal purge, I know I can do a "purge with restart" to re-warm the cache. However, I'm using xkey purging and I'm wondering if there is any way to do something similar when clearing potentially many objects via an xkey purge. My goal is to whenever possible, avoid MISSes by actual web traffic, and have Varnish make any initial requests to warm the cache. Is this possible with xkey purge, or when purging multiple items? ?Or any other ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Thu Aug 29 14:16:59 2019 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Thu, 29 Aug 2019 07:16:59 -0700 Subject: varnish health probe errors In-Reply-To: References: Message-ID: Hi, I think you got everything right: on the Varnish side, the connection was established (4) and successfully transmitted (X), we just never received a response, so yes, this has to do with timing out, most probably. -- Guillaume Quintard On Thu, Aug 29, 2019 at 12:34 AM Giannis Zach wrote: > Hello all, > > a successful health probe will log this flags `4--X-RH` and from the > documentation the flags are: > 4 -- IPv4 connection established > X -- Request transmit succeeded > R -- Read response succeeded > H -- Happy with the result > > The issue I'm facing is that sometimes the health probe returns the flags > `4--X---` marking the backend as sick. > > Can someone please explain to me when a varnish health probe will not log > an `R` (Read response succeeded)? Is this related to the health probe's > timeout value? Does this mean that the TCP connection failed before the > backend sent the response? The backend doesn't even log the request in its > access log, so from my understanding, the backend never received that > request, however, varnish says the request was successfully transmitted > (the `X` flag). > > Thank you for your time. > > -- > Giannis > _______________________________________________ > 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 slink at schokola.de Thu Aug 29 16:43:06 2019 From: slink at schokola.de (Nils Goroll) Date: Thu, 29 Aug 2019 18:43:06 +0200 Subject: varnish health probe errors In-Reply-To: References: Message-ID: <8c9ba25b-37a7-2a81-b458-914890d27b54@schokola.de> Hi, to avoid a common pitfall, if you use .request, remember to add "Connection: close" From guillaume at varnish-software.com Thu Aug 29 16:53:57 2019 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Thu, 29 Aug 2019 09:53:57 -0700 Subject: =?UTF-8?Q?Re=3A_Purge_with_restart_when_using_xkey=E2=80=A6possible=3F?= In-Reply-To: References: <3f3dd1ed-9eda-4b54-98e4-f18d66dc5ddb@Spark> <82ab9f1c-61e7-4705-b7a1-70563f8ca8b6@Spark> Message-ID: Hi, That is not possible, at least a the moment. The biggest problem from an operation standpoint is that if you ban a million objects, that would trigger a huge request rush to the backend(s), which is quite dangerous. -- Guillaume Quintard On Thu, Aug 29, 2019 at 6:59 AM Tim Kelty wrote: > With a normal purge, I know I can do a "purge with restart" to re-warm the > cache. > However, I'm using xkey purging and I'm wondering if there is any way to > do something similar when clearing potentially many objects via an xkey > purge. > > My goal is to whenever possible, avoid MISSes by actual web traffic, and > have Varnish make any initial requests to warm the cache. > Is this possible with xkey purge, or when purging multiple items? > ?Or any other ideas? > _______________________________________________ > 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 timkelty at gmail.com Thu Aug 29 18:37:19 2019 From: timkelty at gmail.com (Tim Kelty) Date: Thu, 29 Aug 2019 14:37:19 -0400 Subject: synth response body not =?utf-8?Q?working=E2=80=A6?= In-Reply-To: <75e61b87-8c43-4992-9a07-b9be6872cc4f@Spark> References: <75e61b87-8c43-4992-9a07-b9be6872cc4f@Spark> Message-ID: <308cb625-999e-43dc-bd3d-06cf10484b44@Spark> Within my vcl_recv, I have something like this: # Allow purging if (req.method == "PURGE") { if (!client.ip ~ purge) { return (synth(403, "Forbidden")); } if (req.http.xkey-purge) { set req.http.n-gone = xkey.purge(req.http.xkey-purge); # If you got this stage (and didn't error out above), purge the cached result return (synth(200, "Invalidated "+req.http.n-gone+" objects")); } else { return (purge); } } ?and a a vcl_synth like: sub vcl_synth { if (resp.status == 720) { # We use this special error status 720 to force redirects with 301 (permanent) redirects # To use this, call the following from anywhere in vcl_recv: return (synth(720, "http://host/new.html")); set resp.http.Location = resp.reason; set resp.status = 301; return (deliver); } elseif (resp.status == 721) { # And we use error status 721 to force redirects with a 302 (temporary) redirect # To use this, call the following from anywhere in vcl_recv: return (synth(720, "http://host/new.html")); set resp.http.Location = resp.reason; set resp.status = 302; return (deliver); } return (deliver); } When I perform the xkey-purge request, I get back a 200, and can confirm that the purging is working, but the content-length is always 0 (I don't get the "Invalidated n objects" message). Not sure where to start debugging?any idea what could cause this? ? Tim Kelty -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Thu Aug 29 19:18:21 2019 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Thu, 29 Aug 2019 12:18:21 -0700 Subject: =?UTF-8?Q?Re=3A_synth_response_body_not_working=E2=80=A6?= In-Reply-To: <308cb625-999e-43dc-bd3d-06cf10484b44@Spark> References: <75e61b87-8c43-4992-9a07-b9be6872cc4f@Spark> <308cb625-999e-43dc-bd3d-06cf10484b44@Spark> Message-ID: because you return deliver, you are bypassing the builtin.vcl section that usually calls synthetic() ( https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishd/builtin.vcl#L113), that is why you have a 0-length body. Also, the "Invalidated..." message is the reason (like the "OK" for a 200), not the body. Check the response line of your response (i.e. the first line, before the headers) -- Guillaume Quintard On Thu, Aug 29, 2019 at 11:38 AM Tim Kelty wrote: > Within my vcl_recv, I have something like this: > > > # Allow purging > if (req.method == "PURGE") { > if (!client.ip ~ purge) { > return (synth(403, "Forbidden")); > } > > if (req.http.xkey-purge) { > set req.http.n-gone = xkey.purge(req.http.xkey-purge); > # If you got this stage (and didn't error out above), purge the cached > result > return (synth(200, "Invalidated "+req.http.n-gone+" objects")); > } else { > return (purge); > } > > } > > ?and a a vcl_synth like: > > sub vcl_synth { > if (resp.status == 720) { > # We use this special error status 720 to force redirects with 301 > (permanent) redirects > # To use this, call the following from anywhere in vcl_recv: return > (synth(720, "http://host/new.html")); > set resp.http.Location = resp.reason; > set resp.status = 301; > return (deliver); > } elseif (resp.status == 721) { > # And we use error status 721 to force redirects with a 302 (temporary) > redirect > # To use this, call the following from anywhere in vcl_recv: return > (synth(720, "http://host/new.html")); > set resp.http.Location = resp.reason; > set resp.status = 302; > return (deliver); > } > > return (deliver); > } > > > When I perform the xkey-purge request, I get back a 200, and can confirm > that the purging is working, but the content-length is always 0 (I don't > get the "Invalidated n objects" message). > > Not sure where to start debugging?any idea what could cause this? > > ? > Tim Kelty > _______________________________________________ > 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 i.zachari at gmail.com Fri Aug 30 14:32:08 2019 From: i.zachari at gmail.com (Giannis Zach) Date: Fri, 30 Aug 2019 17:32:08 +0300 Subject: varnish health probe errors In-Reply-To: References: Message-ID: Thank you Guillaume for the confirmation, I've done some tests by increasing the timeout and the failed health probes were decreased, unfortunately, I've had to increase the timeout to 15 seconds which makes me think that something is wrong with the network. -- Giannis On Thu, 29 Aug 2019 at 17:17, Guillaume Quintard < guillaume at varnish-software.com> wrote: > Hi, > > I think you got everything right: on the Varnish side, the connection was > established (4) and successfully transmitted (X), we just never received a > response, so yes, this has to do with timing out, most probably. > > -- > Guillaume Quintard > > > On Thu, Aug 29, 2019 at 12:34 AM Giannis Zach wrote: > >> Hello all, >> >> a successful health probe will log this flags `4--X-RH` and from the >> documentation the flags are: >> 4 -- IPv4 connection established >> X -- Request transmit succeeded >> R -- Read response succeeded >> H -- Happy with the result >> >> The issue I'm facing is that sometimes the health probe returns the flags >> `4--X---` marking the backend as sick. >> >> Can someone please explain to me when a varnish health probe will not log >> an `R` (Read response succeeded)? Is this related to the health probe's >> timeout value? Does this mean that the TCP connection failed before the >> backend sent the response? The backend doesn't even log the request in its >> access log, so from my understanding, the backend never received that >> request, however, varnish says the request was successfully transmitted >> (the `X` flag). >> >> Thank you for your time. >> >> -- >> Giannis >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > -- Giannis Zachariadis -------------- next part -------------- An HTML attachment was scrubbed... URL: