From stockrt at gmail.com  Thu Nov  5 20:25:48 2009
From: stockrt at gmail.com (=?ISO-8859-1?Q?Rog=E9rio_Schneider?=)
Date: Thu, 5 Nov 2009 18:25:48 -0200
Subject: Saintmode in 2.0
In-Reply-To: <20091021083735.GB4527@kjeks.linpro.no>
References: <20091021083735.GB4527@kjeks.linpro.no>
Message-ID: <100657c90911051225l5dbaa5dage4a40d7184dec3e9@mail.gmail.com>

Saintmode is a great feature, thanks and congrats Kristian.

On Wed, Oct 21, 2009 at 6:37 AM, Kristian Lyngstol
<kristian at redpill-linpro.com> wrote:
> Revisions: 4208 4328 4335
>
> Should be included in 2.0. The latter two adds a paramter which controls
> how long the saintmode list has to be until the backend is considered sick,
> and it also makes it possible to disable saintmode handling entirely. The
> first is beresp.saintmode, which I suppose you have to rename, but
> otherwise it should apply with very little hassle.
>
> In addition, I have a patch awaiting PHK-approval to add
> saintmode_threshold to the backend declaration too, which should probably
> be included too when it's accepted.
>
> --
> Kristian Lyngst?l
> Redpill Linpro AS
> Tlf: +47 21544179
> Mob: +47 99014497
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev
>
>

Cheers,
-- 
Rog?rio Schneider

MSN: stockrt at hotmail.com
GTalk: stockrt at gmail.com
Skype: stockrt
http://stockrt.github.com


From jason at viewpoints.com  Tue Nov 10 21:47:37 2009
From: jason at viewpoints.com (Jason Rohwedder)
Date: Tue, 10 Nov 2009 15:47:37 -0600
Subject: test failing during RPM compile on 2.0.5
Message-ID: <73B9881D-69DB-452C-AF72-F180ABDE1C6E@viewpoints.com>

I'm sorry that I don't really have any information why the test is  
failing, but this is our first foray into using varnish, so I haven't  
had time yet to look at any source outside of the RPM spec file.  If I  
take the spec file in the 2.0.5 release and update to use that version  
of the source, I receive the following error. (the spec still points  
to 2.0.4).

===============================================
1 of 143 tests failed
Please report to varnish-dev at projects.linpro.no
===============================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/varnish-2.0.5/bin/ 
varnishtest'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/usr/src/redhat/BUILD/varnish-2.0.5/bin/ 
varnishtest'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/varnish-2.0.5/bin'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.8604 (%check)

I'm including the log of my compile in hopes it will help you debug.   
The failing test seems to be 00006, and this is being compiled in a  
VMware Fusion VM running Redhat ES 5.2 with some updates but nothing  
major that I recall.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: varnish_2.0.5_log.txt
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20091110/0baf69a2/attachment.txt>
-------------- next part --------------



Thanks for all your hard work on varnish.  It's a very interesting  
project and I'm hopeful we'll end up using it on our production site  
after we spend a bit more time with it.

-jason

--
Jason Rohwedder
Viewpoints Network - Operations

jro at viewpoints.com
312-447-6106


From jason at viewpoints.com  Tue Nov 10 21:59:03 2009
From: jason at viewpoints.com (Jason Rohwedder)
Date: Tue, 10 Nov 2009 15:59:03 -0600
Subject: test failing during RPM compile on 2.0.5
In-Reply-To: <73B9881D-69DB-452C-AF72-F180ABDE1C6E@viewpoints.com>
References: <73B9881D-69DB-452C-AF72-F180ABDE1C6E@viewpoints.com>
Message-ID: <FAC7BE92-A576-4777-8D10-BB9A14A7AD3F@viewpoints.com>

I should have also noted, I don't see the failure when compiling it  
again 2.0.4.  -jro

On Nov 10, 2009, at 3:47 PM, Jason Rohwedder wrote:

> I'm sorry that I don't really have any information why the test is  
> failing, but this is our first foray into using varnish, so I  
> haven't had time yet to look at any source outside of the RPM spec  
> file.  If I take the spec file in the 2.0.5 release and update to  
> use that version of the source, I receive the following error. (the  
> spec still points to 2.0.4).
>
> ===============================================
> 1 of 143 tests failed
> Please report to varnish-dev at projects.linpro.no
> ===============================================
> make[3]: *** [check-TESTS] Error 1
> make[3]: Leaving directory `/usr/src/redhat/BUILD/varnish-2.0.5/bin/ 
> varnishtest'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/usr/src/redhat/BUILD/varnish-2.0.5/bin/ 
> varnishtest'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/usr/src/redhat/BUILD/varnish-2.0.5/bin'
> make: *** [check-recursive] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.8604 (%check)
>
> I'm including the log of my compile in hopes it will help you  
> debug.  The failing test seems to be 00006, and this is being  
> compiled in a VMware Fusion VM running Redhat ES 5.2 with some  
> updates but nothing major that I recall.
>
> <varnish_2.0.5_log.txt><mime-attachment.txt>

--
Jason Rohwedder
Viewpoints Network - Operations

jro at viewpoints.com
312-447-6106



From tfheen at redpill-linpro.com  Thu Nov 12 15:19:47 2009
From: tfheen at redpill-linpro.com (Tollef Fog Heen)
Date: Thu, 12 Nov 2009 16:19:47 +0100
Subject: test failing during RPM compile on 2.0.5
In-Reply-To: <73B9881D-69DB-452C-AF72-F180ABDE1C6E@viewpoints.com> (Jason
	Rohwedder's message of "Tue, 10 Nov 2009 15:47:37 -0600")
References: <73B9881D-69DB-452C-AF72-F180ABDE1C6E@viewpoints.com>
Message-ID: <87vdhfdb3g.fsf@qurzaw.linpro.no>

]] Jason Rohwedder 

| I'm including the log of my compile in hopes it will help you debug.
| The failing test seems to be 00006, and this is being compiled in a
| VMware Fusion VM running Redhat ES 5.2 with some updates but nothing
| major that I recall.

Looks like a timing issue; I have seen it on some VMs too.  Don't worry
about it.

| Thanks for all your hard work on varnish.  It's a very interesting
| project and I'm hopeful we'll end up using it on our production site
| after we spend a bit more time with it.

Good to hear! :-)

Regards,
-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From r.maccallum at imperial.ac.uk  Wed Nov 18 10:32:49 2009
From: r.maccallum at imperial.ac.uk (Bob MacCallum)
Date: Wed, 18 Nov 2009 10:32:49 +0000
Subject: bug in esi:include handling (with patch)
Message-ID: <19203.52561.488165.347385@bio-iisrv1.bio.ic.ac.uk>


Hi,

I found an off-by-one bug in esi_handle_include() - ESI requests were being
made for URLs with one extra character that was left over from the previous
request.


diff -Naur varnish-2.0.5-orig/bin/varnishd/cache_vrt_esi.c varnish-2.0.5/bin/varnishd/cache_vrt_esi.c
--- varnish-2.0.5-orig/bin/varnishd/cache_vrt_esi.c     2009-11-09 09:04:55.000000000 +0000
+++ varnish-2.0.5/bin/varnishd/cache_vrt_esi.c  2009-11-18 10:17:30.000000000 +0000
@@ -383,7 +383,7 @@
                        c = WS_Alloc(ws, s);
                        memcpy(c, val.b, Tlen(val));
                        val.b = c;
-                       val.e = val.b + s;
+                       val.e = val.b + s - 1;
                        *val.e = '\0';
                }
 

If you'd like me to add the ticket, please send the Trac login info off list.

Many thanks for this interesting looking project.

FYI I am trying to embed bioinformatics services (a mixture of apache
mod_perl, tomcat java and other stuff) into a single drupal instance (I'm
"pass"ing everything through at the moment - will think about caching later).
It's looking hopeful at the moment!

cheers,
Bob.


-- 
Bob MacCallum | VectorBase Developer | Kafatos/Christophides Groups |
Division of Cell and Molecular Biology | Imperial College London |
Phone +442075941945 | Email r.maccallum at imperial.ac.uk


From phk at phk.freebsd.dk  Wed Nov 18 11:29:20 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 18 Nov 2009 11:29:20 +0000
Subject: bug in esi:include handling (with patch) 
In-Reply-To: Your message of "Wed, 18 Nov 2009 10:32:49 GMT."
	<19203.52561.488165.347385@bio-iisrv1.bio.ic.ac.uk> 
Message-ID: <86315.1258543760@critter.freebsd.dk>

In message <19203.52561.488165.347385 at bio-iisrv1.bio.ic.ac.uk>, Bob MacCallum w
rites:

>I found an off-by-one bug in esi_handle_include() - ESI requests were being
>made for URLs with one extra character that was left over from the previous
>request.

He, I beat you by a day, I fixed that in r4351 :-)

>If you'd like me to add the ticket, please send the Trac login info off list.

You can create your own trac-login.

-- 
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 r.maccallum at imperial.ac.uk  Wed Nov 18 13:19:00 2009
From: r.maccallum at imperial.ac.uk (Bob MacCallum)
Date: Wed, 18 Nov 2009 13:19:00 +0000
Subject: bug in esi:include handling (with patch) 
In-Reply-To: <86315.1258543760@critter.freebsd.dk>
References: <19203.52561.488165.347385@bio-iisrv1.bio.ic.ac.uk>
	<86315.1258543760@critter.freebsd.dk>
Message-ID: <19203.62532.605771.461417@bio-iisrv1.bio.ic.ac.uk>


Oh, well, at least great minds think alike.

Are includes like this supposed to work:

<esi:include src="http://some.other.site/stuff" />

?

I can't get that to work (although the source code suggests that it should).
If I set a backend to some.other.site upon seeing "^/stuff" in vcl_recv then
<esi:include src="/stuff" />
seems to work OK.

cheers,
Bob.


Poul-Henning Kamp writes:
 > In message <19203.52561.488165.347385 at bio-iisrv1.bio.ic.ac.uk>, Bob MacCallum w
 > rites:
 > 
 > >I found an off-by-one bug in esi_handle_include() - ESI requests were being
 > >made for URLs with one extra character that was left over from the previous
 > >request.
 > 
 > He, I beat you by a day, I fixed that in r4351 :-)
 > 
 > >If you'd like me to add the ticket, please send the Trac login info off list.
 > 
 > You can create your own trac-login.
 > 
 > -- 
 > 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.

-- 
Bob MacCallum | VectorBase Developer | Kafatos/Christophides Groups |
Division of Cell and Molecular Biology | Imperial College London |
Phone +442075941945 | Email r.maccallum at imperial.ac.uk


From phk at phk.freebsd.dk  Wed Nov 18 13:46:49 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 18 Nov 2009 13:46:49 +0000
Subject: bug in esi:include handling (with patch) 
In-Reply-To: Your message of "Wed, 18 Nov 2009 13:19:00 GMT."
	<19203.62532.605771.461417@bio-iisrv1.bio.ic.ac.uk> 
Message-ID: <19688.1258552009@critter.freebsd.dk>

In message <19203.62532.605771.461417 at bio-iisrv1.bio.ic.ac.uk>, Bob MacCallum w
rites:
>
>Oh, well, at least great minds think alike.
>
>Are includes like this supposed to work:
>
><esi:include src="http://some.other.site/stuff" />

It only works if you have a backend defined for that server.

Look at bin/varnistest/tests/e00006.vtc for an example.

-- 
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 robert.olsson at qbranch.se  Fri Nov 20 09:21:37 2009
From: robert.olsson at qbranch.se (Robert Olsson)
Date: Fri, 20 Nov 2009 10:21:37 +0100
Subject: Varnish and sticky sessions
Message-ID: <4B065FA1.1020203@qbranch.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!
Is there any plan to support sticky sessions in varnish?
Some of the sessions will be a cookie-based logins and I need them to use the
same backend (in varnish point of view) during the whole session.
First when the backend server stop answering connections the clients (or sessions)
will be directed to another backend server.

Is this possible to solve today in current stable release or will it be
supported in a future version of varnish?

Thank you for your answers :)

//Robert Olsson
- --
Med v?nlig h?lsning / Best Regards
Robert Olsson
Change Consultant

Qbranch Stockholm AB
Office: +46 8 672 50 00
Cellphone: +46 732 312 475
Fax: +46 8 13 70 70
Address: Primusgatan 18
SE-112 62 Stockholm
QBRANCH: VI F?R IT ATT FUNGERA
Om du inte ?r den mottagare f?r vilken meddelandet ?r avsett,
b?r du radera det och helst underr?tta avs?ndaren om detta.
Du f?r d? enligt lag varken kopiera inneh?llet eller vidarebefordra meddelandet till n?gon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksGX6AACgkQJ0skqjbzPOPlcQCcDv7+55VQn44Mnvg+zzlxQaXj
RCIAoJikczc63Edc/i9V7cKZEYvb5jip
=u9uA
-----END PGP SIGNATURE-----


From sky at crucially.net  Fri Nov 20 10:15:20 2009
From: sky at crucially.net (Artur Bergman)
Date: Fri, 20 Nov 2009 02:15:20 -0800
Subject: Varnish and sticky sessions
In-Reply-To: <4B065FA1.1020203@qbranch.se>
References: <4B065FA1.1020203@qbranch.se>
Message-ID: <26DF61B7-3033-4C58-9900-B4A2F441D750@crucially.net>

set a cookie and direct on that cookie?

On Nov 20, 2009, at 1:21 AM, Robert Olsson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
> Is there any plan to support sticky sessions in varnish?
> Some of the sessions will be a cookie-based logins and I need them  
> to use the
> same backend (in varnish point of view) during the whole session.
> First when the backend server stop answering connections the clients  
> (or sessions)
> will be directed to another backend server.
>
> Is this possible to solve today in current stable release or will it  
> be
> supported in a future version of varnish?
>
> Thank you for your answers :)
>
> //Robert Olsson
> - --
> Med v?nlig h?lsning / Best Regards
> Robert Olsson
> Change Consultant
>
> Qbranch Stockholm AB
> Office: +46 8 672 50 00
> Cellphone: +46 732 312 475
> Fax: +46 8 13 70 70
> Address: Primusgatan 18
> SE-112 62 Stockholm
> QBRANCH: VI F?R IT ATT FUNGERA
> Om du inte ?r den mottagare f?r vilken meddelandet ?r avsett,
> b?r du radera det och helst underr?tta avs?ndaren om detta.
> Du f?r d? enligt lag varken kopiera inneh?llet eller vidarebefordra  
> meddelandet till n?gon.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAksGX6AACgkQJ0skqjbzPOPlcQCcDv7+55VQn44Mnvg+zzlxQaXj
> RCIAoJikczc63Edc/i9V7cKZEYvb5jip
> =u9uA
> -----END PGP SIGNATURE-----
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev



From albert.lash at docunext.com  Fri Nov 20 18:24:54 2009
From: albert.lash at docunext.com (Albert Lash)
Date: Fri, 20 Nov 2009 13:24:54 -0500
Subject: Varnish and sticky sessions
In-Reply-To: <26DF61B7-3033-4C58-9900-B4A2F441D750@crucially.net>
References: <4B065FA1.1020203@qbranch.se>
	<26DF61B7-3033-4C58-9900-B4A2F441D750@crucially.net>
Message-ID: <0a4ab53a1cc9ac4556b85ef3c9fac76d.squirrel@www.savonix.com>

Use of a cookie would definitely work, and there are probably a bunch of
other simpler methods too. One example - I would add client ip addresses
to the hash and select a backend based upon it, randomizing previously
unknown ip addresses. Depending on where the clients are, the load balance
might become off-balance... my mileage always vary.

I vote for keeping it as a documented configuration rather than a built-in
feature.

> set a cookie and direct on that cookie?
>
> On Nov 20, 2009, at 1:21 AM, Robert Olsson wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello!
>> Is there any plan to support sticky sessions in varnish?
>> Some of the sessions will be a cookie-based logins and I need them
>> to use the
>> same backend (in varnish point of view) during the whole session.
>> First when the backend server stop answering connections the clients
>> (or sessions)
>> will be directed to another backend server.
>>
>> Is this possible to solve today in current stable release or will it
>> be
>> supported in a future version of varnish?
>>
>> Thank you for your answers :)
>>
>> //Robert Olsson
>> - --
>> Med v?nlig h?lsning / Best Regards
>> Robert Olsson
>> Change Consultant
>>
>> Qbranch Stockholm AB
>> Office: +46 8 672 50 00
>> Cellphone: +46 732 312 475
>> Fax: +46 8 13 70 70
>> Address: Primusgatan 18
>> SE-112 62 Stockholm
>> QBRANCH: VI F?R IT ATT FUNGERA
>> Om du inte ?r den mottagare f?r vilken meddelandet ?r avsett,
>> b?r du radera det och helst underr?tta avs?ndaren om detta.
>> Du f?r d? enligt lag varken kopiera inneh?llet eller vidarebefordra
>> meddelandet till n?gon.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAksGX6AACgkQJ0skqjbzPOPlcQCcDv7+55VQn44Mnvg+zzlxQaXj
>> RCIAoJikczc63Edc/i9V7cKZEYvb5jip
>> =u9uA
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> varnish-dev mailing list
>> varnish-dev at projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-dev
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev
>


-- 
http://www.docunext.com/



From aotto at mosso.com  Sat Nov 21 18:53:23 2009
From: aotto at mosso.com (aotto at mosso.com)
Date: Sat, 21 Nov 2009 18:53:23 +0000
Subject: Varnish and sticky sessions
In-Reply-To: <0a4ab53a1cc9ac4556b85ef3c9fac76d.squirrel@www.savonix.com>
References: <4B065FA1.1020203@qbranch.se><26DF61B7-3033-4C58-9900-B4A2F441D750@crucially.net><0a4ab53a1cc9ac4556b85ef3c9fac76d.squirrel@www.savonix.com>
Message-ID: <288589531-1258829786-cardhu_decombobulator_blackberry.rim.net-711277551-@bda400.bisx.prod.on.blackberry>

Hash by client source port number and you'll get a nice even distribution.

Adrian
Sent via BlackBerry by AT&T

-----Original Message-----
From: "Albert Lash" <albert.lash at docunext.com>
Date: Fri, 20 Nov 2009 13:24:54 
To: Artur Bergman<sky at crucially.net>
Cc: varnish-dev at projects.linpro.no<varnish-dev at projects.linpro.no>; Robert Olsson<robert.olsson at qbranch.se>
Subject: Re: Varnish and sticky sessions

Use of a cookie would definitely work, and there are probably a bunch of
other simpler methods too. One example - I would add client ip addresses
to the hash and select a backend based upon it, randomizing previously
unknown ip addresses. Depending on where the clients are, the load balance
might become off-balance... my mileage always vary.

I vote for keeping it as a documented configuration rather than a built-in
feature.

> set a cookie and direct on that cookie?
>
> On Nov 20, 2009, at 1:21 AM, Robert Olsson wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello!
>> Is there any plan to support sticky sessions in varnish?
>> Some of the sessions will be a cookie-based logins and I need them
>> to use the
>> same backend (in varnish point of view) during the whole session.
>> First when the backend server stop answering connections the clients
>> (or sessions)
>> will be directed to another backend server.
>>
>> Is this possible to solve today in current stable release or will it
>> be
>> supported in a future version of varnish?
>>
>> Thank you for your answers :)
>>
>> //Robert Olsson
>> - --
>> Med v?nlig h?lsning / Best Regards
>> Robert Olsson
>> Change Consultant
>>
>> Qbranch Stockholm AB
>> Office: +46 8 672 50 00
>> Cellphone: +46 732 312 475
>> Fax: +46 8 13 70 70
>> Address: Primusgatan 18
>> SE-112 62 Stockholm
>> QBRANCH: VI F?R IT ATT FUNGERA
>> Om du inte ?r den mottagare f?r vilken meddelandet ?r avsett,
>> b?r du radera det och helst underr?tta avs?ndaren om detta.
>> Du f?r d? enligt lag varken kopiera inneh?llet eller vidarebefordra
>> meddelandet till n?gon.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAksGX6AACgkQJ0skqjbzPOPlcQCcDv7+55VQn44Mnvg+zzlxQaXj
>> RCIAoJikczc63Edc/i9V7cKZEYvb5jip
>> =u9uA
>> -----END PGP SIGNATURE-----
>>_______________________________________________
>> varnish-dev mailing list
>> varnish-dev at projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-dev
>
>_______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev
>


-- 
http://www.docunext.com/

_______________________________________________
varnish-dev mailing list
varnish-dev at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev

From des at des.no  Sun Nov 22 13:33:25 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Sun, 22 Nov 2009 14:33:25 +0100
Subject: Varnish and sticky sessions
In-Reply-To: <288589531-1258829786-cardhu_decombobulator_blackberry.rim.net-711277551-@bda400.bisx.prod.on.blackberry>
	(aotto@mosso.com's message of "Sat, 21 Nov 2009 18:53:23 +0000")
References: <4B065FA1.1020203@qbranch.se>
	<26DF61B7-3033-4C58-9900-B4A2F441D750@crucially.net>
	<0a4ab53a1cc9ac4556b85ef3c9fac76d.squirrel@www.savonix.com>
	<288589531-1258829786-cardhu_decombobulator_blackberry.rim.net-711277551-@bda400.bisx.prod.on.blackberry>
Message-ID: <86y6lyu1ju.fsf@ds4.des.no>

aotto at mosso.com writes:
> Hash by client source port number and you'll get a nice even
> distribution.

Won't work, Opera opens multiple parallel connections to each server
(IIRC: 4 by default, configurable up to 16)

DES
-- 
Dag-Erling Sm?rgrav - des at des.no


From robert.olsson at qbranch.se  Tue Nov 17 10:45:31 2009
From: robert.olsson at qbranch.se (Robert Olsson)
Date: Tue, 17 Nov 2009 11:45:31 +0100
Subject: Varnish and sticky sessions
Message-ID: <4B027ECB.9050803@qbranch.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!
Is there any plan to support sticky sessions in varnish?
Some of the sessions will be a cookie-based logins and I need them to use the
same backend (in varnish point of view) during the whole session.
First when the backend server stop answering connections the clients (or sessions)
will be directed to another backend server.

Is this possible to solve today in current stable release or will it be
supported in a future version of varnish?

Thank you for your answers :)

//Robert Olsson
- --
Med v?nlig h?lsning / Best Regards
Robert Olsson
Change Consultant

Qbranch Stockholm AB
Office: +46 8 672 50 00
Cellphone: +46 732 312 475
Fax: +46 8 13 70 70
Address: Primusgatan 18
SE-112 62 Stockholm
QBRANCH: VI F?R IT ATT FUNGERA Om du inte ?r den mottagare f?r vilken meddelandet ?r avsett,
b?r du radera det och helst underr?tta avs?ndaren om detta.
Du f?r d? enligt lag varken kopiera inneh?llet eller vidarebefordra meddelandet till n?gon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksCfskACgkQJ0skqjbzPOOvxACgrvTHmGymG/fGRNjOFHC1piIF
12IAn0pGdg7v05nKo/0dTWvQm2kFh8SK
=bD0E
-----END PGP SIGNATURE-----


From phk at phk.freebsd.dk  Fri Nov 27 11:24:08 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 27 Nov 2009 11:24:08 +0000
Subject: Varnish and sticky sessions 
In-Reply-To: Your message of "Tue, 17 Nov 2009 11:45:31 +0100."
	<4B027ECB.9050803@qbranch.se> 
Message-ID: <38547.1259321048@critter.freebsd.dk>

In message <4B027ECB.9050803 at qbranch.se>, Robert Olsson writes:

>Hello!
>Is there any plan to support sticky sessions in varnish?

Plans ?  yes.

Deadlines ?  No.

-- 
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 joe at fixieconsulting.com  Mon Nov 30 20:28:02 2009
From: joe at fixieconsulting.com (Joe Van Dyk)
Date: Mon, 30 Nov 2009 12:28:02 -0800
Subject: Caching of ESI snippets
Message-ID: <c715e640911301228v128b6b10p3e4fd427d76fd07e@mail.gmail.com>

I have two pages /main and /esi.

/main returns:
<esi:include src="/esi" />

/esi has a cache-control of "max-age=60, public" and returns the current time.

I'd expect that when I load /main, /esi would be requested once a
minute.  In a browser, /esi is loaded from the server everytime
(instead of the varnish sending the cached version).  In curl, it all
works as expected.

Ideas?


-- 
Joe Van Dyk
http://fixieconsulting.com


From phk at phk.freebsd.dk  Mon Nov 30 20:41:58 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 30 Nov 2009 20:41:58 +0000
Subject: Caching of ESI snippets 
In-Reply-To: Your message of "Mon, 30 Nov 2009 12:28:02 PST."
	<c715e640911301228v128b6b10p3e4fd427d76fd07e@mail.gmail.com> 
Message-ID: <16259.1259613718@critter.freebsd.dk>

In message <c715e640911301228v128b6b10p3e4fd427d76fd07e at mail.gmail.com>, Joe Va
n Dyk writes:
>I have two pages /main and /esi.
>
>/main returns:
><esi:include src="/esi" />
>
>/esi has a cache-control of "max-age=60, public" and returns the current time.
>
>I'd expect that when I load /main, /esi would be requested once a
>minute.  In a browser, /esi is loaded from the server everytime
>(instead of the varnish sending the cached version).  In curl, it all
>works as expected.

You browser sends cookies along ?

-- 
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 joe at fixieconsulting.com  Mon Nov 30 20:55:32 2009
From: joe at fixieconsulting.com (Joe Van Dyk)
Date: Mon, 30 Nov 2009 12:55:32 -0800
Subject: Caching of ESI snippets
In-Reply-To: <16259.1259613718@critter.freebsd.dk>
References: <c715e640911301228v128b6b10p3e4fd427d76fd07e@mail.gmail.com> 
	<16259.1259613718@critter.freebsd.dk>
Message-ID: <c715e640911301255s2edc2984y615ec4e11efc37a@mail.gmail.com>

On Mon, Nov 30, 2009 at 12:41 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <c715e640911301228v128b6b10p3e4fd427d76fd07e at mail.gmail.com>, Joe Va
> n Dyk writes:
>>I have two pages /main and /esi.
>>
>>/main returns:
>><esi:include src="/esi" />
>>
>>/esi has a cache-control of "max-age=60, public" and returns the current time.
>>
>>I'd expect that when I load /main, /esi would be requested once a
>>minute. ?In a browser, /esi is loaded from the server everytime
>>(instead of the varnish sending the cached version). ?In curl, it all
>>works as expected.
>
> You browser sends cookies along ?

Nope.

However, /include has this cache-control: private, max-age=0,
must-revalidate.  But I wouldn't think that would matter when varnish
decides whether or not to request /esi?


From joe at fixieconsulting.com  Mon Nov 30 21:04:25 2009
From: joe at fixieconsulting.com (Joe Van Dyk)
Date: Mon, 30 Nov 2009 13:04:25 -0800
Subject: sample varnish configuration for ec2?
Message-ID: <c715e640911301304k43432d3p970f54c05fab2825@mail.gmail.com>

Anyone got a sample varnish configuration that they use on Amazon's EC2?

-- 
Joe Van Dyk
http://fixieconsulting.com


From phk at phk.freebsd.dk  Mon Nov 30 21:09:31 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 30 Nov 2009 21:09:31 +0000
Subject: Caching of ESI snippets 
In-Reply-To: Your message of "Mon, 30 Nov 2009 12:55:32 PST."
	<c715e640911301255s2edc2984y615ec4e11efc37a@mail.gmail.com> 
Message-ID: <16386.1259615371@critter.freebsd.dk>

In message <c715e640911301255s2edc2984y615ec4e11efc37a at mail.gmail.com>, Joe Van
 Dyk writes:

>> You browser sends cookies along ?
>
>Nope.
>
>However, /include has this cache-control: private, max-age=3D0,
>must-revalidate.  But I wouldn't think that would matter when varnish
>decides whether or not to request /esi?

Unless Varnish sees that, it will not matter.

Varishlog is, as always, your friend.

-- 
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 joe at fixieconsulting.com  Mon Nov 30 21:18:56 2009
From: joe at fixieconsulting.com (Joe Van Dyk)
Date: Mon, 30 Nov 2009 13:18:56 -0800
Subject: Caching of ESI snippets
In-Reply-To: <16386.1259615371@critter.freebsd.dk>
References: <c715e640911301255s2edc2984y615ec4e11efc37a@mail.gmail.com> 
	<16386.1259615371@critter.freebsd.dk>
Message-ID: <c715e640911301318x2a46ea11rf229f16ca62355c1@mail.gmail.com>

On Mon, Nov 30, 2009 at 1:09 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <c715e640911301255s2edc2984y615ec4e11efc37a at mail.gmail.com>, Joe Van
> ?Dyk writes:
>
>>> You browser sends cookies along ?
>>
>>Nope.
>>
>>However, /include has this cache-control: private, max-age=3D0,
>>must-revalidate. ?But I wouldn't think that would matter when varnish
>>decides whether or not to request /esi?
>
> Unless Varnish sees that, it will not matter.
>
> Varishlog is, as always, your friend.

Here's the output.  Any chance you could glance at it?  I'm not sure
how to read it yet.

    7 ReqStart     c 127.0.0.1 55655 1181355510
    7 RxRequest    c GET
    7 RxURL        c /main
    7 RxProtocol   c HTTP/1.1
    7 RxHeader     c Host: localhost:8080
    7 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
    7 RxHeader     c Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    7 RxHeader     c Accept-Language: en-us,en;q=0.5
    7 RxHeader     c Accept-Encoding: gzip,deflate
    7 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    7 RxHeader     c Keep-Alive: 300
    7 RxHeader     c Connection: keep-alive
    7 RxHeader     c Cookie:
_esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
    7 RxHeader     c If-None-Match: "77386a2121be399962e6f8f70e5472a3"
    7 VCL_call     c recv
    7 VCL_return   c pass
    7 VCL_call     c pass
    7 VCL_return   c pass
    9 BackendOpen  b default 127.0.0.1 55707 127.0.0.1 3000
    7 Backend      c 9 default default
    9 TxRequest    b GET
    9 TxURL        b /main
    9 TxProtocol   b HTTP/1.1
    9 TxHeader     b Host: localhost:8080
    9 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
    9 TxHeader     b Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    9 TxHeader     b Accept-Language: en-us,en;q=0.5
    9 TxHeader     b Accept-Encoding: gzip,deflate
    9 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    9 TxHeader     b Cookie:
_esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
    9 TxHeader     b If-None-Match: "77386a2121be399962e6f8f70e5472a3"
    9 TxHeader     b X-Varnish: 1181355510
    9 TxHeader     b X-Forwarded-For: 127.0.0.1
    7 Debug        c "tag {include src="/esi" } 0 1 0"
    7 Debug        c "Incl " src="/esi" ""
    9 RxProtocol   b HTTP/1.1
    9 RxStatus     b 200
    9 RxResponse   b OK
    9 RxHeader     b Connection: close
    9 RxHeader     b Date: Mon, 30 Nov 2009 21:17:36 GMT
    9 RxHeader     b Status: 200
    9 RxHeader     b ETag: "974a5bab80a34a131da3a1975e35fc8c"
    9 RxHeader     b X-Runtime: 2
    9 RxHeader     b Content-Type: text/html; charset=utf-8
    9 RxHeader     b Content-Length: 148
    9 RxHeader     b Server: Mongrel 1.1.5
    9 RxHeader     b Cache-Control: private, max-age=0, must-revalidate
    7 ObjProtocol  c HTTP/1.1
    7 ObjStatus    c 200
    7 ObjResponse  c OK
    7 ObjHeader    c Date: Mon, 30 Nov 2009 21:17:36 GMT
    7 ObjHeader    c Status: 200
    7 ObjHeader    c ETag: "974a5bab80a34a131da3a1975e35fc8c"
    7 ObjHeader    c X-Runtime: 2
    7 ObjHeader    c Content-Type: text/html; charset=utf-8
    7 ObjHeader    c Server: Mongrel 1.1.5
    7 ObjHeader    c Cache-Control: private, max-age=0, must-revalidate
    9 BackendClose b default
    7 TTL          c 1181355510 RFC 0 1259615856 0 0 0 0
    7 VCL_call     c fetch
    7 VCL_info     c XID 1181355510: obj.prefetch (-30) less than ttl
(-1.25962e+09), ignored.
    7 VCL_return   c deliver
    7 Length       c 148
    7 VCL_call     c deliver
    7 VCL_return   c deliver
    7 TxProtocol   c HTTP/1.1
    7 TxStatus     c 200
    7 TxResponse   c OK
    7 TxHeader     c Status: 200
    7 TxHeader     c ETag: "974a5bab80a34a131da3a1975e35fc8c"
    7 TxHeader     c X-Runtime: 2
    7 TxHeader     c Content-Type: text/html; charset=utf-8
    7 TxHeader     c Server: Mongrel 1.1.5
    7 TxHeader     c Cache-Control: private, max-age=0, must-revalidate
    7 TxHeader     c Transfer-Encoding: chunked
    7 TxHeader     c Date: Mon, 30 Nov 2009 21:17:36 GMT
    7 TxHeader     c X-Varnish: 1181355510
    7 TxHeader     c Age: 0
    7 TxHeader     c Via: 1.1 varnish
    7 TxHeader     c Connection: keep-alive
    7 VCL_call     c recv
    7 VCL_return   c pass
    7 VCL_call     c pass
    7 VCL_return   c pass
    9 BackendOpen  b default 127.0.0.1 55708 127.0.0.1 3000
    7 Backend      c 9 default default
    9 TxRequest    b GET
    9 TxURL        b /esi
    9 TxProtocol   b HTTP/1.1
    9 TxHeader     b Host: localhost:8080
    9 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
    9 TxHeader     b Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    9 TxHeader     b Accept-Language: en-us,en;q=0.5
    9 TxHeader     b Accept-Encoding: gzip,deflate
    9 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    9 TxHeader     b Cookie:
_esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
    9 TxHeader     b If-None-Match: "77386a2121be399962e6f8f70e5472a3"
    9 TxHeader     b X-Varnish: 1181355510
    9 TxHeader     b X-Forwarded-For: 127.0.0.1
    9 RxProtocol   b HTTP/1.1
    9 RxStatus     b 200
    9 RxResponse   b OK
    9 RxHeader     b Connection: close
    9 RxHeader     b Date: Mon, 30 Nov 2009 21:17:36 GMT
    9 RxHeader     b Status: 200
    9 RxHeader     b ETag: "e9ce710e9b09175301008aa45d94f96f"
    9 RxHeader     b X-Runtime: 2
    9 RxHeader     b Content-Type: text/html; charset=utf-8
    9 RxHeader     b Content-Length: 83
    9 RxHeader     b Server: Mongrel 1.1.5
    9 RxHeader     b Cache-Control: max-age=60, public
    7 ObjProtocol  c HTTP/1.1
    7 ObjStatus    c 200
    7 ObjResponse  c OK
    7 ObjHeader    c Date: Mon, 30 Nov 2009 21:17:36 GMT
    7 ObjHeader    c Status: 200
    7 ObjHeader    c ETag: "e9ce710e9b09175301008aa45d94f96f"
    7 ObjHeader    c X-Runtime: 2
    7 ObjHeader    c Content-Type: text/html; charset=utf-8
    7 ObjHeader    c Server: Mongrel 1.1.5
    7 ObjHeader    c Cache-Control: max-age=60, public
    9 BackendClose b default
    7 TTL          c 1181355510 RFC 60 1259615856 0 0 60 0
    7 VCL_call     c fetch
    7 VCL_return   c deliver
    7 Length       c 83
    7 VCL_call     c deliver
    7 VCL_return   c deliver
    7 ReqEnd       c 1181355510 1259615856.047472000
1259615856.069441080 6.975047112 0.021866083 0.000102997
    7 ReqEnd       c 0 1259615856.069535017 1259615856.069535017
0.000093937 0.000000000 0.000000000
    0 StatAddr     - 127.0.0.1 0 3277 63 130 0 113 153 43622 18571


From joe at fixieconsulting.com  Mon Nov 30 21:24:00 2009
From: joe at fixieconsulting.com (Joe Van Dyk)
Date: Mon, 30 Nov 2009 13:24:00 -0800
Subject: Caching of ESI snippets
In-Reply-To: <c715e640911301318x2a46ea11rf229f16ca62355c1@mail.gmail.com>
References: <c715e640911301255s2edc2984y615ec4e11efc37a@mail.gmail.com> 
	<16386.1259615371@critter.freebsd.dk>
	<c715e640911301318x2a46ea11rf229f16ca62355c1@mail.gmail.com>
Message-ID: <c715e640911301324x73f11aa7jc3c44722b25f66d0@mail.gmail.com>

hey, there's a cookie in there.  wtf.

On Mon, Nov 30, 2009 at 1:18 PM, Joe Van Dyk <joe at fixieconsulting.com> wrote:
> On Mon, Nov 30, 2009 at 1:09 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>> In message <c715e640911301255s2edc2984y615ec4e11efc37a at mail.gmail.com>, Joe Van
>> ?Dyk writes:
>>
>>>> You browser sends cookies along ?
>>>
>>>Nope.
>>>
>>>However, /include has this cache-control: private, max-age=3D0,
>>>must-revalidate. ?But I wouldn't think that would matter when varnish
>>>decides whether or not to request /esi?
>>
>> Unless Varnish sees that, it will not matter.
>>
>> Varishlog is, as always, your friend.
>
> Here's the output. ?Any chance you could glance at it? ?I'm not sure
> how to read it yet.
>
> ? ?7 ReqStart ? ? c 127.0.0.1 55655 1181355510
> ? ?7 RxRequest ? ?c GET
> ? ?7 RxURL ? ? ? ?c /main
> ? ?7 RxProtocol ? c HTTP/1.1
> ? ?7 RxHeader ? ? c Host: localhost:8080
> ? ?7 RxHeader ? ? c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
> OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
> ? ?7 RxHeader ? ? c Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> ? ?7 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
> ? ?7 RxHeader ? ? c Accept-Encoding: gzip,deflate
> ? ?7 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> ? ?7 RxHeader ? ? c Keep-Alive: 300
> ? ?7 RxHeader ? ? c Connection: keep-alive
> ? ?7 RxHeader ? ? c Cookie:
> _esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
> s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
> ? ?7 RxHeader ? ? c If-None-Match: "77386a2121be399962e6f8f70e5472a3"
> ? ?7 VCL_call ? ? c recv
> ? ?7 VCL_return ? c pass
> ? ?7 VCL_call ? ? c pass
> ? ?7 VCL_return ? c pass
> ? ?9 BackendOpen ?b default 127.0.0.1 55707 127.0.0.1 3000
> ? ?7 Backend ? ? ?c 9 default default
> ? ?9 TxRequest ? ?b GET
> ? ?9 TxURL ? ? ? ?b /main
> ? ?9 TxProtocol ? b HTTP/1.1
> ? ?9 TxHeader ? ? b Host: localhost:8080
> ? ?9 TxHeader ? ? b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
> OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
> ? ?9 TxHeader ? ? b Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> ? ?9 TxHeader ? ? b Accept-Language: en-us,en;q=0.5
> ? ?9 TxHeader ? ? b Accept-Encoding: gzip,deflate
> ? ?9 TxHeader ? ? b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> ? ?9 TxHeader ? ? b Cookie:
> _esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
> s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
> ? ?9 TxHeader ? ? b If-None-Match: "77386a2121be399962e6f8f70e5472a3"
> ? ?9 TxHeader ? ? b X-Varnish: 1181355510
> ? ?9 TxHeader ? ? b X-Forwarded-For: 127.0.0.1
> ? ?7 Debug ? ? ? ?c "tag {include src="/esi" } 0 1 0"
> ? ?7 Debug ? ? ? ?c "Incl " src="/esi" ""
> ? ?9 RxProtocol ? b HTTP/1.1
> ? ?9 RxStatus ? ? b 200
> ? ?9 RxResponse ? b OK
> ? ?9 RxHeader ? ? b Connection: close
> ? ?9 RxHeader ? ? b Date: Mon, 30 Nov 2009 21:17:36 GMT
> ? ?9 RxHeader ? ? b Status: 200
> ? ?9 RxHeader ? ? b ETag: "974a5bab80a34a131da3a1975e35fc8c"
> ? ?9 RxHeader ? ? b X-Runtime: 2
> ? ?9 RxHeader ? ? b Content-Type: text/html; charset=utf-8
> ? ?9 RxHeader ? ? b Content-Length: 148
> ? ?9 RxHeader ? ? b Server: Mongrel 1.1.5
> ? ?9 RxHeader ? ? b Cache-Control: private, max-age=0, must-revalidate
> ? ?7 ObjProtocol ?c HTTP/1.1
> ? ?7 ObjStatus ? ?c 200
> ? ?7 ObjResponse ?c OK
> ? ?7 ObjHeader ? ?c Date: Mon, 30 Nov 2009 21:17:36 GMT
> ? ?7 ObjHeader ? ?c Status: 200
> ? ?7 ObjHeader ? ?c ETag: "974a5bab80a34a131da3a1975e35fc8c"
> ? ?7 ObjHeader ? ?c X-Runtime: 2
> ? ?7 ObjHeader ? ?c Content-Type: text/html; charset=utf-8
> ? ?7 ObjHeader ? ?c Server: Mongrel 1.1.5
> ? ?7 ObjHeader ? ?c Cache-Control: private, max-age=0, must-revalidate
> ? ?9 BackendClose b default
> ? ?7 TTL ? ? ? ? ?c 1181355510 RFC 0 1259615856 0 0 0 0
> ? ?7 VCL_call ? ? c fetch
> ? ?7 VCL_info ? ? c XID 1181355510: obj.prefetch (-30) less than ttl
> (-1.25962e+09), ignored.
> ? ?7 VCL_return ? c deliver
> ? ?7 Length ? ? ? c 148
> ? ?7 VCL_call ? ? c deliver
> ? ?7 VCL_return ? c deliver
> ? ?7 TxProtocol ? c HTTP/1.1
> ? ?7 TxStatus ? ? c 200
> ? ?7 TxResponse ? c OK
> ? ?7 TxHeader ? ? c Status: 200
> ? ?7 TxHeader ? ? c ETag: "974a5bab80a34a131da3a1975e35fc8c"
> ? ?7 TxHeader ? ? c X-Runtime: 2
> ? ?7 TxHeader ? ? c Content-Type: text/html; charset=utf-8
> ? ?7 TxHeader ? ? c Server: Mongrel 1.1.5
> ? ?7 TxHeader ? ? c Cache-Control: private, max-age=0, must-revalidate
> ? ?7 TxHeader ? ? c Transfer-Encoding: chunked
> ? ?7 TxHeader ? ? c Date: Mon, 30 Nov 2009 21:17:36 GMT
> ? ?7 TxHeader ? ? c X-Varnish: 1181355510
> ? ?7 TxHeader ? ? c Age: 0
> ? ?7 TxHeader ? ? c Via: 1.1 varnish
> ? ?7 TxHeader ? ? c Connection: keep-alive
> ? ?7 VCL_call ? ? c recv
> ? ?7 VCL_return ? c pass
> ? ?7 VCL_call ? ? c pass
> ? ?7 VCL_return ? c pass
> ? ?9 BackendOpen ?b default 127.0.0.1 55708 127.0.0.1 3000
> ? ?7 Backend ? ? ?c 9 default default
> ? ?9 TxRequest ? ?b GET
> ? ?9 TxURL ? ? ? ?b /esi
> ? ?9 TxProtocol ? b HTTP/1.1
> ? ?9 TxHeader ? ? b Host: localhost:8080
> ? ?9 TxHeader ? ? b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
> OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
> ? ?9 TxHeader ? ? b Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> ? ?9 TxHeader ? ? b Accept-Language: en-us,en;q=0.5
> ? ?9 TxHeader ? ? b Accept-Encoding: gzip,deflate
> ? ?9 TxHeader ? ? b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> ? ?9 TxHeader ? ? b Cookie:
> _esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
> s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
> ? ?9 TxHeader ? ? b If-None-Match: "77386a2121be399962e6f8f70e5472a3"
> ? ?9 TxHeader ? ? b X-Varnish: 1181355510
> ? ?9 TxHeader ? ? b X-Forwarded-For: 127.0.0.1
> ? ?9 RxProtocol ? b HTTP/1.1
> ? ?9 RxStatus ? ? b 200
> ? ?9 RxResponse ? b OK
> ? ?9 RxHeader ? ? b Connection: close
> ? ?9 RxHeader ? ? b Date: Mon, 30 Nov 2009 21:17:36 GMT
> ? ?9 RxHeader ? ? b Status: 200
> ? ?9 RxHeader ? ? b ETag: "e9ce710e9b09175301008aa45d94f96f"
> ? ?9 RxHeader ? ? b X-Runtime: 2
> ? ?9 RxHeader ? ? b Content-Type: text/html; charset=utf-8
> ? ?9 RxHeader ? ? b Content-Length: 83
> ? ?9 RxHeader ? ? b Server: Mongrel 1.1.5
> ? ?9 RxHeader ? ? b Cache-Control: max-age=60, public
> ? ?7 ObjProtocol ?c HTTP/1.1
> ? ?7 ObjStatus ? ?c 200
> ? ?7 ObjResponse ?c OK
> ? ?7 ObjHeader ? ?c Date: Mon, 30 Nov 2009 21:17:36 GMT
> ? ?7 ObjHeader ? ?c Status: 200
> ? ?7 ObjHeader ? ?c ETag: "e9ce710e9b09175301008aa45d94f96f"
> ? ?7 ObjHeader ? ?c X-Runtime: 2
> ? ?7 ObjHeader ? ?c Content-Type: text/html; charset=utf-8
> ? ?7 ObjHeader ? ?c Server: Mongrel 1.1.5
> ? ?7 ObjHeader ? ?c Cache-Control: max-age=60, public
> ? ?9 BackendClose b default
> ? ?7 TTL ? ? ? ? ?c 1181355510 RFC 60 1259615856 0 0 60 0
> ? ?7 VCL_call ? ? c fetch
> ? ?7 VCL_return ? c deliver
> ? ?7 Length ? ? ? c 83
> ? ?7 VCL_call ? ? c deliver
> ? ?7 VCL_return ? c deliver
> ? ?7 ReqEnd ? ? ? c 1181355510 1259615856.047472000
> 1259615856.069441080 6.975047112 0.021866083 0.000102997
> ? ?7 ReqEnd ? ? ? c 0 1259615856.069535017 1259615856.069535017
> 0.000093937 0.000000000 0.000000000
> ? ?0 StatAddr ? ? - 127.0.0.1 0 3277 63 130 0 113 153 43622 18571
>



-- 
Joe Van Dyk
http://fixieconsulting.com


From joe at fixieconsulting.com  Mon Nov 30 21:28:04 2009
From: joe at fixieconsulting.com (Joe Van Dyk)
Date: Mon, 30 Nov 2009 13:28:04 -0800
Subject: Caching of ESI snippets
In-Reply-To: <c715e640911301324x73f11aa7jc3c44722b25f66d0@mail.gmail.com>
References: <c715e640911301255s2edc2984y615ec4e11efc37a@mail.gmail.com> 
	<16386.1259615371@critter.freebsd.dk>
	<c715e640911301318x2a46ea11rf229f16ca62355c1@mail.gmail.com> 
	<c715e640911301324x73f11aa7jc3c44722b25f66d0@mail.gmail.com>
Message-ID: <c715e640911301328x1012f835gdfce910f42c27732@mail.gmail.com>

Aha, the browser was sending a cookie -- although it should not have.
Sorry for the noise!

On Mon, Nov 30, 2009 at 1:24 PM, Joe Van Dyk <joe at fixieconsulting.com> wrote:
> hey, there's a cookie in there. ?wtf.
>
> On Mon, Nov 30, 2009 at 1:18 PM, Joe Van Dyk <joe at fixieconsulting.com> wrote:
>> On Mon, Nov 30, 2009 at 1:09 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>>> In message <c715e640911301255s2edc2984y615ec4e11efc37a at mail.gmail.com>, Joe Van
>>> ?Dyk writes:
>>>
>>>>> You browser sends cookies along ?
>>>>
>>>>Nope.
>>>>
>>>>However, /include has this cache-control: private, max-age=3D0,
>>>>must-revalidate. ?But I wouldn't think that would matter when varnish
>>>>decides whether or not to request /esi?
>>>
>>> Unless Varnish sees that, it will not matter.
>>>
>>> Varishlog is, as always, your friend.
>>
>> Here's the output. ?Any chance you could glance at it? ?I'm not sure
>> how to read it yet.
>>
>> ? ?7 ReqStart ? ? c 127.0.0.1 55655 1181355510
>> ? ?7 RxRequest ? ?c GET
>> ? ?7 RxURL ? ? ? ?c /main
>> ? ?7 RxProtocol ? c HTTP/1.1
>> ? ?7 RxHeader ? ? c Host: localhost:8080
>> ? ?7 RxHeader ? ? c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
>> OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
>> ? ?7 RxHeader ? ? c Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> ? ?7 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
>> ? ?7 RxHeader ? ? c Accept-Encoding: gzip,deflate
>> ? ?7 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> ? ?7 RxHeader ? ? c Keep-Alive: 300
>> ? ?7 RxHeader ? ? c Connection: keep-alive
>> ? ?7 RxHeader ? ? c Cookie:
>> _esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
>> s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
>> ? ?7 RxHeader ? ? c If-None-Match: "77386a2121be399962e6f8f70e5472a3"
>> ? ?7 VCL_call ? ? c recv
>> ? ?7 VCL_return ? c pass
>> ? ?7 VCL_call ? ? c pass
>> ? ?7 VCL_return ? c pass
>> ? ?9 BackendOpen ?b default 127.0.0.1 55707 127.0.0.1 3000
>> ? ?7 Backend ? ? ?c 9 default default
>> ? ?9 TxRequest ? ?b GET
>> ? ?9 TxURL ? ? ? ?b /main
>> ? ?9 TxProtocol ? b HTTP/1.1
>> ? ?9 TxHeader ? ? b Host: localhost:8080
>> ? ?9 TxHeader ? ? b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
>> OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
>> ? ?9 TxHeader ? ? b Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> ? ?9 TxHeader ? ? b Accept-Language: en-us,en;q=0.5
>> ? ?9 TxHeader ? ? b Accept-Encoding: gzip,deflate
>> ? ?9 TxHeader ? ? b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> ? ?9 TxHeader ? ? b Cookie:
>> _esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
>> s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
>> ? ?9 TxHeader ? ? b If-None-Match: "77386a2121be399962e6f8f70e5472a3"
>> ? ?9 TxHeader ? ? b X-Varnish: 1181355510
>> ? ?9 TxHeader ? ? b X-Forwarded-For: 127.0.0.1
>> ? ?7 Debug ? ? ? ?c "tag {include src="/esi" } 0 1 0"
>> ? ?7 Debug ? ? ? ?c "Incl " src="/esi" ""
>> ? ?9 RxProtocol ? b HTTP/1.1
>> ? ?9 RxStatus ? ? b 200
>> ? ?9 RxResponse ? b OK
>> ? ?9 RxHeader ? ? b Connection: close
>> ? ?9 RxHeader ? ? b Date: Mon, 30 Nov 2009 21:17:36 GMT
>> ? ?9 RxHeader ? ? b Status: 200
>> ? ?9 RxHeader ? ? b ETag: "974a5bab80a34a131da3a1975e35fc8c"
>> ? ?9 RxHeader ? ? b X-Runtime: 2
>> ? ?9 RxHeader ? ? b Content-Type: text/html; charset=utf-8
>> ? ?9 RxHeader ? ? b Content-Length: 148
>> ? ?9 RxHeader ? ? b Server: Mongrel 1.1.5
>> ? ?9 RxHeader ? ? b Cache-Control: private, max-age=0, must-revalidate
>> ? ?7 ObjProtocol ?c HTTP/1.1
>> ? ?7 ObjStatus ? ?c 200
>> ? ?7 ObjResponse ?c OK
>> ? ?7 ObjHeader ? ?c Date: Mon, 30 Nov 2009 21:17:36 GMT
>> ? ?7 ObjHeader ? ?c Status: 200
>> ? ?7 ObjHeader ? ?c ETag: "974a5bab80a34a131da3a1975e35fc8c"
>> ? ?7 ObjHeader ? ?c X-Runtime: 2
>> ? ?7 ObjHeader ? ?c Content-Type: text/html; charset=utf-8
>> ? ?7 ObjHeader ? ?c Server: Mongrel 1.1.5
>> ? ?7 ObjHeader ? ?c Cache-Control: private, max-age=0, must-revalidate
>> ? ?9 BackendClose b default
>> ? ?7 TTL ? ? ? ? ?c 1181355510 RFC 0 1259615856 0 0 0 0
>> ? ?7 VCL_call ? ? c fetch
>> ? ?7 VCL_info ? ? c XID 1181355510: obj.prefetch (-30) less than ttl
>> (-1.25962e+09), ignored.
>> ? ?7 VCL_return ? c deliver
>> ? ?7 Length ? ? ? c 148
>> ? ?7 VCL_call ? ? c deliver
>> ? ?7 VCL_return ? c deliver
>> ? ?7 TxProtocol ? c HTTP/1.1
>> ? ?7 TxStatus ? ? c 200
>> ? ?7 TxResponse ? c OK
>> ? ?7 TxHeader ? ? c Status: 200
>> ? ?7 TxHeader ? ? c ETag: "974a5bab80a34a131da3a1975e35fc8c"
>> ? ?7 TxHeader ? ? c X-Runtime: 2
>> ? ?7 TxHeader ? ? c Content-Type: text/html; charset=utf-8
>> ? ?7 TxHeader ? ? c Server: Mongrel 1.1.5
>> ? ?7 TxHeader ? ? c Cache-Control: private, max-age=0, must-revalidate
>> ? ?7 TxHeader ? ? c Transfer-Encoding: chunked
>> ? ?7 TxHeader ? ? c Date: Mon, 30 Nov 2009 21:17:36 GMT
>> ? ?7 TxHeader ? ? c X-Varnish: 1181355510
>> ? ?7 TxHeader ? ? c Age: 0
>> ? ?7 TxHeader ? ? c Via: 1.1 varnish
>> ? ?7 TxHeader ? ? c Connection: keep-alive
>> ? ?7 VCL_call ? ? c recv
>> ? ?7 VCL_return ? c pass
>> ? ?7 VCL_call ? ? c pass
>> ? ?7 VCL_return ? c pass
>> ? ?9 BackendOpen ?b default 127.0.0.1 55708 127.0.0.1 3000
>> ? ?7 Backend ? ? ?c 9 default default
>> ? ?9 TxRequest ? ?b GET
>> ? ?9 TxURL ? ? ? ?b /esi
>> ? ?9 TxProtocol ? b HTTP/1.1
>> ? ?9 TxHeader ? ? b Host: localhost:8080
>> ? ?9 TxHeader ? ? b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
>> OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
>> ? ?9 TxHeader ? ? b Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> ? ?9 TxHeader ? ? b Accept-Language: en-us,en;q=0.5
>> ? ?9 TxHeader ? ? b Accept-Encoding: gzip,deflate
>> ? ?9 TxHeader ? ? b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> ? ?9 TxHeader ? ? b Cookie:
>> _esi_session=BAh7BjoPc2Vzc2lvbl9pZCIlMWQxNGY3YjJjNjMyMWE4MjhiZDI2YjNjM2UzNDI5OTU%3D--e429b58563e05452b524f47628cb7d09817f91fb;
>> s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B
>> ? ?9 TxHeader ? ? b If-None-Match: "77386a2121be399962e6f8f70e5472a3"
>> ? ?9 TxHeader ? ? b X-Varnish: 1181355510
>> ? ?9 TxHeader ? ? b X-Forwarded-For: 127.0.0.1
>> ? ?9 RxProtocol ? b HTTP/1.1
>> ? ?9 RxStatus ? ? b 200
>> ? ?9 RxResponse ? b OK
>> ? ?9 RxHeader ? ? b Connection: close
>> ? ?9 RxHeader ? ? b Date: Mon, 30 Nov 2009 21:17:36 GMT
>> ? ?9 RxHeader ? ? b Status: 200
>> ? ?9 RxHeader ? ? b ETag: "e9ce710e9b09175301008aa45d94f96f"
>> ? ?9 RxHeader ? ? b X-Runtime: 2
>> ? ?9 RxHeader ? ? b Content-Type: text/html; charset=utf-8
>> ? ?9 RxHeader ? ? b Content-Length: 83
>> ? ?9 RxHeader ? ? b Server: Mongrel 1.1.5
>> ? ?9 RxHeader ? ? b Cache-Control: max-age=60, public
>> ? ?7 ObjProtocol ?c HTTP/1.1
>> ? ?7 ObjStatus ? ?c 200
>> ? ?7 ObjResponse ?c OK
>> ? ?7 ObjHeader ? ?c Date: Mon, 30 Nov 2009 21:17:36 GMT
>> ? ?7 ObjHeader ? ?c Status: 200
>> ? ?7 ObjHeader ? ?c ETag: "e9ce710e9b09175301008aa45d94f96f"
>> ? ?7 ObjHeader ? ?c X-Runtime: 2
>> ? ?7 ObjHeader ? ?c Content-Type: text/html; charset=utf-8
>> ? ?7 ObjHeader ? ?c Server: Mongrel 1.1.5
>> ? ?7 ObjHeader ? ?c Cache-Control: max-age=60, public
>> ? ?9 BackendClose b default
>> ? ?7 TTL ? ? ? ? ?c 1181355510 RFC 60 1259615856 0 0 60 0
>> ? ?7 VCL_call ? ? c fetch
>> ? ?7 VCL_return ? c deliver
>> ? ?7 Length ? ? ? c 83
>> ? ?7 VCL_call ? ? c deliver
>> ? ?7 VCL_return ? c deliver
>> ? ?7 ReqEnd ? ? ? c 1181355510 1259615856.047472000
>> 1259615856.069441080 6.975047112 0.021866083 0.000102997
>> ? ?7 ReqEnd ? ? ? c 0 1259615856.069535017 1259615856.069535017
>> 0.000093937 0.000000000 0.000000000
>> ? ?0 StatAddr ? ? - 127.0.0.1 0 3277 63 130 0 113 153 43622 18571
>>
>
>
>
> --
> Joe Van Dyk
> http://fixieconsulting.com
>



-- 
Joe Van Dyk
http://fixieconsulting.com