Mailing List Archive

Problems with purging /.
Hi,

I have a problem purging the / pages on a varnish installation.

I have configured the following in varnish.vcl

sub vcl_hit {
if (req.request == "PURGE") {
set obj.ttl = 0s;
error 200 "Purged.";
} else {
deliver;
}
}

and

sub vcl_timeout{
discard;
}


When I try to purge an url via the http-call it works nicely for everyting execpt the / (for example the front page).

The call I send to varnish is constructed like this:

# telnet varnish 80
PURGE / HTTP/1.0
Host: www.somedomain.no

And the response it gives is this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<TITLE>200 OK</TITLE>
</HEAD>
<BODY>
<H1>Error 200 OK</H1>
<P>Purged.</P>
<H3>Guru Meditation:</H3>
<P>XID: 326200233</P>
<I><A href="http://varnish.linpro.no/">Varnish</A></I>
</BODY>
</HTML>

I get the same result if i try to purge another url like this:

PURGE /somefolder/somearticle.ece HTTP/1.0
Host: www.somedomain.no

The domainnames and url's have been changed to hide the sites identity

--

Thomas Westlund
Aftenposten AS, UNIX/nettverksavd.
Postboks 1, 0051 Oslo
Tlf: +47 98 20 30 33
Fax: +47 22 86 40 74
Problems with purging /. [ In reply to ]
In message <20070425121016.GA17668 at aftenposten.no>, Thomas Westlund writes:
>Hi,
>
>I have a problem purging the / pages on a varnish installation.
>
>I have configured the following in varnish.vcl

Uhm, the PURGE request gets the "200" answer you quote from
the:
error 200 "Purged.";

What makes you think the object is not purged ?


--
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.
Problems with purging /. [ In reply to ]
Thomas Westlund <thomas.westlund at aftenposten.no> writes:
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <HTML>
> <HEAD>
> <TITLE>200 OK</TITLE>
> </HEAD>
> <BODY>
> <H1>Error 200 OK</H1>
> <P>Purged.</P>
> <H3>Guru Meditation:</H3>
> <P>XID: 326200233</P>
> <I><A href="http://varnish.linpro.no/">Varnish</A></I>
> </BODY>
> </HTML>

We need to see the Varnish log for this transaction.

Run 'varnishlog -w /tmp/varnish.log' on the server. Send a request
that triggers the bug, then wait a few seconds and stop varnishlog.
You can then extract the relevant entry like this:

# varnishlog -r /tmp/varnish.log -c -o ReqStart XID

where XID is the number shown in the error message (e.g. 326200233).

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Problems with purging /. [ In reply to ]
Hi,

On Wed, Apr 25, 2007 at 12:15:17PM +0000, Poul-Henning Kamp wrote:
> Uhm, the PURGE request gets the "200" answer you quote from
> the:
> error 200 "Purged.";
>
> What makes you think the object is not purged ?

If I update for example the front page on the backend and run the purge-routine for / as I discribed earlier,the document is not updated when I test it via the cache,
but it is when I access it directly on the backend.

--

Thomas Westlund
Aftenposten AS, UNIX/nettverksavd.
Postboks 1, 0051 Oslo
Tlf: +47 98 20 30 33
Fax: +47 22 86 40 74
Problems with purging /. [ In reply to ]
Hi,

On Wed, Apr 25, 2007 at 02:20:13PM +0200, Dag-Erling Sm?rgrav wrote:
> Thomas Westlund <thomas.westlund at aftenposten.no> writes:
> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> > <HTML>
> > <HEAD>
> > <TITLE>200 OK</TITLE>
> > </HEAD>
> > <BODY>
> > <H1>Error 200 OK</H1>
> > <P>Purged.</P>
> > <H3>Guru Meditation:</H3>
> > <P>XID: 326200233</P>
> > <I><A href="http://varnish.linpro.no/">Varnish</A></I>
> > </BODY>
> > </HTML>
>
> We need to see the Varnish log for this transaction.
This is the output:

329 SessionOpen c **.**.**.** 63375
329 VCL_acl c MATCH purge "**.**.**.**"/32
329 SessionClose c Purged.
329 ReqStart c **.**.**.** 63375 326308940
329 RxRequest c PURGE
329 RxURL c /
329 RxProtocol c HTTP/1.0
329 RxHeader c Host: www.**.no
329 VCL_call c recv lookup
329 Hit c 326307698
329 VCL_call c hit
329 TTL c 326307698 VCL 0 1177506682
329 VCL_return c error
329 TxStatus c 200
329 TxProtocol c HTTP/1.1
329 TxResponse c OK
329 Req

IPs and hostnames are changed to preserver privacy.

Iv'e already checked the logs to see what happens, as far as I'm able to se it works as it should,
but the / pages are stil not updated when I try to acesss them via the cache, but they are on the backend-server.

--

Thomas Westlund
Aftenposten AS, UNIX/nettverksavd.
Postboks 1, 0051 Oslo
Tlf: +47 98 20 30 33
Fax: +47 22 86 40 74
Problems with purging /. [ In reply to ]
In message <20070425131850.GB19155 at aftenposten.no>, Thomas Westlund writes:

>This is the output:
>
> 329 SessionOpen c **.**.**.** 63375
> 329 VCL_acl c MATCH purge "**.**.**.**"/32

Just an idea: we need an "anonymous" option to varnishlog, where
all sensitive data gets replaced by random but consistent garbage.


--
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.
Problems with purging /. [ In reply to ]
In message <20070425131850.GB19155 at aftenposten.no>, Thomas Westlund writes:

>> We need to see the Varnish log for this transaction.
>This is the output:
>
> [...]
>
>IPs and hostnames are changed to preserver privacy.
>
>Iv'e already checked the logs to see what happens, as far as I'm able to se it works as it should,
>but the / pages are stil not updated when I try to acesss them via the cache, but they are on the backend-server.

What we really need to see is the log for the next GET of /

--
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.
Problems with purging /. [ In reply to ]
In message <20070425131151.GA19155 at aftenposten.no>, Thomas Westlund writes:
>Hi,
>
>On Wed, Apr 25, 2007 at 12:15:17PM +0000, Poul-Henning Kamp wrote:
>> Uhm, the PURGE request gets the "200" answer you quote from
>> the:
>> error 200 "Purged.";
>>
>> What makes you think the object is not purged ?
>
>If I update for example the front page on the backend and run the purge-routine for / as I discribed earlier,the document is not updated when I test it via the cache,
>but it is when I access it directly on the backend.

And / is not by any chance hit by a 3xx redirect ?

If it is, then you need to purge the destination instead.

--
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.
Problems with purging /. [ In reply to ]
Thomas Westlund <thomas.westlund at aftenposten.no> writes:
> This is the output:
>
> 329 SessionOpen c **.**.**.** 63375
> 329 VCL_acl c MATCH purge "**.**.**.**"/32
> 329 SessionClose c Purged.
> 329 ReqStart c **.**.**.** 63375 326308940
> 329 RxRequest c PURGE
> 329 RxURL c /
> 329 RxProtocol c HTTP/1.0
> 329 RxHeader c Host: www.**.no
> 329 VCL_call c recv lookup
> 329 Hit c 326307698
> 329 VCL_call c hit
> 329 TTL c 326307698 VCL 0 1177506682
> 329 VCL_return c error
> 329 TxStatus c 200
> 329 TxProtocol c HTTP/1.1
> 329 TxResponse c OK
> 329 Req
>
> IPs and hostnames are changed to preserver privacy.

Everything here is fine. Varnish did precisely what you asked it to
do. The error is either in your backend or your expectations...

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Problems with purging /. [ In reply to ]
Hi,

On Wed, Apr 25, 2007 at 04:08:50PM +0200, Dag-Erling Sm?rgrav wrote:
> Thomas Westlund <thomas.westlund at aftenposten.no> writes:
> > This is the output:
> >
> > 329 SessionOpen c **.**.**.** 63375
> > 329 VCL_acl c MATCH purge "**.**.**.**"/32
> > 329 SessionClose c Purged.
> > 329 ReqStart c **.**.**.** 63375 326308940
> > 329 RxRequest c PURGE
> > 329 RxURL c /
> > 329 RxProtocol c HTTP/1.0
> > 329 RxHeader c Host: www.**.no
> > 329 VCL_call c recv lookup
> > 329 Hit c 326307698
> > 329 VCL_call c hit
> > 329 TTL c 326307698 VCL 0 1177506682
> > 329 VCL_return c error
> > 329 TxStatus c 200
> > 329 TxProtocol c HTTP/1.1
> > 329 TxResponse c OK
> > 329 Req
> >
> > IPs and hostnames are changed to preserver privacy.
>
> Everything here is fine. Varnish did precisely what you asked it to
> do. The error is either in your backend or your expectations...
>
> DES

Thanks for the help so far, I've managed to find logs that confirms that varnish does in fact fetch the page anew after
a purge.

I'll have the customer look at their pages so confirmed that we are not fooled by linked pages somehow.

Sorry for the inconvenience...

--

Thomas Westlund
Aftenposten AS, UNIX/nettverksavd.
Postboks 1, 0051 Oslo
Tlf: +47 98 20 30 33
Fax: +47 22 86 40 74