From yianniska at gmail.com  Sun Jan  1 01:21:45 2017
From: yianniska at gmail.com (Yiannis Karayiannidis)
Date: Sun, 1 Jan 2017 03:21:45 +0200
Subject: Varnish segfault inserting leap second
Message-ID: <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ@mail.gmail.com>

Hi all,
Today i had a segfault on my varnish boxes from the leap second


Dec 31 23:59:59 lin-varnish kernel: Clock: inserting leap second 23:59:60
UTC
Dec 31 23:59:59 lin-varnish systemd: Time has been changed
Dec 31 23:59:59 lin-varnish kernel: varnishd[18512]: segfault at 0 ip
0000000000433829 sp 00007fd7c7d1e170 error 4 i
n varnishd[400000+95000]


What a nice way to start the 2017...
??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170101/115a2476/attachment.html>

From phk at phk.freebsd.dk  Sun Jan  1 11:02:50 2017
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 01 Jan 2017 11:02:50 +0000
Subject: Varnish segfault inserting leap second
In-Reply-To: <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ@mail.gmail.com>
References: <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ@mail.gmail.com>
Message-ID: <94155.1483268570@critter.freebsd.dk>

--------
In message <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ at mail.gmail.com>, Yiannis Karayi
annidis writes:

>Dec 31 23:59:59 lin-varnish kernel: Clock: inserting leap second 23:59:60
>UTC
>Dec 31 23:59:59 lin-varnish systemd: Time has been changed
>Dec 31 23:59:59 lin-varnish kernel: varnishd[18512]: segfault at 0 ip
>0000000000433829 sp 00007fd7c7d1e170 error 4 in varnishd[400000+95000]

Do you know how this particular system handled leapseconds ?

(ie: did it step the clock, did it use the ntp_adjtime(STA_INS) or dit it slew it ?)


-- 
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 yianniska at gmail.com  Mon Jan  2 12:48:00 2017
From: yianniska at gmail.com (Yiannis Karayiannidis)
Date: Mon, 2 Jan 2017 14:48:00 +0200
Subject: Varnish segfault inserting leap second
In-Reply-To: <94155.1483268570@critter.freebsd.dk>
References: <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ@mail.gmail.com>
 <94155.1483268570@critter.freebsd.dk>
Message-ID: <CAMbCpVodg+m2-gJdWu13mGcBrXx5fHhHzYu6xxHSO3ZYMOtN1g@mail.gmail.com>

Hi Poul,
the messages i've got were

Dec 31 23:59:59 lin-varnish kernel: Clock: inserting leap second 23:59:60
UTC
and
Jan  1 00:00:02 lin-varnish ntpd[951]: 0.0.0.0 061b 0b leap_event

I'm not sure how the CentOS handled leapsecond...

Regards
Yiannis

2017-01-01 13:02 GMT+02:00 Poul-Henning Kamp <phk at phk.freebsd.dk>:

> --------
> In message <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ@
> mail.gmail.com>, Yiannis Karayi
> annidis writes:
>
> >Dec 31 23:59:59 lin-varnish kernel: Clock: inserting leap second 23:59:60
> >UTC
> >Dec 31 23:59:59 lin-varnish systemd: Time has been changed
> >Dec 31 23:59:59 lin-varnish kernel: varnishd[18512]: segfault at 0 ip
> >0000000000433829 sp 00007fd7c7d1e170 error 4 in varnishd[400000+95000]
>
> Do you know how this particular system handled leapseconds ?
>
> (ie: did it step the clock, did it use the ntp_adjtime(STA_INS) or dit it
> slew it ?)
>
>
> --
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170102/21d75304/attachment.html>

From clausp at campaya.com  Tue Jan  3 13:54:29 2017
From: clausp at campaya.com (Claus Pedersen)
Date: Tue, 3 Jan 2017 14:54:29 +0100
Subject: Http/2.0 POST requests fails
Message-ID: <CAG4Wnj3_uLiSqegKx6Kojo1GKg77xQTeT1e+w55Op-7EXTKM-A@mail.gmail.com>

Hi All,

I am testing Varnish5 with hitch 1.4.3 and everything seems to work fine,
except POST requests doesn't work.
It looks like Varnish is passing the request to the backend server with
request protocol HTTP/2.0 unchanged, which makes the backend server throw
up because it doesn't support it.

I have tried to set bereq.proto in vcl_backend_fetch to "HTTP/1.1" but
without much luck.

Any idea of what causes this?

Kind regards
Claus Pedersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170103/4920a034/attachment.html>

From dridi at varni.sh  Tue Jan  3 14:48:13 2017
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 3 Jan 2017 15:48:13 +0100
Subject: Http/2.0 POST requests fails
In-Reply-To: <CAG4Wnj3_uLiSqegKx6Kojo1GKg77xQTeT1e+w55Op-7EXTKM-A@mail.gmail.com>
References: <CAG4Wnj3_uLiSqegKx6Kojo1GKg77xQTeT1e+w55Op-7EXTKM-A@mail.gmail.com>
Message-ID: <CABoVN9Dwj6HT91yC-XZzqo=T7LUj4_EzbHPTsChOObYQWb6xWA@mail.gmail.com>

On Tue, Jan 3, 2017 at 2:54 PM, Claus Pedersen <clausp at campaya.com> wrote:
> Hi All,
>
> I am testing Varnish5 with hitch 1.4.3 and everything seems to work fine,
> except POST requests doesn't work.
> It looks like Varnish is passing the request to the backend server with
> request protocol HTTP/2.0 unchanged, which makes the backend server throw up
> because it doesn't support it.
>
> I have tried to set bereq.proto in vcl_backend_fetch to "HTTP/1.1" but
> without much luck.
>
> Any idea of what causes this?

You should see "incomplete code" in the panic message. We haven't
implemented yet the body frames handling on the client side.

Please note that HTTP/2 support is currently experimental, some
features are missing. Please report crashes unless the error message
is "incomplete code" and thank you for testing h2 in Varnish!

Cheers,
Dridi



From dridi at varni.sh  Tue Jan  3 14:51:51 2017
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 3 Jan 2017 15:51:51 +0100
Subject: Status of zipnish
In-Reply-To: <8410f80d-73da-ceda-4990-285a85c2155d@gmx.de>
References: <8410f80d-73da-ceda-4990-285a85c2155d@gmx.de>
Message-ID: <CABoVN9CmOAKUCopb3t5rKDvj+HySvXG8KZ34t8if+EGhUHLvRA@mail.gmail.com>

On Sat, Dec 17, 2016 at 10:44 AM, Ronald <ronald.ploeger at gmx.de> wrote:
> Hi,
>
> about a year ago Varnish Software announces "zipnish":
> https://www.varnish-software.com/varnish-software-launches-zipnish/
>
> The last commit on the project
> https://github.com/varnish/zipnish/commits/master was more than half a year
> ago.
>
> Is "zipnish" already dead? Does anyone can comment on the status?

Hello Ronald,

I waited for the whole team to be back from holidays to bring up this
topic and zipnish is not dead. You already had a response from Marius
(zipnish maintainer) on github, I'm responding here too for
completeness.

Dridi



From yianniska at gmail.com  Wed Jan  4 13:22:53 2017
From: yianniska at gmail.com (Yiannis Karayiannidis)
Date: Wed, 4 Jan 2017 15:22:53 +0200
Subject: Varnish segfault inserting leap second
In-Reply-To: <CAMbCpVodg+m2-gJdWu13mGcBrXx5fHhHzYu6xxHSO3ZYMOtN1g@mail.gmail.com>
References: <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ@mail.gmail.com>
 <94155.1483268570@critter.freebsd.dk>
 <CAMbCpVodg+m2-gJdWu13mGcBrXx5fHhHzYu6xxHSO3ZYMOtN1g@mail.gmail.com>
Message-ID: <CAMbCpVpqdrMxKTwAuTepPBzXL1Xb-UQcikmdp8dC38jX1RxJmQ@mail.gmail.com>

Hi all
i 've managed to reproduce the problem.
I had to live migrated the centralized NTP server of my infrastructure and
varnish "failed" again with a new segfault.
-----------------------------------------------------------------------
My simple ntp.conf on the varnish box is as follows:

# file is managed by puppet

driftfile /var/lib/ntp/drift



server ntp1.xxx.com iburst
server ntp2.xxx.com iburst

# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
-------------------------------------------------------------------------------
And the segfault

Jan  4 09:45:07 lin-varnish systemd: Time has been changed
Jan  4 09:45:07 lin-varnish kernel: varnishd[5941]: segfault at 0 ip
0000000000433829 sp 00007fd7b01ba170 error 4 in
 varnishd[400000+95000]

maybe it is related with
https://github.com/varnishcache/varnish-cache/issues/1874 ??

Regards
Yiannis



2017-01-02 14:48 GMT+02:00 Yiannis Karayiannidis <yianniska at gmail.com>:

> Hi Poul,
> the messages i've got were
>
> Dec 31 23:59:59 lin-varnish kernel: Clock: inserting leap second 23:59:60
> UTC
> and
> Jan  1 00:00:02 lin-varnish ntpd[951]: 0.0.0.0 061b 0b leap_event
>
> I'm not sure how the CentOS handled leapsecond...
>
> Regards
> Yiannis
>
> 2017-01-01 13:02 GMT+02:00 Poul-Henning Kamp <phk at phk.freebsd.dk>:
>
>> --------
>> In message <CAMbCpVq4KFEkfbYjVEqEhaJB+PbZWmdv04-z8w2PpvnXkfazCQ at mail.
>> gmail.com>, Yiannis Karayi
>> annidis writes:
>>
>> >Dec 31 23:59:59 lin-varnish kernel: Clock: inserting leap second 23:59:60
>> >UTC
>> >Dec 31 23:59:59 lin-varnish systemd: Time has been changed
>> >Dec 31 23:59:59 lin-varnish kernel: varnishd[18512]: segfault at 0 ip
>> >0000000000433829 sp 00007fd7c7d1e170 error 4 in varnishd[400000+95000]
>>
>> Do you know how this particular system handled leapseconds ?
>>
>> (ie: did it step the clock, did it use the ntp_adjtime(STA_INS) or dit it
>> slew it ?)
>>
>>
>> --
>> 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170104/fa59c2ac/attachment.html>

From vlad.rusu at lola.tech  Thu Jan  5 05:38:34 2017
From: vlad.rusu at lola.tech (Vlad Rusu)
Date: Thu, 5 Jan 2017 07:38:34 +0200
Subject: Varnish 4.1 - manager and cacher processes owned by "varnish"
 user 
In-Reply-To: <08D05DD1-3657-41F1-A070-9FC8B0B8468E@lola.tech>
References: <08D05DD1-3657-41F1-A070-9FC8B0B8468E@lola.tech>
Message-ID: <EAE5A77C-9B37-4F1D-AF4C-DD8177B7DB00@lola.tech>

Hi again, 

Found https://varnish-cache.org/docs/4.1/whats-new/changes.html#proactive-security-features <https://varnish-cache.org/docs/4.1/whats-new/changes.html#proactive-security-features>

Even this shows something else:

?On most systems, the Varnish parent process will now drop effective privileges to normal user mode when not doing operations needing special access.
The Varnish worker child should now be run as a separate vcache user."

Thanks!

--
Vlad Rusu
skypeid: rusu.h.vlad | cell: +40758066019

Lola Tech | lola.tech <https://lola.tech/>
> On 22 Nov 2016, at 21:57, Vlad Rusu <vlad.rusu at lola.tech> wrote:
> 
> Hi everyone, 
> 
> I noticed the user owning both varnishd processes (parent + child) is now ?varnish" (or whatever user we specify in the config). I was previously using Varnish 3 in RHEL 6 and the parent process was owned by root, as the book also describes.
> 
> Looking at the Varnish 4.0 book (can?t find a 4.1 one), it still says that?s how it should be ?> http://book.varnish-software.com/4.0/chapters/Tuning.html#the-parent-process-the-manager <http://book.varnish-software.com/4.0/chapters/Tuning.html#the-parent-process-the-manager>
> 
> Before I start testing diff Varnish versions on different OS versions, can you tell me if this is expected? Is it safe.. ?
> 
> =======
> 
> OS: Centos 7.2
> Varnish: 4.1.3 from the Varnish repo
> 
> [root at xxx varnish]# cat /etc/redhat-release
> CentOS Linux release 7.2.1511 (Core)
> 
> [root at xxx varnish]# rpm -qi varnish
> Name        : varnish
> Version     : 4.1.3
> Release     : 1.el7
> Architecture: x86_64
> Install Date: Tue 22 Nov 2016 07:16:30 PM UTC
> Group       : System Environment/Daemons
> Size        : 1131779
> License     : BSD
> Signature   : RSA/SHA1, Wed 06 Jul 2016 12:39:52 PM UTC, Key ID 60e7c096c4deffeb
> Source RPM  : varnish-4.1.3-1.el7.src.rpm
> Build Date  : Wed 06 Jul 2016 12:30:55 PM UTC
> Build Host  : centos7.varnish-software.com <http://centos7.varnish-software.com/>
> Relocations : (not relocatable)
> URL         : https://www.varnish-cache.org/ <https://www.varnish-cache.org/>
> Summary     : High-performance HTTP accelerator
> 
> [root at xxx varnish]# ps auxf | grep varnish
> varnish  14899  0.0  0.0 133080  1292 ?        Ss   19:32   0:00 /usr/sbin/varnishd -P /var/run/varnish.pid -f /etc/varnish/default.vcl -a :6081 -T 127.0.0.1:6082 -S /etc/varnish/secret -s malloc,256M
> varnish  14901  0.0  4.5 314788 85248 ?        Sl   19:32   0:00  \_ /usr/sbin/varnishd -P /var/run/varnish.pid -f /etc/varnish/default.vcl -a :6081 -T 127.0.0.1:6082 -S /etc/varnish/secret -s malloc,256M
> 
> =======
> 
> Thanks!
> 
> --
> Vlad Rusu
> skypeid: rusu.h.vlad | cell: +40758066019
> 
> Lola Tech | lola.tech <https://lola.tech/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170105/2e46c544/attachment.html>

From vlad.rusu at lola.tech  Fri Jan  6 09:28:33 2017
From: vlad.rusu at lola.tech (Vlad Rusu)
Date: Fri, 6 Jan 2017 11:28:33 +0200
Subject: Varnish 4.1.4 - MAIN.n_gunzip counter increasing for every
 MAIN.backend_req
Message-ID: <0F515569-4675-4CE0-A374-EB26F5CF4B3F@lola.tech>

Hi guys, 

https://www.varnish-cache.org/docs/4.1/reference/vsl.html <https://www.varnish-cache.org/docs/4.1/reference/vsl.html>

Gzip tag, in the format section, shows a possible flag of ?u? representing a Gunzip-test

In my varnishstat output I see how MAIN.n_gunzip equals (roughly) MAIN.backend_req


Looking at the Gzip tag, I see the following for every backend request:

Gzip           u F - 70 55 80 80 489


Can someone help me understand what a Gunzip-test means / does? It sure gets counted against MAIN.n_gunzip.

Am not attaching the VCL or a full varnishstat as I don?t think it makes sense. Each backend sends gzipped data back to Varnish and each client requests for gzipped data from Varnish.. 

Thanks!

--
Vlad Rusu
skypeid: rusu.h.vlad | cell: +40758066019

Lola Tech | lola.tech <https://lola.tech/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170106/b8f01b7c/attachment.html>

From dridi at varni.sh  Fri Jan  6 13:07:32 2017
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Fri, 6 Jan 2017 14:07:32 +0100
Subject: Varnish 4.1.4 - MAIN.n_gunzip counter increasing for every
 MAIN.backend_req
In-Reply-To: <0F515569-4675-4CE0-A374-EB26F5CF4B3F@lola.tech>
References: <0F515569-4675-4CE0-A374-EB26F5CF4B3F@lola.tech>
Message-ID: <CABoVN9DTFLOHUmDaBjLGqxvncppbitxtuppq3jouvk3pAGfg0w@mail.gmail.com>

On Fri, Jan 6, 2017 at 10:28 AM, Vlad Rusu <vlad.rusu at lola.tech> wrote:
> Hi guys,
>
> https://www.varnish-cache.org/docs/4.1/reference/vsl.html
>
> Gzip tag, in the format section, shows a possible flag of ?u? representing a
> Gunzip-test
>
> In my varnishstat output I see how MAIN.n_gunzip equals (roughly)
> MAIN.backend_req
>
>
> Looking at the Gzip tag, I see the following for every backend request:
>
> Gzip           u F - 70 55 80 80 489
>
>
> Can someone help me understand what a Gunzip-test means / does? It sure gets
> counted against MAIN.n_gunzip.

Hello Vlad,

The gunzip test is performed when an already-gzipped backend response
is inserted in the cache. It is inflated in a black-hole, only to make sure
that the object being fetched is proper gzip.

> Am not attaching the VCL or a full varnishstat as I don?t think it makes
> sense. Each backend sends gzipped data back to Varnish and each client
> requests for gzipped data from Varnish..

For each gzipped backend response, you will see this behavior (u flag
in logs, and counter increment). There is no separate counter for test
gunzip vs regular gunzip, although some of us would like to make the
distinction.

As an end-user, how and where would this be best documented in your
opinion?

Best Regards,
Dridi



From vlad.rusu at lola.tech  Fri Jan  6 13:40:25 2017
From: vlad.rusu at lola.tech (Vlad Rusu)
Date: Fri, 6 Jan 2017 15:40:25 +0200
Subject: Varnish 4.1.4 - MAIN.n_gunzip counter increasing for every
 MAIN.backend_req
In-Reply-To: <CABoVN9DTFLOHUmDaBjLGqxvncppbitxtuppq3jouvk3pAGfg0w@mail.gmail.com>
References: <0F515569-4675-4CE0-A374-EB26F5CF4B3F@lola.tech>
 <CABoVN9DTFLOHUmDaBjLGqxvncppbitxtuppq3jouvk3pAGfg0w@mail.gmail.com>
Message-ID: <48BCFFB9-AC61-41DF-8018-505F2BA3A677@lola.tech>

Thanks a lot Dridi!

That makes sense :)

To answer your 2nd question, I would have liked to see this documented as follows:

http://www.varnish-cache.org/docs/4.1/reference/varnish-counters.html <http://www.varnish-cache.org/docs/4.1/reference/varnish-counters.html> - in the n_gunzip section (i.e. includes the.. )

https://www.varnish-cache.org/docs/4.1/reference/vsl.html <https://www.varnish-cache.org/docs/4.1/reference/vsl.html> - in the Gzip tag section

https://varnish-cache.org/docs/4.1/phk/gzip.html <https://varnish-cache.org/docs/4.1/phk/gzip.html> - and here.. 


Thanks for your hard work on this cool product guys!

--
Vlad Rusu
skypeid: rusu.h.vlad | cell: +40758066019

Lola Tech | lola.tech <https://lola.tech/>
> On 06 Jan 2017, at 15:07, Dridi Boukelmoune <dridi at varni.sh> wrote:
> 
> On Fri, Jan 6, 2017 at 10:28 AM, Vlad Rusu <vlad.rusu at lola.tech> wrote:
>> Hi guys,
>> 
>> https://www.varnish-cache.org/docs/4.1/reference/vsl.html
>> 
>> Gzip tag, in the format section, shows a possible flag of ?u? representing a
>> Gunzip-test
>> 
>> In my varnishstat output I see how MAIN.n_gunzip equals (roughly)
>> MAIN.backend_req
>> 
>> 
>> Looking at the Gzip tag, I see the following for every backend request:
>> 
>> Gzip           u F - 70 55 80 80 489
>> 
>> 
>> Can someone help me understand what a Gunzip-test means / does? It sure gets
>> counted against MAIN.n_gunzip.
> 
> Hello Vlad,
> 
> The gunzip test is performed when an already-gzipped backend response
> is inserted in the cache. It is inflated in a black-hole, only to make sure
> that the object being fetched is proper gzip.
> 
>> Am not attaching the VCL or a full varnishstat as I don?t think it makes
>> sense. Each backend sends gzipped data back to Varnish and each client
>> requests for gzipped data from Varnish..
> 
> For each gzipped backend response, you will see this behavior (u flag
> in logs, and counter increment). There is no separate counter for test
> gunzip vs regular gunzip, although some of us would like to make the
> distinction.
> 
> As an end-user, how and where would this be best documented in your
> opinion?
> 
> Best Regards,
> Dridi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170106/712c9628/attachment.html>

From sander at hoentjen.eu  Mon Jan  9 08:50:14 2017
From: sander at hoentjen.eu (Sander Hoentjen)
Date: Mon, 9 Jan 2017 09:50:14 +0100
Subject: Proxy Protocol - CLIENT_SSL
In-Reply-To: <79f63449-300a-5f07-79ca-44fae6fa4150@hoentjen.eu>
References: <57c9c467-b4d1-ae6a-0328-acf8c35ded5e@hoentjen.eu>
 <79f63449-300a-5f07-79ca-44fae6fa4150@hoentjen.eu>
Message-ID: <4b8d697a-5e15-1d95-97e7-2bf2f75ff4f9@hoentjen.eu>

Does anybody know a better place where I can ask this question?

Regards,
Sander

On 12/29/2016 04:01 PM, Sander Hoentjen wrote:
> On 12/23/2016 11:18 AM, Sander Hoentjen wrote:
>> Hi list,
>>
>> I have a questioned about both Hitch and Varnish:
>> Does hitch support (defines) PP2_CLIENT_SSL from proxy-protocol [1]?
>> The follow-up question is: Can Varnish proxy this information (in
>> essence just keep the proxy header as-is)
>>
>> Regards,
>> Sander
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
> Hmm, it seems I forgot the link to proxy-protocol [1]:
> http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
> And then specifically I am talking about the binary header format
> (version 2).
>
> """
>
> If the length specified in the PROXY protocol header indicates that additional
> bytes are part of the header beyond the address information, a receiver may
> choose to skip over and ignore those bytes, or attempt to interpret those
> bytes.
>
> The information in those bytes will be arranged in Type-Length-Value (TLV
> vectors) in the following format.  The first byte is the Type of the vector.
> The second two bytes represent the length in bytes of the value (not included
> the Type and Length bytes), and following the length field is the number of
> bytes specified by the length.
>
>         struct pp2_tlv {
>             uint8_t type;
>             uint8_t length_hi;
>             uint8_t length_lo;
>             uint8_t value[0];
>         };
>
> The following types have already been registered for the <type> field :
>
>         #define PP2_TYPE_ALPN           0x01
>         #define PP2_TYPE_AUTHORITY      0x02
>         #define PP2_TYPE_SSL            0x20
>         #define PP2_SUBTYPE_SSL_VERSION 0x21
>         #define PP2_SUBTYPE_SSL_CN      0x22
>         #define PP2_TYPE_NETNS          0x30
> """
>
> It would be very nice if Hitch supports this, but I can't find any info
> on it. If this is not the right mailing list to ask, it would be nice if
> someone can point me in the right direction.
>
> Regards,
> Sander
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>




From guillaume at varnish-software.com  Mon Jan  9 14:09:34 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Mon, 9 Jan 2017 15:09:34 +0100
Subject: Proxy Protocol - CLIENT_SSL
In-Reply-To: <4b8d697a-5e15-1d95-97e7-2bf2f75ff4f9@hoentjen.eu>
References: <57c9c467-b4d1-ae6a-0328-acf8c35ded5e@hoentjen.eu>
 <79f63449-300a-5f07-79ca-44fae6fa4150@hoentjen.eu>
 <4b8d697a-5e15-1d95-97e7-2bf2f75ff4f9@hoentjen.eu>
Message-ID: <CAJ6ZYQxQNDt9+7TBG9-Q2b6dRT3=w0airX-1zY34pjXfBehsnQ@mail.gmail.com>

Hi,

To my knowledge, the answer to both questions is no, at the moment.

-- 
Guillaume Quintard

On Mon, Jan 9, 2017 at 9:50 AM, Sander Hoentjen <sander at hoentjen.eu> wrote:

> Does anybody know a better place where I can ask this question?
>
> Regards,
> Sander
>
> On 12/29/2016 04:01 PM, Sander Hoentjen wrote:
> > On 12/23/2016 11:18 AM, Sander Hoentjen wrote:
> >> Hi list,
> >>
> >> I have a questioned about both Hitch and Varnish:
> >> Does hitch support (defines) PP2_CLIENT_SSL from proxy-protocol [1]?
> >> The follow-up question is: Can Varnish proxy this information (in
> >> essence just keep the proxy header as-is)
> >>
> >> Regards,
> >> Sander
> >>
> >> _______________________________________________
> >> varnish-misc mailing list
> >> varnish-misc at varnish-cache.org
> >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> >>
> > Hmm, it seems I forgot the link to proxy-protocol [1]:
> > http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
> > And then specifically I am talking about the binary header format
> > (version 2).
> >
> > """
> >
> > If the length specified in the PROXY protocol header indicates that
> additional
> > bytes are part of the header beyond the address information, a receiver
> may
> > choose to skip over and ignore those bytes, or attempt to interpret those
> > bytes.
> >
> > The information in those bytes will be arranged in Type-Length-Value (TLV
> > vectors) in the following format.  The first byte is the Type of the
> vector.
> > The second two bytes represent the length in bytes of the value (not
> included
> > the Type and Length bytes), and following the length field is the number
> of
> > bytes specified by the length.
> >
> >         struct pp2_tlv {
> >             uint8_t type;
> >             uint8_t length_hi;
> >             uint8_t length_lo;
> >             uint8_t value[0];
> >         };
> >
> > The following types have already been registered for the <type> field :
> >
> >         #define PP2_TYPE_ALPN           0x01
> >         #define PP2_TYPE_AUTHORITY      0x02
> >         #define PP2_TYPE_SSL            0x20
> >         #define PP2_SUBTYPE_SSL_VERSION 0x21
> >         #define PP2_SUBTYPE_SSL_CN      0x22
> >         #define PP2_TYPE_NETNS          0x30
> > """
> >
> > It would be very nice if Hitch supports this, but I can't find any info
> > on it. If this is not the right mailing list to ask, it would be nice if
> > someone can point me in the right direction.
> >
> > Regards,
> > Sander
> >
> > _______________________________________________
> > 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170109/27e057cc/attachment.html>

From sander at hoentjen.eu  Mon Jan  9 15:21:56 2017
From: sander at hoentjen.eu (Sander Hoentjen)
Date: Mon, 9 Jan 2017 16:21:56 +0100
Subject: Proxy Protocol - CLIENT_SSL
In-Reply-To: <CAJ6ZYQxQNDt9+7TBG9-Q2b6dRT3=w0airX-1zY34pjXfBehsnQ@mail.gmail.com>
References: <57c9c467-b4d1-ae6a-0328-acf8c35ded5e@hoentjen.eu>
 <79f63449-300a-5f07-79ca-44fae6fa4150@hoentjen.eu>
 <4b8d697a-5e15-1d95-97e7-2bf2f75ff4f9@hoentjen.eu>
 <CAJ6ZYQxQNDt9+7TBG9-Q2b6dRT3=w0airX-1zY34pjXfBehsnQ@mail.gmail.com>
Message-ID: <37dd05e1-e2d5-5e72-bfe5-52a32b6aa110@hoentjen.eu>

Guillaume,

Thanks for your response. Too bad I am not a coder, I am interested in
having this added :)
-- 
Sander

On 01/09/2017 03:09 PM, Guillaume Quintard wrote:
> Hi,
>
> To my knowledge, the answer to both questions is no, at the moment.
>
> -- 
> Guillaume Quintard
>
> On Mon, Jan 9, 2017 at 9:50 AM, Sander Hoentjen <sander at hoentjen.eu
> <mailto:sander at hoentjen.eu>> wrote:
>
>     Does anybody know a better place where I can ask this question?
>
>     Regards,
>     Sander
>
>     On 12/29/2016 04:01 PM, Sander Hoentjen wrote:
>     > On 12/23/2016 11:18 AM, Sander Hoentjen wrote:
>     >> Hi list,
>     >>
>     >> I have a questioned about both Hitch and Varnish:
>     >> Does hitch support (defines) PP2_CLIENT_SSL from proxy-protocol
>     [1]?
>     >> The follow-up question is: Can Varnish proxy this information (in
>     >> essence just keep the proxy header as-is)
>     >>
>     >> Regards,
>     >> Sander
>     >>
>     >> _______________________________________________
>     >> varnish-misc mailing list
>     >> varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     >>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>     >>
>     > Hmm, it seems I forgot the link to proxy-protocol [1]:
>     > http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
>     <http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt>
>     > And then specifically I am talking about the binary header format
>     > (version 2).
>     >
>     > """
>     >
>     > If the length specified in the PROXY protocol header indicates
>     that additional
>     > bytes are part of the header beyond the address information, a
>     receiver may
>     > choose to skip over and ignore those bytes, or attempt to
>     interpret those
>     > bytes.
>     >
>     > The information in those bytes will be arranged in
>     Type-Length-Value (TLV
>     > vectors) in the following format.  The first byte is the Type of
>     the vector.
>     > The second two bytes represent the length in bytes of the value
>     (not included
>     > the Type and Length bytes), and following the length field is
>     the number of
>     > bytes specified by the length.
>     >
>     >         struct pp2_tlv {
>     >             uint8_t type;
>     >             uint8_t length_hi;
>     >             uint8_t length_lo;
>     >             uint8_t value[0];
>     >         };
>     >
>     > The following types have already been registered for the <type>
>     field :
>     >
>     >         #define PP2_TYPE_ALPN           0x01
>     >         #define PP2_TYPE_AUTHORITY      0x02
>     >         #define PP2_TYPE_SSL            0x20
>     >         #define PP2_SUBTYPE_SSL_VERSION 0x21
>     >         #define PP2_SUBTYPE_SSL_CN      0x22
>     >         #define PP2_TYPE_NETNS          0x30
>     > """
>     >
>     > It would be very nice if Hitch supports this, but I can't find
>     any info
>     > on it. If this is not the right mailing list to ask, it would be
>     nice if
>     > someone can point me in the right direction.
>     >
>     > Regards,
>     > Sander
>     >
>     > _______________________________________________
>     > varnish-misc mailing list
>     > varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     >
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>     >
>
>
>     _______________________________________________
>     varnish-misc mailing list
>     varnish-misc at varnish-cache.org <mailto:varnish-misc at varnish-cache.org>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <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




From Tim.Stalker at ucdenver.edu  Thu Jan 19 06:28:45 2017
From: Tim.Stalker at ucdenver.edu (Stalker, Tim)
Date: Thu, 19 Jan 2017 06:28:45 +0000
Subject: Varnish on stand-alone server
Message-ID: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>

I'm setting up a web development cluster with 3 or 4 backend webservers. Because this is all offline at the moment, provisioning this with vagrant and ansible in a private network of servers with no fqdn. I have no problem getting varnish to connect to the backends over port 80 from within the varnish VM itself over lynx and curl, but from outside the VM on my host machine, varnish is unaware of the backends. Varnish works fine if I install it on the same machine as apache but if I try to run it in its own virtual machine. I would like to simulate a production environment as much as possible when all of the server names are fully qualified.


Can anyone suggest ways I might get varnish to provide caching from browsers on my host machine while running in its own virtual machine in a cluster?


Thanks a ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170119/e36b88f1/attachment.html>

From dridi at varni.sh  Thu Jan 19 08:41:01 2017
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Thu, 19 Jan 2017 09:41:01 +0100
Subject: Varnish 4.1.4 - MAIN.n_gunzip counter increasing for every
 MAIN.backend_req
In-Reply-To: <48BCFFB9-AC61-41DF-8018-505F2BA3A677@lola.tech>
References: <0F515569-4675-4CE0-A374-EB26F5CF4B3F@lola.tech>
 <CABoVN9DTFLOHUmDaBjLGqxvncppbitxtuppq3jouvk3pAGfg0w@mail.gmail.com>
 <48BCFFB9-AC61-41DF-8018-505F2BA3A677@lola.tech>
Message-ID: <CABoVN9Ac9HAc=9g33VECDBh_2_Ajfxqr2yFaq1ihm6rokAsLhw@mail.gmail.com>

On Fri, Jan 6, 2017 at 2:40 PM, Vlad Rusu <vlad.rusu at lola.tech> wrote:
> Thanks a lot Dridi!

Hello,

We discussed this with the core team during last bug wash, and we'll
try to fix that the best we can.

> That makes sense :)
>
> To answer your 2nd question, I would have liked to see this documented as
> follows:
>
> http://www.varnish-cache.org/docs/4.1/reference/varnish-counters.html - in
> the n_gunzip section (i.e. includes the.. )

A new counter for test gunzip will be introduced in the next major release.

> https://www.varnish-cache.org/docs/4.1/reference/vsl.html - in the Gzip tag
> section

I will see to that separately, I think it will simply refer to the
counter's documentation once it lands. So that the canonical
description of test gunzip is found in one place.

> https://varnish-cache.org/docs/4.1/phk/gzip.html - and here..

I'm not touching that, it's a bit like a piece of Varnish history:
what phk had to say (in this case about gzip) when he wrote that. I
don't think we maintain the "random outbursts" besides typos.

> Thanks for your hard work on this cool product guys!

Thanks for your help!

Dridi



From guillaume at varnish-software.com  Thu Jan 19 09:35:20 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Thu, 19 Jan 2017 10:35:20 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <CAJ6ZYQwafprbrUXkd1nz7XRSShXAF2tbWJAczPFiN2aA97KNWQ@mail.gmail.com>

Looks like a vagrant problem rather than a Varnish one. Sadly, I can't help
you on that one.

-- 
Guillaume Quintard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170119/363523a5/attachment.html>

From apj at mutt.dk  Thu Jan 19 10:44:26 2017
From: apj at mutt.dk (Andreas Plesner)
Date: Thu, 19 Jan 2017 11:44:26 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <20170119104426.GE22017@nerd.dk>

On Thu, Jan 19, 2017 at 06:28:45AM +0000, Stalker, Tim wrote:

> I have no problem getting varnish to connect to the backends over port 80
> from within the varnish VM itself over lynx and curl, but from outside the VM
> on my host machine, varnish is unaware of the backends.

Unaware, how?

What did you try already? what doesn't work? Logs?

-- 
Andreas



From miguel_3_gonzalez at yahoo.es  Thu Jan 19 10:48:26 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Thu, 19 Jan 2017 11:48:26 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>

I guess it?s not a firewall issue since you say you can reach the
backends with curl or wget, maybe the acl purge is not correctly
configured in the backends?

On 01/19/17 7:28 AM, Stalker, Tim wrote:
> I'm setting up a web development cluster with 3 or 4 backend webservers.
> Because this is all offline at the moment, provisioning this with
> vagrant and ansible in a private network of servers with no fqdn. I have
> no problem getting varnish to connect to the backends over port 80
> from within the varnish VM itself over lynx and curl, but from outside
> the VM on my host machine, varnish is unaware of the backends. Varnish
> works fine if I install it on the same machine as apache but if I try to
> run it in its own virtual machine. I would like to simulate a production
> environment as much as possible when all of the server names are fully
> qualified.
> 
> 
> Can anyone suggest ways I might get varnish to provide caching from
> browsers on my host machine while running in its own virtual machine in
> a cluster?
> 
> 
> Thanks a ton
> 
> 
> 
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> 




From Tim.Stalker at ucdenver.edu  Thu Jan 19 18:23:56 2017
From: Tim.Stalker at ucdenver.edu (Stalker, Tim)
Date: Thu, 19 Jan 2017 18:23:56 +0000
Subject: Varnish on stand-alone server
In-Reply-To: <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>,
 <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
Message-ID: <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>

Varnish is aware of the backend I have set and works fine as long as I'm logged into its virtual machine and run either curl or lynx to the address of the machine with apache running. I have my /etc/hosts file set with the backend address and virtual host as configured in the apache box, but it seems that varnish ignores the /etc/hosts file. I get logging and see the headers when I run curl -I http://backend.vhost.name<http://backend.vhost.name/> but when I do the same thing via the browser, curl, or lynx on my host computer, no logging, nothing happens inside the varnish vm.

It's probably some sort of networking config on the virtual machines themselves. One thing about the documentation surrounding varnish is that it all assumes varnish is to be installed on the same server as apache, nginx, or whatever one's frontend is. There's little if anything I can find as to how to run varnish on its own server, either virtually with no fully qualified domain name or virtually with DNS set appropriately. Are there any pointers I could go to for how to set DNS, for example? Does one point the A record to varnish or apache?

Thanks again all. Any insight you can provide would be great.

Tim


________________________________
From: Miguel Gonz?lez <miguel_3_gonzalez at yahoo.es>
Sent: Thursday, January 19, 2017 3:48:26 AM
To: Stalker, Tim; varnish-misc at varnish-cache.org
Subject: Re: Varnish on stand-alone server

I guess it?s not a firewall issue since you say you can reach the
backends with curl or wget, maybe the acl purge is not correctly
configured in the backends?

On 01/19/17 7:28 AM, Stalker, Tim wrote:
> I'm setting up a web development cluster with 3 or 4 backend webservers.
> Because this is all offline at the moment, provisioning this with
> vagrant and ansible in a private network of servers with no fqdn. I have
> no problem getting varnish to connect to the backends over port 80
> from within the varnish VM itself over lynx and curl, but from outside
> the VM on my host machine, varnish is unaware of the backends. Varnish
> works fine if I install it on the same machine as apache but if I try to
> run it in its own virtual machine. I would like to simulate a production
> environment as much as possible when all of the server names are fully
> qualified.
>
>
> Can anyone suggest ways I might get varnish to provide caching from
> browsers on my host machine while running in its own virtual machine in
> a cluster?
>
>
> Thanks a ton
>
>
>
> _______________________________________________
> 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170119/55d65a9f/attachment.html>

From Tim.Stalker at ucdenver.edu  Thu Jan 19 21:32:03 2017
From: Tim.Stalker at ucdenver.edu (Stalker, Tim)
Date: Thu, 19 Jan 2017 21:32:03 +0000
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <CO2PR05MB74666DD0588AFBFF076CBD7907E0@CO2PR05MB746.namprd05.prod.outlook.com>

It would seem that if running varnish on its own server, the backend host must point to a fqdn.

________________________________
From: Stalker, Tim
Sent: Wednesday, January 18, 2017 11:28:45 PM
To: varnish-misc at varnish-cache.org
Subject: Varnish on stand-alone server


I'm setting up a web development cluster with 3 or 4 backend webservers. Because this is all offline at the moment, provisioning this with vagrant and ansible in a private network of servers with no fqdn. I have no problem getting varnish to connect to the backends over port 80 from within the varnish VM itself over lynx and curl, but from outside the VM on my host machine, varnish is unaware of the backends. Varnish works fine if I install it on the same machine as apache but if I try to run it in its own virtual machine. I would like to simulate a production environment as much as possible when all of the server names are fully qualified.


Can anyone suggest ways I might get varnish to provide caching from browsers on my host machine while running in its own virtual machine in a cluster?


Thanks a ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170119/75fb073b/attachment.html>

From miguel_3_gonzalez at yahoo.es  Thu Jan 19 22:26:07 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Thu, 19 Jan 2017 23:26:07 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB74666DD0588AFBFF076CBD7907E0@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <CO2PR05MB74666DD0588AFBFF076CBD7907E0@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <bf623c51-c44d-2f75-0bca-a70f481cc75c@yahoo.es>

You can use local dns or trick your system using hosts file to have your
own local domain.


On 01/19/17 10:32 PM, Stalker, Tim wrote:
> It would seem that if running varnish on its own server, the backend
> host must point to a fqdn.
> 
> ------------------------------------------------------------------------
> *From:* Stalker, Tim
> *Sent:* Wednesday, January 18, 2017 11:28:45 PM
> *To:* varnish-misc at varnish-cache.org
> *Subject:* Varnish on stand-alone server
>  
> 
> I'm setting up a web development cluster with 3 or 4 backend webservers.
> Because this is all offline at the moment, provisioning this with
> vagrant and ansible in a private network of servers with no fqdn. I have
> no problem getting varnish to connect to the backends over port 80
> from within the varnish VM itself over lynx and curl, but from outside
> the VM on my host machine, varnish is unaware of the backends. Varnish
> works fine if I install it on the same machine as apache but if I try to
> run it in its own virtual machine. I would like to simulate a production
> environment as much as possible when all of the server names are fully
> qualified.
> 
> 
> Can anyone suggest ways I might get varnish to provide caching from
> browsers on my host machine while running in its own virtual machine in
> a cluster?
> 
> 
> Thanks a ton
> 
> 
> 
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> 




From apj at mutt.dk  Fri Jan 20 09:56:02 2017
From: apj at mutt.dk (Andreas Plesner)
Date: Fri, 20 Jan 2017 10:56:02 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB74666DD0588AFBFF076CBD7907E0@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <CO2PR05MB74666DD0588AFBFF076CBD7907E0@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <20170120095602.GF22017@nerd.dk>

On Thu, Jan 19, 2017 at 09:32:03PM +0000, Stalker, Tim wrote:

> It would seem that if running varnish on its own server, the backend host
> must point to a fqdn.

That is not the case. Varnish resolves the backend using getaddrinfo(3).

-- 
Andreas



From apj at mutt.dk  Fri Jan 20 09:59:10 2017
From: apj at mutt.dk (Andreas Plesner)
Date: Fri, 20 Jan 2017 10:59:10 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
 <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <20170120095910.GG22017@nerd.dk>

On Thu, Jan 19, 2017 at 06:23:56PM +0000, Stalker, Tim wrote:
> Varnish is aware of the backend I have set and works fine as long as I'm
> logged into its virtual machine and run either curl or lynx to the address of
> the machine with apache running. I have my /etc/hosts file set with the
> backend address and virtual host as configured in the apache box, but it
> seems that varnish ignores the /etc/hosts file. I get logging and see the
> headers when I run curl -I
> http://backend.vhost.name<http://backend.vhost.name/> but when I do the same
> thing via the browser, curl, or lynx on my host computer, no logging, nothing
> happens inside the varnish vm.

You're not giving us any info that actually enables us to help you. What
doesn't work? What error messages do you get? What did you already try? What
were the results of these attempts? What is in the log?

Most important is:

What doesn't work? You've only stated that it doesn't work, not what is
actually happening when you've determined that it doesn't work.

-- 
Andreas



From Tim.Stalker at ucdenver.edu  Fri Jan 20 16:38:57 2017
From: Tim.Stalker at ucdenver.edu (Stalker, Tim)
Date: Fri, 20 Jan 2017 16:38:57 +0000
Subject: Varnish on stand-alone server
In-Reply-To: <20170120095910.GG22017@nerd.dk>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
 <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>,
 <20170120095910.GG22017@nerd.dk>
Message-ID: <CO2PR05MB7468EEA864B38B1A2D8793590710@CO2PR05MB746.namprd05.prod.outlook.com>

I can't provide much detail because I don't get any reports or data from varnishlog. No errors are reported. When I run "varnishadm backend.list", the backend is reported as healthy. Plus, there's no issues with varnish communicating with the backend when I visit the backend host from within the varnish virtual machine. Everything works as intended when I run a web client (curl or lynx) from the varnish vm terminal. The problem is varnish doesn't communicate with the backend when I visit the backend host from outside the vm on my host computer's web browser.


The setup is is this - two virtual machines running in vagrant and virtualbox


192.168.33.26 (apache box with hostname clas-test.myhost.pvt listening on port 84)

192.168.33.27 (clas-varnish.myhost.pvt)


>From default.vcl:


vcl 4.0;
import std;
import directors;

include "backends.vcl";


sub vcl_init {

    new local_test = directors.round_robin();
    local_test.add_backend(express_test);
}
sub vcl_recv {

  if (server.hostname == "clas-test.hostname.pvt") {
    set req.backend_hint = local_test.backend();
  }
}
sub vcl_deliver {
  if (obj.hits > 0) {
    set resp.http.X-Cache = "HIT";
    std.log("hitmiss:HIT");
  } else {
    set resp.http.X-Cache = "MISS";
    std.log("hitmiss:MISS");
  }
}


>From backends.vcl:


backend express_test {
  .host = "192.168.33.26"; #ip of my host in its own virtual machine
  .port = "84"; #port I have set in the virtual host on my host's virtual machine
}

In /etc/varnish/varnish.params I have the VARNISH_LISTEN_PORT set to port 80 and VARNISH_LISTEN_ADDRESS commented out. Note, that when I set the address to my backend ip, varnish won't start and I get this error:

bind(): Cannot assign requested address
[19743]: Error: Failed to open (any) accept sockets.

And yet when I run "varnishadm backend.list" with the listen address commented out, the backend is reported as healthy.

Thanks again, all




________________________________
From: varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org <varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org> on behalf of Andreas Plesner <apj at mutt.dk>
Sent: Friday, January 20, 2017 2:59:10 AM
To: varnish-misc at varnish-cache.org
Subject: Re: Varnish on stand-alone server

On Thu, Jan 19, 2017 at 06:23:56PM +0000, Stalker, Tim wrote:
> Varnish is aware of the backend I have set and works fine as long as I'm
> logged into its virtual machine and run either curl or lynx to the address of
> the machine with apache running. I have my /etc/hosts file set with the
> backend address and virtual host as configured in the apache box, but it
> seems that varnish ignores the /etc/hosts file. I get logging and see the
> headers when I run curl -I
> http://backend.vhost.name<http://backend.vhost.name/> but when I do the same
> thing via the browser, curl, or lynx on my host computer, no logging, nothing
> happens inside the varnish vm.

You're not giving us any info that actually enables us to help you. What
doesn't work? What error messages do you get? What did you already try? What
were the results of these attempts? What is in the log?

Most important is:

What doesn't work? You've only stated that it doesn't work, not what is
actually happening when you've determined that it doesn't work.

--
Andreas

_______________________________________________
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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170120/0db58362/attachment.html>

From apj at mutt.dk  Fri Jan 20 19:25:46 2017
From: apj at mutt.dk (Andreas Plesner)
Date: Fri, 20 Jan 2017 20:25:46 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB7468EEA864B38B1A2D8793590710@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
 <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <20170120095910.GG22017@nerd.dk>
 <CO2PR05MB7468EEA864B38B1A2D8793590710@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <20170120192546.GH22017@nerd.dk>

On Fri, Jan 20, 2017 at 04:38:57PM +0000, Stalker, Tim wrote:

> The problem is varnish doesn't communicate with the backend when I visit the
> backend host from outside the vm on my host computer's web browser.

How do you know? How do *WE* know?

> In /etc/varnish/varnish.params I have the VARNISH_LISTEN_PORT set to port 80
> and VARNISH_LISTEN_ADDRESS commented out. Note, that when I set the address
> to my backend ip, varnish won't start and I get this error:

I would assume that VARNISH_LISTEN_ADDRESS is where varnish listens for
connections, not the address of the backend, but that is specific to the
packaging done for your OS.

-- 
Andreas



From miguel_3_gonzalez at yahoo.es  Fri Jan 20 22:18:51 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Fri, 20 Jan 2017 23:18:51 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB7468EEA864B38B1A2D8793590710@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
 <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <20170120095910.GG22017@nerd.dk>
 <CO2PR05MB7468EEA864B38B1A2D8793590710@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <a74366bf-80c8-58c0-84f5-c4a8f04241f9@yahoo.es>

What about the acl purge entries?

You probably know that you have to add in your hosts file where you are
running your browser you have to point the domain you are hitting with
the ip address of your varnish VM, don?t you?

Miguel




On 01/20/17 5:38 PM, Stalker, Tim wrote:
> I can't provide much detail because I don't get any reports or data from
> varnishlog. No errors are reported. When I run "varnishadm
> backend.list", the backend is reported as healthy. Plus, there's no
> issues with varnish communicating with the backend when I visit the
> backend host from within the varnish virtual machine. Everything works
> as intended when I run a web client (curl or lynx) from the varnish vm
> terminal. The problem is varnish doesn't communicate with the backend
> when I visit the backend host from outside the vm on my host computer's
> web browser.
> 
> 
> The setup is is this - two virtual machines running in vagrant and
> virtualbox
> 
> 
> 192.168.33.26 (apache box with hostname clas-test.myhost.pvt listening
> on port 84)
> 
> 192.168.33.27 (clas-varnish.myhost.pvt)
> 
> 
> From default.vcl:
> 
> 
> vcl 4.0;
> import std;
> import directors;
> 
> include "backends.vcl";
> 
> sub vcl_init {
> 
>     new local_test = directors.round_robin();
>     local_test.add_backend(express_test);
> }
> sub vcl_recv {
> 
>   if (server.hostname == "clas-test.hostname.pvt") {
>     set req.backend_hint = local_test.backend();
>   }
> }
> sub vcl_deliver {
>   if (obj.hits > 0) {
>     set resp.http.X-Cache = "HIT";
>     std.log("hitmiss:HIT");
>   } else {
>     set resp.http.X-Cache = "MISS";
>     std.log("hitmiss:MISS");
>   }
> }
> 
> From backends.vcl:
> 
> 
> backend express_test {
>   .host = "192.168.33.26"; #ip of my host in its own virtual machine
>   .port = "84"; #port I have set in the virtual host on my host's
> virtual machine
> }
> 
> In /etc/varnish/varnish.params I have the VARNISH_LISTEN_PORT set to
> port 80 and VARNISH_LISTEN_ADDRESS commented out. Note, that when I set
> the address to my backend ip, varnish won't start and I get this error:
> 
> bind(): Cannot assign requested address
> [19743]: Error: Failed to open (any) accept sockets.
> 
> And yet when I run "varnishadm backend.list" with the listen address
> commented out, the backend is reported as healthy.
> 
> Thanks again, all
> 
> 
> 
> ------------------------------------------------------------------------
> *From:* varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org
> <varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org> on
> behalf of Andreas Plesner <apj at mutt.dk>
> *Sent:* Friday, January 20, 2017 2:59:10 AM
> *To:* varnish-misc at varnish-cache.org
> *Subject:* Re: Varnish on stand-alone server
>  
> On Thu, Jan 19, 2017 at 06:23:56PM +0000, Stalker, Tim wrote:
>> Varnish is aware of the backend I have set and works fine as long as I'm
>> logged into its virtual machine and run either curl or lynx to the address of
>> the machine with apache running. I have my /etc/hosts file set with the
>> backend address and virtual host as configured in the apache box, but it
>> seems that varnish ignores the /etc/hosts file. I get logging and see the
>> headers when I run curl -I
>> http://backend.vhost.name<http://backend.vhost.name/> but when I do the same
>> thing via the browser, curl, or lynx on my host computer, no logging, nothing
>> happens inside the varnish vm.
> 
> You're not giving us any info that actually enables us to help you. What
> doesn't work? What error messages do you get? What did you already try? What
> were the results of these attempts? What is in the log?
> 
> Most important is:
> 
> What doesn't work? You've only stated that it doesn't work, not what is
> actually happening when you've determined that it doesn't work.
> 
> -- 
> Andreas
> 
> _______________________________________________
> 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
> 




From Tim.Stalker at ucdenver.edu  Sat Jan 21 18:04:48 2017
From: Tim.Stalker at ucdenver.edu (Stalker, Tim)
Date: Sat, 21 Jan 2017 18:04:48 +0000
Subject: Varnish on stand-alone server
In-Reply-To: <a74366bf-80c8-58c0-84f5-c4a8f04241f9@yahoo.es>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
 <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <20170120095910.GG22017@nerd.dk>
 <CO2PR05MB7468EEA864B38B1A2D8793590710@CO2PR05MB746.namprd05.prod.outlook.com>,
 <a74366bf-80c8-58c0-84f5-c4a8f04241f9@yahoo.es>
Message-ID: <CO2PR05MB746B5FC971E1736F83D83FD90700@CO2PR05MB746.namprd05.prod.outlook.com>

Yes, when I point the backend host to the ip of the varnish virtual machine in my host computer's /etc/hosts file, I get this response in the varnish log on the varnish vm:


*   << BeReq    >> 17
-   Begin          bereq 16 fetch
-   Timestamp      Start: 1485021291.247201 0.000000 0.000000
-   BereqMethod    GET
-   BereqURL       /
-   BereqProtocol  HTTP/1.1
-   BereqHeader    Host: clas-test.myvhost.pvt
-   BereqHeader    Upgrade-Insecure-Requests: 1
-   BereqHeader    User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
-   BereqHeader    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
-   BereqHeader    Accept-Language: en-US,en;q=0.8
-   BereqHeader    X-Forwarded-For: 192.168.33.1
-   BereqHeader    Accept-Encoding: gzip
-   BereqHeader    X-Varnish: 17
-   VCL_call       BACKEND_FETCH
-   VCL_return     fetch
-   FetchError     no backend connection
-   Timestamp      Beresp: 1485021291.247212 0.000011 0.000011
-   Timestamp      Error: 1485021291.247215 0.000013 0.000002
-   BerespProtocol HTTP/1.1
-   BerespStatus   503
-   BerespReason   Service Unavailable
-   BerespReason   Backend fetch failed
-   BerespHeader   Date: Sat, 21 Jan 2017 17:54:51 GMT
-   BerespHeader   Server: Varnish
-   VCL_call       BACKEND_ERROR
-   BerespHeader   Content-Type: text/html; charset=utf-8
-   VCL_return     deliver
-   Storage        malloc Transient
-   ObjProtocol    HTTP/1.1
-   ObjStatus      503
-   ObjReason      Backend fetch failed
-   ObjHeader      Date: Sat, 21 Jan 2017 17:54:51 GMT
-   ObjHeader      Server: Varnish
-   ObjHeader      Content-Type: text/html; charset=utf-8
-   Length         27910
-   BereqAcct      0 0 0 0 0 0
-   End


*   << Session  >> 163842
-   Begin          sess 0 HTTP/1
-   SessOpen       192.168.33.1 40398 :80 192.168.33.27 80 1485021291.241650 16
-   SessClose      RX_TIMEOUT 5.094
-   End

*   << Session  >> 131074
-   Begin          sess 0 HTTP/1
-   SessOpen       192.168.33.1 40400 :80 192.168.33.27 80 1485021291.241657 17
-   SessClose      RX_TIMEOUT 5.094
-   End

*   << Session  >> 15
-   Begin          sess 0 HTTP/1
-   SessOpen       192.168.33.1 40396 :80 192.168.33.27 80 1485021291.241622 14
-   Link           req 16 rxreq
-   Link           req 18 rxreq
-   SessClose      RX_TIMEOUT 5.395
-   End


Any ideas? I can only think that it's a networking issue because the same setup I have, same default.vcl, backends.vcl files, with apache installed on the same VM as varnish, works fine. The backend host when separate from varnish in its own VM also works fine. But varnish cannot connect to it.

________________________________
From: Miguel Gonz?lez <miguel_3_gonzalez at yahoo.es>
Sent: Friday, January 20, 2017 3:18:51 PM
To: Stalker, Tim; Andreas Plesner; varnish-misc at varnish-cache.org
Subject: Re: Varnish on stand-alone server

What about the acl purge entries?

You probably know that you have to add in your hosts file where you are
running your browser you have to point the domain you are hitting with
the ip address of your varnish VM, don?t you?

Miguel




On 01/20/17 5:38 PM, Stalker, Tim wrote:
> I can't provide much detail because I don't get any reports or data from
> varnishlog. No errors are reported. When I run "varnishadm
> backend.list", the backend is reported as healthy. Plus, there's no
> issues with varnish communicating with the backend when I visit the
> backend host from within the varnish virtual machine. Everything works
> as intended when I run a web client (curl or lynx) from the varnish vm
> terminal. The problem is varnish doesn't communicate with the backend
> when I visit the backend host from outside the vm on my host computer's
> web browser.
>
>
> The setup is is this - two virtual machines running in vagrant and
> virtualbox
>
>
> 192.168.33.26 (apache box with hostname clas-test.myhost.pvt listening
> on port 84)
>
> 192.168.33.27 (clas-varnish.myhost.pvt)
>
>
> From default.vcl:
>
>
> vcl 4.0;
> import std;
> import directors;
>
> include "backends.vcl";
>
> sub vcl_init {
>
>     new local_test = directors.round_robin();
>     local_test.add_backend(express_test);
> }
> sub vcl_recv {
>
>   if (server.hostname == "clas-test.hostname.pvt") {
>     set req.backend_hint = local_test.backend();
>   }
> }
> sub vcl_deliver {
>   if (obj.hits > 0) {
>     set resp.http.X-Cache = "HIT";
>     std.log("hitmiss:HIT");
>   } else {
>     set resp.http.X-Cache = "MISS";
>     std.log("hitmiss:MISS");
>   }
> }
>
> From backends.vcl:
>
>
> backend express_test {
>   .host = "192.168.33.26"; #ip of my host in its own virtual machine
>   .port = "84"; #port I have set in the virtual host on my host's
> virtual machine
> }
>
> In /etc/varnish/varnish.params I have the VARNISH_LISTEN_PORT set to
> port 80 and VARNISH_LISTEN_ADDRESS commented out. Note, that when I set
> the address to my backend ip, varnish won't start and I get this error:
>
> bind(): Cannot assign requested address
> [19743]: Error: Failed to open (any) accept sockets.
>
> And yet when I run "varnishadm backend.list" with the listen address
> commented out, the backend is reported as healthy.
>
> Thanks again, all
>
>
>
> ------------------------------------------------------------------------
> *From:* varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org
> <varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org> on
> behalf of Andreas Plesner <apj at mutt.dk>
> *Sent:* Friday, January 20, 2017 2:59:10 AM
> *To:* varnish-misc at varnish-cache.org
> *Subject:* Re: Varnish on stand-alone server
>
> On Thu, Jan 19, 2017 at 06:23:56PM +0000, Stalker, Tim wrote:
>> Varnish is aware of the backend I have set and works fine as long as I'm
>> logged into its virtual machine and run either curl or lynx to the address of
>> the machine with apache running. I have my /etc/hosts file set with the
>> backend address and virtual host as configured in the apache box, but it
>> seems that varnish ignores the /etc/hosts file. I get logging and see the
>> headers when I run curl -I
>> http://backend.vhost.name<http://backend.vhost.name/> but when I do the same
>> thing via the browser, curl, or lynx on my host computer, no logging, nothing
>> happens inside the varnish vm.
>
> You're not giving us any info that actually enables us to help you. What
> doesn't work? What error messages do you get? What did you already try? What
> were the results of these attempts? What is in the log?
>
> Most important is:
>
> What doesn't work? You've only stated that it doesn't work, not what is
> actually happening when you've determined that it doesn't work.
>
> --
> Andreas
>
> _______________________________________________
> 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170121/9b4670b1/attachment.html>

From miguel_3_gonzalez at yahoo.es  Sun Jan 22 10:59:21 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Sun, 22 Jan 2017 11:59:21 +0100
Subject: Varnish on stand-alone server
In-Reply-To: <CO2PR05MB746B5FC971E1736F83D83FD90700@CO2PR05MB746.namprd05.prod.outlook.com>
References: <CO2PR05MB746F3FF2EE3F9DD67370868907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <cd1c0f05-9155-04f4-cd20-30a1bce082cd@yahoo.es>
 <CO2PR05MB7460BE8C5D5212AC6D45EDE907E0@CO2PR05MB746.namprd05.prod.outlook.com>
 <20170120095910.GG22017@nerd.dk>
 <CO2PR05MB7468EEA864B38B1A2D8793590710@CO2PR05MB746.namprd05.prod.outlook.com>
 <a74366bf-80c8-58c0-84f5-c4a8f04241f9@yahoo.es>
 <CO2PR05MB746B5FC971E1736F83D83FD90700@CO2PR05MB746.namprd05.prod.outlook.com>
Message-ID: <435f951a-c71f-4826-6c60-2caaa678c77d@yahoo.es>

What about the acl purge list in the default.vcl file?


On 01/21/17 7:04 PM, Stalker, Tim wrote:
> Yes, when I point the backend host to the ip of the varnish virtual
> machine in my host computer's /etc/hosts file, I get this response in
> the varnish log on the varnish vm:
> 
> 
> *   << BeReq    >> 17        
> -   Begin          bereq 16 fetch
> -   Timestamp      Start: 1485021291.247201 0.000000 0.000000
> -   BereqMethod    GET
> -   BereqURL       /
> -   BereqProtocol  HTTP/1.1
> -   BereqHeader    Host: clas-test.myvhost.pvt
> -   BereqHeader    Upgrade-Insecure-Requests: 1
> -   BereqHeader    User-Agent: Mozilla/5.0 (X11; Linux x86_64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
> -   BereqHeader    Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> -   BereqHeader    Accept-Language: en-US,en;q=0.8
> -   BereqHeader    X-Forwarded-For: 192.168.33.1
> -   BereqHeader    Accept-Encoding: gzip
> -   BereqHeader    X-Varnish: 17
> -   VCL_call       BACKEND_FETCH
> -   VCL_return     fetch
> -   FetchError     no backend connection
> -   Timestamp      Beresp: 1485021291.247212 0.000011 0.000011
> -   Timestamp      Error: 1485021291.247215 0.000013 0.000002
> -   BerespProtocol HTTP/1.1
> -   BerespStatus   503
> -   BerespReason   Service Unavailable
> -   BerespReason   Backend fetch failed
> -   BerespHeader   Date: Sat, 21 Jan 2017 17:54:51 GMT
> -   BerespHeader   Server: Varnish
> -   VCL_call       BACKEND_ERROR
> -   BerespHeader   Content-Type: text/html; charset=utf-8
> -   VCL_return     deliver
> -   Storage        malloc Transient
> -   ObjProtocol    HTTP/1.1
> -   ObjStatus      503
> -   ObjReason      Backend fetch failed
> -   ObjHeader      Date: Sat, 21 Jan 2017 17:54:51 GMT
> -   ObjHeader      Server: Varnish
> -   ObjHeader      Content-Type: text/html; charset=utf-8
> -   Length         27910
> -   BereqAcct      0 0 0 0 0 0
> -   End            
> 
> 
> *   << Session  >> 163842    
> -   Begin          sess 0 HTTP/1
> -   SessOpen       192.168.33.1 40398 :80 192.168.33.27 80
> 1485021291.241650 16
> -   SessClose      RX_TIMEOUT 5.094
> -   End            
> 
> *   << Session  >> 131074    
> -   Begin          sess 0 HTTP/1
> -   SessOpen       192.168.33.1 40400 :80 192.168.33.27 80
> 1485021291.241657 17
> -   SessClose      RX_TIMEOUT 5.094
> -   End            
> 
> *   << Session  >> 15        
> -   Begin          sess 0 HTTP/1
> -   SessOpen       192.168.33.1 40396 :80 192.168.33.27 80
> 1485021291.241622 14
> -   Link           req 16 rxreq
> -   Link           req 18 rxreq
> -   SessClose      RX_TIMEOUT 5.395
> -   End          
> 
> 
> Any ideas? I can only think that it's a networking issue because the
> same setup I have, same default.vcl, backends.vcl files, with apache
> installed on the same VM as varnish, works fine. The backend host when
> separate from varnish in its own VM also works fine. But varnish cannot
> connect to it.
> 
> ------------------------------------------------------------------------
> *From:* Miguel Gonz?lez <miguel_3_gonzalez at yahoo.es>
> *Sent:* Friday, January 20, 2017 3:18:51 PM
> *To:* Stalker, Tim; Andreas Plesner; varnish-misc at varnish-cache.org
> *Subject:* Re: Varnish on stand-alone server
>  
> What about the acl purge entries?
> 
> You probably know that you have to add in your hosts file where you are
> running your browser you have to point the domain you are hitting with
> the ip address of your varnish VM, don?t you?
> 
> Miguel
> 
> 
> 
> 
> On 01/20/17 5:38 PM, Stalker, Tim wrote:
>> I can't provide much detail because I don't get any reports or data from
>> varnishlog. No errors are reported. When I run "varnishadm
>> backend.list", the backend is reported as healthy. Plus, there's no
>> issues with varnish communicating with the backend when I visit the
>> backend host from within the varnish virtual machine. Everything works
>> as intended when I run a web client (curl or lynx) from the varnish vm
>> terminal. The problem is varnish doesn't communicate with the backend
>> when I visit the backend host from outside the vm on my host computer's
>> web browser.
>> 
>> 
>> The setup is is this - two virtual machines running in vagrant and
>> virtualbox
>> 
>> 
>> 192.168.33.26 (apache box with hostname clas-test.myhost.pvt listening
>> on port 84)
>> 
>> 192.168.33.27 (clas-varnish.myhost.pvt)
>> 
>> 
>> From default.vcl:
>> 
>> 
>> vcl 4.0;
>> import std;
>> import directors;
>> 
>> include "backends.vcl";
>> 
>> sub vcl_init {
>> 
>>     new local_test = directors.round_robin();
>>     local_test.add_backend(express_test);
>> }
>> sub vcl_recv {
>> 
>>   if (server.hostname == "clas-test.hostname.pvt") {
>>     set req.backend_hint = local_test.backend();
>>   }
>> }
>> sub vcl_deliver {
>>   if (obj.hits > 0) {
>>     set resp.http.X-Cache = "HIT";
>>     std.log("hitmiss:HIT");
>>   } else {
>>     set resp.http.X-Cache = "MISS";
>>     std.log("hitmiss:MISS");
>>   }
>> }
>> 
>> From backends.vcl:
>> 
>> 
>> backend express_test {
>>   .host = "192.168.33.26"; #ip of my host in its own virtual machine
>>   .port = "84"; #port I have set in the virtual host on my host's
>> virtual machine
>> }
>> 
>> In /etc/varnish/varnish.params I have the VARNISH_LISTEN_PORT set to
>> port 80 and VARNISH_LISTEN_ADDRESS commented out. Note, that when I set
>> the address to my backend ip, varnish won't start and I get this error:
>> 
>> bind(): Cannot assign requested address
>> [19743]: Error: Failed to open (any) accept sockets.
>> 
>> And yet when I run "varnishadm backend.list" with the listen address
>> commented out, the backend is reported as healthy.
>> 
>> Thanks again, all
>> 
>> 
>> 
>> ------------------------------------------------------------------------
>> *From:* varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org
>> <varnish-misc-bounces+tim.stalker=ucdenver.edu at varnish-cache.org> on
>> behalf of Andreas Plesner <apj at mutt.dk>
>> *Sent:* Friday, January 20, 2017 2:59:10 AM
>> *To:* varnish-misc at varnish-cache.org
>> *Subject:* Re: Varnish on stand-alone server
>>  
>> On Thu, Jan 19, 2017 at 06:23:56PM +0000, Stalker, Tim wrote:
>>> Varnish is aware of the backend I have set and works fine as long as I'm
>>> logged into its virtual machine and run either curl or lynx to the address of
>>> the machine with apache running. I have my /etc/hosts file set with the
>>> backend address and virtual host as configured in the apache box, but it
>>> seems that varnish ignores the /etc/hosts file. I get logging and see the
>>> headers when I run curl -I
>>> http://backend.vhost.name<http://backend.vhost.name/> but when I do the same
>>> thing via the browser, curl, or lynx on my host computer, no logging, nothing
>>> happens inside the varnish vm.
>> 
>> You're not giving us any info that actually enables us to help you. What
>> doesn't work? What error messages do you get? What did you already try? What
>> were the results of these attempts? What is in the log?
>> 
>> Most important is:
>> 
>> What doesn't work? You've only stated that it doesn't work, not what is
>> actually happening when you've determined that it doesn't work.
>> 
>> -- 
>> Andreas
>> 
>> _______________________________________________
>> 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
>> 
> 




From jprins at betterbe.com  Mon Jan 23 12:56:52 2017
From: jprins at betterbe.com (Jan Hugo Prins | BetterBe)
Date: Mon, 23 Jan 2017 13:56:52 +0100
Subject: Support for If-None-Match header.
Message-ID: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>

Hello,

We are currently investigating the use of Varnish for our
infrastructure. In the software we build, we depend on the If-None-Match
header and the use of ETAG's.
The API we have created creates mainly JSON objects, and they differ in
size from a few hundreds of bytes to several megabytes. A lot of these
JSON objects are perfectly suited for caching, until someone changes a
parameter and this can happen at any moment. That is also why we keep a
record of all ETAG's and we invalidate them when needed.

What we would like to do is cache created JSON object in front of our
production environment and when someone requests the same calculation
that someone else has requested before and the ETAG is still valid, send
out the cached object. But this basicly implies the following workflow:



Somewhere I found an old Trac Wiki document that describes something
like this, but I can't figure out if this has been implemented or not.
https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8

Could someone tell me if the workflow I describe is possible? My first
tests tell me that in the default setup it isn't working like this.

Best regards,
Jan Hugo Prins


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/87c83915/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cjpfoeckcepgfhfg.png
Type: image/png
Size: 112886 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/87c83915/attachment.png>

From geoff at uplex.de  Mon Jan 23 13:20:57 2017
From: geoff at uplex.de (Geoff Simmons)
Date: Mon, 23 Jan 2017 14:20:57 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
Message-ID: <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>

On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
> 
> Somewhere I found an old Trac Wiki document that describes
> something like this, but I can't figure out if this has been
> implemented or not. 
> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8

That
> 
Wiki page is obsolete -- it was about an experimental branch that
was developed while Varnish 3 was the released version.

(Maybe we should delete the Wiki page, it's not the first time someone
has been led astray.)

Varnish has supported 304 responses to client requests with
If-Modified-Since/If-None-Match for as long as I've known about it
(going back to Varnish 2). Backend conditional requests have been
supported since Varnish 4.

However, by default that doesn't quite work as your flow chart
indicates, if I've understood it correctly. If the client request is
for a cached response with an unelapsed TTL, then Varnish delivers the
cached response unconditionally, without re-validating the response
with the backend. Conditional requests to backends are done for the
fetch after the TTL elapses.

That's the default, but I believe you can get your own VCL to
implement re-validation after cache hits. I haven't tried that myself
-- maybe someone reading the list has some working VCL they can share?


Best,
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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/5aa60d53/attachment.bin>

From guillaume at varnish-software.com  Mon Jan 23 13:47:36 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Mon, 23 Jan 2017 14:47:36 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
Message-ID: <CAJ6ZYQwAt51T1zVXQknej4HsKDzJV1KnCN+vJvRzZnKzwSKNZw@mail.gmail.com>

Hi,

Short answer is : no, unless you want some very involved set.

BUT, what you can do is: let varnish work its magic, and just ban objects
based on ETAG when they become invalid.

-- 
Guillaume Quintard

On Mon, Jan 23, 2017 at 1:56 PM, Jan Hugo Prins | BetterBe <
jprins at betterbe.com> wrote:

> Hello,
>
> We are currently investigating the use of Varnish for our infrastructure.
> In the software we build, we depend on the If-None-Match header and the use
> of ETAG's.
> The API we have created creates mainly JSON objects, and they differ in
> size from a few hundreds of bytes to several megabytes. A lot of these JSON
> objects are perfectly suited for caching, until someone changes a parameter
> and this can happen at any moment. That is also why we keep a record of all
> ETAG's and we invalidate them when needed.
>
> What we would like to do is cache created JSON object in front of our
> production environment and when someone requests the same calculation that
> someone else has requested before and the ETAG is still valid, send out the
> cached object. But this basicly implies the following workflow:
>
>
>
> Somewhere I found an old Trac Wiki document that describes something like
> this, but I can't figure out if this has been implemented or not.
> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?
> version=8
>
> Could someone tell me if the workflow I describe is possible? My first
> tests tell me that in the default setup it isn't working like this.
>
> Best regards,
> Jan Hugo Prins
>
>
>
> _______________________________________________
> 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/f9ef1135/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cjpfoeckcepgfhfg.png
Type: image/png
Size: 112886 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/f9ef1135/attachment.png>

From jprins at betterbe.com  Mon Jan 23 14:05:24 2017
From: jprins at betterbe.com (Jan Hugo Prins | BetterBe)
Date: Mon, 23 Jan 2017 15:05:24 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <CAJ6ZYQwAt51T1zVXQknej4HsKDzJV1KnCN+vJvRzZnKzwSKNZw@mail.gmail.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <CAJ6ZYQwAt51T1zVXQknej4HsKDzJV1KnCN+vJvRzZnKzwSKNZw@mail.gmail.com>
Message-ID: <c16cbbda-b206-18e9-6cbc-bdd6d0ede809@betterbe.com>

What do you mean by "unless you want some very involved set"?
And sure, Varnish can ban objects when they become invalid, but then it
still needs to check the origin to see if the object is still valid.

Jan Hugo


On 01/23/2017 02:47 PM, Guillaume Quintard wrote:
> Hi,
>
> Short answer is : no, unless you want some very involved set.
>
> BUT, what you can do is: let varnish work its magic, and just ban
> objects based on ETAG when they become invalid.
>
> -- 
> Guillaume Quintard
>
> On Mon, Jan 23, 2017 at 1:56 PM, Jan Hugo Prins | BetterBe
> <jprins at betterbe.com <mailto:jprins at betterbe.com>> wrote:
>
>     Hello,
>
>     We are currently investigating the use of Varnish for our
>     infrastructure. In the software we build, we depend on the
>     If-None-Match header and the use of ETAG's.
>     The API we have created creates mainly JSON objects, and they
>     differ in size from a few hundreds of bytes to several megabytes.
>     A lot of these JSON objects are perfectly suited for caching,
>     until someone changes a parameter and this can happen at any
>     moment. That is also why we keep a record of all ETAG's and we
>     invalidate them when needed.
>
>     What we would like to do is cache created JSON object in front of
>     our production environment and when someone requests the same
>     calculation that someone else has requested before and the ETAG is
>     still valid, send out the cached object. But this basicly implies
>     the following workflow:
>
>
>
>     Somewhere I found an old Trac Wiki document that describes
>     something like this, but I can't figure out if this has been
>     implemented or not.
>     https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>     <https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8>
>
>     Could someone tell me if the workflow I describe is possible? My
>     first tests tell me that in the default setup it isn't working
>     like this.
>
>     Best regards,
>     Jan Hugo Prins
>
>
>
>     _______________________________________________
>     varnish-misc mailing list
>     varnish-misc at varnish-cache.org <mailto:varnish-misc at varnish-cache.org>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>
>

-- 

Met vriendelijke groet / Best regards,

Jan Hugo Prins
/Infra and Storage consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E 	*T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede 	*E* jprins at betterbe.com <mailto:jprins at betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/37af19e8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 112886 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/37af19e8/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/37af19e8/attachment-0001.png>

From guillaume at varnish-software.com  Mon Jan 23 14:22:38 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Mon, 23 Jan 2017 15:22:38 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <c16cbbda-b206-18e9-6cbc-bdd6d0ede809@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <CAJ6ZYQwAt51T1zVXQknej4HsKDzJV1KnCN+vJvRzZnKzwSKNZw@mail.gmail.com>
 <c16cbbda-b206-18e9-6cbc-bdd6d0ede809@betterbe.com>
Message-ID: <CAJ6ZYQwE+Ypy9ZSC-kHW1ZjRpw7mNwzWuBz6GVC8L-oqUEpo5w@mail.gmail.com>

*set up, sorry, fat fingers. I haven't studied the question in depth, but
i'm pretty sure you can bend varnish's arm and do what you ask, but that's
complicated.

Regarding your second question, Varnish doesn't need to check the origin if
the origin pushes the bans directly.

-- 
Guillaume Quintard

On Mon, Jan 23, 2017 at 3:05 PM, Jan Hugo Prins | BetterBe <
jprins at betterbe.com> wrote:

> What do you mean by "unless you want some very involved set"?
> And sure, Varnish can ban objects when they become invalid, but then it
> still needs to check the origin to see if the object is still valid.
>
> Jan Hugo
>
>
>
> On 01/23/2017 02:47 PM, Guillaume Quintard wrote:
>
> Hi,
>
> Short answer is : no, unless you want some very involved set.
>
> BUT, what you can do is: let varnish work its magic, and just ban objects
> based on ETAG when they become invalid.
>
> --
> Guillaume Quintard
>
> On Mon, Jan 23, 2017 at 1:56 PM, Jan Hugo Prins | BetterBe <
> jprins at betterbe.com> wrote:
>
>> Hello,
>>
>> We are currently investigating the use of Varnish for our infrastructure.
>> In the software we build, we depend on the If-None-Match header and the use
>> of ETAG's.
>> The API we have created creates mainly JSON objects, and they differ in
>> size from a few hundreds of bytes to several megabytes. A lot of these JSON
>> objects are perfectly suited for caching, until someone changes a parameter
>> and this can happen at any moment. That is also why we keep a record of all
>> ETAG's and we invalidate them when needed.
>>
>> What we would like to do is cache created JSON object in front of our
>> production environment and when someone requests the same calculation that
>> someone else has requested before and the ETAG is still valid, send out the
>> cached object. But this basicly implies the following workflow:
>>
>>
>>
>> Somewhere I found an old Trac Wiki document that describes something like
>> this, but I can't figure out if this has been implemented or not.
>> https://www.varnish-cache.org/trac/wiki/BackendConditionalRe
>> quests?version=8
>>
>> Could someone tell me if the workflow I describe is possible? My first
>> tests tell me that in the default setup it isn't working like this.
>>
>> Best regards,
>> Jan Hugo Prins
>>
>>
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>
>
> --
>
> Met vriendelijke groet / Best regards,
>
> Jan Hugo Prins
> *Infra and Storage consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins at betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/4ce60032/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/4ce60032/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 112886 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/4ce60032/attachment-0001.png>

From cservin-varnish at cromagnon.com  Mon Jan 23 15:02:00 2017
From: cservin-varnish at cromagnon.com (Craig Servin)
Date: Mon, 23 Jan 2017 09:02:00 -0600
Subject: Support for If-None-Match header.
In-Reply-To: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
Message-ID: <dba47ad870a585c22150f1d6bdda113e@www.cromagnon.com>

Hi Jan,

You might want to consider using the libvmod-xkey and then having 
backend changes just tell varnish to invalidate based on that secondary 
key.

Cheers,

Craig



On 2017-01-23 06:56, Jan Hugo Prins | BetterBe wrote:
> Hello,
> 
> We are currently investigating the use of Varnish for our
> infrastructure. In the software we build, we depend on the
> If-None-Match header and the use of ETAG's.
> The API we have created creates mainly JSON objects, and they differ
> in size from a few hundreds of bytes to several megabytes. A lot of
> these JSON objects are perfectly suited for caching, until someone
> changes a parameter and this can happen at any moment. That is also
> why we keep a record of all ETAG's and we invalidate them when needed.
> 
> 
> What we would like to do is cache created JSON object in front of our
> production environment and when someone requests the same calculation
> that someone else has requested before and the ETAG is still valid,
> send out the cached object. But this basicly implies the following
> workflow:




From reza at varnish-software.com  Mon Jan 23 17:28:36 2017
From: reza at varnish-software.com (Reza Naghibi)
Date: Mon, 23 Jan 2017 12:28:36 -0500
Subject: Support for If-None-Match header.
In-Reply-To: <dba47ad870a585c22150f1d6bdda113e@www.cromagnon.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <dba47ad870a585c22150f1d6bdda113e@www.cromagnon.com>
Message-ID: <CAAARNrFh39QAeXARgtJgH7q=MWtsWOtRADEad_3G5_u6nsrizA@mail.gmail.com>

You could vary on the Etag which will keep multiple Etag versions in cache
while allowing for 304 responses on each one:

---

vcl 4.0;

backend default
{
  .host = "127.0.0.1";
  .port = "80";
}

sub vcl_recv
{
  if (req.http.If-None-Match) {
    set req.http.ETag = req.http.If-None-Match;
  }
}

sub vcl_backend_response
{
  set beresp.http.Vary = "ETag";
}

---

I may have misunderstood the question, but your backend would have to
return the correct response matching upto the Etag.

--
Reza Naghibi
Varnish Software

On Mon, Jan 23, 2017 at 10:02 AM, Craig Servin <
cservin-varnish at cromagnon.com> wrote:

> Hi Jan,
>
> You might want to consider using the libvmod-xkey and then having backend
> changes just tell varnish to invalidate based on that secondary key.
>
> Cheers,
>
> Craig
>
>
>
> On 2017-01-23 06:56, Jan Hugo Prins | BetterBe wrote:
>
>> Hello,
>>
>> We are currently investigating the use of Varnish for our
>> infrastructure. In the software we build, we depend on the
>> If-None-Match header and the use of ETAG's.
>> The API we have created creates mainly JSON objects, and they differ
>> in size from a few hundreds of bytes to several megabytes. A lot of
>> these JSON objects are perfectly suited for caching, until someone
>> changes a parameter and this can happen at any moment. That is also
>> why we keep a record of all ETAG's and we invalidate them when needed.
>>
>>
>> What we would like to do is cache created JSON object in front of our
>> production environment and when someone requests the same calculation
>> that someone else has requested before and the ETAG is still valid,
>> send out the cached object. But this basicly implies the following
>> workflow:
>>
>
>
> _______________________________________________
> 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/e8053c2d/attachment.html>

From reza at varnish-software.com  Mon Jan 23 19:42:07 2017
From: reza at varnish-software.com (Reza Naghibi)
Date: Mon, 23 Jan 2017 14:42:07 -0500
Subject: Support for If-None-Match header.
In-Reply-To: <CAAARNrFh39QAeXARgtJgH7q=MWtsWOtRADEad_3G5_u6nsrizA@mail.gmail.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <dba47ad870a585c22150f1d6bdda113e@www.cromagnon.com>
 <CAAARNrFh39QAeXARgtJgH7q=MWtsWOtRADEad_3G5_u6nsrizA@mail.gmail.com>
Message-ID: <CAAARNrHtUqg99RsXDrE9guqh=jZSvPXhhJaXi343MFZD02VF5w@mail.gmail.com>

Actually, the VCL can be simplified greatly (I was expecting to change the
Etag while writing that):

---

sub vcl_backend_response
{
  set beresp.http.Vary = "If-None-Match";
}

---

If there is a previous value of Vary, just append the If-None-Match.

--
Reza Naghibi
Varnish Software

On Mon, Jan 23, 2017 at 12:28 PM, Reza Naghibi <reza at varnish-software.com>
wrote:

> You could vary on the Etag which will keep multiple Etag versions in cache
> while allowing for 304 responses on each one:
>
> ---
>
> vcl 4.0;
>
> backend default
> {
>   .host = "127.0.0.1";
>   .port = "80";
> }
>
> sub vcl_recv
> {
>   if (req.http.If-None-Match) {
>     set req.http.ETag = req.http.If-None-Match;
>   }
> }
>
> sub vcl_backend_response
> {
>   set beresp.http.Vary = "ETag";
> }
>
> ---
>
> I may have misunderstood the question, but your backend would have to
> return the correct response matching upto the Etag.
>
> --
> Reza Naghibi
> Varnish Software
>
> On Mon, Jan 23, 2017 at 10:02 AM, Craig Servin <
> cservin-varnish at cromagnon.com> wrote:
>
>> Hi Jan,
>>
>> You might want to consider using the libvmod-xkey and then having backend
>> changes just tell varnish to invalidate based on that secondary key.
>>
>> Cheers,
>>
>> Craig
>>
>>
>>
>> On 2017-01-23 06:56, Jan Hugo Prins | BetterBe wrote:
>>
>>> Hello,
>>>
>>> We are currently investigating the use of Varnish for our
>>> infrastructure. In the software we build, we depend on the
>>> If-None-Match header and the use of ETAG's.
>>> The API we have created creates mainly JSON objects, and they differ
>>> in size from a few hundreds of bytes to several megabytes. A lot of
>>> these JSON objects are perfectly suited for caching, until someone
>>> changes a parameter and this can happen at any moment. That is also
>>> why we keep a record of all ETAG's and we invalidate them when needed.
>>>
>>>
>>> What we would like to do is cache created JSON object in front of our
>>> production environment and when someone requests the same calculation
>>> that someone else has requested before and the ETAG is still valid,
>>> send out the cached object. But this basicly implies the following
>>> workflow:
>>>
>>
>>
>> _______________________________________________
>> 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170123/332ba08f/attachment.html>

From jprins at betterbe.com  Tue Jan 24 01:49:41 2017
From: jprins at betterbe.com (Jan Hugo Prins | BetterBe)
Date: Tue, 24 Jan 2017 02:49:41 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
Message-ID: <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>

After reading this mail and doing a lot more searching in the
mailinglist and on the web, I think it is actually rather simple. At
least I think that I'm seeing the correct behaviour. I'm not sure
though, it could be that the response is first generated and that the
origin is only checked after the response has been send to the client.
What I have now in my vcl_backend_response is nothing more then:

sub vcl_backend_response {
    if (beresp.http.Cache-Control ~ "must-revalidate") {
        set beresp.ttl = 1s;
        set beresp.keep = 3600s;
        set beresp.grace = 3600s;
    }
    return (deliver);
}


Jan Hugo Prins



On 01/23/2017 02:20 PM, Geoff Simmons wrote:
> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>> Somewhere I found an old Trac Wiki document that describes
>> something like this, but I can't figure out if this has been
>> implemented or not. 
>> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
> That
> Wiki page is obsolete -- it was about an experimental branch that
> was developed while Varnish 3 was the released version.
>
> (Maybe we should delete the Wiki page, it's not the first time someone
> has been led astray.)
>
> Varnish has supported 304 responses to client requests with
> If-Modified-Since/If-None-Match for as long as I've known about it
> (going back to Varnish 2). Backend conditional requests have been
> supported since Varnish 4.
>
> However, by default that doesn't quite work as your flow chart
> indicates, if I've understood it correctly. If the client request is
> for a cached response with an unelapsed TTL, then Varnish delivers the
> cached response unconditionally, without re-validating the response
> with the backend. Conditional requests to backends are done for the
> fetch after the TTL elapses.
>
> That's the default, but I believe you can get your own VCL to
> implement re-validation after cache hits. I haven't tried that myself
> -- maybe someone reading the list has some working VCL they can share?
>
>
> Best,
> Geoff

-- 

Met vriendelijke groet / Best regards,

Jan Hugo Prins
/Infra and Storage consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E 	*T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede 	*E* jprins at betterbe.com <mailto:jprins at betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/3430c466/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/3430c466/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/3430c466/attachment.bin>

From guillaume at varnish-software.com  Tue Jan 24 09:17:14 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Tue, 24 Jan 2017 10:17:14 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
 <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>
Message-ID: <CAJ6ZYQxXWS45RGARvu8LwXwAM7J0zxsy44=bEbq=sXc730+qjQ@mail.gmail.com>

Hello,

Indeed, with this vcl code, the object is checked asynchronously. So, if
the check fails, the user that triggered the check will have received the
outdated object. It may or may not be an issue depending on your use case.

Note that you can reduce the TTL further.

On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins at betterbe.com>
wrote:

> After reading this mail and doing a lot more searching in the mailinglist
> and on the web, I think it is actually rather simple. At least I think that
> I'm seeing the correct behaviour. I'm not sure though, it could be that the
> response is first generated and that the origin is only checked after the
> response has been send to the client. What I have now in my
> vcl_backend_response is nothing more then:
>
> sub vcl_backend_response {
>     if (beresp.http.Cache-Control ~ "must-revalidate") {
>         set beresp.ttl = 1s;
>         set beresp.keep = 3600s;
>         set beresp.grace = 3600s;
>     }
>     return (deliver);
> }
>
>
> Jan Hugo Prins
>
>
>
> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>
> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>
>
> Somewhere I found an old Trac Wiki document that describes
> something like this, but I can't figure out if this has been
> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>
>
> That
>
>  Wiki page is obsolete -- it was about an experimental branch that
> was developed while Varnish 3 was the released version.
>
> (Maybe we should delete the Wiki page, it's not the first time someone
> has been led astray.)
>
> Varnish has supported 304 responses to client requests with
> If-Modified-Since/If-None-Match for as long as I've known about it
> (going back to Varnish 2). Backend conditional requests have been
> supported since Varnish 4.
>
> However, by default that doesn't quite work as your flow chart
> indicates, if I've understood it correctly. If the client request is
> for a cached response with an unelapsed TTL, then Varnish delivers the
> cached response unconditionally, without re-validating the response
> with the backend. Conditional requests to backends are done for the
> fetch after the TTL elapses.
>
> That's the default, but I believe you can get your own VCL to
> implement re-validation after cache hits. I haven't tried that myself
> -- maybe someone reading the list has some working VCL they can share?
>
>
> Best,
> Geoff
>
>
> --
>
> Met vriendelijke groet / Best regards,
>
> Jan Hugo Prins
> *Infra and Storage consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins at betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>
> _______________________________________________
> 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/f5c47809/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/f5c47809/attachment.png>

From jprins at betterbe.com  Tue Jan 24 10:19:33 2017
From: jprins at betterbe.com (Jan Hugo Prins | BetterBe)
Date: Tue, 24 Jan 2017 11:19:33 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <CAJ6ZYQxXWS45RGARvu8LwXwAM7J0zxsy44=bEbq=sXc730+qjQ@mail.gmail.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
 <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>
 <CAJ6ZYQxXWS45RGARvu8LwXwAM7J0zxsy44=bEbq=sXc730+qjQ@mail.gmail.com>
Message-ID: <11c121c6-b856-df11-6410-9cfa68cb82e9@betterbe.com>

Is it possible in any way to force the check before the result is send
to the client?

Jan Hugo


On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
> Hello,
>
> Indeed, with this vcl code, the object is checked asynchronously. So,
> if the check fails, the user that triggered the check will have
> received the outdated object. It may or may not be an issue depending
> on your use case.
>
> Note that you can reduce the TTL further.
>
> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe"
> <jprins at betterbe.com <mailto:jprins at betterbe.com>> wrote:
>
>     After reading this mail and doing a lot more searching in the
>     mailinglist and on the web, I think it is actually rather simple.
>     At least I think that I'm seeing the correct behaviour. I'm not
>     sure though, it could be that the response is first generated and
>     that the origin is only checked after the response has been send
>     to the client. What I have now in my vcl_backend_response is
>     nothing more then:
>
>     sub vcl_backend_response {
>         if (beresp.http.Cache-Control ~ "must-revalidate") {
>             set beresp.ttl = 1s;
>             set beresp.keep = 3600s;
>             set beresp.grace = 3600s;
>         }
>         return (deliver);
>     }
>
>
>     Jan Hugo Prins
>
>
>
>     On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>     On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>>     Somewhere I found an old Trac Wiki document that describes
>>>     something like this, but I can't figure out if this has been
>>>     implemented or not. 
>>>     https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>>     <https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8>
>>     That
>>     Wiki page is obsolete -- it was about an experimental branch that
>>     was developed while Varnish 3 was the released version.
>>
>>     (Maybe we should delete the Wiki page, it's not the first time someone
>>     has been led astray.)
>>
>>     Varnish has supported 304 responses to client requests with
>>     If-Modified-Since/If-None-Match for as long as I've known about it
>>     (going back to Varnish 2). Backend conditional requests have been
>>     supported since Varnish 4.
>>
>>     However, by default that doesn't quite work as your flow chart
>>     indicates, if I've understood it correctly. If the client request is
>>     for a cached response with an unelapsed TTL, then Varnish delivers the
>>     cached response unconditionally, without re-validating the response
>>     with the backend. Conditional requests to backends are done for the
>>     fetch after the TTL elapses.
>>
>>     That's the default, but I believe you can get your own VCL to
>>     implement re-validation after cache hits. I haven't tried that myself
>>     -- maybe someone reading the list has some working VCL they can share?
>>
>>
>>     Best,
>>     Geoff
>     -- 
>
>     Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and
>     Storage consultant/
>
>     BetterBe - Transforming automotive leasing worldwide
>     <https://www.betterbe.com>
>     Auke Vleerstraat 140 E 	*T* +31 (0) 53 48 00 694
>     <tel:+31%20%280%29%2053%2048%2000%20694>
>     7547 AN Enschede 	*E* jprins at betterbe.com
>     <mailto:jprins at betterbe.com>
>     CC no. 08097527
>     <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>     	*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
>     www.betterbe.com <https://www.betterbe.com>
>     BetterBe accepts no liability for the content of this email, or
>     for the consequences of any actions taken on the basis of the
>     information provided, unless that information is subsequently
>     confirmed in writing. If you are not the intended recipient you
>     are notified that disclosing, copying, distributing or taking any
>     action in reliance on the contents of this information is strictly
>     prohibited.
>
>     _______________________________________________ varnish-misc
>     mailing list varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc> 
>
-- 

Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and Storage
consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E 	*T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede 	*E* jprins at betterbe.com <mailto:jprins at betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/f5816242/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/f5816242/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/f5816242/attachment-0001.png>

From guillaume at varnish-software.com  Tue Jan 24 10:35:09 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Tue, 24 Jan 2017 11:35:09 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <11c121c6-b856-df11-6410-9cfa68cb82e9@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
 <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>
 <CAJ6ZYQxXWS45RGARvu8LwXwAM7J0zxsy44=bEbq=sXc730+qjQ@mail.gmail.com>
 <11c121c6-b856-df11-6410-9cfa68cb82e9@betterbe.com>
Message-ID: <CAJ6ZYQy=uOs4+=D4kfCOTkS629r5+FoB6kNapAzhEwNSR4-nbQ@mail.gmail.com>

Yes, you can:
- look for a match, and if you find one, note the etag, then restart. If no
match is found, fetch and deliver
- pass to the backend, if the etag doesn't match what you noted, ban the
object. Note the new etag, restart again
- if the new etag matches the one sent by the client, synthesize a 304,
otherwise deliver

But, is that really worth it? And is it easier than asking the backend to
purge?


-- 
Guillaume Quintard

On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe <
jprins at betterbe.com> wrote:

> Is it possible in any way to force the check before the result is send to
> the client?
>
> Jan Hugo
>
>
>
> On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>
> Hello,
>
> Indeed, with this vcl code, the object is checked asynchronously. So, if
> the check fails, the user that triggered the check will have received the
> outdated object. It may or may not be an issue depending on your use case.
>
> Note that you can reduce the TTL further.
>
> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins at betterbe.com>
> wrote:
>
>> After reading this mail and doing a lot more searching in the mailinglist
>> and on the web, I think it is actually rather simple. At least I think that
>> I'm seeing the correct behaviour. I'm not sure though, it could be that the
>> response is first generated and that the origin is only checked after the
>> response has been send to the client. What I have now in my
>> vcl_backend_response is nothing more then:
>>
>> sub vcl_backend_response {
>>     if (beresp.http.Cache-Control ~ "must-revalidate") {
>>         set beresp.ttl = 1s;
>>         set beresp.keep = 3600s;
>>         set beresp.grace = 3600s;
>>     }
>>     return (deliver);
>> }
>>
>>
>> Jan Hugo Prins
>>
>>
>>
>> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>
>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>
>> Somewhere I found an old Trac Wiki document that describes
>> something like this, but I can't figure out if this has been
>> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>
>> That
>>
>> Wiki page is obsolete -- it was about an experimental branch that
>> was developed while Varnish 3 was the released version.
>>
>> (Maybe we should delete the Wiki page, it's not the first time someone
>> has been led astray.)
>>
>> Varnish has supported 304 responses to client requests with
>> If-Modified-Since/If-None-Match for as long as I've known about it
>> (going back to Varnish 2). Backend conditional requests have been
>> supported since Varnish 4.
>>
>> However, by default that doesn't quite work as your flow chart
>> indicates, if I've understood it correctly. If the client request is
>> for a cached response with an unelapsed TTL, then Varnish delivers the
>> cached response unconditionally, without re-validating the response
>> with the backend. Conditional requests to backends are done for the
>> fetch after the TTL elapses.
>>
>> That's the default, but I believe you can get your own VCL to
>> implement re-validation after cache hits. I haven't tried that myself
>> -- maybe someone reading the list has some working VCL they can share?
>>
>>
>> Best,
>> Geoff
>>
>> --
>>
>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
>> consultant*
>> [image: BetterBe - Transforming automotive leasing worldwide]
>> <https://www.betterbe.com>
>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>> <+31%20%280%29%2053%2048%2000%20694>
>> 7547 AN Enschede *E* jprins at betterbe.com
>> CC no. 08097527
>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>> www.betterbe.com
>> BetterBe accepts no liability for the content of this email, or for the
>> consequences of any actions taken on the basis of the information provided,
>> unless that information is subsequently confirmed in writing. If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited.
>> _______________________________________________ varnish-misc mailing
>> list varnish-misc at varnish-cache.org https://www.varnish-cache.org/
>> lists/mailman/listinfo/varnish-misc
>
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
> consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins at betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/27ab34fd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/27ab34fd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/27ab34fd/attachment-0001.png>

From jprins at betterbe.com  Tue Jan 24 11:31:00 2017
From: jprins at betterbe.com (Jan Hugo Prins | BetterBe)
Date: Tue, 24 Jan 2017 12:31:00 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <CAJ6ZYQy=uOs4+=D4kfCOTkS629r5+FoB6kNapAzhEwNSR4-nbQ@mail.gmail.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
 <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>
 <CAJ6ZYQxXWS45RGARvu8LwXwAM7J0zxsy44=bEbq=sXc730+qjQ@mail.gmail.com>
 <11c121c6-b856-df11-6410-9cfa68cb82e9@betterbe.com>
 <CAJ6ZYQy=uOs4+=D4kfCOTkS629r5+FoB6kNapAzhEwNSR4-nbQ@mail.gmail.com>
Message-ID: <109ba66d-041b-dfcf-2cbc-f4daaa9ba47b@betterbe.com>

The problem is that asking the backend to purge is not an option because
that would not scale. If we would want to do that we need to know at the
backend how many varnish nodes the cluster has and how to reach them all
to purge the object effectively. Scaling the landscape would very soon
become a big nightmare.

The solution you provide here sounds like something that is programmable
by someone familiar with VCL. VCL is completely new to me so I will
start creating a flow diagram to see if I can understand that way what
you wrote down. If you have any example code that would help me in the
right direction I would be very happy.

Best regards,
Jan Hugo Prins


On 01/24/2017 11:35 AM, Guillaume Quintard wrote:
> Yes, you can:
> - look for a match, and if you find one, note the etag, then restart.
> If no match is found, fetch and deliver
> - pass to the backend, if the etag doesn't match what you noted, ban
> the object. Note the new etag, restart again
> - if the new etag matches the one sent by the client, synthesize a
> 304, otherwise deliver
>
> But, is that really worth it? And is it easier than asking the backend
> to purge?
>
>
> -- 
> Guillaume Quintard
>
> On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe
> <jprins at betterbe.com <mailto:jprins at betterbe.com>> wrote:
>
>     Is it possible in any way to force the check before the result is
>     send to the client?
>
>     Jan Hugo
>
>
>
>     On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>>     Hello,
>>
>>     Indeed, with this vcl code, the object is checked asynchronously.
>>     So, if the check fails, the user that triggered the check will
>>     have received the outdated object. It may or may not be an issue
>>     depending on your use case.
>>
>>     Note that you can reduce the TTL further.
>>
>>     On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe"
>>     <jprins at betterbe.com <mailto:jprins at betterbe.com>> wrote:
>>
>>         After reading this mail and doing a lot more searching in the
>>         mailinglist and on the web, I think it is actually rather
>>         simple. At least I think that I'm seeing the correct
>>         behaviour. I'm not sure though, it could be that the response
>>         is first generated and that the origin is only checked after
>>         the response has been send to the client. What I have now in
>>         my vcl_backend_response is nothing more then:
>>
>>         sub vcl_backend_response {
>>             if (beresp.http.Cache-Control ~ "must-revalidate") {
>>                 set beresp.ttl = 1s;
>>                 set beresp.keep = 3600s;
>>                 set beresp.grace = 3600s;
>>             }
>>             return (deliver);
>>         }
>>
>>
>>         Jan Hugo Prins
>>
>>
>>
>>         On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>>         On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>>>         Somewhere I found an old Trac Wiki document that describes
>>>>         something like this, but I can't figure out if this has been
>>>>         implemented or not. 
>>>>         https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>>>         <https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8>
>>>         That
>>>         Wiki page is obsolete -- it was about an experimental branch that
>>>         was developed while Varnish 3 was the released version.
>>>
>>>         (Maybe we should delete the Wiki page, it's not the first time someone
>>>         has been led astray.)
>>>
>>>         Varnish has supported 304 responses to client requests with
>>>         If-Modified-Since/If-None-Match for as long as I've known about it
>>>         (going back to Varnish 2). Backend conditional requests have been
>>>         supported since Varnish 4.
>>>
>>>         However, by default that doesn't quite work as your flow chart
>>>         indicates, if I've understood it correctly. If the client request is
>>>         for a cached response with an unelapsed TTL, then Varnish delivers the
>>>         cached response unconditionally, without re-validating the response
>>>         with the backend. Conditional requests to backends are done for the
>>>         fetch after the TTL elapses.
>>>
>>>         That's the default, but I believe you can get your own VCL to
>>>         implement re-validation after cache hits. I haven't tried that myself
>>>         -- maybe someone reading the list has some working VCL they can share?
>>>
>>>
>>>         Best,
>>>         Geoff
>>         -- 
>>
>>         Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra
>>         and Storage consultant/
>>
>>         BetterBe - Transforming automotive leasing worldwide
>>         <https://www.betterbe.com>
>>         Auke Vleerstraat 140 E 	*T* +31 (0) 53 48 00 694
>>         <tel:+31%20%280%29%2053%2048%2000%20694>
>>         7547 AN Enschede 	*E* jprins at betterbe.com
>>         <mailto:jprins at betterbe.com>
>>         CC no. 08097527
>>         <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>>         	*M* +31 (0)6 26 358 951
>>         <tel:+31%20%280%296%2026%20358%20951> 	www.betterbe.com
>>         <https://www.betterbe.com>
>>         BetterBe accepts no liability for the content of this email,
>>         or for the consequences of any actions taken on the basis of
>>         the information provided, unless that information is
>>         subsequently confirmed in writing. If you are not the
>>         intended recipient you are notified that disclosing, copying,
>>         distributing or taking any action in reliance on the contents
>>         of this information is strictly prohibited.
>>
>>         _______________________________________________ varnish-misc
>>         mailing list varnish-misc at varnish-cache.org
>>         <mailto:varnish-misc at varnish-cache.org>
>>         https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>         <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>>
>>
>     -- 
>
>     Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and
>     Storage consultant/
>
>     BetterBe - Transforming automotive leasing worldwide
>     <https://www.betterbe.com>
>     Auke Vleerstraat 140 E 	*T* +31 (0) 53 48 00 694
>     <tel:+31%20%280%29%2053%2048%2000%20694>
>     7547 AN Enschede 	*E* jprins at betterbe.com
>     <mailto:jprins at betterbe.com>
>     CC no. 08097527
>     <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>     	*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
>     www.betterbe.com <https://www.betterbe.com>
>     BetterBe accepts no liability for the content of this email, or
>     for the consequences of any actions taken on the basis of the
>     information provided, unless that information is subsequently
>     confirmed in writing. If you are not the intended recipient you
>     are notified that disclosing, copying, distributing or taking any
>     action in reliance on the contents of this information is strictly
>     prohibited.
>
-- 

Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and Storage
consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E 	*T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede 	*E* jprins at betterbe.com <mailto:jprins at betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/10f8ccb0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/10f8ccb0/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/10f8ccb0/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/10f8ccb0/attachment-0002.png>

From guillaume at varnish-software.com  Tue Jan 24 11:52:47 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Tue, 24 Jan 2017 12:52:47 +0100
Subject: Support for If-None-Match header.
In-Reply-To: <109ba66d-041b-dfcf-2cbc-f4daaa9ba47b@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
 <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>
 <CAJ6ZYQxXWS45RGARvu8LwXwAM7J0zxsy44=bEbq=sXc730+qjQ@mail.gmail.com>
 <11c121c6-b856-df11-6410-9cfa68cb82e9@betterbe.com>
 <CAJ6ZYQy=uOs4+=D4kfCOTkS629r5+FoB6kNapAzhEwNSR4-nbQ@mail.gmail.com>
 <109ba66d-041b-dfcf-2cbc-f4daaa9ba47b@betterbe.com>
Message-ID: <CAJ6ZYQw0uTYQB+6mRDYwH2YwHHDko_Pam44Chc+qffvWwiOtBQ@mail.gmail.com>

Sadly, I don't have time to work on this at the moment, I recommend you
have a look at the wiki
https://www.varnish-software.com/wiki/start/index.html and at the
documentation https://www.varnish-cache.org/docs/trunk/.

You have to understand that with this logic, when an object changes, you
still have to send a first, extra request to check its freshness.

-- 
Guillaume Quintard

On Tue, Jan 24, 2017 at 12:31 PM, Jan Hugo Prins | BetterBe <
jprins at betterbe.com> wrote:

> The problem is that asking the backend to purge is not an option because
> that would not scale. If we would want to do that we need to know at the
> backend how many varnish nodes the cluster has and how to reach them all to
> purge the object effectively. Scaling the landscape would very soon become
> a big nightmare.
>
> The solution you provide here sounds like something that is programmable
> by someone familiar with VCL. VCL is completely new to me so I will start
> creating a flow diagram to see if I can understand that way what you wrote
> down. If you have any example code that would help me in the right
> direction I would be very happy.
>
> Best regards,
> Jan Hugo Prins
>
>
> On 01/24/2017 11:35 AM, Guillaume Quintard wrote:
>
> Yes, you can:
> - look for a match, and if you find one, note the etag, then restart. If
> no match is found, fetch and deliver
> - pass to the backend, if the etag doesn't match what you noted, ban the
> object. Note the new etag, restart again
> - if the new etag matches the one sent by the client, synthesize a 304,
> otherwise deliver
>
> But, is that really worth it? And is it easier than asking the backend to
> purge?
>
>
> --
> Guillaume Quintard
>
> On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe <
> jprins at betterbe.com> wrote:
>
>> Is it possible in any way to force the check before the result is send to
>> the client?
>>
>> Jan Hugo
>>
>>
>>
>> On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>>
>> Hello,
>>
>> Indeed, with this vcl code, the object is checked asynchronously. So, if
>> the check fails, the user that triggered the check will have received the
>> outdated object. It may or may not be an issue depending on your use case.
>>
>> Note that you can reduce the TTL further.
>>
>> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins at betterbe.com>
>> wrote:
>>
>>> After reading this mail and doing a lot more searching in the
>>> mailinglist and on the web, I think it is actually rather simple. At least
>>> I think that I'm seeing the correct behaviour. I'm not sure though, it
>>> could be that the response is first generated and that the origin is only
>>> checked after the response has been send to the client. What I have now in
>>> my vcl_backend_response is nothing more then:
>>>
>>> sub vcl_backend_response {
>>>     if (beresp.http.Cache-Control ~ "must-revalidate") {
>>>         set beresp.ttl = 1s;
>>>         set beresp.keep = 3600s;
>>>         set beresp.grace = 3600s;
>>>     }
>>>     return (deliver);
>>> }
>>>
>>>
>>> Jan Hugo Prins
>>>
>>>
>>>
>>> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>>
>>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>>
>>> Somewhere I found an old Trac Wiki document that describes
>>> something like this, but I can't figure out if this has been
>>> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>>
>>> That
>>>
>>> Wiki page is obsolete -- it was about an experimental branch that
>>> was developed while Varnish 3 was the released version.
>>>
>>> (Maybe we should delete the Wiki page, it's not the first time someone
>>> has been led astray.)
>>>
>>> Varnish has supported 304 responses to client requests with
>>> If-Modified-Since/If-None-Match for as long as I've known about it
>>> (going back to Varnish 2). Backend conditional requests have been
>>> supported since Varnish 4.
>>>
>>> However, by default that doesn't quite work as your flow chart
>>> indicates, if I've understood it correctly. If the client request is
>>> for a cached response with an unelapsed TTL, then Varnish delivers the
>>> cached response unconditionally, without re-validating the response
>>> with the backend. Conditional requests to backends are done for the
>>> fetch after the TTL elapses.
>>>
>>> That's the default, but I believe you can get your own VCL to
>>> implement re-validation after cache hits. I haven't tried that myself
>>> -- maybe someone reading the list has some working VCL they can share?
>>>
>>>
>>> Best,
>>> Geoff
>>>
>>> --
>>>
>>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and
>>> Storage consultant*
>>> [image: BetterBe - Transforming automotive leasing worldwide]
>>> <https://www.betterbe.com>
>>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>>> <+31%20%280%29%2053%2048%2000%20694>
>>> 7547 AN Enschede *E* jprins at betterbe.com
>>> CC no. 08097527
>>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>>> www.betterbe.com
>>> BetterBe accepts no liability for the content of this email, or for the
>>> consequences of any actions taken on the basis of the information provided,
>>> unless that information is subsequently confirmed in writing. If you are
>>> not the intended recipient you are notified that disclosing, copying,
>>> distributing or taking any action in reliance on the contents of this
>>> information is strictly prohibited.
>>> _______________________________________________ varnish-misc mailing
>>> list varnish-misc at varnish-cache.org https://www.varnish-cache.org/
>>> lists/mailman/listinfo/varnish-misc
>>
>> --
>>
>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
>> consultant*
>> [image: BetterBe - Transforming automotive leasing worldwide]
>> <https://www.betterbe.com>
>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>> <+31%20%280%29%2053%2048%2000%20694>
>> 7547 AN Enschede *E* jprins at betterbe.com
>> CC no. 08097527
>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>> www.betterbe.com
>> BetterBe accepts no liability for the content of this email, or for the
>> consequences of any actions taken on the basis of the information provided,
>> unless that information is subsequently confirmed in writing. If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited.
>>
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
> consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins at betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/99e6230c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/99e6230c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/99e6230c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/99e6230c/attachment-0002.png>

From lagged at gmail.com  Tue Jan 24 14:13:10 2017
From: lagged at gmail.com (Andrei)
Date: Tue, 24 Jan 2017 16:13:10 +0200
Subject: Support for If-None-Match header.
In-Reply-To: <109ba66d-041b-dfcf-2cbc-f4daaa9ba47b@betterbe.com>
References: <5c92da03-6a28-fc3c-8e23-2466c49448de@betterbe.com>
 <cc79bb48-02f3-2b78-9232-e4b72d1581f2@uplex.de>
 <aeb52d8e-e59e-2095-2a5a-0034f8b02c8c@betterbe.com>
 <CAJ6ZYQxXWS45RGARvu8LwXwAM7J0zxsy44=bEbq=sXc730+qjQ@mail.gmail.com>
 <11c121c6-b856-df11-6410-9cfa68cb82e9@betterbe.com>
 <CAJ6ZYQy=uOs4+=D4kfCOTkS629r5+FoB6kNapAzhEwNSR4-nbQ@mail.gmail.com>
 <109ba66d-041b-dfcf-2cbc-f4daaa9ba47b@betterbe.com>
Message-ID: <CAP+vvEvzHtEjHhhKu2rn=NRcxiONEBszcF1sEMvPvhZuiSfRog@mail.gmail.com>

This can also be approached by sending the request to an intermediary
"fanout"/request duplication endpoint. That way, the backends will always
send the purge request to a single location, which then duplicates the
requests to the related varnish nodes/clusters.

On Tue, Jan 24, 2017 at 1:31 PM, Jan Hugo Prins | BetterBe <
jprins at betterbe.com> wrote:

> The problem is that asking the backend to purge is not an option because
> that would not scale. If we would want to do that we need to know at the
> backend how many varnish nodes the cluster has and how to reach them all to
> purge the object effectively. Scaling the landscape would very soon become
> a big nightmare.
>
> The solution you provide here sounds like something that is programmable
> by someone familiar with VCL. VCL is completely new to me so I will start
> creating a flow diagram to see if I can understand that way what you wrote
> down. If you have any example code that would help me in the right
> direction I would be very happy.
>
> Best regards,
> Jan Hugo Prins
>
>
> On 01/24/2017 11:35 AM, Guillaume Quintard wrote:
>
> Yes, you can:
> - look for a match, and if you find one, note the etag, then restart. If
> no match is found, fetch and deliver
> - pass to the backend, if the etag doesn't match what you noted, ban the
> object. Note the new etag, restart again
> - if the new etag matches the one sent by the client, synthesize a 304,
> otherwise deliver
>
> But, is that really worth it? And is it easier than asking the backend to
> purge?
>
>
> --
> Guillaume Quintard
>
> On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe <
> jprins at betterbe.com> wrote:
>
>> Is it possible in any way to force the check before the result is send to
>> the client?
>>
>> Jan Hugo
>>
>>
>>
>> On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>>
>> Hello,
>>
>> Indeed, with this vcl code, the object is checked asynchronously. So, if
>> the check fails, the user that triggered the check will have received the
>> outdated object. It may or may not be an issue depending on your use case.
>>
>> Note that you can reduce the TTL further.
>>
>> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins at betterbe.com>
>> wrote:
>>
>>> After reading this mail and doing a lot more searching in the
>>> mailinglist and on the web, I think it is actually rather simple. At least
>>> I think that I'm seeing the correct behaviour. I'm not sure though, it
>>> could be that the response is first generated and that the origin is only
>>> checked after the response has been send to the client. What I have now in
>>> my vcl_backend_response is nothing more then:
>>>
>>> sub vcl_backend_response {
>>>     if (beresp.http.Cache-Control ~ "must-revalidate") {
>>>         set beresp.ttl = 1s;
>>>         set beresp.keep = 3600s;
>>>         set beresp.grace = 3600s;
>>>     }
>>>     return (deliver);
>>> }
>>>
>>>
>>> Jan Hugo Prins
>>>
>>>
>>>
>>> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>>
>>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>>
>>> Somewhere I found an old Trac Wiki document that describes
>>> something like this, but I can't figure out if this has been
>>> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>>
>>> That
>>>
>>> Wiki page is obsolete -- it was about an experimental branch that
>>> was developed while Varnish 3 was the released version.
>>>
>>> (Maybe we should delete the Wiki page, it's not the first time someone
>>> has been led astray.)
>>>
>>> Varnish has supported 304 responses to client requests with
>>> If-Modified-Since/If-None-Match for as long as I've known about it
>>> (going back to Varnish 2). Backend conditional requests have been
>>> supported since Varnish 4.
>>>
>>> However, by default that doesn't quite work as your flow chart
>>> indicates, if I've understood it correctly. If the client request is
>>> for a cached response with an unelapsed TTL, then Varnish delivers the
>>> cached response unconditionally, without re-validating the response
>>> with the backend. Conditional requests to backends are done for the
>>> fetch after the TTL elapses.
>>>
>>> That's the default, but I believe you can get your own VCL to
>>> implement re-validation after cache hits. I haven't tried that myself
>>> -- maybe someone reading the list has some working VCL they can share?
>>>
>>>
>>> Best,
>>> Geoff
>>>
>>> --
>>>
>>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and
>>> Storage consultant*
>>> [image: BetterBe - Transforming automotive leasing worldwide]
>>> <https://www.betterbe.com>
>>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>>> <+31%20%280%29%2053%2048%2000%20694>
>>> 7547 AN Enschede *E* jprins at betterbe.com
>>> CC no. 08097527
>>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>>> www.betterbe.com
>>> BetterBe accepts no liability for the content of this email, or for the
>>> consequences of any actions taken on the basis of the information provided,
>>> unless that information is subsequently confirmed in writing. If you are
>>> not the intended recipient you are notified that disclosing, copying,
>>> distributing or taking any action in reliance on the contents of this
>>> information is strictly prohibited.
>>> _______________________________________________ varnish-misc mailing
>>> list varnish-misc at varnish-cache.org https://www.varnish-cache.org/
>>> lists/mailman/listinfo/varnish-misc
>>
>> --
>>
>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
>> consultant*
>> [image: BetterBe - Transforming automotive leasing worldwide]
>> <https://www.betterbe.com>
>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>> <+31%20%280%29%2053%2048%2000%20694>
>> 7547 AN Enschede *E* jprins at betterbe.com
>> CC no. 08097527
>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>> www.betterbe.com
>> BetterBe accepts no liability for the content of this email, or for the
>> consequences of any actions taken on the basis of the information provided,
>> unless that information is subsequently confirmed in writing. If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited.
>>
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
> consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins at betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>
> _______________________________________________
> 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: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/8bd35b30/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/8bd35b30/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/8bd35b30/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170124/8bd35b30/attachment-0002.png>

From opa.auto at t-online.de  Wed Jan 25 07:27:02 2017
From: opa.auto at t-online.de (opa.auto at t-online.de)
Date: Wed, 25 Jan 2017 08:27:02 +0100 (MET)
Subject: Unix Domain socket?
Message-ID: 55612875-B5A9-48DE-8DF7-9CDEE44A9FA8@mobileclient.telekom.de


Hi,

How can I bind varnish to a unix domain socket?

Kr

Mat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170125/73a09e7b/attachment.html>

From guillaume at varnish-software.com  Wed Jan 25 08:23:16 2017
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Wed, 25 Jan 2017 09:23:16 +0100
Subject: Unix Domain socket?
In-Reply-To: <58885524.464f190a.351f9.13d4SMTPIN_ADDED_BROKEN@mx.google.com>
References: <58885524.464f190a.351f9.13d4SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CAJ6ZYQzAG--WUpA06B-wE16gCn=G0-1qGMDDgq5vwJ8gUzbGGw@mail.gmail.com>

Hello,

That's currently not possible.

Cheers,

-- 
Guillaume Quintard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20170125/d53f1e80/attachment.html>

From dridi at varni.sh  Wed Jan 25 08:38:11 2017
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Wed, 25 Jan 2017 09:38:11 +0100
Subject: Unix Domain socket?
In-Reply-To: <588855ed.0156190a.b78c8.0d1aSMTPIN_ADDED_BROKEN@mx.google.com>
References: <588855ed.0156190a.b78c8.0d1aSMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CABoVN9C12ZE7eMr6BjY57LqztiP-rFUStDCf0BCnVtxQqhn_+A@mail.gmail.com>

On Wed, Jan 25, 2017 at 8:27 AM,  <opa.auto at t-online.de> wrote:
>
> Hi,
>
> How can I bind varnish to a unix domain socket?

Hello,

Unfortunately you can't, and nothing's planned in this area today.

Dridi



From miguel_3_gonzalez at yahoo.es  Thu Jan 26 19:25:24 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Thu, 26 Jan 2017 20:25:24 +0100
Subject: varnish and wordpress
Message-ID: <a7e700a6-0193-4ec9-1439-48b335e34366@yahoo.es>

Dear all,

  Probably since I?m a newbie I assume a cache system makes a "static"
copy of a web and serve it to the browser. I have several Wordpress
sites, same backend and speed load differs quite much (from 1 second to
6 seconds). Obviously size matters but shouldn?t load all items (CSS,
JS, images) almost at the same time? Webpagetest shows it?s not the case.

  I have tried to use together with Varnish other plugin caches as W3
Total Cache but the performance is even worse.

  Maybe my assumptions are wrong or my VCL is wrong.

  I have 4.1 as was suggested by someone from the list.

 Thanks!

 Miguel

my default.vcl:

#
# This is an example VCL file for Varnish.
#
# It does not do anything by default, delegating control to the
# builtin VCL. The builtin VCL is called when there is no explicit
# return statement.
#
# See the VCL chapters in the Users Guide at
https://www.varnish-cache.org/docs/
# and http://varnish-cache.org/trac/wiki/VCLExamples for more examples.

# Marker to tell the VCL compiler that this VCL has been adapted to the
# new 4.0 format.
vcl 4.0;

import std;

# Default backend definition. Set this to point to your content server.
backend default {
    .host = "127.0.0.1";
    .port = "82";
    .connect_timeout = 600s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 600s;


}

acl purge {
        "localhost";
        "127.0.0.1";
}


# This function is used when a request is send by a HTTP client (Browser)
sub vcl_recv {

        # remove ?ver=xxxxx strings from urls so css and js files are
cached.
        # Watch out when upgrading WordPress, need to restart Varnish or
flush cache.
        set req.url = regsub(req.url, "\?ver=.*$", "");

        # Remove "replytocom" from requests to make caching better.
        set req.url = regsub(req.url, "\?replytocom=.*$", "");

        #We pass real IP and Port to the backend

        if (req.http.X-Forwarded-Proto == "https" ) {
           set req.http.X-Port = "443";
        } else {
           set req.http.X-Port = "80";
        }

        set req.http.X-Forwarded-For = regsub(req.http.X-Forwarded-For,
"^([^,]+),?.*$", "\1");


        # Normalize the header, remove the port (in case you're testing
this on various TCP ports)

        set req.http.Host = regsub(req.http.Host, ":[0-9]+", "");

        # Remove has_js and CloudFlare/Google Analytics __* cookies.
        set req.http.Cookie = regsuball(req.http.Cookie,
"(^|;\s*)(_[_a-z]+|has_js)=[^;]*", "");
        # Remove a ";" prefix, if present.
        set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");


        # Allow purging from ACL
        if (req.method == "PURGE") {
                # If not allowed then a error 405 is returned
                if (!client.ip ~ purge) {
                        return(synth(405, "This IP is not allowed to
send PURGE requests."));
                }
                # If allowed, do a cache_lookup -> vlc_hit() or vlc_miss()
                return (purge);
        }

        # Post requests will not be cached
        #if (req.http.Authorization || req.method == "POST") {
        #       return (pass);
        #}

        # Pass anything other than GET and HEAD directly.
        if (req.method != "GET" && req.method != "HEAD") {
                return( pass );
        }      /* We only deal with GET and HEAD by default */


        #Woocommerce don't cache :
        if (req.url ~
"^/(cart|my-account/*|checkout|addons|logout|lost-password|product/*)") {
          return (pass);
        }

        #Woocommerce add to cart pass :
        if (req.url ~ "\?add-to-cart=" ) {
          return (pass);
        }
        if (req.url ~ "/wp-cron.php" || req.url ~ "preview=true") {
          return (pass);
        }

        # Woocommerce
        if (req.url ~ "(cart|my-account|checkout|addons)") {
          return (pass);
        }
        if ( req.url ~ "\?add-to-cart=" ) {
          return (pass);
        }


        # --- WordPress specific configuration
        # Did not cache the admin and login pages
        if (req.url ~
"nocache|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|wp-(comments-post|login|signup|activate|mail|cron)\.php|preview\=true|admin-ajax\.php|xmlrpc\.php|bb-admin|whm-server-status|server-status|control\.php|bb-login\.php|bb-reset-password\.php|register\.php")
{
            return (pass);
        }

        if (req.url ~ "(ajax|dynamic|custom)") {
             return(pass);
        }

        # Remove the "has_js" cookie
        set req.http.Cookie = regsuball(req.http.Cookie, "has_js=[^;]+(;
)?", "");

        # Remove any Google Analytics based cookies
        set req.http.Cookie = regsuball(req.http.Cookie, "__utm.=[^;]+(;
)?", "");

        # Remove the Quant Capital cookies (added by some plugin, all __qca)
        set req.http.Cookie = regsuball(req.http.Cookie, "__qc.=[^;]+(;
)?", "");

        # Remove the wp-settings-1 cookie
        set req.http.Cookie = regsuball(req.http.Cookie,
"wp-settings-1=[^;]+(; )?", "");

        # Remove the wp-settings-time-1 cookie
        set req.http.Cookie = regsuball(req.http.Cookie,
"wp-settings-time-1=[^;]+(; )?", "");

        # Remove the wp test cookie
        set req.http.Cookie = regsuball(req.http.Cookie,
"wordpress_test_cookie=[^;]+(; )?", "");

        # Are there cookies left with only spaces or that are empty?
        if (req.http.cookie ~ "^ *$") {
                    unset req.http.cookie;
        }

        # Cache the following files extensions
        if (req.url ~ "\.(txt|css|js|png|gif|jp(e)?g|swf|ico)") {
                unset req.http.cookie;
        }

        # Normalize Accept-Encoding header and compression
        # https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
        if (req.http.Accept-Encoding) {
                # Do no compress compressed files...
                if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
                                unset req.http.Accept-Encoding;
                } elsif (req.http.Accept-Encoding ~ "gzip") {
                        set req.http.Accept-Encoding = "gzip";
                } elsif (req.http.Accept-Encoding ~ "deflate") {
                        set req.http.Accept-Encoding = "deflate";
                } else {
                        unset req.http.Accept-Encoding;
                }
        }

        # Check the cookies for wordpress-specific items
        if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~
"comment_") {
                return (pass);
        }
        if (!req.http.cookie) {
                unset req.http.cookie;
        }

        # --- End of WordPress specific configuration

        # Did not cache HTTP authentication and HTTP Cookie
        if (req.http.Authorization || req.http.Cookie) {
                # Not cacheable by default
                return (pass);
        }

        # Cache all others requests
        return (hash);
}

sub vcl_pipe {
        return (pipe);
}

sub vcl_pass {
        return (fetch);
}

# The data on which the hashing will take place
sub vcl_hash {
        hash_data(req.url);
        if (req.http.host) {
        hash_data(req.http.host);
        } else {
        hash_data(server.ip);
        }

        # If the client supports compression, keep that in a different cache
        if (req.http.Accept-Encoding) {
                hash_data(req.http.Accept-Encoding);
        }

        return (lookup);
}

# This function is used when a request is sent by our backend (Nginx server)
sub vcl_backend_response {
        # Remove some headers we never want to see
        unset beresp.http.Server;
        unset beresp.http.X-Powered-By;

        if (beresp.http.content-type ~
"(text|javascript|application/x-font-woff)") {
          set beresp.do_gzip = true;
        }

        # For static content strip all backend cookies
        if (bereq.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
                unset beresp.http.cookie;
        }
        # Don't store backend
        if (bereq.url ~ "wp-(login|admin)" || bereq.url ~ "preview=true") {
                set beresp.uncacheable = true;
                set beresp.ttl = 30s;
                return (deliver);
        }

        # Only allow cookies to be set if we're in admin area
                if (!(bereq.url ~
"(wp-login|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|preview=true)"))
{
                unset beresp.http.set-cookie;
        }

        # don't cache response to posted requests or those with basic auth
        if ( bereq.method == "POST" || bereq.http.Authorization ) {
                set beresp.uncacheable = true;
                set beresp.ttl = 120s;
                return (deliver);
        }

        # don't cache search results
        if ( bereq.url ~ "\?s=" ){
                set beresp.uncacheable = true;
                set beresp.ttl = 120s;
                return (deliver);
        }

        # only cache status ok
        if ( beresp.status != 200 ) {
                set beresp.uncacheable = true;
                set beresp.ttl = 120s;
                return (deliver);
        }

        # A TTL of 24h
        set beresp.ttl = 24h;
        # Define the default grace period to serve cached content
        #set beresp.grace = 30s;
        set beresp.grace = 1h;

        return (deliver);
}

# The routine when we deliver the HTTP request to the user
# Last chance to modify headers that are sent to the client
sub vcl_deliver {
        if (obj.hits > 0) {
                set resp.http.X-Cache = "cached";
        } else {
                set resp.http.x-Cache = "uncached";
        }

        # Remove some headers: PHP version
        unset resp.http.X-Powered-By;

        # Remove some headers: Apache version & OS
        unset resp.http.Server;

        # Remove some heanders: Varnish
        unset resp.http.Via;
        unset resp.http.X-Varnish;

        return (deliver);
}

sub vcl_init {
        return (ok);
}

sub vcl_fini {
        return (ok);
}



From miguel_3_gonzalez at yahoo.es  Thu Jan 26 20:57:03 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Thu, 26 Jan 2017 21:57:03 +0100
Subject: varnish and wordpress
In-Reply-To: <CAE7KU85+YzmJP37nEkHZU5Ta+e8FRkgOO4-T_U_dfPiO5J72tw@mail.gmail.com>
References: <a7e700a6-0193-4ec9-1439-48b335e34366@yahoo.es>
 <CAE7KU85+YzmJP37nEkHZU5Ta+e8FRkgOO4-T_U_dfPiO5J72tw@mail.gmail.com>
Message-ID: <66c1f7c8-164c-ccef-8497-3cf44cdf80d4@yahoo.es>

What is the relation of this setting with Varnish? I?m not finding any
information about this setting and Varnish.

Thanks!

Miguel


On 01/26/17 9:22 PM, Carlos Fernandez wrote:
> That VCL looks similar to what we use. What does the
> "session.cache_limiter" setting in your php.ini file say? If it's set to
> "nocache" (the default), then PHP will always respond with an Expires
> header set in the past so that Varnish will not cache it.
> 
> On Thu, Jan 26, 2017 at 2:25 PM, Miguel Gonz?lez
> <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>> wrote:
> 
>     Dear all,
> 
>       Probably since I?m a newbie I assume a cache system makes a "static"
>     copy of a web and serve it to the browser. I have several Wordpress
>     sites, same backend and speed load differs quite much (from 1 second to
>     6 seconds). Obviously size matters but shouldn?t load all items (CSS,
>     JS, images) almost at the same time? Webpagetest shows it?s not the
>     case.
> 
>       I have tried to use together with Varnish other plugin caches as W3
>     Total Cache but the performance is even worse.
> 
>       Maybe my assumptions are wrong or my VCL is wrong.
> 
>       I have 4.1 as was suggested by someone from the list.
> 
>      Thanks!
> 
>      Miguel
> 
>     my default.vcl:
> 
>     #
>     # This is an example VCL file for Varnish.
>     #
>     # It does not do anything by default, delegating control to the
>     # builtin VCL. The builtin VCL is called when there is no explicit
>     # return statement.
>     #
>     # See the VCL chapters in the Users Guide at
>     https://www.varnish-cache.org/docs/
>     <https://www.varnish-cache.org/docs/>
>     # and http://varnish-cache.org/trac/wiki/VCLExamples
>     <http://varnish-cache.org/trac/wiki/VCLExamples> for more examples.
> 
>     # Marker to tell the VCL compiler that this VCL has been adapted to the
>     # new 4.0 format.
>     vcl 4.0;
> 
>     import std;
> 
>     # Default backend definition. Set this to point to your content server.
>     backend default {
>         .host = "127.0.0.1";
>         .port = "82";
>         .connect_timeout = 600s;
>         .first_byte_timeout = 600s;
>         .between_bytes_timeout = 600s;
> 
> 
>     }
> 
>     acl purge {
>             "localhost";
>             "127.0.0.1";
>     }
> 
> 
>     # This function is used when a request is send by a HTTP client
>     (Browser)
>     sub vcl_recv {
> 
>             # remove ?ver=xxxxx strings from urls so css and js files are
>     cached.
>             # Watch out when upgrading WordPress, need to restart Varnish or
>     flush cache.
>             set req.url = regsub(req.url, "\?ver=.*$", "");
> 
>             # Remove "replytocom" from requests to make caching better.
>             set req.url = regsub(req.url, "\?replytocom=.*$", "");
> 
>             #We pass real IP and Port to the backend
> 
>             if (req.http.X-Forwarded-Proto == "https" ) {
>                set req.http.X-Port = "443";
>             } else {
>                set req.http.X-Port = "80";
>             }
> 
>             set req.http.X-Forwarded-For = regsub(req.http.X-Forwarded-For,
>     "^([^,]+),?.*$", "\1");
> 
> 
>             # Normalize the header, remove the port (in case you're testing
>     this on various TCP ports)
> 
>             set req.http.Host = regsub(req.http.Host, ":[0-9]+", "");
> 
>             # Remove has_js and CloudFlare/Google Analytics __* cookies.
>             set req.http.Cookie = regsuball(req.http.Cookie,
>     "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", "");
>             # Remove a ";" prefix, if present.
>             set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
> 
> 
>             # Allow purging from ACL
>             if (req.method == "PURGE") {
>                     # If not allowed then a error 405 is returned
>                     if (!client.ip ~ purge) {
>                             return(synth(405, "This IP is not allowed to
>     send PURGE requests."));
>                     }
>                     # If allowed, do a cache_lookup -> vlc_hit() or
>     vlc_miss()
>                     return (purge);
>             }
> 
>             # Post requests will not be cached
>             #if (req.http.Authorization || req.method == "POST") {
>             #       return (pass);
>             #}
> 
>             # Pass anything other than GET and HEAD directly.
>             if (req.method != "GET" && req.method != "HEAD") {
>                     return( pass );
>             }      /* We only deal with GET and HEAD by default */
> 
> 
>             #Woocommerce don't cache :
>             if (req.url ~
>     "^/(cart|my-account/*|checkout|addons|logout|lost-password|product/*)")
>     {
>               return (pass);
>             }
> 
>             #Woocommerce add to cart pass :
>             if (req.url ~ "\?add-to-cart=" ) {
>               return (pass);
>             }
>             if (req.url ~ "/wp-cron.php" || req.url ~ "preview=true") {
>               return (pass);
>             }
> 
>             # Woocommerce
>             if (req.url ~ "(cart|my-account|checkout|addons)") {
>               return (pass);
>             }
>             if ( req.url ~ "\?add-to-cart=" ) {
>               return (pass);
>             }
> 
> 
>             # --- WordPress specific configuration
>             # Did not cache the admin and login pages
>             if (req.url ~
>     "nocache|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|wp-(comments-post|login|signup|activate|mail|cron)\.php|preview\=true|admin-ajax\.php|xmlrpc\.php|bb-admin|whm-server-status|server-status|control\.php|bb-login\.php|bb-reset-password\.php|register\.php")
>     {
>                 return (pass);
>             }
> 
>             if (req.url ~ "(ajax|dynamic|custom)") {
>                  return(pass);
>             }
> 
>             # Remove the "has_js" cookie
>             set req.http.Cookie = regsuball(req.http.Cookie, "has_js=[^;]+(;
>     )?", "");
> 
>             # Remove any Google Analytics based cookies
>             set req.http.Cookie = regsuball(req.http.Cookie, "__utm.=[^;]+(;
>     )?", "");
> 
>             # Remove the Quant Capital cookies (added by some plugin,
>     all __qca)
>             set req.http.Cookie = regsuball(req.http.Cookie, "__qc.=[^;]+(;
>     )?", "");
> 
>             # Remove the wp-settings-1 cookie
>             set req.http.Cookie = regsuball(req.http.Cookie,
>     "wp-settings-1=[^;]+(; )?", "");
> 
>             # Remove the wp-settings-time-1 cookie
>             set req.http.Cookie = regsuball(req.http.Cookie,
>     "wp-settings-time-1=[^;]+(; )?", "");
> 
>             # Remove the wp test cookie
>             set req.http.Cookie = regsuball(req.http.Cookie,
>     "wordpress_test_cookie=[^;]+(; )?", "");
> 
>             # Are there cookies left with only spaces or that are empty?
>             if (req.http.cookie ~ "^ *$") {
>                         unset req.http.cookie;
>             }
> 
>             # Cache the following files extensions
>             if (req.url ~ "\.(txt|css|js|png|gif|jp(e)?g|swf|ico)") {
>                     unset req.http.cookie;
>             }
> 
>             # Normalize Accept-Encoding header and compression
>             # https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
>     <https://www.varnish-cache.org/docs/3.0/tutorial/vary.html>
>             if (req.http.Accept-Encoding) {
>                     # Do no compress compressed files...
>                     if (req.url ~
>     "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
>                                     unset req.http.Accept-Encoding;
>                     } elsif (req.http.Accept-Encoding ~ "gzip") {
>                             set req.http.Accept-Encoding = "gzip";
>                     } elsif (req.http.Accept-Encoding ~ "deflate") {
>                             set req.http.Accept-Encoding = "deflate";
>                     } else {
>                             unset req.http.Accept-Encoding;
>                     }
>             }
> 
>             # Check the cookies for wordpress-specific items
>             if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~
>     "comment_") {
>                     return (pass);
>             }
>             if (!req.http.cookie) {
>                     unset req.http.cookie;
>             }
> 
>             # --- End of WordPress specific configuration
> 
>             # Did not cache HTTP authentication and HTTP Cookie
>             if (req.http.Authorization || req.http.Cookie) {
>                     # Not cacheable by default
>                     return (pass);
>             }
> 
>             # Cache all others requests
>             return (hash);
>     }
> 
>     sub vcl_pipe {
>             return (pipe);
>     }
> 
>     sub vcl_pass {
>             return (fetch);
>     }
> 
>     # The data on which the hashing will take place
>     sub vcl_hash {
>             hash_data(req.url);
>             if (req.http.host) {
>             hash_data(req.http.host);
>             } else {
>             hash_data(server.ip);
>             }
> 
>             # If the client supports compression, keep that in a
>     different cache
>             if (req.http.Accept-Encoding) {
>                     hash_data(req.http.Accept-Encoding);
>             }
> 
>             return (lookup);
>     }
> 
>     # This function is used when a request is sent by our backend (Nginx
>     server)
>     sub vcl_backend_response {
>             # Remove some headers we never want to see
>             unset beresp.http.Server;
>             unset beresp.http.X-Powered-By;
> 
>             if (beresp.http.content-type ~
>     "(text|javascript|application/x-font-woff)") {
>               set beresp.do_gzip = true;
>             }
> 
>             # For static content strip all backend cookies
>             if (bereq.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
>                     unset beresp.http.cookie;
>             }
>             # Don't store backend
>             if (bereq.url ~ "wp-(login|admin)" || bereq.url ~
>     "preview=true") {
>                     set beresp.uncacheable = true;
>                     set beresp.ttl = 30s;
>                     return (deliver);
>             }
> 
>             # Only allow cookies to be set if we're in admin area
>                     if (!(bereq.url ~
>     "(wp-login|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|preview=true)"))
>     {
>                     unset beresp.http.set-cookie;
>             }
> 
>             # don't cache response to posted requests or those with
>     basic auth
>             if ( bereq.method == "POST" || bereq.http.Authorization ) {
>                     set beresp.uncacheable = true;
>                     set beresp.ttl = 120s;
>                     return (deliver);
>             }
> 
>             # don't cache search results
>             if ( bereq.url ~ "\?s=" ){
>                     set beresp.uncacheable = true;
>                     set beresp.ttl = 120s;
>                     return (deliver);
>             }
> 
>             # only cache status ok
>             if ( beresp.status != 200 ) {
>                     set beresp.uncacheable = true;
>                     set beresp.ttl = 120s;
>                     return (deliver);
>             }
> 
>             # A TTL of 24h
>             set beresp.ttl = 24h;
>             # Define the default grace period to serve cached content
>             #set beresp.grace = 30s;
>             set beresp.grace = 1h;
> 
>             return (deliver);
>     }
> 
>     # The routine when we deliver the HTTP request to the user
>     # Last chance to modify headers that are sent to the client
>     sub vcl_deliver {
>             if (obj.hits > 0) {
>                     set resp.http.X-Cache = "cached";
>             } else {
>                     set resp.http.x-Cache = "uncached";
>             }
> 
>             # Remove some headers: PHP version
>             unset resp.http.X-Powered-By;
> 
>             # Remove some headers: Apache version & OS
>             unset resp.http.Server;
> 
>             # Remove some heanders: Varnish
>             unset resp.http.Via;
>             unset resp.http.X-Varnish;
> 
>             return (deliver);
>     }
> 
>     sub vcl_init {
>             return (ok);
>     }
> 
>     sub vcl_fini {
>             return (ok);
>     }
> 
>     _______________________________________________
>     varnish-misc mailing list
>     varnish-misc at varnish-cache.org <mailto:varnish-misc at varnish-cache.org>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
> 
> 
> 
> 
> -- 
> 
> Best regards,
> 
> --
> 
> Carlos M. Fern?ndez
> 
> Enterprise Systems Manager
> 
> *Saint Joseph?s University*
> 
> Philadelphia PA 19131
> 
> T: +1 610 660 1501
> 




From miguel_3_gonzalez at yahoo.es  Thu Jan 26 21:22:48 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Thu, 26 Jan 2017 22:22:48 +0100
Subject: varnish and wordpress
In-Reply-To: <CAE7KU85EYyLVoymUi2Yj18Bcv2uQxUCMTk_byhRXo=S7qU-2Dw@mail.gmail.com>
References: <a7e700a6-0193-4ec9-1439-48b335e34366@yahoo.es>
 <CAE7KU85+YzmJP37nEkHZU5Ta+e8FRkgOO4-T_U_dfPiO5J72tw@mail.gmail.com>
 <b659323f-3458-f8cf-b0a2-637ae8c4bf1b@yahoo.es>
 <CAE7KU85EYyLVoymUi2Yj18Bcv2uQxUCMTk_byhRXo=S7qU-2Dw@mail.gmail.com>
Message-ID: <51ac041b-e505-c8b1-896a-47e819b23f37@yahoo.es>

thanks for answering so quickly.

I have found some people mentioning the public setting for cache_limiter
here:

http://www.kriesi.at/support/topic/enfold-seems-to-add-cache-disabling-headers/

There are purging plugins as varnish-http-purge which (supposedly)
purges Varnish cache when new content is created. I have found myself
having to manually ban content with varnishadm because it doesn?t always
work.

I have tested from a different machine with curl and currently it seems
expiration is set to one month. I guess from this setting in .htaccess:

ExpiresByType text/html "access 1 month"

curl -I -H 'Accept-Encoding: gzip,deflate' https://www.mysite.com/
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 04:50:03 GMT
Server: Apache
X-Pingback: https://www.mysite.com/xmlrpc.php
Link: <https://www.mysite.com/wp-json/>; rel="https://api.w.org/",
<https://www.mysite.com/>; rel=shortlink
Cache-Control: max-age=2592000
Expires: Sat, 25 Feb 2017 04:50:03 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Vary: Accept-Encoding
Age: 59348
X-Cache: cached
Accept-Ranges: bytes

Thanks!

Miguel


On 01/26/17 10:10 PM, Carlos Fernandez wrote:
> I don't know about recommended settings, that decision should come from
> a discussion with the content editors since they might have some
> expectation about how quickly new content gets published -- the
> workaround to that would be to have WordPress automatically purge the
> objects in Varnish, but I have not yet seen an easy solution for that
> and I have no intention or responsibility for coding that myself. I have
> session.cache_limiter set to "public" and session.cache_expires to 1440
> minutes (1 day) -- the latter affects the value of the Expires header
> and thus the TTL of the cached objects in Varnish, so you may want to
> adjust that according to your needs.
> 
> Enhorabuena.
> 
> 
> On Thu, Jan 26, 2017 at 3:47 PM, Miguel Gonz?lez
> <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>> wrote:
> 
>     It does indeed! What are the recommended settings?
> 
> 
>     On 01/26/17 9:22 PM, Carlos Fernandez wrote:
>     > That VCL looks similar to what we use. What does the
>     > "session.cache_limiter" setting in your php.ini file say? If it's set to
>     > "nocache" (the default), then PHP will always respond with an Expires
>     > header set in the past so that Varnish will not cache it.
>     >
>     > On Thu, Jan 26, 2017 at 2:25 PM, Miguel Gonz?lez
>     > <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>
>     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>>> wrote:
>     >
>     >     Dear all,
>     >
>     >       Probably since I?m a newbie I assume a cache system makes a
>     "static"
>     >     copy of a web and serve it to the browser. I have several
>     Wordpress
>     >     sites, same backend and speed load differs quite much (from 1
>     second to
>     >     6 seconds). Obviously size matters but shouldn?t load all
>     items (CSS,
>     >     JS, images) almost at the same time? Webpagetest shows it?s
>     not the
>     >     case.
>     >
>     >       I have tried to use together with Varnish other plugin
>     caches as W3
>     >     Total Cache but the performance is even worse.
>     >
>     >       Maybe my assumptions are wrong or my VCL is wrong.
>     >
>     >       I have 4.1 as was suggested by someone from the list.
>     >
>     >      Thanks!
>     >
>     >      Miguel
>     >
>     >     my default.vcl:
>     >
>     >     #
>     >     # This is an example VCL file for Varnish.
>     >     #
>     >     # It does not do anything by default, delegating control to the
>     >     # builtin VCL. The builtin VCL is called when there is no explicit
>     >     # return statement.
>     >     #
>     >     # See the VCL chapters in the Users Guide at
>     >     https://www.varnish-cache.org/docs/
>     <https://www.varnish-cache.org/docs/>
>     >     <https://www.varnish-cache.org/docs/
>     <https://www.varnish-cache.org/docs/>>
>     >     # and http://varnish-cache.org/trac/wiki/VCLExamples
>     <http://varnish-cache.org/trac/wiki/VCLExamples>
>     >     <http://varnish-cache.org/trac/wiki/VCLExamples
>     <http://varnish-cache.org/trac/wiki/VCLExamples>> for more examples.
>     >
>     >     # Marker to tell the VCL compiler that this VCL has been
>     adapted to the
>     >     # new 4.0 format.
>     >     vcl 4.0;
>     >
>     >     import std;
>     >
>     >     # Default backend definition. Set this to point to your
>     content server.
>     >     backend default {
>     >         .host = "127.0.0.1";
>     >         .port = "82";
>     >         .connect_timeout = 600s;
>     >         .first_byte_timeout = 600s;
>     >         .between_bytes_timeout = 600s;
>     >
>     >
>     >     }
>     >
>     >     acl purge {
>     >             "localhost";
>     >             "127.0.0.1";
>     >     }
>     >
>     >
>     >     # This function is used when a request is send by a HTTP client
>     >     (Browser)
>     >     sub vcl_recv {
>     >
>     >             # remove ?ver=xxxxx strings from urls so css and js
>     files are
>     >     cached.
>     >             # Watch out when upgrading WordPress, need to restart
>     Varnish or
>     >     flush cache.
>     >             set req.url = regsub(req.url, "\?ver=.*$", "");
>     >
>     >             # Remove "replytocom" from requests to make caching
>     better.
>     >             set req.url = regsub(req.url, "\?replytocom=.*$", "");
>     >
>     >             #We pass real IP and Port to the backend
>     >
>     >             if (req.http.X-Forwarded-Proto == "https" ) {
>     >                set req.http.X-Port = "443";
>     >             } else {
>     >                set req.http.X-Port = "80";
>     >             }
>     >
>     >             set req.http.X-Forwarded-For =
>     regsub(req.http.X-Forwarded-For,
>     >     "^([^,]+),?.*$", "\1");
>     >
>     >
>     >             # Normalize the header, remove the port (in case
>     you're testing
>     >     this on various TCP ports)
>     >
>     >             set req.http.Host = regsub(req.http.Host, ":[0-9]+", "");
>     >
>     >             # Remove has_js and CloudFlare/Google Analytics __*
>     cookies.
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", "");
>     >             # Remove a ";" prefix, if present.
>     >             set req.http.Cookie = regsub(req.http.Cookie, "^;\s*",
>     "");
>     >
>     >
>     >             # Allow purging from ACL
>     >             if (req.method == "PURGE") {
>     >                     # If not allowed then a error 405 is returned
>     >                     if (!client.ip ~ purge) {
>     >                             return(synth(405, "This IP is not
>     allowed to
>     >     send PURGE requests."));
>     >                     }
>     >                     # If allowed, do a cache_lookup -> vlc_hit() or
>     >     vlc_miss()
>     >                     return (purge);
>     >             }
>     >
>     >             # Post requests will not be cached
>     >             #if (req.http.Authorization || req.method == "POST") {
>     >             #       return (pass);
>     >             #}
>     >
>     >             # Pass anything other than GET and HEAD directly.
>     >             if (req.method != "GET" && req.method != "HEAD") {
>     >                     return( pass );
>     >             }      /* We only deal with GET and HEAD by default */
>     >
>     >
>     >             #Woocommerce don't cache :
>     >             if (req.url ~
>     >   
>      "^/(cart|my-account/*|checkout|addons|logout|lost-password|product/*)")
>     >     {
>     >               return (pass);
>     >             }
>     >
>     >             #Woocommerce add to cart pass :
>     >             if (req.url ~ "\?add-to-cart=" ) {
>     >               return (pass);
>     >             }
>     >             if (req.url ~ "/wp-cron.php" || req.url ~
>     "preview=true") {
>     >               return (pass);
>     >             }
>     >
>     >             # Woocommerce
>     >             if (req.url ~ "(cart|my-account|checkout|addons)") {
>     >               return (pass);
>     >             }
>     >             if ( req.url ~ "\?add-to-cart=" ) {
>     >               return (pass);
>     >             }
>     >
>     >
>     >             # --- WordPress specific configuration
>     >             # Did not cache the admin and login pages
>     >             if (req.url ~
>     >   
>      "nocache|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|wp-(comments-post|login|signup|activate|mail|cron)\.php|preview\=true|admin-ajax\.php|xmlrpc\.php|bb-admin|whm-server-status|server-status|control\.php|bb-login\.php|bb-reset-password\.php|register\.php")
>     >     {
>     >                 return (pass);
>     >             }
>     >
>     >             if (req.url ~ "(ajax|dynamic|custom)") {
>     >                  return(pass);
>     >             }
>     >
>     >             # Remove the "has_js" cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     "has_js=[^;]+(;
>     >     )?", "");
>     >
>     >             # Remove any Google Analytics based cookies
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     "__utm.=[^;]+(;
>     >     )?", "");
>     >
>     >             # Remove the Quant Capital cookies (added by some plugin,
>     >     all __qca)
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     "__qc.=[^;]+(;
>     >     )?", "");
>     >
>     >             # Remove the wp-settings-1 cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "wp-settings-1=[^;]+(; )?", "");
>     >
>     >             # Remove the wp-settings-time-1 cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "wp-settings-time-1=[^;]+(; )?", "");
>     >
>     >             # Remove the wp test cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "wordpress_test_cookie=[^;]+(; )?", "");
>     >
>     >             # Are there cookies left with only spaces or that are
>     empty?
>     >             if (req.http.cookie ~ "^ *$") {
>     >                         unset req.http.cookie;
>     >             }
>     >
>     >             # Cache the following files extensions
>     >             if (req.url ~ "\.(txt|css|js|png|gif|jp(e)?g|swf|ico)") {
>     >                     unset req.http.cookie;
>     >             }
>     >
>     >             # Normalize Accept-Encoding header and compression
>     >             #
>     https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
>     <https://www.varnish-cache.org/docs/3.0/tutorial/vary.html>
>     >     <https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
>     <https://www.varnish-cache.org/docs/3.0/tutorial/vary.html>>
>     >             if (req.http.Accept-Encoding) {
>     >                     # Do no compress compressed files...
>     >                     if (req.url ~
>     >     "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
>     >                                     unset req.http.Accept-Encoding;
>     >                     } elsif (req.http.Accept-Encoding ~ "gzip") {
>     >                             set req.http.Accept-Encoding = "gzip";
>     >                     } elsif (req.http.Accept-Encoding ~ "deflate") {
>     >                             set req.http.Accept-Encoding = "deflate";
>     >                     } else {
>     >                             unset req.http.Accept-Encoding;
>     >                     }
>     >             }
>     >
>     >             # Check the cookies for wordpress-specific items
>     >             if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~
>     >     "comment_") {
>     >                     return (pass);
>     >             }
>     >             if (!req.http.cookie) {
>     >                     unset req.http.cookie;
>     >             }
>     >
>     >             # --- End of WordPress specific configuration
>     >
>     >             # Did not cache HTTP authentication and HTTP Cookie
>     >             if (req.http.Authorization || req.http.Cookie) {
>     >                     # Not cacheable by default
>     >                     return (pass);
>     >             }
>     >
>     >             # Cache all others requests
>     >             return (hash);
>     >     }
>     >
>     >     sub vcl_pipe {
>     >             return (pipe);
>     >     }
>     >
>     >     sub vcl_pass {
>     >             return (fetch);
>     >     }
>     >
>     >     # The data on which the hashing will take place
>     >     sub vcl_hash {
>     >             hash_data(req.url);
>     >             if (req.http.host) {
>     >             hash_data(req.http.host);
>     >             } else {
>     >             hash_data(server.ip);
>     >             }
>     >
>     >             # If the client supports compression, keep that in a
>     >     different cache
>     >             if (req.http.Accept-Encoding) {
>     >                     hash_data(req.http.Accept-Encoding);
>     >             }
>     >
>     >             return (lookup);
>     >     }
>     >
>     >     # This function is used when a request is sent by our backend
>     (Nginx
>     >     server)
>     >     sub vcl_backend_response {
>     >             # Remove some headers we never want to see
>     >             unset beresp.http.Server;
>     >             unset beresp.http.X-Powered-By;
>     >
>     >             if (beresp.http.content-type ~
>     >     "(text|javascript|application/x-font-woff)") {
>     >               set beresp.do_gzip = true;
>     >             }
>     >
>     >             # For static content strip all backend cookies
>     >             if (bereq.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
>     >                     unset beresp.http.cookie;
>     >             }
>     >             # Don't store backend
>     >             if (bereq.url ~ "wp-(login|admin)" || bereq.url ~
>     >     "preview=true") {
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 30s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # Only allow cookies to be set if we're in admin area
>     >                     if (!(bereq.url ~
>     >   
>      "(wp-login|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|preview=true)"))
>     >     {
>     >                     unset beresp.http.set-cookie;
>     >             }
>     >
>     >             # don't cache response to posted requests or those with
>     >     basic auth
>     >             if ( bereq.method == "POST" ||
>     bereq.http.Authorization ) {
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 120s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # don't cache search results
>     >             if ( bereq.url ~ "\?s=" ){
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 120s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # only cache status ok
>     >             if ( beresp.status != 200 ) {
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 120s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # A TTL of 24h
>     >             set beresp.ttl = 24h;
>     >             # Define the default grace period to serve cached content
>     >             #set beresp.grace = 30s;
>     >             set beresp.grace = 1h;
>     >
>     >             return (deliver);
>     >     }
>     >
>     >     # The routine when we deliver the HTTP request to the user
>     >     # Last chance to modify headers that are sent to the client
>     >     sub vcl_deliver {
>     >             if (obj.hits > 0) {
>     >                     set resp.http.X-Cache = "cached";
>     >             } else {
>     >                     set resp.http.x-Cache = "uncached";
>     >             }
>     >
>     >             # Remove some headers: PHP version
>     >             unset resp.http.X-Powered-By;
>     >
>     >             # Remove some headers: Apache version & OS
>     >             unset resp.http.Server;
>     >
>     >             # Remove some heanders: Varnish
>     >             unset resp.http.Via;
>     >             unset resp.http.X-Varnish;
>     >
>     >             return (deliver);
>     >     }
>     >
>     >     sub vcl_init {
>     >             return (ok);
>     >     }
>     >
>     >     sub vcl_fini {
>     >             return (ok);
>     >     }
>     >
>     >     _______________________________________________
>     >     varnish-misc mailing list
>     >     varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>
>     >   
>      https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>     >     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>>
>     >
>     >
>     >
>     >
>     > --
>     >
>     > Best regards,
>     >
>     > --
>     >
>     > Carlos M. Fern?ndez
>     >
>     > Enterprise Systems Manager
>     >
>     > *Saint Joseph?s University*
>     >
>     > Philadelphia PA 19131
>     >
>     > T: +1 610 660 1501
>     >
> 
> 
> 
> 
> -- 
> 
> Best regards,
> 
> --
> 
> Carlos M. Fern?ndez
> 
> Enterprise Systems Manager
> 
> *Saint Joseph?s University*
> 
> Philadelphia PA 19131
> 
> T: +1 610 660 1501
> 




From miguel_3_gonzalez at yahoo.es  Thu Jan 26 22:18:01 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Thu, 26 Jan 2017 23:18:01 +0100
Subject: varnish and wordpress
In-Reply-To: <CAE7KU87eRuNJfPB+ji7ei0PsZ9MP8bkFur3nVXkVJQQCHi0+Zw@mail.gmail.com>
References: <a7e700a6-0193-4ec9-1439-48b335e34366@yahoo.es>
 <CAE7KU85+YzmJP37nEkHZU5Ta+e8FRkgOO4-T_U_dfPiO5J72tw@mail.gmail.com>
 <66c1f7c8-164c-ccef-8497-3cf44cdf80d4@yahoo.es>
 <CAE7KU87eRuNJfPB+ji7ei0PsZ9MP8bkFur3nVXkVJQQCHi0+Zw@mail.gmail.com>
Message-ID: <42cea191-fde7-520b-61f8-671b54e3ec17@yahoo.es>

thanks for this information.

Wouldn?t it help just setting in .htaccess:

ExpiresByType text/html "access 1 month"

?

Miguel



On 01/26/17 10:42 PM, Carlos Fernandez wrote:
> Per php.net <http://php.net>:
> 
> "The cache limiter defines which cache control HTTP headers are sent to
> the client. These headers determine the rules by which the page content
> may be cached by the client and intermediate proxies. Setting the cache
> limiter to /nocache/disallows any client/proxy caching. A value
> of /public/ permits caching by proxies and the client,
> whereas /private/ disallows caching by proxies and permits the client to
> cache the contents."
> 
> Varnish obeys the cache control headers in the backend response,
> therefore this setting (and cache_expires) indirectly affects Varnish by
> way of the headers. You could alter them in VCL, but that takes more work.
> 
> 
> On Thu, Jan 26, 2017 at 16:29 Miguel Gonz?lez
> <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>> wrote:
> 
>     What is the relation of this setting with Varnish? I?m not finding any
>     information about this setting and Varnish.
> 
>     Thanks!
> 
>     Miguel
> 
> 
>     On 01/26/17 9:22 PM, Carlos Fernandez wrote:
>     > That VCL looks similar to what we use. What does the
>     > "session.cache_limiter" setting in your php.ini file say? If it's
>     set to
>     > "nocache" (the default), then PHP will always respond with an Expires
>     > header set in the past so that Varnish will not cache it.
>     >
>     > On Thu, Jan 26, 2017 at 2:25 PM, Miguel Gonz?lez
>     > <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>
>     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>>> wrote:
>     >
>     >     Dear all,
>     >
>     >       Probably since I?m a newbie I assume a cache system makes a
>     "static"
>     >     copy of a web and serve it to the browser. I have several
>     Wordpress
>     >     sites, same backend and speed load differs quite much (from 1
>     second to
>     >     6 seconds). Obviously size matters but shouldn?t load all
>     items (CSS,
>     >     JS, images) almost at the same time? Webpagetest shows it?s
>     not the
>     >     case.
>     >
>     >       I have tried to use together with Varnish other plugin
>     caches as W3
>     >     Total Cache but the performance is even worse.
>     >
>     >       Maybe my assumptions are wrong or my VCL is wrong.
>     >
>     >       I have 4.1 as was suggested by someone from the list.
>     >
>     >      Thanks!
>     >
>     >      Miguel
>     >
>     >     my default.vcl:
>     >
>     >     #
>     >     # This is an example VCL file for Varnish.
>     >     #
>     >     # It does not do anything by default, delegating control to the
>     >     # builtin VCL. The builtin VCL is called when there is no explicit
>     >     # return statement.
>     >     #
>     >     # See the VCL chapters in the Users Guide at
>     >     https://www.varnish-cache.org/docs/
>     >     <https://www.varnish-cache.org/docs/>
>     >     # and http://varnish-cache.org/trac/wiki/VCLExamples
>     >     <http://varnish-cache.org/trac/wiki/VCLExamples> for more
>     examples.
>     >
>     >     # Marker to tell the VCL compiler that this VCL has been
>     adapted to the
>     >     # new 4.0 format.
>     >     vcl 4.0;
>     >
>     >     import std;
>     >
>     >     # Default backend definition. Set this to point to your
>     content server.
>     >     backend default {
>     >         .host = "127.0.0.1";
>     >         .port = "82";
>     >         .connect_timeout = 600s;
>     >         .first_byte_timeout = 600s;
>     >         .between_bytes_timeout = 600s;
>     >
>     >
>     >     }
>     >
>     >     acl purge {
>     >             "localhost";
>     >             "127.0.0.1";
>     >     }
>     >
>     >
>     >     # This function is used when a request is send by a HTTP client
>     >     (Browser)
>     >     sub vcl_recv {
>     >
>     >             # remove ?ver=xxxxx strings from urls so css and js
>     files are
>     >     cached.
>     >             # Watch out when upgrading WordPress, need to restart
>     Varnish or
>     >     flush cache.
>     >             set req.url = regsub(req.url, "\?ver=.*$", "");
>     >
>     >             # Remove "replytocom" from requests to make caching
>     better.
>     >             set req.url = regsub(req.url, "\?replytocom=.*$", "");
>     >
>     >             #We pass real IP and Port to the backend
>     >
>     >             if (req.http.X-Forwarded-Proto == "https" ) {
>     >                set req.http.X-Port = "443";
>     >             } else {
>     >                set req.http.X-Port = "80";
>     >             }
>     >
>     >             set req.http.X-Forwarded-For =
>     regsub(req.http.X-Forwarded-For,
>     >     "^([^,]+),?.*$", "\1");
>     >
>     >
>     >             # Normalize the header, remove the port (in case
>     you're testing
>     >     this on various TCP ports)
>     >
>     >             set req.http.Host = regsub(req.http.Host, ":[0-9]+", "");
>     >
>     >             # Remove has_js and CloudFlare/Google Analytics __*
>     cookies.
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", "");
>     >             # Remove a ";" prefix, if present.
>     >             set req.http.Cookie = regsub(req.http.Cookie, "^;\s*",
>     "");
>     >
>     >
>     >             # Allow purging from ACL
>     >             if (req.method == "PURGE") {
>     >                     # If not allowed then a error 405 is returned
>     >                     if (!client.ip ~ purge) {
>     >                             return(synth(405, "This IP is not
>     allowed to
>     >     send PURGE requests."));
>     >                     }
>     >                     # If allowed, do a cache_lookup -> vlc_hit() or
>     >     vlc_miss()
>     >                     return (purge);
>     >             }
>     >
>     >             # Post requests will not be cached
>     >             #if (req.http.Authorization || req.method == "POST") {
>     >             #       return (pass);
>     >             #}
>     >
>     >             # Pass anything other than GET and HEAD directly.
>     >             if (req.method != "GET" && req.method != "HEAD") {
>     >                     return( pass );
>     >             }      /* We only deal with GET and HEAD by default */
>     >
>     >
>     >             #Woocommerce don't cache :
>     >             if (req.url ~
>     >   
>      "^/(cart|my-account/*|checkout|addons|logout|lost-password|product/*)")
>     >     {
>     >               return (pass);
>     >             }
>     >
>     >             #Woocommerce add to cart pass :
>     >             if (req.url ~ "\?add-to-cart=" ) {
>     >               return (pass);
>     >             }
>     >             if (req.url ~ "/wp-cron.php" || req.url ~
>     "preview=true") {
>     >               return (pass);
>     >             }
>     >
>     >             # Woocommerce
>     >             if (req.url ~ "(cart|my-account|checkout|addons)") {
>     >               return (pass);
>     >             }
>     >             if ( req.url ~ "\?add-to-cart=" ) {
>     >               return (pass);
>     >             }
>     >
>     >
>     >             # --- WordPress specific configuration
>     >             # Did not cache the admin and login pages
>     >             if (req.url ~
>     >   
>      "nocache|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|wp-(comments-post|login|signup|activate|mail|cron)\.php|preview\=true|admin-ajax\.php|xmlrpc\.php|bb-admin|whm-server-status|server-status|control\.php|bb-login\.php|bb-reset-password\.php|register\.php")
>     >     {
>     >                 return (pass);
>     >             }
>     >
>     >             if (req.url ~ "(ajax|dynamic|custom)") {
>     >                  return(pass);
>     >             }
>     >
>     >             # Remove the "has_js" cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     "has_js=[^;]+(;
>     >     )?", "");
>     >
>     >             # Remove any Google Analytics based cookies
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     "__utm.=[^;]+(;
>     >     )?", "");
>     >
>     >             # Remove the Quant Capital cookies (added by some plugin,
>     >     all __qca)
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     "__qc.=[^;]+(;
>     >     )?", "");
>     >
>     >             # Remove the wp-settings-1 cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "wp-settings-1=[^;]+(; )?", "");
>     >
>     >             # Remove the wp-settings-time-1 cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "wp-settings-time-1=[^;]+(; )?", "");
>     >
>     >             # Remove the wp test cookie
>     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "wordpress_test_cookie=[^;]+(; )?", "");
>     >
>     >             # Are there cookies left with only spaces or that are
>     empty?
>     >             if (req.http.cookie ~ "^ *$") {
>     >                         unset req.http.cookie;
>     >             }
>     >
>     >             # Cache the following files extensions
>     >             if (req.url ~ "\.(txt|css|js|png|gif|jp(e)?g|swf|ico)") {
>     >                     unset req.http.cookie;
>     >             }
>     >
>     >             # Normalize Accept-Encoding header and compression
>     >             #
>     https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
>     >     <https://www.varnish-cache.org/docs/3.0/tutorial/vary.html>
>     >             if (req.http.Accept-Encoding) {
>     >                     # Do no compress compressed files...
>     >                     if (req.url ~
>     >     "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
>     >                                     unset req.http.Accept-Encoding;
>     >                     } elsif (req.http.Accept-Encoding ~ "gzip") {
>     >                             set req.http.Accept-Encoding = "gzip";
>     >                     } elsif (req.http.Accept-Encoding ~ "deflate") {
>     >                             set req.http.Accept-Encoding = "deflate";
>     >                     } else {
>     >                             unset req.http.Accept-Encoding;
>     >                     }
>     >             }
>     >
>     >             # Check the cookies for wordpress-specific items
>     >             if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~
>     >     "comment_") {
>     >                     return (pass);
>     >             }
>     >             if (!req.http.cookie) {
>     >                     unset req.http.cookie;
>     >             }
>     >
>     >             # --- End of WordPress specific configuration
>     >
>     >             # Did not cache HTTP authentication and HTTP Cookie
>     >             if (req.http.Authorization || req.http.Cookie) {
>     >                     # Not cacheable by default
>     >                     return (pass);
>     >             }
>     >
>     >             # Cache all others requests
>     >             return (hash);
>     >     }
>     >
>     >     sub vcl_pipe {
>     >             return (pipe);
>     >     }
>     >
>     >     sub vcl_pass {
>     >             return (fetch);
>     >     }
>     >
>     >     # The data on which the hashing will take place
>     >     sub vcl_hash {
>     >             hash_data(req.url);
>     >             if (req.http.host) {
>     >             hash_data(req.http.host);
>     >             } else {
>     >             hash_data(server.ip);
>     >             }
>     >
>     >             # If the client supports compression, keep that in a
>     >     different cache
>     >             if (req.http.Accept-Encoding) {
>     >                     hash_data(req.http.Accept-Encoding);
>     >             }
>     >
>     >             return (lookup);
>     >     }
>     >
>     >     # This function is used when a request is sent by our backend
>     (Nginx
>     >     server)
>     >     sub vcl_backend_response {
>     >             # Remove some headers we never want to see
>     >             unset beresp.http.Server;
>     >             unset beresp.http.X-Powered-By;
>     >
>     >             if (beresp.http.content-type ~
>     >     "(text|javascript|application/x-font-woff)") {
>     >               set beresp.do_gzip = true;
>     >             }
>     >
>     >             # For static content strip all backend cookies
>     >             if (bereq.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
>     >                     unset beresp.http.cookie;
>     >             }
>     >             # Don't store backend
>     >             if (bereq.url ~ "wp-(login|admin)" || bereq.url ~
>     >     "preview=true") {
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 30s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # Only allow cookies to be set if we're in admin area
>     >                     if (!(bereq.url ~
>     >   
>      "(wp-login|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|preview=true)"))
>     >     {
>     >                     unset beresp.http.set-cookie;
>     >             }
>     >
>     >             # don't cache response to posted requests or those with
>     >     basic auth
>     >             if ( bereq.method == "POST" ||
>     bereq.http.Authorization ) {
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 120s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # don't cache search results
>     >             if ( bereq.url ~ "\?s=" ){
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 120s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # only cache status ok
>     >             if ( beresp.status != 200 ) {
>     >                     set beresp.uncacheable = true;
>     >                     set beresp.ttl = 120s;
>     >                     return (deliver);
>     >             }
>     >
>     >             # A TTL of 24h
>     >             set beresp.ttl = 24h;
>     >             # Define the default grace period to serve cached content
>     >             #set beresp.grace = 30s;
>     >             set beresp.grace = 1h;
>     >
>     >             return (deliver);
>     >     }
>     >
>     >     # The routine when we deliver the HTTP request to the user
>     >     # Last chance to modify headers that are sent to the client
>     >     sub vcl_deliver {
>     >             if (obj.hits > 0) {
>     >                     set resp.http.X-Cache = "cached";
>     >             } else {
>     >                     set resp.http.x-Cache = "uncached";
>     >             }
>     >
>     >             # Remove some headers: PHP version
>     >             unset resp.http.X-Powered-By;
>     >
>     >             # Remove some headers: Apache version & OS
>     >             unset resp.http.Server;
>     >
>     >             # Remove some heanders: Varnish
>     >             unset resp.http.Via;
>     >             unset resp.http.X-Varnish;
>     >
>     >             return (deliver);
>     >     }
>     >
>     >     sub vcl_init {
>     >             return (ok);
>     >     }
>     >
>     >     sub vcl_fini {
>     >             return (ok);
>     >     }
>     >
>     >     _______________________________________________
>     >     varnish-misc mailing list
>     >     varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>
>     >     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     >   
>      <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>     >
>     >
>     >
>     >
>     > --
>     >
>     > Best regards,
>     >
>     > --
>     >
>     > Carlos M. Fern?ndez
>     >
>     > Enterprise Systems Manager
>     >
>     > *Saint Joseph?s University*
>     >
>     > Philadelphia PA 19131
>     >
>     > T: +1 610 660 1501
>     >
> 
> 
>     _______________________________________________
>     varnish-misc mailing list
>     varnish-misc at varnish-cache.org <mailto:varnish-misc at varnish-cache.org>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> 
> -- 
> 
> Best regards,
> 
> --
> 
> Carlos M. Fern?ndez
> 
> Enterprise Systems Manager
> 
> *Saint Joseph?s University*
> 
> Philadelphia PA 19131
> 
> T: +1 610 660 1501
> 




From miguel_3_gonzalez at yahoo.es  Fri Jan 27 09:43:10 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Fri, 27 Jan 2017 10:43:10 +0100
Subject: varnish and wordpress
In-Reply-To: <CAE7KU85LLr0Gpn9K528bDB+AWacBkhChq2UrzzW+gOYPG3EX5A@mail.gmail.com>
References: <a7e700a6-0193-4ec9-1439-48b335e34366@yahoo.es>
 <CAE7KU85+YzmJP37nEkHZU5Ta+e8FRkgOO4-T_U_dfPiO5J72tw@mail.gmail.com>
 <66c1f7c8-164c-ccef-8497-3cf44cdf80d4@yahoo.es>
 <CAE7KU87eRuNJfPB+ji7ei0PsZ9MP8bkFur3nVXkVJQQCHi0+Zw@mail.gmail.com>
 <42cea191-fde7-520b-61f8-671b54e3ec17@yahoo.es>
 <CAE7KU85LLr0Gpn9K528bDB+AWacBkhChq2UrzzW+gOYPG3EX5A@mail.gmail.com>
Message-ID: <51f33015-79f1-1e06-53b5-a5e0138d8ea3@yahoo.es>

I kept on researching and I found this:

http://serverfault.com/questions/780590/inconsistent-cache-and-expires-headers-pragmanocache/

The last answer mentions an add-headers plugin, but this one is deprecated.

I will explore the php_set path or using wp-config.php just for one
website before thinking of making the change system wide.

Regards,

Miguel


On 01/27/17 1:08 AM, Carlos Fernandez wrote:
> I think you could do that through the php_set command or its analog in
> Nginx (we use Apache). Those settings can also be modified on a per
> session basis through PHP functions so that an application could control
> it (WordPress doesn't), so you could in theory put them in
> wp-config.php. You do have to set cache_limiter first, otherwise PHP
> will ignore the expiration time setting. The idea here is that it's PHP
> that generates the Expires and Cache-Control headers when a backend
> request goes to WordPress, not the web server (Apache/Nginx/IIS/etc).
> 
> 
> On Thu, Jan 26, 2017 at 18:33 Miguel Gonz?lez
> <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>> wrote:
> 
>     thanks for this information.
> 
>     Wouldn?t it help just setting in .htaccess:
> 
>     ExpiresByType text/html "access 1 month"
> 
>     ?
> 
>     Miguel
> 
> 
> 
>     On 01/26/17 10:42 PM, Carlos Fernandez wrote:
>     > Per php.net <http://php.net> <http://php.net>:
>     >
>     > "The cache limiter defines which cache control HTTP headers are
>     sent to
>     > the client. These headers determine the rules by which the page
>     content
>     > may be cached by the client and intermediate proxies. Setting the
>     cache
>     > limiter to /nocache/disallows any client/proxy caching. A value
>     > of /public/ permits caching by proxies and the client,
>     > whereas /private/ disallows caching by proxies and permits the
>     client to
>     > cache the contents."
>     >
>     > Varnish obeys the cache control headers in the backend response,
>     > therefore this setting (and cache_expires) indirectly affects
>     Varnish by
>     > way of the headers. You could alter them in VCL, but that takes
>     more work.
>     >
>     >
>     > On Thu, Jan 26, 2017 at 16:29 Miguel Gonz?lez
>     > <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>
>     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>>> wrote:
>     >
>     >     What is the relation of this setting with Varnish? I?m not
>     finding any
>     >     information about this setting and Varnish.
>     >
>     >     Thanks!
>     >
>     >     Miguel
>     >
>     >
>     >     On 01/26/17 9:22 PM, Carlos Fernandez wrote:
>     >     > That VCL looks similar to what we use. What does the
>     >     > "session.cache_limiter" setting in your php.ini file say? If
>     it's
>     >     set to
>     >     > "nocache" (the default), then PHP will always respond with
>     an Expires
>     >     > header set in the past so that Varnish will not cache it.
>     >     >
>     >     > On Thu, Jan 26, 2017 at 2:25 PM, Miguel Gonz?lez
>     >     > <miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>
>     <mailto:miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>>
>     >     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>
>     >     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>>>> wrote:
>     >     >
>     >     >     Dear all,
>     >     >
>     >     >       Probably since I?m a newbie I assume a cache system
>     makes a
>     >     "static"
>     >     >     copy of a web and serve it to the browser. I have several
>     >     Wordpress
>     >     >     sites, same backend and speed load differs quite much
>     (from 1
>     >     second to
>     >     >     6 seconds). Obviously size matters but shouldn?t load all
>     >     items (CSS,
>     >     >     JS, images) almost at the same time? Webpagetest shows it?s
>     >     not the
>     >     >     case.
>     >     >
>     >     >       I have tried to use together with Varnish other plugin
>     >     caches as W3
>     >     >     Total Cache but the performance is even worse.
>     >     >
>     >     >       Maybe my assumptions are wrong or my VCL is wrong.
>     >     >
>     >     >       I have 4.1 as was suggested by someone from the list.
>     >     >
>     >     >      Thanks!
>     >     >
>     >     >      Miguel
>     >     >
>     >     >     my default.vcl:
>     >     >
>     >     >     #
>     >     >     # This is an example VCL file for Varnish.
>     >     >     #
>     >     >     # It does not do anything by default, delegating control
>     to the
>     >     >     # builtin VCL. The builtin VCL is called when there is
>     no explicit
>     >     >     # return statement.
>     >     >     #
>     >     >     # See the VCL chapters in the Users Guide at
>     >     >     https://www.varnish-cache.org/docs/
>     >     >     <https://www.varnish-cache.org/docs/>
>     >     >     # and http://varnish-cache.org/trac/wiki/VCLExamples
>     >     >     <http://varnish-cache.org/trac/wiki/VCLExamples> for more
>     >     examples.
>     >     >
>     >     >     # Marker to tell the VCL compiler that this VCL has been
>     >     adapted to the
>     >     >     # new 4.0 format.
>     >     >     vcl 4.0;
>     >     >
>     >     >     import std;
>     >     >
>     >     >     # Default backend definition. Set this to point to your
>     >     content server.
>     >     >     backend default {
>     >     >         .host = "127.0.0.1";
>     >     >         .port = "82";
>     >     >         .connect_timeout = 600s;
>     >     >         .first_byte_timeout = 600s;
>     >     >         .between_bytes_timeout = 600s;
>     >     >
>     >     >
>     >     >     }
>     >     >
>     >     >     acl purge {
>     >     >             "localhost";
>     >     >             "127.0.0.1";
>     >     >     }
>     >     >
>     >     >
>     >     >     # This function is used when a request is send by a HTTP
>     client
>     >     >     (Browser)
>     >     >     sub vcl_recv {
>     >     >
>     >     >             # remove ?ver=xxxxx strings from urls so css and js
>     >     files are
>     >     >     cached.
>     >     >             # Watch out when upgrading WordPress, need to
>     restart
>     >     Varnish or
>     >     >     flush cache.
>     >     >             set req.url = regsub(req.url, "\?ver=.*$", "");
>     >     >
>     >     >             # Remove "replytocom" from requests to make caching
>     >     better.
>     >     >             set req.url = regsub(req.url,
>     "\?replytocom=.*$", "");
>     >     >
>     >     >             #We pass real IP and Port to the backend
>     >     >
>     >     >             if (req.http.X-Forwarded-Proto == "https" ) {
>     >     >                set req.http.X-Port = "443";
>     >     >             } else {
>     >     >                set req.http.X-Port = "80";
>     >     >             }
>     >     >
>     >     >             set req.http.X-Forwarded-For =
>     >     regsub(req.http.X-Forwarded-For,
>     >     >     "^([^,]+),?.*$", "\1");
>     >     >
>     >     >
>     >     >             # Normalize the header, remove the port (in case
>     >     you're testing
>     >     >     this on various TCP ports)
>     >     >
>     >     >             set req.http.Host = regsub(req.http.Host,
>     ":[0-9]+", "");
>     >     >
>     >     >             # Remove has_js and CloudFlare/Google Analytics __*
>     >     cookies.
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", "");
>     >     >             # Remove a ";" prefix, if present.
>     >     >             set req.http.Cookie = regsub(req.http.Cookie,
>     "^;\s*",
>     >     "");
>     >     >
>     >     >
>     >     >             # Allow purging from ACL
>     >     >             if (req.method == "PURGE") {
>     >     >                     # If not allowed then a error 405 is
>     returned
>     >     >                     if (!client.ip ~ purge) {
>     >     >                             return(synth(405, "This IP is not
>     >     allowed to
>     >     >     send PURGE requests."));
>     >     >                     }
>     >     >                     # If allowed, do a cache_lookup ->
>     vlc_hit() or
>     >     >     vlc_miss()
>     >     >                     return (purge);
>     >     >             }
>     >     >
>     >     >             # Post requests will not be cached
>     >     >             #if (req.http.Authorization || req.method ==
>     "POST") {
>     >     >             #       return (pass);
>     >     >             #}
>     >     >
>     >     >             # Pass anything other than GET and HEAD directly.
>     >     >             if (req.method != "GET" && req.method != "HEAD") {
>     >     >                     return( pass );
>     >     >             }      /* We only deal with GET and HEAD by
>     default */
>     >     >
>     >     >
>     >     >             #Woocommerce don't cache :
>     >     >             if (req.url ~
>     >     >
>     >     
>     "^/(cart|my-account/*|checkout|addons|logout|lost-password|product/*)")
>     >     >     {
>     >     >               return (pass);
>     >     >             }
>     >     >
>     >     >             #Woocommerce add to cart pass :
>     >     >             if (req.url ~ "\?add-to-cart=" ) {
>     >     >               return (pass);
>     >     >             }
>     >     >             if (req.url ~ "/wp-cron.php" || req.url ~
>     >     "preview=true") {
>     >     >               return (pass);
>     >     >             }
>     >     >
>     >     >             # Woocommerce
>     >     >             if (req.url ~ "(cart|my-account|checkout|addons)") {
>     >     >               return (pass);
>     >     >             }
>     >     >             if ( req.url ~ "\?add-to-cart=" ) {
>     >     >               return (pass);
>     >     >             }
>     >     >
>     >     >
>     >     >             # --- WordPress specific configuration
>     >     >             # Did not cache the admin and login pages
>     >     >             if (req.url ~
>     >     >
>     >     
>     "nocache|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|wp-(comments-post|login|signup|activate|mail|cron)\.php|preview\=true|admin-ajax\.php|xmlrpc\.php|bb-admin|whm-server-status|server-status|control\.php|bb-login\.php|bb-reset-password\.php|register\.php")
>     >     >     {
>     >     >                 return (pass);
>     >     >             }
>     >     >
>     >     >             if (req.url ~ "(ajax|dynamic|custom)") {
>     >     >                  return(pass);
>     >     >             }
>     >     >
>     >     >             # Remove the "has_js" cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "has_js=[^;]+(;
>     >     >     )?", "");
>     >     >
>     >     >             # Remove any Google Analytics based cookies
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "__utm.=[^;]+(;
>     >     >     )?", "");
>     >     >
>     >     >             # Remove the Quant Capital cookies (added by
>     some plugin,
>     >     >     all __qca)
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "__qc.=[^;]+(;
>     >     >     )?", "");
>     >     >
>     >     >             # Remove the wp-settings-1 cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "wp-settings-1=[^;]+(; )?", "");
>     >     >
>     >     >             # Remove the wp-settings-time-1 cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "wp-settings-time-1=[^;]+(; )?", "");
>     >     >
>     >     >             # Remove the wp test cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "wordpress_test_cookie=[^;]+(; )?", "");
>     >     >
>     >     >             # Are there cookies left with only spaces or
>     that are
>     >     empty?
>     >     >             if (req.http.cookie ~ "^ *$") {
>     >     >                         unset req.http.cookie;
>     >     >             }
>     >     >
>     >     >             # Cache the following files extensions
>     >     >             if (req.url ~
>     "\.(txt|css|js|png|gif|jp(e)?g|swf|ico)") {
>     >     >                     unset req.http.cookie;
>     >     >             }
>     >     >
>     >     >             # Normalize Accept-Encoding header and compression
>     >     >             #
>     >     https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
>     >     >     <https://www.varnish-cache.org/docs/3.0/tutorial/vary.html>
>     >     >             if (req.http.Accept-Encoding) {
>     >     >                     # Do no compress compressed files...
>     >     >                     if (req.url ~
>     >     >     "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
>     >     >                                     unset
>     req.http.Accept-Encoding;
>     >     >                     } elsif (req.http.Accept-Encoding ~
>     "gzip") {
>     >     >                             set req.http.Accept-Encoding =
>     "gzip";
>     >     >                     } elsif (req.http.Accept-Encoding ~
>     "deflate") {
>     >     >                             set req.http.Accept-Encoding =
>     "deflate";
>     >     >                     } else {
>     >     >                             unset req.http.Accept-Encoding;
>     >     >                     }
>     >     >             }
>     >     >
>     >     >             # Check the cookies for wordpress-specific items
>     >     >             if (req.http.Cookie ~ "wordpress_" ||
>     req.http.Cookie ~
>     >     >     "comment_") {
>     >     >                     return (pass);
>     >     >             }
>     >     >             if (!req.http.cookie) {
>     >     >                     unset req.http.cookie;
>     >     >             }
>     >     >
>     >     >             # --- End of WordPress specific configuration
>     >     >
>     >     >             # Did not cache HTTP authentication and HTTP Cookie
>     >     >             if (req.http.Authorization || req.http.Cookie) {
>     >     >                     # Not cacheable by default
>     >     >                     return (pass);
>     >     >             }
>     >     >
>     >     >             # Cache all others requests
>     >     >             return (hash);
>     >     >     }
>     >     >
>     >     >     sub vcl_pipe {
>     >     >             return (pipe);
>     >     >     }
>     >     >
>     >     >     sub vcl_pass {
>     >     >             return (fetch);
>     >     >     }
>     >     >
>     >     >     # The data on which the hashing will take place
>     >     >     sub vcl_hash {
>     >     >             hash_data(req.url);
>     >     >             if (req.http.host) {
>     >     >             hash_data(req.http.host);
>     >     >             } else {
>     >     >             hash_data(server.ip);
>     >     >             }
>     >     >
>     >     >             # If the client supports compression, keep that in a
>     >     >     different cache
>     >     >             if (req.http.Accept-Encoding) {
>     >     >                     hash_data(req.http.Accept-Encoding);
>     >     >             }
>     >     >
>     >     >             return (lookup);
>     >     >     }
>     >     >
>     >     >     # This function is used when a request is sent by our
>     backend
>     >     (Nginx
>     >     >     server)
>     >     >     sub vcl_backend_response {
>     >     >             # Remove some headers we never want to see
>     >     >             unset beresp.http.Server;
>     >     >             unset beresp.http.X-Powered-By;
>     >     >
>     >     >             if (beresp.http.content-type ~
>     >     >     "(text|javascript|application/x-font-woff)") {
>     >     >               set beresp.do_gzip = true;
>     >     >             }
>     >     >
>     >     >             # For static content strip all backend cookies
>     >     >             if (bereq.url ~
>     "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
>     >     >                     unset beresp.http.cookie;
>     >     >             }
>     >     >             # Don't store backend
>     >     >             if (bereq.url ~ "wp-(login|admin)" || bereq.url ~
>     >     >     "preview=true") {
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 30s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # Only allow cookies to be set if we're in admin
>     area
>     >     >                     if (!(bereq.url ~
>     >     >
>     >     
>     "(wp-login|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|preview=true)"))
>     >     >     {
>     >     >                     unset beresp.http.set-cookie;
>     >     >             }
>     >     >
>     >     >             # don't cache response to posted requests or
>     those with
>     >     >     basic auth
>     >     >             if ( bereq.method == "POST" ||
>     >     bereq.http.Authorization ) {
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 120s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # don't cache search results
>     >     >             if ( bereq.url ~ "\?s=" ){
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 120s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # only cache status ok
>     >     >             if ( beresp.status != 200 ) {
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 120s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # A TTL of 24h
>     >     >             set beresp.ttl = 24h;
>     >     >             # Define the default grace period to serve
>     cached content
>     >     >             #set beresp.grace = 30s;
>     >     >             set beresp.grace = 1h;
>     >     >
>     >     >             return (deliver);
>     >     >     }
>     >     >
>     >     >     # The routine when we deliver the HTTP request to the user
>     >     >     # Last chance to modify headers that are sent to the client
>     >     >     sub vcl_deliver {
>     >     >             if (obj.hits > 0) {
>     >     >                     set resp.http.X-Cache = "cached";
>     >     >             } else {
>     >     >                     set resp.http.x-Cache = "uncached";
>     >     >             }
>     >     >
>     >     >             # Remove some headers: PHP version
>     >     >             unset resp.http.X-Powered-By;
>     >     >
>     >     >             # Remove some headers: Apache version & OS
>     >     >             unset resp.http.Server;
>     >     >
>     >     >             # Remove some heanders: Varnish
>     >     >             unset resp.http.Via;
>     >     >             unset resp.http.X-Varnish;
>     >     >
>     >     >             return (deliver);
>     >     >     }
>     >     >
>     >     >     sub vcl_init {
>     >     >             return (ok);
>     >     >     }
>     >     >
>     >     >     sub vcl_fini {
>     >     >             return (ok);
>     >     >     }
>     >     >
>     >     >     _______________________________________________
>     >     >     varnish-misc mailing list
>     >     >     varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     >     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>
>     >     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     >     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>>
>     >     >   
>      https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     >     >
>     >     
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > --
>     >     >
>     >     > Best regards,
>     >     >
>     >     > --
>     >     >
>     >     > Carlos M. Fern?ndez
>     >     >
>     >     > Enterprise Systems Manager
>     >     >
>     >     > *Saint Joseph?s University*
>     >     >
>     >     > Philadelphia PA 19131
>     >     >
>     >     > T: +1 610 660 1501
>     >     >
>     >
>     >
>     >     _______________________________________________
>     >     varnish-misc mailing list
>     >     varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>
>     >     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     >
>     > --
>     >
>     > Best regards,
>     >
>     > --
>     >
>     > Carlos M. Fern?ndez
>     >
>     > Enterprise Systems Manager
>     >
>     > *Saint Joseph?s University*
>     >
>     > Philadelphia PA 19131
>     >
>     > T: +1 610 660 1501
>     >
> 
> 
>     _______________________________________________
>     varnish-misc mailing list
>     varnish-misc at varnish-cache.org <mailto:varnish-misc at varnish-cache.org>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> 
> -- 
> 
> Best regards,
> 
> --
> 
> Carlos M. Fern?ndez
> 
> Enterprise Systems Manager
> 
> *Saint Joseph?s University*
> 
> Philadelphia PA 19131
> 
> T: +1 610 660 1501
> 




From miguel_3_gonzalez at yahoo.es  Sun Jan 29 16:43:59 2017
From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=)
Date: Sun, 29 Jan 2017 17:43:59 +0100
Subject: varnish and wordpress
In-Reply-To: <CAE7KU85LLr0Gpn9K528bDB+AWacBkhChq2UrzzW+gOYPG3EX5A@mail.gmail.com>
References: <a7e700a6-0193-4ec9-1439-48b335e34366@yahoo.es>
 <CAE7KU85+YzmJP37nEkHZU5Ta+e8FRkgOO4-T_U_dfPiO5J72tw@mail.gmail.com>
 <66c1f7c8-164c-ccef-8497-3cf44cdf80d4@yahoo.es>
 <CAE7KU87eRuNJfPB+ji7ei0PsZ9MP8bkFur3nVXkVJQQCHi0+Zw@mail.gmail.com>
 <42cea191-fde7-520b-61f8-671b54e3ec17@yahoo.es>
 <CAE7KU85LLr0Gpn9K528bDB+AWacBkhChq2UrzzW+gOYPG3EX5A@mail.gmail.com>
Message-ID: <d98efceb-24a4-04a2-1ce5-f53554c293f6@yahoo.es>

I have enabled cache_limiter to public and I don?t see much difference
in my main website (I have added in Cpanel PHP 7.1 that setting), but
the truth is that in my main website was loading in 1 second.

Do I have to disable the expiresbytype entries in .htaccess?

Thanks,

Miguel


On 01/27/17 1:08 AM, Carlos Fernandez wrote:
> I think you could do that through the php_set command or its analog in
> Nginx (we use Apache). Those settings can also be modified on a per
> session basis through PHP functions so that an application could control
> it (WordPress doesn't), so you could in theory put them in
> wp-config.php. You do have to set cache_limiter first, otherwise PHP
> will ignore the expiration time setting. The idea here is that it's PHP
> that generates the Expires and Cache-Control headers when a backend
> request goes to WordPress, not the web server (Apache/Nginx/IIS/etc).
> 
> 
> On Thu, Jan 26, 2017 at 18:33 Miguel Gonz?lez
> <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>> wrote:
> 
>     thanks for this information.
> 
>     Wouldn?t it help just setting in .htaccess:
> 
>     ExpiresByType text/html "access 1 month"
> 
>     ?
> 
>     Miguel
> 
> 
> 
>     On 01/26/17 10:42 PM, Carlos Fernandez wrote:
>     > Per php.net <http://php.net> <http://php.net>:
>     >
>     > "The cache limiter defines which cache control HTTP headers are
>     sent to
>     > the client. These headers determine the rules by which the page
>     content
>     > may be cached by the client and intermediate proxies. Setting the
>     cache
>     > limiter to /nocache/disallows any client/proxy caching. A value
>     > of /public/ permits caching by proxies and the client,
>     > whereas /private/ disallows caching by proxies and permits the
>     client to
>     > cache the contents."
>     >
>     > Varnish obeys the cache control headers in the backend response,
>     > therefore this setting (and cache_expires) indirectly affects
>     Varnish by
>     > way of the headers. You could alter them in VCL, but that takes
>     more work.
>     >
>     >
>     > On Thu, Jan 26, 2017 at 16:29 Miguel Gonz?lez
>     > <miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>
>     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>>> wrote:
>     >
>     >     What is the relation of this setting with Varnish? I?m not
>     finding any
>     >     information about this setting and Varnish.
>     >
>     >     Thanks!
>     >
>     >     Miguel
>     >
>     >
>     >     On 01/26/17 9:22 PM, Carlos Fernandez wrote:
>     >     > That VCL looks similar to what we use. What does the
>     >     > "session.cache_limiter" setting in your php.ini file say? If
>     it's
>     >     set to
>     >     > "nocache" (the default), then PHP will always respond with
>     an Expires
>     >     > header set in the past so that Varnish will not cache it.
>     >     >
>     >     > On Thu, Jan 26, 2017 at 2:25 PM, Miguel Gonz?lez
>     >     > <miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>
>     <mailto:miguel_3_gonzalez at yahoo.es <mailto:miguel_3_gonzalez at yahoo.es>>
>     >     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>
>     >     <mailto:miguel_3_gonzalez at yahoo.es
>     <mailto:miguel_3_gonzalez at yahoo.es>>>> wrote:
>     >     >
>     >     >     Dear all,
>     >     >
>     >     >       Probably since I?m a newbie I assume a cache system
>     makes a
>     >     "static"
>     >     >     copy of a web and serve it to the browser. I have several
>     >     Wordpress
>     >     >     sites, same backend and speed load differs quite much
>     (from 1
>     >     second to
>     >     >     6 seconds). Obviously size matters but shouldn?t load all
>     >     items (CSS,
>     >     >     JS, images) almost at the same time? Webpagetest shows it?s
>     >     not the
>     >     >     case.
>     >     >
>     >     >       I have tried to use together with Varnish other plugin
>     >     caches as W3
>     >     >     Total Cache but the performance is even worse.
>     >     >
>     >     >       Maybe my assumptions are wrong or my VCL is wrong.
>     >     >
>     >     >       I have 4.1 as was suggested by someone from the list.
>     >     >
>     >     >      Thanks!
>     >     >
>     >     >      Miguel
>     >     >
>     >     >     my default.vcl:
>     >     >
>     >     >     #
>     >     >     # This is an example VCL file for Varnish.
>     >     >     #
>     >     >     # It does not do anything by default, delegating control
>     to the
>     >     >     # builtin VCL. The builtin VCL is called when there is
>     no explicit
>     >     >     # return statement.
>     >     >     #
>     >     >     # See the VCL chapters in the Users Guide at
>     >     >     https://www.varnish-cache.org/docs/
>     >     >     <https://www.varnish-cache.org/docs/>
>     >     >     # and http://varnish-cache.org/trac/wiki/VCLExamples
>     >     >     <http://varnish-cache.org/trac/wiki/VCLExamples> for more
>     >     examples.
>     >     >
>     >     >     # Marker to tell the VCL compiler that this VCL has been
>     >     adapted to the
>     >     >     # new 4.0 format.
>     >     >     vcl 4.0;
>     >     >
>     >     >     import std;
>     >     >
>     >     >     # Default backend definition. Set this to point to your
>     >     content server.
>     >     >     backend default {
>     >     >         .host = "127.0.0.1";
>     >     >         .port = "82";
>     >     >         .connect_timeout = 600s;
>     >     >         .first_byte_timeout = 600s;
>     >     >         .between_bytes_timeout = 600s;
>     >     >
>     >     >
>     >     >     }
>     >     >
>     >     >     acl purge {
>     >     >             "localhost";
>     >     >             "127.0.0.1";
>     >     >     }
>     >     >
>     >     >
>     >     >     # This function is used when a request is send by a HTTP
>     client
>     >     >     (Browser)
>     >     >     sub vcl_recv {
>     >     >
>     >     >             # remove ?ver=xxxxx strings from urls so css and js
>     >     files are
>     >     >     cached.
>     >     >             # Watch out when upgrading WordPress, need to
>     restart
>     >     Varnish or
>     >     >     flush cache.
>     >     >             set req.url = regsub(req.url, "\?ver=.*$", "");
>     >     >
>     >     >             # Remove "replytocom" from requests to make caching
>     >     better.
>     >     >             set req.url = regsub(req.url,
>     "\?replytocom=.*$", "");
>     >     >
>     >     >             #We pass real IP and Port to the backend
>     >     >
>     >     >             if (req.http.X-Forwarded-Proto == "https" ) {
>     >     >                set req.http.X-Port = "443";
>     >     >             } else {
>     >     >                set req.http.X-Port = "80";
>     >     >             }
>     >     >
>     >     >             set req.http.X-Forwarded-For =
>     >     regsub(req.http.X-Forwarded-For,
>     >     >     "^([^,]+),?.*$", "\1");
>     >     >
>     >     >
>     >     >             # Normalize the header, remove the port (in case
>     >     you're testing
>     >     >     this on various TCP ports)
>     >     >
>     >     >             set req.http.Host = regsub(req.http.Host,
>     ":[0-9]+", "");
>     >     >
>     >     >             # Remove has_js and CloudFlare/Google Analytics __*
>     >     cookies.
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", "");
>     >     >             # Remove a ";" prefix, if present.
>     >     >             set req.http.Cookie = regsub(req.http.Cookie,
>     "^;\s*",
>     >     "");
>     >     >
>     >     >
>     >     >             # Allow purging from ACL
>     >     >             if (req.method == "PURGE") {
>     >     >                     # If not allowed then a error 405 is
>     returned
>     >     >                     if (!client.ip ~ purge) {
>     >     >                             return(synth(405, "This IP is not
>     >     allowed to
>     >     >     send PURGE requests."));
>     >     >                     }
>     >     >                     # If allowed, do a cache_lookup ->
>     vlc_hit() or
>     >     >     vlc_miss()
>     >     >                     return (purge);
>     >     >             }
>     >     >
>     >     >             # Post requests will not be cached
>     >     >             #if (req.http.Authorization || req.method ==
>     "POST") {
>     >     >             #       return (pass);
>     >     >             #}
>     >     >
>     >     >             # Pass anything other than GET and HEAD directly.
>     >     >             if (req.method != "GET" && req.method != "HEAD") {
>     >     >                     return( pass );
>     >     >             }      /* We only deal with GET and HEAD by
>     default */
>     >     >
>     >     >
>     >     >             #Woocommerce don't cache :
>     >     >             if (req.url ~
>     >     >
>     >     
>     "^/(cart|my-account/*|checkout|addons|logout|lost-password|product/*)")
>     >     >     {
>     >     >               return (pass);
>     >     >             }
>     >     >
>     >     >             #Woocommerce add to cart pass :
>     >     >             if (req.url ~ "\?add-to-cart=" ) {
>     >     >               return (pass);
>     >     >             }
>     >     >             if (req.url ~ "/wp-cron.php" || req.url ~
>     >     "preview=true") {
>     >     >               return (pass);
>     >     >             }
>     >     >
>     >     >             # Woocommerce
>     >     >             if (req.url ~ "(cart|my-account|checkout|addons)") {
>     >     >               return (pass);
>     >     >             }
>     >     >             if ( req.url ~ "\?add-to-cart=" ) {
>     >     >               return (pass);
>     >     >             }
>     >     >
>     >     >
>     >     >             # --- WordPress specific configuration
>     >     >             # Did not cache the admin and login pages
>     >     >             if (req.url ~
>     >     >
>     >     
>     "nocache|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|wp-(comments-post|login|signup|activate|mail|cron)\.php|preview\=true|admin-ajax\.php|xmlrpc\.php|bb-admin|whm-server-status|server-status|control\.php|bb-login\.php|bb-reset-password\.php|register\.php")
>     >     >     {
>     >     >                 return (pass);
>     >     >             }
>     >     >
>     >     >             if (req.url ~ "(ajax|dynamic|custom)") {
>     >     >                  return(pass);
>     >     >             }
>     >     >
>     >     >             # Remove the "has_js" cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "has_js=[^;]+(;
>     >     >     )?", "");
>     >     >
>     >     >             # Remove any Google Analytics based cookies
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "__utm.=[^;]+(;
>     >     >     )?", "");
>     >     >
>     >     >             # Remove the Quant Capital cookies (added by
>     some plugin,
>     >     >     all __qca)
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     "__qc.=[^;]+(;
>     >     >     )?", "");
>     >     >
>     >     >             # Remove the wp-settings-1 cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "wp-settings-1=[^;]+(; )?", "");
>     >     >
>     >     >             # Remove the wp-settings-time-1 cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "wp-settings-time-1=[^;]+(; )?", "");
>     >     >
>     >     >             # Remove the wp test cookie
>     >     >             set req.http.Cookie = regsuball(req.http.Cookie,
>     >     >     "wordpress_test_cookie=[^;]+(; )?", "");
>     >     >
>     >     >             # Are there cookies left with only spaces or
>     that are
>     >     empty?
>     >     >             if (req.http.cookie ~ "^ *$") {
>     >     >                         unset req.http.cookie;
>     >     >             }
>     >     >
>     >     >             # Cache the following files extensions
>     >     >             if (req.url ~
>     "\.(txt|css|js|png|gif|jp(e)?g|swf|ico)") {
>     >     >                     unset req.http.cookie;
>     >     >             }
>     >     >
>     >     >             # Normalize Accept-Encoding header and compression
>     >     >             #
>     >     https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
>     >     >     <https://www.varnish-cache.org/docs/3.0/tutorial/vary.html>
>     >     >             if (req.http.Accept-Encoding) {
>     >     >                     # Do no compress compressed files...
>     >     >                     if (req.url ~
>     >     >     "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
>     >     >                                     unset
>     req.http.Accept-Encoding;
>     >     >                     } elsif (req.http.Accept-Encoding ~
>     "gzip") {
>     >     >                             set req.http.Accept-Encoding =
>     "gzip";
>     >     >                     } elsif (req.http.Accept-Encoding ~
>     "deflate") {
>     >     >                             set req.http.Accept-Encoding =
>     "deflate";
>     >     >                     } else {
>     >     >                             unset req.http.Accept-Encoding;
>     >     >                     }
>     >     >             }
>     >     >
>     >     >             # Check the cookies for wordpress-specific items
>     >     >             if (req.http.Cookie ~ "wordpress_" ||
>     req.http.Cookie ~
>     >     >     "comment_") {
>     >     >                     return (pass);
>     >     >             }
>     >     >             if (!req.http.cookie) {
>     >     >                     unset req.http.cookie;
>     >     >             }
>     >     >
>     >     >             # --- End of WordPress specific configuration
>     >     >
>     >     >             # Did not cache HTTP authentication and HTTP Cookie
>     >     >             if (req.http.Authorization || req.http.Cookie) {
>     >     >                     # Not cacheable by default
>     >     >                     return (pass);
>     >     >             }
>     >     >
>     >     >             # Cache all others requests
>     >     >             return (hash);
>     >     >     }
>     >     >
>     >     >     sub vcl_pipe {
>     >     >             return (pipe);
>     >     >     }
>     >     >
>     >     >     sub vcl_pass {
>     >     >             return (fetch);
>     >     >     }
>     >     >
>     >     >     # The data on which the hashing will take place
>     >     >     sub vcl_hash {
>     >     >             hash_data(req.url);
>     >     >             if (req.http.host) {
>     >     >             hash_data(req.http.host);
>     >     >             } else {
>     >     >             hash_data(server.ip);
>     >     >             }
>     >     >
>     >     >             # If the client supports compression, keep that in a
>     >     >     different cache
>     >     >             if (req.http.Accept-Encoding) {
>     >     >                     hash_data(req.http.Accept-Encoding);
>     >     >             }
>     >     >
>     >     >             return (lookup);
>     >     >     }
>     >     >
>     >     >     # This function is used when a request is sent by our
>     backend
>     >     (Nginx
>     >     >     server)
>     >     >     sub vcl_backend_response {
>     >     >             # Remove some headers we never want to see
>     >     >             unset beresp.http.Server;
>     >     >             unset beresp.http.X-Powered-By;
>     >     >
>     >     >             if (beresp.http.content-type ~
>     >     >     "(text|javascript|application/x-font-woff)") {
>     >     >               set beresp.do_gzip = true;
>     >     >             }
>     >     >
>     >     >             # For static content strip all backend cookies
>     >     >             if (bereq.url ~
>     "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
>     >     >                     unset beresp.http.cookie;
>     >     >             }
>     >     >             # Don't store backend
>     >     >             if (bereq.url ~ "wp-(login|admin)" || bereq.url ~
>     >     >     "preview=true") {
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 30s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # Only allow cookies to be set if we're in admin
>     area
>     >     >                     if (!(bereq.url ~
>     >     >
>     >     
>     "(wp-login|cart|my-account|checkout|addons|tienda|mi-cuenta|carro|producto/*|login|wp-admin|preview=true)"))
>     >     >     {
>     >     >                     unset beresp.http.set-cookie;
>     >     >             }
>     >     >
>     >     >             # don't cache response to posted requests or
>     those with
>     >     >     basic auth
>     >     >             if ( bereq.method == "POST" ||
>     >     bereq.http.Authorization ) {
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 120s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # don't cache search results
>     >     >             if ( bereq.url ~ "\?s=" ){
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 120s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # only cache status ok
>     >     >             if ( beresp.status != 200 ) {
>     >     >                     set beresp.uncacheable = true;
>     >     >                     set beresp.ttl = 120s;
>     >     >                     return (deliver);
>     >     >             }
>     >     >
>     >     >             # A TTL of 24h
>     >     >             set beresp.ttl = 24h;
>     >     >             # Define the default grace period to serve
>     cached content
>     >     >             #set beresp.grace = 30s;
>     >     >             set beresp.grace = 1h;
>     >     >
>     >     >             return (deliver);
>     >     >     }
>     >     >
>     >     >     # The routine when we deliver the HTTP request to the user
>     >     >     # Last chance to modify headers that are sent to the client
>     >     >     sub vcl_deliver {
>     >     >             if (obj.hits > 0) {
>     >     >                     set resp.http.X-Cache = "cached";
>     >     >             } else {
>     >     >                     set resp.http.x-Cache = "uncached";
>     >     >             }
>     >     >
>     >     >             # Remove some headers: PHP version
>     >     >             unset resp.http.X-Powered-By;
>     >     >
>     >     >             # Remove some headers: Apache version & OS
>     >     >             unset resp.http.Server;
>     >     >
>     >     >             # Remove some heanders: Varnish
>     >     >             unset resp.http.Via;
>     >     >             unset resp.http.X-Varnish;
>     >     >
>     >     >             return (deliver);
>     >     >     }
>     >     >
>     >     >     sub vcl_init {
>     >     >             return (ok);
>     >     >     }
>     >     >
>     >     >     sub vcl_fini {
>     >     >             return (ok);
>     >     >     }
>     >     >
>     >     >     _______________________________________________
>     >     >     varnish-misc mailing list
>     >     >     varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     >     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>
>     >     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     >     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>>
>     >     >   
>      https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     >     >
>     >     
>     <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > --
>     >     >
>     >     > Best regards,
>     >     >
>     >     > --
>     >     >
>     >     > Carlos M. Fern?ndez
>     >     >
>     >     > Enterprise Systems Manager
>     >     >
>     >     > *Saint Joseph?s University*
>     >     >
>     >     > Philadelphia PA 19131
>     >     >
>     >     > T: +1 610 660 1501
>     >     >
>     >
>     >
>     >     _______________________________________________
>     >     varnish-misc mailing list
>     >     varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>
>     <mailto:varnish-misc at varnish-cache.org
>     <mailto:varnish-misc at varnish-cache.org>>
>     >     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>     >
>     > --
>     >
>     > Best regards,
>     >
>     > --
>     >
>     > Carlos M. Fern?ndez
>     >
>     > Enterprise Systems Manager
>     >
>     > *Saint Joseph?s University*
>     >
>     > Philadelphia PA 19131
>     >
>     > T: +1 610 660 1501
>     >
> 
> 
>     _______________________________________________
>     varnish-misc mailing list
>     varnish-misc at varnish-cache.org <mailto:varnish-misc at varnish-cache.org>
>     https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> 
> -- 
> 
> Best regards,
> 
> --
> 
> Carlos M. Fern?ndez
> 
> Enterprise Systems Manager
> 
> *Saint Joseph?s University*
> 
> Philadelphia PA 19131
> 
> T: +1 610 660 1501
>