From andersb at vgnett.no Wed Mar 1 01:08:18 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 1 Mar 2006 02:08:18 +0100 (CET) Subject: notes1 In-Reply-To: <20060224125308.27584BC6D@phk.freebsd.dk> References: <20060224125308.27584BC6D@phk.freebsd.dk> Message-ID: <61114.193.213.34.102.1141175298.squirrel@denise.vg.no> I have been playing around with trying to structure/document the Configuration Language: http://klikk.vg.no/vcl.html I just wanna ask if I am wasting my time before I continue? Don't we need this in one form or another? Or have your rocket-speed fingers already done this Poul? Anders Berg > ----------------------------------------------------------------------- Configuration Language > XXX: include lines. > BNF: > program: function > | program function > function: "sub" function_name compound_statement > compound_statement: "{" statements "}" > statements: /* empty */ > | statement > | statements statement > statement: if_statement > | call_statement > | "finish" > | assignment_statement > | action_statement > if_statement: "if" condition compound_statement elif_parts else_part elif_parts: /* empty */ > | elif_part > | elif_parts elif_part > elif_part: "elseif" condition compound_statement > | "elsif" condition compound_statement > | "else if" condition compound_statement > else_part: /* empty */ > | "else" compound_statement > call_statement: "call" function_name > assign_statement: field "=" value > field: object > field "." variable > action_statement: action arguments > arguments: /* empty */ > arguments | argument > ----------------------------------------------------------------------- Sample request policy program > sub request_policy { > if (client.ip in 10.0.0.0/8) { > no-cache > finish > } > if (req.url.host ~ "cnn.no$") { > rewrite s/cnn.no$/vg.no/ > } > if (req.url.path ~ "cgi-bin") { > no-cache > } > if (req.useragent ~ "spider") { > no-new-cache > } > if (backend.response_time > 0.8s) { > set req.ttlfactor = 1.5 > } elseif (backend.response_time > 1.5s) { > set req.ttlfactor = 2.0 > } elseif (backend.response_time > 2.5s) { > set req.ttlfactor = 5.0 > } > /* > * the program contains no references to > * maxage, s-maxage and expires, so the > * default handling (RFC2616) applies > */ > } > ----------------------------------------------------------------------- Sample fetch policy program > sub backends { > set backend.vg.ip = {...} > set backend.ads.ip = {...} > set backend.chat.ip = {...} > set backend.chat.timeout = 10s > set backend.chat.bandwidth = 2000 MB/s > set backend.other.ip = {...} > } > sub vg_backend { > set backend.ip = {10.0.0.1-5} > set backend.timeout = 4s > set backend.bandwidth = 2000Mb/s > } > sub fetch_policy { > if (req.url.host ~ "/vg.no$/") { > set req.backend = vg > call vg_backend > } else { > /* XXX: specify 404 page url ? */ > error 404 > } > if (backend.response_time > 2.0s) { > if (req.url.path ~ "/landbrugspriser/") { > error 504 > } > } > fetch > if (backend.down) { > if (obj.exist) { > set obj.ttl += 10m > finish > } > switch_config ohhshit > } > if (obj.result == 404) { > error 300 "http://www.vg.no" > } > if (obj.result != 200) { > finish > } > if (obj.size > 256k) { > no-cache > } else if (obj.size > 32k && obj.ttl < 2m) { > obj.tll = 5m > } > if (backend.response_time > 2.0s) { > set ttl *= 2.0 > } > } > sub prefetch_policy { > if (obj.usage < 10 && obj.ttl < 5m) { > fetch > } > } > ----------------------------------------------------------------------- > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev From andersb at vgnett.no Sun Mar 5 22:50:37 2006 From: andersb at vgnett.no (Anders Berg) Date: Sun, 5 Mar 2006 23:50:37 +0100 Subject: Key dates Varnish Message-ID: Hi guys, threw together some dates that we could focus on. My guess is that it will be revised, but we might as well start somewhere. April 20. Progressmeeting, Denmark. June 1. Progressmeeting, Oslo. June 26-30. Livetest. July 10-28. Vacation? August 7-11. Livetest 2. August 14-17. Acceptancetest. August 18. Deliverydate. attached is also a iCal-file. I think Trac has support for that. Also, could I get some feedback on: http://klikk.vg.no/vcl.html its good to know I am not throwing away time before I continue and invent variables myself :) Do we need a page like this or not? I have also done some work on the "About" file that I might post later tonight. The "History" file is also near complete. YS Anders Berg From andersb at vgnett.no Mon Mar 6 00:04:53 2006 From: andersb at vgnett.no (Anders Berg) Date: Mon, 6 Mar 2006 01:04:53 +0100 (CET) Subject: "About" - page Message-ID: <62710.193.213.34.102.1141603493.squirrel@denise.vg.no> Did a mockup of how the "About" page could look: http://klikk.vg.no/varnish.html Have no fear, this is just a mockup :) Anders Berg From phk at phk.freebsd.dk Mon Mar 6 09:38:24 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 06 Mar 2006 09:38:24 +0000 Subject: "About" - page In-Reply-To: Your message of "Mon, 06 Mar 2006 01:04:53 +0100." <62710.193.213.34.102.1141603493.squirrel@denise.vg.no> Message-ID: <5036.1141637904@critter.freebsd.dk> In message <62710.193.213.34.102.1141603493.squirrel at denise.vg.no>, "Anders Ber g" writes: >Did a mockup of how the "About" page could look: > >http://klikk.vg.no/varnish.html > >Have no fear, this is just a mockup :) Wouldn't it be more clear if you showed two clients, the first one pulls from the backend and the second one gets cached result ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Mon Mar 6 09:41:52 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 06 Mar 2006 09:41:52 +0000 Subject: Key dates Varnish In-Reply-To: Your message of "Sun, 05 Mar 2006 23:50:37 +0100." Message-ID: <5050.1141638112@critter.freebsd.dk> In message , Anders Berg writes : >Hi guys, > >threw together some dates that we could focus on. My guess is that it >will be revised, but we might as well start somewhere. > >April 20. Progressmeeting, Denmark. >June 1. Progressmeeting, Oslo. >June 26-30. Livetest. >July 10-28. Vacation? >August 7-11. Livetest 2. >August 14-17. Acceptancetest. >August 18. Deliverydate. I've put them in my calendar and see no obvious conflicts, but as usual, I need to confirm with the ?berkommando before I can commit :-) >http://klikk.vg.no/vcl.html > >its good to know I am not throwing away time before I continue and >invent variables myself :) >Do we need a page like this or not? Yes, we will need a page like that. I've decided to tackle the "varnish programming language" compiler first because it gives us so much flexibility during development and test that not doing it first doesn't make sense. If you have time to write a couple of config files it would be great to have some "actual" test data :-) -- 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 des at linpro.no Mon Mar 6 09:44:50 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 06 Mar 2006 10:44:50 +0100 Subject: "About" - page References: <62710.193.213.34.102.1141603493.squirrel@denise.vg.no> Message-ID: "Anders Berg" writes: > Did a mockup of how the "About" page could look: > > http://klikk.vg.no/varnish.html I'd prefer a darker shade of red, but other than that, it looks great! DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vg.no Mon Mar 6 09:45:50 2006 From: andersb at vg.no (Anders Berg) Date: Mon, 06 Mar 2006 10:45:50 +0100 Subject: "About" - page In-Reply-To: <5036.1141637904@critter.freebsd.dk> References: < Your message of "Mon, 06 Mar 2006 01:04:53 +0100." <62710.193.213.34.102.1141603493.squirrel@denise.vg.no> Message-ID: <5.2.0.9.0.20060306104354.011bbc10@pop.vg.no> At 09:38 06.03.2006 +0000, Poul-Henning Kamp wrote: >In message <62710.193.213.34.102.1141603493.squirrel at denise.vg.no>, >"Anders Ber >g" writes: > >Did a mockup of how the "About" page could look: > > > >http://klikk.vg.no/varnish.html > > > >Have no fear, this is just a mockup :) > >Wouldn't it be more clear if you showed two clients, the first one >pulls from the backend and the second one gets cached result ? Yes, I'll sort that out. Anders Berg >-- >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. >_______________________________________________ >varnish-dev mailing list >varnish-dev at projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-dev ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From des at linpro.no Mon Mar 6 09:46:44 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 06 Mar 2006 10:46:44 +0100 Subject: Key dates Varnish References: Message-ID: Anders Berg writes: > threw together some dates that we could focus on. My guess is that > it will be revised, but we might as well start somewhere. > > April 20. Progressmeeting, Denmark. > June 1. Progressmeeting, Oslo. > June 26-30. Livetest. > July 10-28. Vacation? > August 7-11. Livetest 2. > August 14-17. Acceptancetest. > August 18. Deliverydate. > > attached is also a iCal-file. I think Trac has support for that. It can only export milestones in iCal format, not import - and besides, mailman strips all attachments that have a mime-type that doesn't start with "text/". I'll punch them in. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Mon Mar 6 09:47:37 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 06 Mar 2006 10:47:37 +0100 Subject: notes1 References: <20060224125308.27584BC6D@phk.freebsd.dk> <61114.193.213.34.102.1141175298.squirrel@denise.vg.no> Message-ID: "Anders Berg" writes: > I have been playing around with trying to structure/document the > Configuration Language: > > http://klikk.vg.no/vcl.html > > I just wanna ask if I am wasting my time before I continue? As long as you're not doing it while your squid servers are on fire :) DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Mar 2 11:58:12 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 02 Mar 2006 11:58:12 +0000 Subject: quick questions... Message-ID: <17763.1141300692@critter.freebsd.dk> SVN version 1.3 from ports is what I should use ? Any magic parameters I need to know ? Are there changes from svn1.2 (as documented in the book) to svn1.3 that I should know about ? -- 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 des at linpro.no Mon Mar 6 11:04:59 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 06 Mar 2006 12:04:59 +0100 Subject: quick questions... References: <17763.1141300692@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > SVN version 1.3 from ports is what I should use ? Yes. > Any magic parameters I need to know ? Nope. > Are there changes from svn1.2 (as documented in the book) to svn1.3 > that I should know about ? Nothing you will notice; most of the differences are on the server side and in code internals. There is a summary here: http://subversion.tigris.org/svn_1.3_releasenotes.html DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Mon Mar 6 18:18:36 2006 From: andersb at vgnett.no (Anders Berg) Date: Mon, 6 Mar 2006 19:18:36 +0100 (CET) Subject: "About" - page In-Reply-To: <5036.1141637904@critter.freebsd.dk> References: Your message of "Mon, 06 Mar 2006 01:04:53 +0100." <62710.193.213.34.102.1141603493.squirrel@denise.vg.no> <5036.1141637904@critter.freebsd.dk> Message-ID: <62966.193.213.34.102.1141669116.squirrel@denise.vg.no> > In message <62710.193.213.34.102.1141603493.squirrel at denise.vg.no>, > "Anders Ber > g" writes: >>Did a mockup of how the "About" page could look: >> >>http://klikk.vg.no/varnish.html >> >>Have no fear, this is just a mockup :) > > Wouldn't it be more clear if you showed two clients, the first one > pulls from the backend and the second one gets cached result ? Updated http://klikk.vg.no/varnish.html to something more like you described Poul-Henning. Guess its more pedantic. Getting closer? Ab > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > > From phk at phk.freebsd.dk Mon Mar 6 20:08:24 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 06 Mar 2006 20:08:24 +0000 Subject: "About" - page In-Reply-To: Your message of "Mon, 06 Mar 2006 19:18:36 +0100." <62966.193.213.34.102.1141669116.squirrel@denise.vg.no> Message-ID: <7324.1141675704@critter.freebsd.dk> In message <62966.193.213.34.102.1141669116.squirrel at denise.vg.no>, "Anders Ber g" writes: >> In message <62710.193.213.34.102.1141603493.squirrel at denise.vg.no>, >> "Anders Ber >> g" writes: >>>Did a mockup of how the "About" page could look: >>> >>>http://klikk.vg.no/varnish.html >>> >>>Have no fear, this is just a mockup :) >> >> Wouldn't it be more clear if you showed two clients, the first one >> pulls from the backend and the second one gets cached result ? > >Updated http://klikk.vg.no/varnish.html to something more like you >described Poul-Henning. Guess its more pedantic. Getting closer? Much more instructive :-) -- 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 andersb at vgnett.no Tue Mar 7 00:55:49 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 7 Mar 2006 01:55:49 +0100 (CET) Subject: Key dates Varnish In-Reply-To: <5050.1141638112@critter.freebsd.dk> References: Your message of "Sun, 05 Mar 2006 23:50:37 +0100." <5050.1141638112@critter.freebsd.dk> Message-ID: <1947.193.213.34.102.1141692949.squirrel@denise.vg.no> > In message , Anders Berg > writes > : >>Hi guys, >> >>threw together some dates that we could focus on. My guess is that it >>will be revised, but we might as well start somewhere. >> >>April 20. Progressmeeting, Denmark. >>June 1. Progressmeeting, Oslo. >>June 26-30. Livetest. >>July 10-28. Vacation? >>August 7-11. Livetest 2. >>August 14-17. Acceptancetest. >>August 18. Deliverydate. > > I've put them in my calendar and see no obvious conflicts, but as > usual, I need to confirm with the ?berkommando before I can > commit :-) Great :) Need to do the same. First of the vacation bit can be "tricky". Secondly, the deliver date is so close to my weedingdate (when I get to be a small department in the ?berkommando, 26. August) that it may cause some problems there. >>http://klikk.vg.no/vcl.html >> >>its good to know I am not throwing away time before I continue and >>invent variables myself :) >>Do we need a page like this or not? > > Yes, we will need a page like that. > > I've decided to tackle the "varnish programming language" compiler > first because it gives us so much flexibility during development and > test that not doing it first doesn't make sense. I agree. Done some more work on: http://klikk.vg.no/vcl.html But I am having trouble to structure the document right. > If you have time to write a couple of config files it would be great > to have some "actual" test data :-) Yes, when the "varnish programming language" is more defined I will write some mockups. Anders Berg > -- > 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 andersb at vgnett.no Tue Mar 7 01:01:08 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 7 Mar 2006 02:01:08 +0100 (CET) Subject: "About" - page In-Reply-To: References: <62710.193.213.34.102.1141603493.squirrel@denise.vg.no> Message-ID: <2022.193.213.34.102.1141693268.squirrel@denise.vg.no> > "Anders Berg" writes: >> Did a mockup of how the "About" page could look: >> >> http://klikk.vg.no/varnish.html > > I'd prefer a darker shade of red, but other than that, it looks great! Your wish is gonna be granted :) Right now I am just using "red" and "#FF0000" to make things visible to the extent of possible eye-damage. The visuals are beeing sorted out with time from VG designers. The mockups are more for content than visuals. Anders Berg > DES > -- > Dag-Erling Sm?rgrav > Senior Software Developer > Linpro AS - www.linpro.no > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Tue Mar 7 08:21:15 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 07 Mar 2006 08:21:15 +0000 Subject: Key dates Varnish In-Reply-To: Your message of "Tue, 07 Mar 2006 01:55:49 +0100." <1947.193.213.34.102.1141692949.squirrel@denise.vg.no> Message-ID: <9843.1141719675@critter.freebsd.dk> In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders Berg " writes: >>>http://klikk.vg.no/vcl.html >> I've decided to tackle the "varnish programming language" compiler Varnish Configuration Language makes more sense, it is less frightening that a "programming language". >But I am having trouble to structure the document right. I actually like it, we will need a reference document like that at the end. Here are some comments: no-cache -> no_cache no-new-cache -> no_new_cache I realized that it is easier if I don't have to check for double meaning of '-' so lets use underscore instead. req.ttlfactor I actually wanted to have one per request also, so that it is possible to decide that somebody isn't very important. (microsoft proxy thing) req.backend Not sure what I was thinking. -- 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 des at linpro.no Tue Mar 7 08:59:04 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 07 Mar 2006 09:59:04 +0100 Subject: "About" - page References: <62710.193.213.34.102.1141603493.squirrel@denise.vg.no> <5036.1141637904@critter.freebsd.dk> <62966.193.213.34.102.1141669116.squirrel@denise.vg.no> Message-ID: "Anders Berg" writes: > Updated http://klikk.vg.no/varnish.html to something more like you > described Poul-Henning. Guess its more pedantic. Getting closer? I'd replace "request for same file" with "subsequent request". You've also spelled "document" with a k in one place :) You should also use PNG (or GIF) instead of JPG to avoid compression artifacts. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Tue Mar 7 09:57:49 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 7 Mar 2006 10:57:49 +0100 (CET) Subject: Key dates Varnish In-Reply-To: <9843.1141719675@critter.freebsd.dk> References: Your message of "Tue, 07 Mar 2006 01:55:49 +0100." <1947.193.213.34.102.1141692949.squirrel@denise.vg.no> <9843.1141719675@critter.freebsd.dk> Message-ID: <1231.193.213.34.102.1141725469.squirrel@denise.vg.no> > In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders > Berg > " writes: > >>>>http://klikk.vg.no/vcl.html > >>> I've decided to tackle the "varnish programming language" compiler > > Varnish Configuration Language makes more sense, it is less frightening > that a "programming language". Yes. I would guess so. >>But I am having trouble to structure the document right. > > I actually like it, we will need a reference document like that at the > end. > > Here are some comments: > > no-cache -> no_cache > no-new-cache -> no_new_cache > I realized that it is easier if I don't have to check > for double meaning of '-' so lets use underscore instead. > > req.ttlfactor > I actually wanted to have one per request also, so that > it is possible to decide that somebody isn't very important. > (microsoft proxy thing) > > req.backend > Not sure what I was thinking. Fixed. One thing that eluded me so far is how we are gonna configure the storage backend(s). Are we looking at something like: storage.type = disk|memory storage.size = 200M storage.depth = 16 256 storage.algorithm = LRU But that means they must be configurable in runtime. What happens when one changes: storage.type = disk -> storage.type = memory ? Or is this gonna be implemented from the commandline tool and part of the managment protocol? Anyone have any thoughts? Ab > -- > 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 andersb at vgnett.no Tue Mar 7 09:58:12 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 7 Mar 2006 10:58:12 +0100 (CET) Subject: "About" - page In-Reply-To: References: <62710.193.213.34.102.1141603493.squirrel@denise.vg.no><5036.1141637904@critter.freebsd.dk><62966.193.213.34.102.1141669116.squirrel@denise.vg.no> Message-ID: <1235.193.213.34.102.1141725492.squirrel@denise.vg.no> > "Anders Berg" writes: >> Updated http://klikk.vg.no/varnish.html to something more like you >> described Poul-Henning. Guess its more pedantic. Getting closer? > > I'd replace "request for same file" with "subsequent request". You've > also spelled "document" with a k in one place :) > > You should also use PNG (or GIF) instead of JPG to avoid compression > artifacts. Fixed. Anders Berg > DES > -- > Dag-Erling Sm?rgrav > Senior Software Developer > Linpro AS - www.linpro.no > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Tue Mar 7 10:00:29 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 07 Mar 2006 10:00:29 +0000 Subject: Key dates Varnish In-Reply-To: Your message of "Tue, 07 Mar 2006 10:57:49 +0100." <1231.193.213.34.102.1141725469.squirrel@denise.vg.no> Message-ID: <10387.1141725629@critter.freebsd.dk> In message <1231.193.213.34.102.1141725469.squirrel at denise.vg.no>, "Anders Berg " writes: >Fixed. One thing that eluded me so far is how we are gonna configure the >storage backend(s). > >Or is this gonna be implemented from the commandline tool and part of the >managment protocol? > Yes. Storage will be defined with command line args or if that gets too unweildy, with a traditional config file for the management process. -- 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 andersb at vgnett.no Wed Mar 8 00:43:19 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 8 Mar 2006 01:43:19 +0100 (CET) Subject: Storage configuration/Varnish configuration language In-Reply-To: <10387.1141725629@critter.freebsd.dk> References: Your message of "Tue, 07 Mar 2006 10:57:49 +0100." <1231.193.213.34.102.1141725469.squirrel@denise.vg.no> <10387.1141725629@critter.freebsd.dk> Message-ID: <62714.193.213.34.102.1141778599.squirrel@denise.vg.no> > In message <1231.193.213.34.102.1141725469.squirrel at denise.vg.no>, "Anders > Berg > " writes: > > >>Fixed. One thing that eluded me so far is how we are gonna configure the >>storage backend(s). >> >>Or is this gonna be implemented from the commandline tool and part of the >>managment protocol? >> > > Yes. > > Storage will be defined with command line args or if that gets too > unweildy, with a traditional config file for the management process. Okay, I can see how that might turn out unweildy. Either way, a Varnish configuration must exist on every node anyway, if not for any other purpose than to know the IP address of the managment node. The reason I asked was to see if we might need storage commands in the Varnish Configuration Language. if (storage.freespace < 200MB){ if (obj.size > 200MB){ no_cache } } http://klikk.vg.no/vcl.html is updated some, and I put some notes under the Object table. Anders Berg > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > > From phk at phk.freebsd.dk Fri Mar 10 10:04:16 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 10 Mar 2006 11:04:16 +0100 Subject: This VCL compiler thing... Message-ID: <6654.1141985056@critter.freebsd.dk> ... is moving nicely along. I have made some changes to the syntax relative to what we talked about at the meeting, mostly in order to be able to make the compiler simpler and to give better error messages. First of all, I have given all actions a trailing semi-colon. In case of syntax errors, that will stop the compiler from trying to make sense of subsequent tokens and that will hopefully limit the amount of non-sense errors emitted in that case. I have also decided that all assignments will start out with the keyword "set". Finally I have decided to enforce proper types and units throughout, so if you compare a time variable, you must specify the units: if (obj.ttl < 10m) etc. I have added explicit backend declarations: backend vg { set backend.ip = 10.0.0.1, 10.0.0.2, 10.0.0.3; set backend.timeout = 4s; set backend.bandwidth = 2000Mb/s; } because we need a data structure for each backend. And this gets me to the something which is a sticky point right now: IP numbers and IP lists. With respect to backends, I think we need to declare them individually because things like response time etc is per backend and not shared for the cluster of backends. In the above example that would restrict us to giving one IP#. (We can later expand this to a concept of backend clusters but I need time to think about data structures before I make up my mind. The other thing is matching against IP lists, I think from both a code and configuration point of view it makes sense to declare IP access lists explicitly, so that instead of if (client.ip ~ {10.0.0.0/8,172.16.0,0/12,192.168.0.0/16}) { ... it would be written Acl Rfc1918 { 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 } ... if (client.ip ~ rfc1918) { ... But I would still allow comparison to a single IP: if (client.ip = 10.0.1.2) { ... Still thinking about this though... The compiler so far is 900 lines of C-code and a 170 line tcl script to generate some C-code for keyword recognition. Attached a sample config file and the compiled output as it looks right now: begin 664 sample.vcl M"G-U8B!R97%U97-T7W!O;&EC>2!["@H):68@*&-L:65N="YI<"!^(#$P+C`N M,"XP+S at I('L*"0EN;U]C86-H93L*"0EF:6YIPH)"7)E=W)I=&4@(F-N;BYN;R0B(")V M9RYN;R(["@E]"@H):68@*')E<2YUPH) M"6YO7V-A8VAE.PH)?0H*"6EF("AR97$N=7-EPH)"7-E="!R97$N='1L9F%C=&]R M(#T@,2XU.PH)?2!E;'-E:68@*&)A8VME;F0N&%G92P@PH)PH)"7-E="!R97$N8F%C:V5N9"`]('9G.PH)?2!E;'-E('L*"0DO*B!86%@Z M('-P96-I9GD at -#`T('!A9V4@=7)L(#\@*B\*"0EEPH)"0EC86QL(&)A M:6P["@D)?0H)?0H)9F5T8V@["@EI9B`H8F%C:V5N9"YD;W=N*2!["@D):68@ M*&]B:BYE>&ES="D@>PH)"0ES970@;V)J+G1T;"`K/2`Q,&T["@D)"69I;FES M:#L*"0E]"@D)PH*"6EF("AO8FHN=7-A9V4@/"`Q,"`F)B!O8FHN='1L 7(#P at -6TI('L*"0EF971C:#L*"7T*?0H` ` end begin 664 sample.c M+B]V<&, at +VUN="]P:&LO5F%R;FES:"]60TPOPHO*B!)9E-T M;70@("`@("`J+R`@(&EF(`HO*B!#;VYD:71I;VYA;"`J+R`@("`@*`HO*B!# M;VYD7S`@("`@("`J+R`@("`@("`H"B\J($-O;F1?,2`@("`@("HO("`@("`@ M("`@*`HO*B!#;VYD7S(@("`@("`J+R`@("`@("`@("`@*`I)4$P at 6PI=($E0 M3`HO*B!#;VYD7S(@("`@("`J+R`@("`@("`@("`@*0HO*B!#;VYD7S$@("`@ M("`J+R`@("`@("`@("D*+RH at 0V]N9%\P("`@("`@*B\@("`@("`@*0HO*B!# M;VYD:71I;VYA;"`J+R`@("`@*0HO*B!#;VUP;W5N9"`@("`J+R`@("`@>PHO M*B!!8W1I;VX@("`@("`J+R`@("`@5D-,7VYO7V-A8VAE*"D["B\J($%C=&EO M;B`@("`@("HO("`@("!R971UPHO*B!!8W1I;VX@("`@("`J+R`@("`@5D-,7VYO7VYE M=U]C86-H92 at I.PHO*B!#;VUP;W5N9"`@("`J+R`@("`@?0HO*B!)9E-T;70@ M("`@("`J+R`@(&EF(`HO*B!#;VYD:71I;VYA;"`J+R`@("`@*`HO*B!#;VYD M7S`@("`@("`J+R`@("`@("`H"B\J($-O;F1?,2`@("`@("HO("`@("`@("`@ M*`HO*B!#;VYD7S(@("`@("`J+R`@("`@("`@("`@*`HO*B!#;VYD7TEN="`@ M("`J+R`@("`@("`@("`@("!B86-K96YD+G)EPHO M*B!!8W1I;VX@("`@("`J+R`@(&)A8VME;F0N:7`@25!,(%L*72!)4$P*"B\J M($%C=&EO;B`@("`@("HO("`@8F%C:V5N9"YT:6UE;W5T(#T@*#0@*B`Q*3L* M+RH at 06-T:6]N("`@("`@*B\@("!B86-K96YD+F)A;F1W:61T:"`]("@R,#`P M("H@,2XP-#@U.&4K,#8I.PHO*B!#;VUP;W5N9"`@("`J+R`@('T*+RH at 1G5N M8W1I;VX@("`@*B\@PHO*B!!8W1I;VX@("`@("`J+R`@ M(%9#3%]EPHO*B!)9E-T;70@("`@ M("`J+R`@(&EF(`HO*B!#;VYD:71I;VYA;"`J+R`@("`@*`HO*B!#;VYD7S`@ M("`@("`J+R`@("`@("`H"B\J($-O;F1?,2`@("`@("HO("`@("`@("`@*`HO M*B!#;VYD7S(@("`@("`J+R`@("`@("`@("`@*`HO*B!#;VYD7U-TPHO*B!!8W1I;VX@("`@("`J+R`@("`@("!60TQ? M9G5N8W1I;VY?8F%I;"@I.PHO*B!#;VUP;W5N9"`@("`J+R`@("`@("!]"B\J M($-O;7!O=6YD("`@("HO("`@("!]"B\J($%C=&EO;B`@("`@("HO("`@5D-, M7V9E=&-H*"D["B\J($EF4W1M="`@("`@("HO("`@:68@"B\J($-O;F1I=&EO M;F%L("HO("`@("`H"B\J($-O;F1?,"`@("`@("HO("`@("`@("@*+RH at 0V]N M9%\Q("`@("`@*B\@("`@("`@("`H"B\J($-O;F1?,B`@("`@("HO("`@("`@ M("`@("`H"B\J($-O;F1?,B`@("`@("HO("`@("`@("`@("`I"B\J($-O;F1? M,2`@("`@("HO("`@("`@("`@*0HO*B!#;VYD7S`@("`@("`J+R`@("`@("`I M"B\J($-O;F1I=&EO;F%L("HO("`@("`I"B\J($-O;7!O=6YD("`@("HO("`@ M("!["B\J($EF4W1M="`@("`@("HO("`@("!I9B`*+RH at 0V]N9&ET:6]N86P@ M*B\@("`@("`@*`HO*B!#;VYD7S`@("`@("`J+R`@("`@("`@("@*+RH at 0V]N M9%\Q("`@("`@*B\@("`@("`@("`@("@*+RH at 0V]N9%\R("`@("`@*B\@("`@ M("`@("`@("`@*`HO*B!#;VYD7S(@("`@("`J+R`@("`@("`@("`@("`I"B\J M($-O;F1?,2`@("`@("HO("`@("`@("`@("`I"B\J($-O;F1?,"`@("`@("HO M("`@("`@("`@*0HO*B!#;VYD:71I;VYA;"`J+R`@("`@("`I"B\J($-O;7!O M=6YD("`@("HO("`@("`@('L*+RH at 06-T:6]N("`@("`@*B\@("`@("`@;V)J M+G1T;"`K/2`H,3`@*B`V,"D["B\J($%C=&EO;B`@("`@("HO("`@("`@(')E M='5R;CL*+RH at 0V]M<&]U;F0@("`@*B\@("`@("`@?0HO*B!!8W1I;VX@("`@ M("`J+R`@("`@5D-,7W-W:71C:%]C;VYF:6F4@/B`H,C4V("H@,3`R-"D*+RH at 0V]N9%\R("`@("`@*B\@("`@("`@ M("`@("D*+RH at 0V]N9%\Q("`@("`@*B\@("`@("`@("`I"B\J($-O;F1?,"`@ M("`@("HO("`@("`@("D*+RH at 0V]N9&ET:6]N86P@*B\@("`@("D*+RH at 0V]M M<&]U;F0@("`@*B\@("`@('L*+RH at 06-T:6]N("`@("`@*B\@("`@(%9#3%]N M;U]C86-H92 at I.PHO*B!#;VUP;W5N9"`@("`J+R`@("`@?0HO*B!)9E-T;70@ M("`@("`J+R`@(&5L2`H=F]I M9"D*+RH at 0V]M<&]U;F0@("`@*B\@("!["B\J($EF4W1M="`@("`@("HO("`@ M:68@"B\J($-O;F1I=&EO;F%L("HO("`@("`H"B\J($-O;F1?,"`@("`@("HO M("`@("`@("@*+RH at 0V]N9%\Q("`@("`@*B\@("`@("`@("`H"B\J($-O;F1? M,B`@("`@("HO("`@("`@("`@("`H"B\J($-O;F1?26YT("`@("HO("`@("`@ M("`@("`@(&]B:BYU Message-ID: "Poul-Henning Kamp" writes: > Finally I have decided to enforce proper types and units throughout, > so if you compare a time variable, you must specify the units: > > if (obj.ttl < 10m) Excellent. I thought about this, but forgot to mention it. It gives us all the advantages of Hungarian notation without any of the disadvantages (such as having to use Hungarian notation) :) > The compiler so far is 900 lines of C-code and a 170 line tcl script > to generate some C-code for keyword recognition. I imagine the Tcl script will be replaced with lex/yacc at some point? DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Fri Mar 10 12:05:36 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 10 Mar 2006 13:05:36 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Fri, 10 Mar 2006 12:38:43 +0100." Message-ID: <7299.1141992336@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >"Poul-Henning Kamp" writes: >> Finally I have decided to enforce proper types and units throughout, >> so if you compare a time variable, you must specify the units: >> >> if (obj.ttl < 10m) > >Excellent. I thought about this, but forgot to mention it. It gives >us all the advantages of Hungarian notation without any of the >disadvantages (such as having to use Hungarian notation) :) :-) >> The compiler so far is 900 lines of C-code and a 170 line tcl script >> to generate some C-code for keyword recognition. > >I imagine the Tcl script will be replaced with lex/yacc at some point? My plan was to run the tcl script by hand and check both the script and the result into the tree. -- 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 des at linpro.no Fri Mar 10 12:16:39 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Fri, 10 Mar 2006 13:16:39 +0100 Subject: This VCL compiler thing... References: <7299.1141992336@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Dag-Erling Sm?rgrav?= writes: > > I imagine the Tcl script will be replaced with lex/yacc at some point? > My plan was to run the tcl script by hand and check both the script > and the result into the tree. OK. We can convert it to lex/yacc at some later date - as long as Tcl does not become a build dependency. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Fri Mar 10 12:19:36 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 10 Mar 2006 13:19:36 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Fri, 10 Mar 2006 13:16:39 +0100." Message-ID: <7527.1141993176@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >"Poul-Henning Kamp" writes: >> Dag-Erling Sm=F8rgrav?=3D writes: >> > I imagine the Tcl script will be replaced with lex/yacc at some point? >> My plan was to run the tcl script by hand and check both the script >> and the result into the tree. > >OK. We can convert it to lex/yacc at some later date - as long as Tcl >does not become a build dependency. lex/yacc would be a major pain in this context. It would be easier to convert the tcl script to $some_other_scripting_language instead of tcl. But for now, don't sweat it, tcl will not be a build dependency. -- 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 andersb at vgnett.no Sat Mar 11 16:09:13 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 11 Mar 2006 17:09:13 +0100 (CET) Subject: This VCL compiler thing... In-Reply-To: <6654.1141985056@critter.freebsd.dk> References: <6654.1141985056@critter.freebsd.dk> Message-ID: <1420.193.213.34.102.1142093353.squirrel@denise.vg.no> > > ... is moving nicely along. > > I have made some changes to the syntax relative to what we talked > about at the meeting, mostly in order to be able to make the compiler > simpler and to give better error messages. I have no objections to any of the changes. In fact I find working with ACL's and "strict" configurations good. It may take some more time to configure, but the gain is that it is easy to debug from a sys.adm point of view and easier for people from the "outside" to see what you have done. Also it tends to be accurate in the sense that with "strict" notations, you more seldom experience "Wow, I thought I did something else there". Anders Berg > First of all, I have given all actions a trailing semi-colon. > In case of syntax errors, that will stop the compiler from trying to > make sense of subsequent tokens and that will hopefully limit the > amount of non-sense errors emitted in that case. > > I have also decided that all assignments will start out with the > keyword "set". > > Finally I have decided to enforce proper types and units throughout, > so if you compare a time variable, you must specify the units: > > if (obj.ttl < 10m) > > etc. > > I have added explicit backend declarations: > > backend vg { > set backend.ip = 10.0.0.1, 10.0.0.2, 10.0.0.3; > set backend.timeout = 4s; > set backend.bandwidth = 2000Mb/s; > } > > because we need a data structure for each backend. > > And this gets me to the something which is a sticky point right > now: IP numbers and IP lists. > > With respect to backends, I think we need to declare them individually > because things like response time etc is per backend and not shared > for the cluster of backends. In the above example that would > restrict us to giving one IP#. (We can later expand this to a > concept of backend clusters but I need time to think about data structures > before I make up my mind. > > The other thing is matching against IP lists, I think from both a code > and configuration point of view it makes sense to declare IP access lists > explicitly, so that instead of > > if (client.ip ~ {10.0.0.0/8,172.16.0,0/12,192.168.0.0/16}) { ... > > it would be written > > Acl Rfc1918 { > 10.0.0.0/8 > 172.16.0.0/12 > 192.168.0.0/16 > } > ... > > if (client.ip ~ rfc1918) { ... > > But I would still allow comparison to a single IP: > > if (client.ip = 10.0.1.2) { ... > > Still thinking about this though... > > The compiler so far is 900 lines of C-code and a 170 line tcl script > to generate some C-code for keyword recognition. > > Attached a sample config file and the compiled output as it > looks right now: > > -- > 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. > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Mon Mar 13 09:43:18 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Mar 2006 10:43:18 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Sat, 11 Mar 2006 17:09:13 +0100." <1420.193.213.34.102.1142093353.squirrel@denise.vg.no> Message-ID: <14614.1142242998@critter.freebsd.dk> In message <1420.193.213.34.102.1142093353.squirrel at denise.vg.no>, "Anders Berg " writes: I know some people are quite religious about error messages, so here are a couple of samples from the VCL compiler: Unreferenced function 'request_policy', first mention is Line 8 Pos 4 sub request_policy { ----##############-- Unknown variable 'obj.bandwidth' At: Line 88 Pos 12 if (obj.bandwidth < 1 kb/h) { ------------#############------------ Assignments not possible for 'backend.down' Line 88 Pos 25 set backend.down = 1; -------------------------#--- Expected action, 'if' or '}' Line 88 Pos 8 backend.down = 1; --------############----- Syntax error at Line 80 Pos 13 fetch@; -------------#- Is that livable ? -- 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 des at linpro.no Mon Mar 13 09:53:38 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 13 Mar 2006 10:53:38 +0100 Subject: This VCL compiler thing... References: <14614.1142242998@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I know some people are quite religious about error messages, so here > are a couple of samples from the VCL compiler: > > > Unreferenced function 'request_policy', first mention is > Line 8 Pos 4 > sub request_policy { > ----##############-- > > > Unknown variable 'obj.bandwidth' > At: Line 88 Pos 12 > if (obj.bandwidth < 1 kb/h) { > ------------#############------------ > > > Assignments not possible for 'backend.down' > Line 88 Pos 25 > set backend.down = 1; > -------------------------#--- > > > Expected action, 'if' or '}' > Line 88 Pos 8 > backend.down = 1; > --------############----- > > > Syntax error at > Line 80 Pos 13 > fetch@; > -------------#- > > Is that livable ? Good enough for government work. We can add a command-line option later to generate editor-friendly error messages. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vg.no Mon Mar 13 09:55:14 2006 From: andersb at vg.no (Anders Berg) Date: Mon, 13 Mar 2006 10:55:14 +0100 Subject: This VCL compiler thing... In-Reply-To: <14614.1142242998@critter.freebsd.dk> References: < Your message of "Sat, 11 Mar 2006 17:09:13 +0100." <1420.193.213.34.102.1142093353.squirrel@denise.vg.no> Message-ID: <5.2.0.9.0.20060313104755.0339a8a8@pop.vg.no> They satisfy me. Line, Pos and errortype. If I am not mistaken getting more "humanreadable" error's is just a matter of spending alot of time in the C code, without really changing the logic of your parsercode and testing iteration after iteration? If that is the case, I say move on :) Anders Berg At 10:43 13.03.2006 +0100, Poul-Henning Kamp wrote: >In message <1420.193.213.34.102.1142093353.squirrel at denise.vg.no>, "Anders >Berg >" writes: > >I know some people are quite religious about error messages, so here >are a couple of samples from the VCL compiler: > > > Unreferenced function 'request_policy', first mention is > Line 8 Pos 4 > sub request_policy { > ----##############-- > > > Unknown variable 'obj.bandwidth' > At: Line 88 Pos 12 > if (obj.bandwidth < 1 kb/h) { > ------------#############------------ > > > Assignments not possible for 'backend.down' > Line 88 Pos 25 > set backend.down = 1; > -------------------------#--- > > > Expected action, 'if' or '}' > Line 88 Pos 8 > backend.down = 1; > --------############----- > > > Syntax error at > Line 80 Pos 13 > fetch@; > -------------#- > >Is that livable ? > >-- >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. >_______________________________________________ >varnish-dev mailing list >varnish-dev at projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-dev ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From phk at phk.freebsd.dk Mon Mar 13 09:56:49 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Mar 2006 10:56:49 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Mon, 13 Mar 2006 10:55:14 +0100." <5.2.0.9.0.20060313104755.0339a8a8@pop.vg.no> Message-ID: <14676.1142243809@critter.freebsd.dk> In message <5.2.0.9.0.20060313104755.0339a8a8 at pop.vg.no>, Anders Berg writes: >They satisfy me. > >Line, Pos and errortype. > >If I am not mistaken getting more "humanreadable" error's is just a matter >of spending alot of time in the C code, without really changing the logic >of your parsercode and testing iteration after iteration? If that is the >case, I say move on :) Yes, the actual errors are just a matter of printf calls. -- 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 andersb at vg.no Mon Mar 13 10:05:29 2006 From: andersb at vg.no (Anders Berg) Date: Mon, 13 Mar 2006 11:05:29 +0100 Subject: This VCL compiler thing... In-Reply-To: <14676.1142243809@critter.freebsd.dk> References: < Your message of "Mon, 13 Mar 2006 10:55:14 +0100." <5.2.0.9.0.20060313104755.0339a8a8@pop.vg.no> Message-ID: <5.2.0.9.0.20060313110024.033ffd78@pop.vg.no> It also accured to me that we could link the errors to the error documentation. Unreferenced function 'request_policy', first mention is Line 8 Pos 4 sub request_policy { ----##############-- Read more about this type of error: http://varnish/doc/error.html#Unreferenced%20function Unknown variable 'obj.bandwidth' At: Line 88 Pos 12 if (obj.bandwidth < 1 kb/h) { ------------#############------------ Read more about this type of error: http://varnish/doc/error.html#Unknown%20variable or something of the likes. I think that is easy to implement and would help people that may be stuck. Just throw in some links, so we will remember to document them later when we see the errors. Anders Berg At 10:56 13.03.2006 +0100, Poul-Henning Kamp wrote: >In message <5.2.0.9.0.20060313104755.0339a8a8 at pop.vg.no>, Anders Berg writes: > >They satisfy me. > > > >Line, Pos and errortype. > > > >If I am not mistaken getting more "humanreadable" error's is just a matter > >of spending alot of time in the C code, without really changing the logic > >of your parsercode and testing iteration after iteration? If that is the > >case, I say move on :) > >Yes, the actual errors are just a matter of printf calls. > >-- >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. ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From phk at phk.freebsd.dk Mon Mar 13 10:20:16 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Mar 2006 11:20:16 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Mon, 13 Mar 2006 11:05:29 +0100." <5.2.0.9.0.20060313110024.033ffd78@pop.vg.no> Message-ID: <14773.1142245216@critter.freebsd.dk> In message <5.2.0.9.0.20060313110024.033ffd78 at pop.vg.no>, Anders Berg writes: >It also accured to me that we could link the errors to the error documentation. > >Unreferenced function 'request_policy', first mention is > Line 8 Pos 4 > sub request_policy { > ----##############-- >Read more about this type of error: >http://varnish/doc/error.html#Unreferenced%20function > > > Unknown variable 'obj.bandwidth' > At: Line 88 Pos 12 > if (obj.bandwidth < 1 kb/h) { > ------------#############------------ >Read more about this type of error: >http://varnish/doc/error.html#Unknown%20variable Good idea. -- 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 des at linpro.no Mon Mar 13 10:40:36 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 13 Mar 2006 11:40:36 +0100 Subject: This VCL compiler thing... References: < Your message of "Mon, 13 Mar 2006 10:55:14 +0100." <5.2.0.9.0.20060313104755.0339a8a8@pop.vg.no> <5.2.0.9.0.20060313110024.033ffd78@pop.vg.no> Message-ID: Anders Berg writes: > It also accured to me that we could link the errors to the error > documentation. [...] I think that is easy to implement and would > help people that may be stuck. Just throw in some links, so we will > remember to document them later when we see the errors. If Poul-Henning makes up a keyword for each type of error and places the link in the error message, I'll write the documentation. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Mar 13 11:58:16 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Mar 2006 12:58:16 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Mon, 13 Mar 2006 11:40:36 +0100." Message-ID: <15323.1142251096@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >Anders Berg writes: >> It also accured to me that we could link the errors to the error >> documentation. [...] I think that is easy to implement and would >> help people that may be stuck. Just throw in some links, so we will >> remember to document them later when we see the errors. > >If Poul-Henning makes up a keyword for each type of error and places >the link in the error message, I'll write the documentation. I would prefer we don't spend too much time until we know more about what the language will look like and do in practice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Mon Mar 13 12:44:02 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Mar 2006 13:44:02 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Mon, 13 Mar 2006 12:58:16 +0100." <15323.1142251096@critter.freebsd.dk> Message-ID: <20927.1142253842@critter.freebsd.dk> I've checked in the VCL compiler stuff, but I had no luck getting the authgen.sh script to work on my FreeBSD-current (even after substituting s/autoconf/autoconf259/ etc). For now I resorted to checking in the FreeBSD style makefile that drives the compilation, but we obviouly need to get this stuff working. Also, the vcl compiler needs sbufs, so we need to get that worked out/in. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Mon Mar 13 12:48:01 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Mar 2006 13:48:01 +0100 Subject: autogen.sh In-Reply-To: Your message of "Mon, 13 Mar 2006 12:58:16 +0100." <15323.1142251096@critter.freebsd.dk> Message-ID: <23070.1142254081@critter.freebsd.dk> Would this be an acceptable way to handle the version numbered auto* tools from FreeBSD's ports collection ? Index: autogen.sh =================================================================== --- autogen.sh (revision 43) +++ autogen.sh (working copy) @@ -3,7 +3,13 @@ # $Id$ # -aclocal -autoheader -automake --add-missing --copy --force --foreign -autoconf +set -ex + +aclocal || \ + aclocal19 +autoheader || \ + autoheader259 +automake --add-missing --copy --force --foreign || \ + automake19 --add-missing --copy --force --foreign +autoconf || \ + autoconf259 -- 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 des at linpro.no Mon Mar 13 12:51:13 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 13 Mar 2006 13:51:13 +0100 Subject: This VCL compiler thing... References: <15323.1142251096@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > "Dag-Erling Sm?rgrav" writes: > > If Poul-Henning makes up a keyword for each type of error and places > > the link in the error message, I'll write the documentation. > I would prefer we don't spend too much time until we know more > about what the language will look like and do in practice. What I was basically trying to say was "T PHK DON'T WASTE TIME WRITING THOSE DOX K PLZ THX" :) DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Mon Mar 13 12:51:58 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 13 Mar 2006 13:51:58 +0100 Subject: This VCL compiler thing... References: <20927.1142253842@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I've checked in the VCL compiler stuff, but I had no luck > getting the authgen.sh script to work on my FreeBSD-current > (even after substituting s/autoconf/autoconf259/ etc). no, you need to install devel/gnu-autoconf etc. (as documented in the wiki) DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Mon Mar 13 12:53:15 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 13 Mar 2006 13:53:15 +0100 Subject: This VCL compiler thing... References: <20927.1142253842@critter.freebsd.dk> Message-ID: des at linpro.no (Dag-Erling Sm?rgrav) writes: > "Poul-Henning Kamp" writes: > > I've checked in the VCL compiler stuff, but I had no luck > > getting the authgen.sh script to work on my FreeBSD-current > > (even after substituting s/autoconf/autoconf259/ etc). > no, you need to install devel/gnu-autoconf etc. (as documented in the > wiki) umm, as *should* have been documented in the wiki. you need to install devel/gnu-autoconf, devel/gnu-automake and either devel/gnu-libtool or (with the latest ports tree) devel/libtool15. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Mar 13 13:18:49 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Mar 2006 14:18:49 +0100 Subject: This VCL compiler thing... In-Reply-To: Your message of "Mon, 13 Mar 2006 13:53:15 +0100." Message-ID: <23189.1142255929@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >des at linpro.no (Dag-Erling Sm?rgrav) writes: >> "Poul-Henning Kamp" writes: >> > I've checked in the VCL compiler stuff, but I had no luck >> > getting the authgen.sh script to work on my FreeBSD-current >> > (even after substituting s/autoconf/autoconf259/ etc). >> no, you need to install devel/gnu-autoconf etc. (as documented in the >> wiki) > >umm, as *should* have been documented in the wiki. I'd actually prefer a COMPILING file in the source tree for that. I hate downloading source code and then having to go somwhere else to figure out what to do with 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 des at linpro.no Mon Mar 13 13:52:42 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 13 Mar 2006 14:52:42 +0100 Subject: This VCL compiler thing... References: <23189.1142255929@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I hate downloading source code and then having to go somwhere else > to figure out what to do with it... source tarballs, when we get around to releasing them, will contain a ready-to-run configure script. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Mon Mar 13 22:31:56 2006 From: andersb at vgnett.no (Anders Berg) Date: Mon, 13 Mar 2006 23:31:56 +0100 (CET) Subject: Key dates Varnish In-Reply-To: <9843.1141719675@critter.freebsd.dk> References: Your message of "Tue, 07 Mar 2006 01:55:49 +0100." <1947.193.213.34.102.1141692949.squirrel@denise.vg.no> <9843.1141719675@critter.freebsd.dk> Message-ID: <2168.193.213.34.102.1142289116.squirrel@denise.vg.no> > In message <1947.193.213.34.102.1141692949.squirrel at denise.vg.no>, "Anders > Berg > " writes: > > > Here are some comments: > > req.ttlfactor > I actually wanted to have one per request also, so that > it is possible to decide that somebody isn't very important. > (microsoft proxy thing) > What do you mean with that? if (req.header.User-Agent ~ "MS Proxy"){ req.ttlfactor = 1.5 } Like this? Would not: if (req.header.User-Agent ~ "MS Proxy"){ obj.ttl += 10m } be the same? As you can see I have noticed I really do not understand obj.ttl like mentioned in notes1 (as I thought I did). obj.ttl can either act like a modifier on the Expire output, on the object itself, and as "deliver stale for ttl more seconds". Which one is it? Lets say an object (index.html) expires: Expires: Tue, 14 Mar 2006 16:00:00 GMT from the backend. The object is matched in the config. if (req.url.path ~ "index.html"){ obj.ttl += 10m } would the object stored in memory, or storage backend, be modified such that Varnish reads: Expires: Tue, 14 Mar 2006 16:10:00 GMT next time? In that case well, that request would make it (if it is not flagged as matching that exact reg-exp, which could be the case): Expires: Tue, 14 Mar 2006 16:20:00 GMT The document would never expire if we modify the object in memory or disk (and don't flag it). So lets look at the other approach, where the object is just modified on the "output" side. The object gets: Expires: Tue, 14 Mar 2006 16:00:00 GMT from the backend. Is stored in memory, is requested, and delivers: Expires: Tue, 14 Mar 2006 16:10:00 GMT back to the requester. @ Tue, 14 Mar 2006 16:00:01 GMT we have to get a new document from the backend (we do not lighten load), and lets say we delivered 3000 requests with: Expires: Tue, 14 Mar 2006 16:10:00 GMT well, 3000 clients are gonna request that document then (if they ask for it again, which is the point, or else, obj.ttl has no meaning). What we just did was to "buy" ourselvs 10 min at the first hit/request, nothing more, because its a sliding window and does not lessen load on backend. So I guess obj.ttl would be used to say that even if the document is expired, let it live 10 more minutes in cache. Used like this: Backend delivers a: Expires: Tue, 14 Mar 2006 16:00:00 GMT document to Varnish. Request comes @ Tue, 14 Mar 2006 16:00:01 GMT and hits. if (req.header.User-Agent ~ "MS Proxy"){ obj.ttl += 10m } then old document is delivered. This is the only way I can see this variable beeing used, and then it will be the same as req.ttlfactor in my opinion. It does not really make sense to use it on all requests, because then it would be the same as saying "I don't wanna control my Expires from my backend", which one really should. Or is this variable for controlling exactly that? "It's easier to do on Varnish since I have 5 backends, so lets do it there". Sorry for using so much text to say/ask so little. But I see it as one of those "problems" that have to be discussed in detail. Ab > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > > From phk at phk.freebsd.dk Tue Mar 14 07:34:14 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Mar 2006 08:34:14 +0100 Subject: Key dates Varnish In-Reply-To: Your message of "Mon, 13 Mar 2006 23:31:56 +0100." <2168.193.213.34.102.1142289116.squirrel@denise.vg.no> Message-ID: <33621.1142321654@critter.freebsd.dk> In message <2168.193.213.34.102.1142289116.squirrel at denise.vg.no>, "Anders Berg " writes: >> Here are some comments: >> >> req.ttlfactor >> I actually wanted to have one per request also, so that >> it is possible to decide that somebody isn't very important. >> (microsoft proxy thing) >> > >What do you mean with that? I guess you have thought more about it than I have now, and it doesn't seem to work after all :-) This is the sort of thing I hope we will discover more off as we start writing some actual VCL encoded policies. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Tue Mar 14 08:14:13 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Mar 2006 09:14:13 +0100 Subject: libvarnish vs libvarnishapi Message-ID: <33945.1142324053@critter.freebsd.dk> I'm slightly confused here, I thought libvarnishapi was the library that will expose API's for 3rd party software (stuff like reading the shmem log etc) and libvarnish was the library the varnish process(es) would get linked against (containing internal stuff). But I see in the tree now that varnish_debug.c varnish_log.c and varnish_util.c lives in libvarnishapi not libvarnish ? Who of us have a sign error here ? -- 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 des at linpro.no Tue Mar 14 08:55:27 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 09:55:27 +0100 Subject: libvarnish vs libvarnishapi References: <33945.1142324053@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I thought libvarnishapi was the library that will expose API's for 3rd party > software (stuff like reading the shmem log etc) and libvarnish was the > library the varnish process(es) would get linked against (containing internal > stuff). > > But I see in the tree now that varnish_debug.c varnish_log.c and > varnish_util.c lives in libvarnishapi not libvarnish ? > > Who of us have a sign error here ? I didn't want to split up the log code into reading and writing parts, so I put everything in libvarnishapi. I'm not happy with it, though, so I think I'll move the varnish_debug and varnish_log over to libvarnish and split up varnish_log. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Mar 14 09:03:52 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Mar 2006 10:03:52 +0100 Subject: libvarnish vs libvarnishapi In-Reply-To: Your message of "Tue, 14 Mar 2006 09:55:27 +0100." Message-ID: <34078.1142327032@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >"Poul-Henning Kamp" writes: >> I thought libvarnishapi was the library that will expose API's for 3rd party >> software (stuff like reading the shmem log etc) and libvarnish was the >> library the varnish process(es) would get linked against (containing internal >> stuff). >> >> But I see in the tree now that varnish_debug.c varnish_log.c and >> varnish_util.c lives in libvarnishapi not libvarnish ? >> >> Who of us have a sign error here ? > >I didn't want to split up the log code into reading and writing parts, >so I put everything in libvarnishapi. I'm not happy with it, though, >so I think I'll move the varnish_debug and varnish_log over to >libvarnish and split up varnish_log. Most of the sharing will be in a .h file anyway wouldn't 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 phk at phk.freebsd.dk Tue Mar 14 10:03:23 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Mar 2006 11:03:23 +0100 Subject: event engine library selection Message-ID: <40535.1142330603@critter.freebsd.dk> DES and I talked a bit about which event library to select for varnish long time ago and and I belive we have ISC's and Niels Provos' in the pool. As far as I can tell from inspection, the ISC code is "industry strength" where the Provos code is more "engineering sample". I'm quite worried that the multi-thread support in Provos library consists of creating events, and then as quickly as possible move them from the most recent engine to the one where they belong, that doesn't sound very safe to me. On the other hand, the Provos engine sounds like it is much more performance focused than ISC's engine, and that must count heavily for it as the acceptor/header-collector point is going to see significant load. If we decide on the Provos engine, we may have to spend time to fix up his multi-thread support and hope he will accept the patches. Comments ? Poul-Henning -- 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 des at linpro.no Tue Mar 14 11:16:01 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 12:16:01 +0100 Subject: event engine library selection References: <40535.1142330603@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > DES and I talked a bit about which event library to select for > varnish long time ago and and I belive we have ISC's and Niels > Provos' in the pool. > > As far as I can tell from inspection, the ISC code is "industry > strength" where the Provos code is more "engineering sample". > > I'm quite worried that the multi-thread support in Provos library > consists of creating events, and then as quickly as possible move > them from the most recent engine to the one where they belong, that > doesn't sound very safe to me. > > On the other hand, the Provos engine sounds like it is much more > performance focused than ISC's engine, and that must count heavily > for it as the acceptor/header-collector point is going to see > significant load. It also has several features the ISC code lacks, like support for signals, kqueue, poll etc. > If we decide on the Provos engine, we may have to spend time to fix up his > multi-thread support and hope he will accept the patches. He's a reasonable guy, I don't see any reason why he wouldn't. In any case, we'll want to keep our own copy of the code in our tree. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Mar 14 11:33:22 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Mar 2006 12:33:22 +0100 Subject: event engine library selection In-Reply-To: Your message of "Tue, 14 Mar 2006 12:16:01 +0100." Message-ID: <56771.1142336002@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >It also has several features the ISC code lacks, like support for >signals, kqueue, poll etc. yeah, well, and vice versa, the ISC code has a lot of high-level stuff that provos code lacks. >> If we decide on the Provos engine, we may have to spend time to fix up his >> multi-thread support and hope he will accept the patches. > >He's a reasonable guy, I don't see any reason why he wouldn't. In any >case, we'll want to keep our own copy of the code in our tree. Lets go with provos code then. Integrating it in the tree probably takes a bit more auto* foo than I have, since I guess we need to merge libevent's auto* stuff into our auto* stuff ? When I compile libevent on -current I run into weird messages because includes to cope with various userland malware. I'm investigating right now what malware that might be. -- 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 des at linpro.no Tue Mar 14 12:07:25 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 13:07:25 +0100 Subject: event engine library selection In-Reply-To: <56771.1142336002@critter.freebsd.dk> (Poul-Henning Kamp's message of "Tue, 14 Mar 2006 12:33:22 +0100") References: <56771.1142336002@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Lets go with provos code then. > > Integrating it in the tree probably takes a bit more auto* foo than I > have, since I guess we need to merge libevent's auto* stuff into our > auto* stuff ? I'll take care of it in a minute. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vg.no Tue Mar 14 13:15:18 2006 From: andersb at vg.no (Anders Berg) Date: Tue, 14 Mar 2006 14:15:18 +0100 Subject: Varnish design/logo Message-ID: <5.2.0.9.0.20060314141003.03506868@pop.vg.no> Here is what our designer has come up with so far. He has started with the Logo, since the rest of the design is based on what we choose. These are consepts, not final. The final will then be based on the consept we choose and made in different forms/shapes after what need there is. All will be vector based so we can scale and use in print. Any favorites? Anders Berg ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: VarnishLogo01.jpg Type: image/jpeg Size: 318199 bytes Desc: not available URL: From des at linpro.no Tue Mar 14 13:19:36 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 14:19:36 +0100 Subject: r51 - in trunk/varnish-cache: . contrib contrib/libevent contrib/libevent/WIN32-Code contrib/libevent/WIN32-Prj contrib/libevent/WIN32-Prj/event_test contrib/libevent/WIN32-Prj/signal_test contrib/libevent/WIN32-Prj/time_test contrib/libevent/compat contrib/libevent/compat/sys contrib/libevent/sample contrib/libevent/test References: <20060314125413.8409A1ED54A@projects.linpro.no> Message-ID: des at projects.linpro.no writes: > Author: des > Date: 2006-03-14 13:54:13 +0100 (Tue, 14 Mar 2006) > New Revision: 51 > > Added: > trunk/varnish-cache/contrib/ > trunk/varnish-cache/contrib/libevent/ > [...] > Log: > Add Niels Provos's libevent 1.1a. This is sufficient so one can "cd contrib/libevent" and run configure && make && make install if one does not already have libevent. I'll add glue to the top-level configure script later to make this happen automagically. I'm considering doing the same with libsbuf, to avoid collisions on BSD systems which already have it. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Tue Mar 14 13:30:57 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 14:30:57 +0100 Subject: Varnish design/logo References: <5.2.0.9.0.20060314141003.03506868@pop.vg.no> Message-ID: Anders Berg writes: > Here is what our designer has come up with so far. > > He has started with the Logo, since the rest of the design is based > on what we choose. > > These are consepts, not final. The final will then be based on the > consept we choose and made in different forms/shapes after what need > there is. > > All will be vector based so we can scale and use in print. > > Any favorites? third from the top in the left column. One thing, though: I'd like the blobs to be more similar in size, especially the center blob. And I'm a little bit unsure about the font, which feels kind of uneven. I also like the three with the star in the lower half of the middle column (although the color is wrong), but they remind me a little too much of a dishwasher sufactant ("finish" or something like that?) How about the red one in the left column, with the font from the blue one in the middle column? DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Mar 14 14:09:29 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Mar 2006 15:09:29 +0100 Subject: Varnish design/logo In-Reply-To: Your message of "Tue, 14 Mar 2006 14:15:18 +0100." <5.2.0.9.0.20060314141003.03506868@pop.vg.no> Message-ID: <87898.1142345369@critter.freebsd.dk> In message <5.2.0.9.0.20060314141003.03506868 at pop.vg.no>, Anders Berg writes: >Here is what our designer has come up with so far. I had sort of expected to see something like a brush painting a swash and the name and the "ball-stick" drawing appear in negative in the swash... -- 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 andersb at vg.no Tue Mar 14 14:34:19 2006 From: andersb at vg.no (Anders Berg) Date: Tue, 14 Mar 2006 15:34:19 +0100 Subject: event engine library selection In-Reply-To: <40535.1142330603@critter.freebsd.dk> Message-ID: <5.2.0.9.0.20060314141536.0351cb30@pop.vg.no> At 11:03 14.03.2006 +0100, Poul-Henning Kamp wrote: >DES and I talked a bit about which event library to select for >varnish long time ago and and I belive we have ISC's and Niels >Provos' in the pool. > >As far as I can tell from inspection, the ISC code is "industry >strength" where the Provos code is more "engineering sample". > >I'm quite worried that the multi-thread support in Provos library >consists of creating events, and then as quickly as possible move >them from the most recent engine to the one where they belong, that >doesn't sound very safe to me. > >On the other hand, the Provos engine sounds like it is much more >performance focused than ISC's engine, and that must count heavily >for it as the acceptor/header-collector point is going to see >significant load. > >If we decide on the Provos engine, we may have to spend time to fix up his >multi-thread support and hope he will accept the patches. > >Comments ? My gut feeling would say Provos (speed), but I really am not qualified to give a guess, never having read any of the code. If it's not to much work, we could end up with giving a speedy eventlib a more "industry strength" approach, and that's the best of 2 worlds. Anders Berg >Poul-Henning > >-- >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. >_______________________________________________ >varnish-dev mailing list >varnish-dev at projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-dev ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From phk at phk.freebsd.dk Tue Mar 14 14:37:04 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Mar 2006 15:37:04 +0100 Subject: r51 - in trunk/varnish-cache: . contrib contrib/libevent contrib/libevent/WIN32-Code contrib/libevent/WIN32-Prj contrib/libevent/WIN32-Prj/event_test contrib/libevent/WIN32-Prj/signal_test contrib/libevent/WIN32-Prj/time_test contrib/libevent/compat contrib/libevent/compat/sys contrib/libevent/sample contrib/libevent/test In-Reply-To: Your message of "Tue, 14 Mar 2006 14:19:36 +0100." Message-ID: <10922.1142347024@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >des at projects.linpro.no writes: >> Date: 2006-03-14 13:54:13 +0100 (Tue, 14 Mar 2006) >> New Revision: 51 >> >> Added: >> trunk/varnish-cache/contrib/ >> trunk/varnish-cache/contrib/libevent/ >> [...] >> Log: >> Add Niels Provos's libevent 1.1a. > >This is sufficient so one can "cd contrib/libevent" and run configure >[...] only there is no configure script in there... -- 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 des at linpro.no Tue Mar 14 15:00:18 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 16:00:18 +0100 Subject: r51 - in trunk/varnish-cache: . contrib contrib/libevent contrib/libevent/WIN32-Code contrib/libevent/WIN32-Prj contrib/libevent/WIN32-Prj/event_test contrib/libevent/WIN32-Prj/signal_test contrib/libevent/WIN32-Prj/time_test contrib/libevent/compat contrib/libevent/compat/sys contrib/libevent/sample contrib/libevent/test References: <10922.1142347024@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Dag-Erling Sm?rgrav writes: > > This is sufficient so one can "cd contrib/libevent" and run configure > > [...] > only there is no configure script in there... sorry - just run ../../autogen.sh and one will appear. I will make this seamless when I get a spare moment. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Tue Mar 14 15:03:24 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 16:03:24 +0100 Subject: Varnish design/logo References: <87898.1142345369@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Anders Berg writes: > > Here is what our designer has come up with so far. > I had sort of expected to see something like a brush painting a > swash and the name and the "ball-stick" drawing appear in negative > in the swash... That sounds neat - it certainly fits the name. Anders, could you ask your designer about it? DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vg.no Tue Mar 14 15:24:33 2006 From: andersb at vg.no (Anders Berg) Date: Tue, 14 Mar 2006 16:24:33 +0100 Subject: Varnish design/logo In-Reply-To: References: <87898.1142345369@critter.freebsd.dk> Message-ID: <5.2.0.9.0.20060314162357.03524468@pop.vg.no> At 16:03 14.03.2006 +0100, you wrote: >"Poul-Henning Kamp" writes: > > Anders Berg writes: > > > Here is what our designer has come up with so far. > > I had sort of expected to see something like a brush painting a > > swash and the name and the "ball-stick" drawing appear in negative > > in the swash... > >That sounds neat - it certainly fits the name. Anders, could you ask >your designer about it? I'll run it by him, but I have some difficulty picturing it :) Anders Berg >DES >-- >Dag-Erling Sm?rgrav >Senior Software Developer >Linpro AS - www.linpro.no >_______________________________________________ >varnish-dev mailing list >varnish-dev at projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-dev ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From des at linpro.no Tue Mar 14 15:31:58 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 14 Mar 2006 16:31:58 +0100 Subject: Varnish design/logo References: <87898.1142345369@critter.freebsd.dk> <5.2.0.9.0.20060314162357.03524468@pop.vg.no> Message-ID: Anders Berg writes: > Dag-Erling Sm?rgrav writes: > > "Poul-Henning Kamp" writes: > > > Anders Berg writes: > > > > Here is what our designer has come up with so far. > > > I had sort of expected to see something like a brush painting a > > > swash and the name and the "ball-stick" drawing appear in negative > > > in the swash... > > That sounds neat - it certainly fits the name. Anders, could you ask > > your designer about it? > I'll run it by him, but I have some difficulty picturing it :) Imagine painting a white wall with red paint and a wide, flat brush - make a horizontal stroke from left to right, then use that as the background for the text and the sticks-and-balls logo. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Thu Mar 16 00:12:54 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 16 Mar 2006 01:12:54 +0100 (CET) Subject: Varnish design/logo In-Reply-To: References: <87898.1142345369@critter.freebsd.dk><5.2.0.9.0.20060314162357.03524468@pop.vg.no> Message-ID: <1275.193.213.34.102.1142467974.squirrel@denise.vg.no> > Anders Berg writes: >> Dag-Erling Sm?rgrav writes: >> > "Poul-Henning Kamp" writes: >> > > Anders Berg writes: >> > > > Here is what our designer has come up with so far. >> > > I had sort of expected to see something like a brush painting a >> > > swash and the name and the "ball-stick" drawing appear in negative >> > > in the swash... >> > That sounds neat - it certainly fits the name. Anders, could you ask >> > your designer about it? >> I'll run it by him, but I have some difficulty picturing it :) > > Imagine painting a white wall with red paint and a wide, flat brush - > make a horizontal stroke from left to right, then use that as the > background for the text and the sticks-and-balls logo. Do I have to? :) We are in the hands of a good designer here. What I sent was a prospect, not final ideas, they go threw many fases apperently :) Here comes a small sample of the design prosess so far. Feel free to stop reading when you feel like it. Hehe. *** Past **** Bla, bla, bla, speed, bla, new, bla, bla, modular, bla, small, bla, bla... *** Present **** What has been said from my side, after studying the works with the designer is that we are probably looking at the one in the upper left corner, that one has bigger "boobs" than the ones below it. I like that one, as you do. But you said you liked the red color, so whats happening is that he is gonna mock up that one with many different colors (blue, red, green, etc...) but gonna keep that "background". Then all the fonts you see on the page can be used in any logo, they are just fonts to look at and see if you like. You liked the detergent one, me 2, but we gotta loose the star (2 many elements, with the "rods"), and I felt the R was to much like the A. This guy makes his own fonts for the job. So he is gonna tune the font a little, and try it in the upper left logo. Also I had some other font I like, so we throw in a few of those, in different colors also. Italic seems to work fine. We need another logo also, for standing up. Bla, bla, bla... We make 3D models also, of some of the stuff. (already done some). Bla, bla, bla... *** Future *** I am gonna bla, bla some and we are gonna end up happy :) I have full trust in Kristian, our in-house designer, and I am sure we will be pleased. He's good. I enjoy all the bla, bla'ing. This is not an example of "Puh, look at what I must do". I am really into Varnish, and wanna get things going on many parts. VG is behind this and I/we really wanna make a good first impression :) I think Redmond has shown the world that impressions and wrapping is key. If we can deliver a good product as well, and I am sure we will :), I hope that we will succeed parts of the goal ("The end product will result in the fastest, overall best, well-documented and well-known Open Source HTTP accelerator in the market."). I also hope that we will be able to contrbute another goal that is not written, but spoken of, a contribution back to the Open Source communities (hopefully the BSD camp also). You guys have already contributed so much work so you don't get to work'ed up over it :) I haven't. Hehe. I understand where somebody threw the word religion into the equation... So for me everything is fun, but I am NOT gonna sharpen my C, so I'll try other areas :) YS Anders Berg > DES > -- > Dag-Erling Sm?rgrav > Senior Software Developer > Linpro AS - www.linpro.no > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Thu Mar 16 09:00:15 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 16 Mar 2006 10:00:15 +0100 Subject: compiler warnings ? In-Reply-To: Your message of "Tue, 14 Mar 2006 08:34:14 +0100." <33621.1142321654@critter.freebsd.dk> Message-ID: <59962.1142499615@critter.freebsd.dk> Is it possible to get auto* to set a bunch of compiler flags so that we get warnings that correspond to WARNS=5 in FreeBSD ? -- 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 des at linpro.no Thu Mar 16 10:47:11 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 16 Mar 2006 11:47:11 +0100 Subject: compiler warnings ? References: <59962.1142499615@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Is it possible to get auto* to set a bunch of compiler flags so > that we get warnings that correspond to WARNS=5 in FreeBSD ? ./configure --enable-pedantic --enable-wall --enable-werror --enable-dependency-tracking will go some way towards that. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Sat Mar 18 20:49:19 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 18 Mar 2006 21:49:19 +0100 (CET) Subject: Module-map Varnish In-Reply-To: <2158.193.69.165.4.1140789300.squirrel@denise.vg.no> References: <2158.193.69.165.4.1140789300.squirrel@denise.vg.no> Message-ID: <2489.193.213.34.102.1142714959.squirrel@denise.vg.no> Updated the module-map some. I think we are gonna "need" a graphical representation of the processes and communication between them. The names are not right and I have stuck some questionmarks on the image, where I am unsure about the name . Also I am unsure about to whom the management part, of what I have called Varnishd, is supposed to "speak". Am I off the bat here? Or should I continue work on this module-map? Anders Berg -------------- next part -------------- A non-text attachment was scrubbed... Name: application_structure.png Type: image/x-png Size: 61500 bytes Desc: not available URL: From andersb at vgnett.no Wed Mar 22 15:36:07 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 22 Mar 2006 16:36:07 +0100 Subject: SV: Varnish design/logo In-Reply-To: <1275.193.213.34.102.1142467974.squirrel@denise.vg.no> Message-ID: Here is the latest logo-file. Its more to find a color than to find the final design, I am told :) Any colorpreferances? Anders Berg -----Opprinnelig melding----- Fra: varnish-dev-bounces at projects.linpro.no [mailto:varnish-dev-bounces at projects.linpro.no] P? vegne av Anders Berg Sendt: 16. mars 2006 01:13 Til: varnish-dev at projects.linpro.no Emne: Re: Varnish design/logo > Anders Berg writes: >> Dag-Erling Sm?rgrav writes: >> > "Poul-Henning Kamp" writes: >> > > Anders Berg writes: >> > > > Here is what our designer has come up with so far. >> > > I had sort of expected to see something like a brush painting a >> > > swash and the name and the "ball-stick" drawing appear in >> > > negative in the swash... >> > That sounds neat - it certainly fits the name. Anders, could you >> > ask your designer about it? >> I'll run it by him, but I have some difficulty picturing it :) > > Imagine painting a white wall with red paint and a wide, flat brush - > make a horizontal stroke from left to right, then use that as the > background for the text and the sticks-and-balls logo. Do I have to? :) We are in the hands of a good designer here. What I sent was a prospect, not final ideas, they go threw many fases apperently :) Here comes a small sample of the design prosess so far. Feel free to stop reading when you feel like it. Hehe. *** Past **** Bla, bla, bla, speed, bla, new, bla, bla, modular, bla, small, bla, bla... *** Present **** What has been said from my side, after studying the works with the designer is that we are probably looking at the one in the upper left corner, that one has bigger "boobs" than the ones below it. I like that one, as you do. But you said you liked the red color, so whats happening is that he is gonna mock up that one with many different colors (blue, red, green, etc...) but gonna keep that "background". Then all the fonts you see on the page can be used in any logo, they are just fonts to look at and see if you like. You liked the detergent one, me 2, but we gotta loose the star (2 many elements, with the "rods"), and I felt the R was to much like the A. This guy makes his own fonts for the job. So he is gonna tune the font a little, and try it in the upper left logo. Also I had some other font I like, so we throw in a few of those, in different colors also. Italic seems to work fine. We need another logo also, for standing up. Bla, bla, bla... We make 3D models also, of some of the stuff. (already done some). Bla, bla, bla... *** Future *** I am gonna bla, bla some and we are gonna end up happy :) I have full trust in Kristian, our in-house designer, and I am sure we will be pleased. He's good. I enjoy all the bla, bla'ing. This is not an example of "Puh, look at what I must do". I am really into Varnish, and wanna get things going on many parts. VG is behind this and I/we really wanna make a good first impression :) I think Redmond has shown the world that impressions and wrapping is key. If we can deliver a good product as well, and I am sure we will :), I hope that we will succeed parts of the goal ("The end product will result in the fastest, overall best, well-documented and well-known Open Source HTTP accelerator in the market."). I also hope that we will be able to contrbute another goal that is not written, but spoken of, a contribution back to the Open Source communities (hopefully the BSD camp also). You guys have already contributed so much work so you don't get to work'ed up over it :) I haven't. Hehe. I understand where somebody threw the word religion into the equation... So for me everything is fun, but I am NOT gonna sharpen my C, so I'll try other areas :) YS Anders Berg -------------- next part -------------- A non-text attachment was scrubbed... Name: VarnishLogo02.jpg Type: image/jpeg Size: 252843 bytes Desc: not available URL: From phk at phk.freebsd.dk Wed Mar 22 16:01:21 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 22 Mar 2006 17:01:21 +0100 Subject: SV: Varnish design/logo In-Reply-To: Your message of "Wed, 22 Mar 2006 16:36:07 +0100." Message-ID: <10479.1143043281@critter.freebsd.dk> In message , "Anders Be rg" writes: >Here is the latest logo-file. Its more to find a color than to find the >final design, I am told :) > >Any colorpreferances? Not really. And btw, I've practically not managed to do any work this week, I'm down with a sore throat or influenza of some kind. And no, I've not been hugging any birds :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Mar 23 09:06:44 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 23 Mar 2006 10:06:44 +0100 Subject: suspend/resume in trouble... Message-ID: <50142.1143104804@critter.freebsd.dk> I love it when I learn something, but I hate when it is a new bug in UNIX. It seems that once you have listen(2)'ed a socket, there is no way to unlisten(2) again. I might intuitively be expected that listen(2) with a queue length of zero would make it reject all future connection attempts, but the semantics for that case is to accept the one connection and reject all others while that connection exists. So to implement suspend/resume we will have to close and recreate the (remote) listener socket(s) which means that doing so moves from the mgt to the cache process and that restarting the cache process without a break in service is not possible any more. (Unless we resort to passing fd's over unix domain sockets, but I'm firmly against that on religious reasons) I've put the "suspend/resume" facility on the "needs further study" for now. -- 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 Anders.Berg at vg.no Wed Mar 22 23:39:55 2006 From: Anders.Berg at vg.no (Anders Berg) Date: Thu, 23 Mar 2006 00:39:55 +0100 Subject: SV: SV: Varnish design/logo References: <10479.1143043281@critter.freebsd.dk> Message-ID: <6AD33D89A21F7B479107D712EF96FDA528CB53@VG-EXC-VIR-1.Akersgt.local> ________________________________ Fra: varnish-dev-bounces at projects.linpro.no p? vegne av Poul-Henning Kamp Sendt: on 22.03.2006 17:01 Til: Anders Berg Kopi: varnish-dev at projects.linpro.no Emne: Re: SV: Varnish design/logo In message , "Anders Be rg" writes: >Here is the latest logo-file. Its more to find a color than to find the >final design, I am told :) > >Any colorpreferances? Not really. And btw, I've practically not managed to do any work this week, I'm down with a sore throat or influenza of some kind. To bad :( Hope you get better soon. I have been busy this week, so no more Visio diagrams :) And no, I've not been hugging any birds :-) I guess thats only because they are so hard to catch. Hehe. -- 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. _______________________________________________ varnish-dev mailing list varnish-dev at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From des at linpro.no Thu Mar 23 11:39:46 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 23 Mar 2006 12:39:46 +0100 Subject: suspend/resume in trouble... References: <50142.1143104804@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I love it when I learn something, but I hate when it is a new bug in > UNIX. > > It seems that once you have listen(2)'ed a socket, there is no way > to unlisten(2) again. > > I might intuitively be expected that listen(2) with a queue length > of zero would make it reject all future connection attempts, but the > semantics for that case is to accept the one connection and reject > all others while that connection exists. Well, we can easily fix that in FreeBSD. Strictly speaking, POSIX allows listen(0) to work as we want it to: A backlog argument of 0 may allow the socket to accept connections, in which case the length of the listen queue may be set to an implementation-defined minimum value. (note "may") However, there's a significant chance this may break existing applications which expect listen(0) to be equivalent to listen(SOME_IMPLEMENTATION_DEFINED_NON_ZERO_VALUE). It's also very hard to test for in a configure script. Therefore, it's probably simpler to add an unlisten() syscall. I'm fairly certain I can come up with a patch for Linux as well, but it will take time to get it accepted. On systems which lack unlisten(), a suspended server can simply reply to any incoming connections with 503 Service Unavailable, without even bothering to look at the request. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Mar 23 11:51:38 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 23 Mar 2006 12:51:38 +0100 Subject: suspend/resume in trouble... In-Reply-To: Your message of "Thu, 23 Mar 2006 12:39:46 +0100." Message-ID: <62116.1143114698@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >However, there's a significant chance this may break existing >applications which expect listen(0) to be equivalent to >listen(SOME_IMPLEMENTATION_DEFINED_NON_ZERO_VALUE). It's also very >hard to test for in a configure script. Therefore, it's probably >simpler to add an unlisten() syscall. I would probably go for listen(-1) instead. Adding a syscall is a major pita, and if you do unlisten(2) on a socket, does that mean you can connect(2) it then ? listen(-1) should be trivial to test for in autoconf. >On systems which lack unlisten(), a suspended server can simply reply >to any incoming connections with 503 Service Unavailable, without even >bothering to look at the request. But that sort of defeats the entire purpose behind suspend/resume: to let the load-balancer front-end discover that we're not answering. I would say: if system offers listen(-1): suspend / resume works as advertised. else suspend is not implemented resume works only once. -- 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 des at linpro.no Thu Mar 23 12:23:28 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 23 Mar 2006 13:23:28 +0100 Subject: suspend/resume in trouble... In-Reply-To: <62116.1143114698@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 23 Mar 2006 12:51:38 +0100") References: <62116.1143114698@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I would probably go for listen(-1) instead. No, POSIX requires listen(-1) to be equivalent to listen(0). DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Mar 23 12:34:08 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 23 Mar 2006 13:34:08 +0100 Subject: suspend/resume in trouble... In-Reply-To: Your message of "Thu, 23 Mar 2006 13:23:28 +0100." Message-ID: <63078.1143117248@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> I would probably go for listen(-1) instead. > >No, POSIX requires listen(-1) to be equivalent to listen(0). But it also allows listen(0) to have the behaviour we seek (implicit in the "may allow the socket to accept connections", so I'm sure I could wiggle myself out of that :-) Either way, lets park this issue on the to-do list for now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Mar 23 13:32:38 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 23 Mar 2006 14:32:38 +0100 Subject: The shared memory log Message-ID: <63306.1143120758@critter.freebsd.dk> I've been thinking about the shared memory log som more, and come up with a few minor course adjustments. The first is that since we control the API on both sides of the shared memory, the actual layout of the shared memory need not be the exact XML format we have decided, as long as the API produces that. The reason why this is interesting is that we will be logging more data than any one log-consumer will want to look at, so sorting it into per request "log lines" in the cache process is not actually necessary. So instead of putting XML into the log, I think I will put only XML tags into the log and let the client side, sort these into XML "lines" as appropriate. Imagine if the "final" log output line would be: 10.0.0.2:2004 http://www.vg.no kdjfslkfjskldf [...] 65023 The initial idea was to write all this to shared memory at the end of the transaction, but that means that the cache process needs to somewhere to keep it until then, and that means copying/formatting the log entry into dynamically allocated memory, and then copying it to shared memory at the end of the request. It would be far cheaper to stick the individual bits directly into shared memory as soon as we have them, but that means that different requests will be intereleaved which the logclient will have to sort that out. But, since the logclient is likely to want to ignore some number of the 'fields', doing so is actually cheaper if they can be ignored at first sight, instead of having to 'edit them out' of the full record. So in this new scheme of things, we write shared memory in records like these: 1 byte: field type 0x00 = NEW log record 0x01 = CLIENT 0x02 = URL 0x03 = ... 0xff = end of log record 2 byte: magic number 1 byte: length (possibly 2 bytes ?) data and the above example would look like: [0x00, 0x1838, 0] NEW log entry with magic 0x1838 ... [0x01, 0x1838, 13] "10.0.0.2:2004" ... [0x02, 0x1838, 16] "http://www.vg.no" ... [0x03, 0x1838, 5] "65023" ... [0x04, 0x1838, 4] "1.24" ... [0xff, 0x1838, 0] End record I belive this will be quite a bit faster than the other way around... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Mar 23 14:04:50 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 23 Mar 2006 15:04:50 +0100 Subject: Svn question Message-ID: <63451.1143122690@critter.freebsd.dk> I keep wondering if I've forgotten to "svn add" any files. With CVS, a cvs update will mention unexpected files and this gives a fair warning, is there anything similar for svn ? -- 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 des at linpro.no Thu Mar 23 15:06:26 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 23 Mar 2006 16:06:26 +0100 Subject: Svn question References: <63451.1143122690@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I keep wondering if I've forgotten to "svn add" any files. > > With CVS, a cvs update will mention unexpected files and this > gives a fair warning, is there anything similar for svn ? 'svn status' will show unknown files with a question mark. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Thu Mar 23 16:22:01 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 23 Mar 2006 17:22:01 +0100 (CET) Subject: The shared memory log In-Reply-To: <63306.1143120758@critter.freebsd.dk> References: <63306.1143120758@critter.freebsd.dk> Message-ID: <1336.193.213.34.102.1143130921.squirrel@denise.vg.no> I agree to this approach (if I understand it right :)). You may still get the same data, and the logclient can slap together the XML, if thats what it wants to do, at its own cost. Actually it is easier to ignore the data you don't want (no XML parsing). And its faster :) Perfect. There was no reason to have XML in shared memory other than we could attach a "cat" or "tail" tool, and get "sane" data. We/others can still do that with small modifications to "cat" and "tail". So it was more of a fun-feature than a must-have. Speed on the other had is key :) Hope I understood this correctly. Hehe. Anders Berg > I've been thinking about the shared memory log som more, and come up > with a few minor course adjustments. > > The first is that since we control the API on both sides of the shared > memory, the actual layout of the shared memory need not be the exact > XML format we have decided, as long as the API produces that. > > The reason why this is interesting is that we will be logging more > data than any one log-consumer will want to look at, so sorting it > into per request "log lines" in the cache process is not actually > necessary. > > So instead of putting XML into the log, I think I will put only XML > tags into the log and let the client side, sort these into XML "lines" > as appropriate. > > Imagine if the "final" log output line would be: > 10.0.0.2:2004 > http://www.vg.no > kdjfslkfjskldf > [...] > 65023 > > > The initial idea was to write all this to shared memory at the end of > the transaction, but that means that the cache process needs to somewhere > to keep it until then, and that means copying/formatting the log entry > into dynamically allocated memory, and then copying it to shared > memory at the end of the request. > > It would be far cheaper to stick the individual bits directly into > shared memory as soon as we have them, but that means that different > requests will be intereleaved which the logclient will have to sort > that out. > > But, since the logclient is likely to want to ignore some number of > the 'fields', doing so is actually cheaper if they can be ignored > at first sight, instead of having to 'edit them out' of the full record. > > So in this new scheme of things, we write shared memory in records > like these: > > 1 byte: field type > 0x00 = NEW log record > 0x01 = CLIENT > 0x02 = URL > 0x03 = ... > 0xff = end of log record > 2 byte: magic number > 1 byte: length (possibly 2 bytes ?) > data > > and the above example would look like: > > [0x00, 0x1838, 0] NEW log entry with magic 0x1838 > ... > [0x01, 0x1838, 13] "10.0.0.2:2004" > ... > [0x02, 0x1838, 16] "http://www.vg.no" > ... > [0x03, 0x1838, 5] "65023" > ... > [0x04, 0x1838, 4] "1.24" > ... > [0xff, 0x1838, 0] End record > > > I belive this will be quite a bit faster than the other way around... > > -- > 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. > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Fri Mar 24 10:50:48 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 24 Mar 2006 11:50:48 +0100 Subject: non GET/HEAD requests. Message-ID: <58736.1143197448@critter.freebsd.dk> We'll do wonderous and magic thing for GET and HEAD requests, but eventhing else we just pass through. But do we want to give the VCL program a chance to mess up the transaction before we pass it to the backend ? Intuitively I'd say we should have a special VCL function for these and if the user doesn't define it, we just pass to the backend, if the user does define it it's all in his hands. Possible application could be stuff like DoS prevention and anti-scripting. Comments ? -- 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 Anders.Berg at vg.no Fri Mar 24 10:54:38 2006 From: Anders.Berg at vg.no (Anders Berg) Date: Fri, 24 Mar 2006 11:54:38 +0100 Subject: SV: non GET/HEAD requests. Message-ID: <6AD33D89A21F7B479107D712EF96FDA52A6B1C@VG-EXC-VIR-1.Akersgt.local> Yes. Not just for saying "yes" to every feature, but because we should let the administrator handle not so "common" requests on way or another. Anders Berg -----Opprinnelig melding----- Fra: varnish-dev-bounces at projects.linpro.no [mailto:varnish-dev-bounces at projects.linpro.no] P? vegne av Poul-Henning Kamp Sendt: 24. mars 2006 11:51 Til: varnish-dev at projects.linpro.no Emne: non GET/HEAD requests. We'll do wonderous and magic thing for GET and HEAD requests, but eventhing else we just pass through. But do we want to give the VCL program a chance to mess up the transaction before we pass it to the backend ? Intuitively I'd say we should have a special VCL function for these and if the user doesn't define it, we just pass to the backend, if the user does define it it's all in his hands. Possible application could be stuff like DoS prevention and anti-scripting. Comments ? -- 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. _______________________________________________ varnish-dev mailing list varnish-dev at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From phk at phk.freebsd.dk Fri Mar 24 10:56:52 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 24 Mar 2006 11:56:52 +0100 Subject: SV: non GET/HEAD requests. In-Reply-To: Your message of "Fri, 24 Mar 2006 11:54:38 +0100." <6AD33D89A21F7B479107D712EF96FDA52A6B1C@VG-EXC-VIR-1.Akersgt.local> Message-ID: <58791.1143197812@critter.freebsd.dk> In message <6AD33D89A21F7B479107D712EF96FDA52A6B1C at VG-EXC-VIR-1.Akersgt.local>, "Anders Berg" writes: >Yes. Not just for saying "yes" to every feature, but because we should let = >the administrator handle not so "common" requests on way or another. Well adding features by sticking in a VCL function and saying "Do It YourSelf" is a cheap way to add features, so I'm not worried :-) I just realized why we don't even have a choice here: Backend-selection. -- 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 des at linpro.no Fri Mar 24 11:21:35 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Fri, 24 Mar 2006 12:21:35 +0100 Subject: non GET/HEAD requests. References: <58736.1143197448@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > We'll do wonderous and magic thing for GET and HEAD requests, but > eventhing else we just pass through. ...or reject. > But do we want to give the VCL program a chance to mess up the > transaction before we pass it to the backend ? I'd say so, yes, at the very least so the admin has the option of rejecting them. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Sat Mar 25 18:34:11 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 25 Mar 2006 19:34:11 +0100 (CET) Subject: A 20k+ paper In-Reply-To: References: <58736.1143197448@critter.freebsd.dk> Message-ID: <1387.193.213.34.102.1143311651.squirrel@denise.vg.no> Hi, I just found this paper about how to scale apache beyond 20k+ connections. http://www.stdlib.net/~colmmacc/Apachecon-EU2005/scaling-apache-handout.pdf Fun reading, but it also gives us a heads up on one problem. Under section 3.4: 3.4 SendFile If at all possible, use of the sendfile call will almost certainly boost performance and increase effciency. Unfortunately in our case, Linux's sendfile implementation does not operate on our hardware (or any that we can find) without corrupting IPv6 sessions (3). As HEAnet is committed to offering all production services over IPv6 as well as IPv4, simply turning off IPv6 was not an option for us. (3) The bug is actually caused by TCP checksum miscalculations by almost all network interfaces, and Linux uses checksum offoading during use of the sendfile call. This was tracked down with the help of Joe Orton. Well, now we know that. Anders Berg From andersb at vgnett.no Mon Mar 27 22:42:12 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 28 Mar 2006 00:42:12 +0200 (CEST) Subject: VCL language Message-ID: <2607.193.213.34.102.1143499332.squirrel@denise.vg.no> Hi, seeing that Poul-Henning is back to the VCL compiler again in the code, I think it is time to start a more detailed discussion about the VCL. My guess is that we are gonna spend "alot" of time on it, and it could be a natural part of a face-to-face meeting. I also acknowledge that the sooner we "freeze" the language, the easier and less rewrite of code Poul-Henning has to do. I think our small "proof-of-concept" and the general look-and-feel of VCL, will make it suitable and _really_ good for Varnish. As my footnote on the Object part of: http://klikk.vg.no/vcl.html states, I was having some problems getting the hang of the Object part. I later posted some of the "problems" I had in: http://projects.linpro.no/pipermail/varnish-dev/2006-March/000065.html (talk about of-topic topic :)) I/We haven't gotten down to trying/thinking/poking/defining/documenting the VCL yet, but I _think_ I might have come up with a "system" to make VCL easier to understand, and possible easier to code both for Poul-Henning and the end user. I am attaching 2 documents: vcl_diagram_v1.png and vcl_diagram_proposal.png (*v1 is approx. what we have today) Not gonna spend to much time discussing details here, but the main idea is to have the first part of the "variable" name tell you if this is a backend variable or a client variable. Also, the object (document if you like) has 2 sets of variables. For example I think that backend.obj.usage and client.obj.usage makes sense. Lets say it's a number/factor to say how often this object is used/refreshed. A JPEG will have a low backend.obj.usage (since it typical is not often requested from backend) but client.obj.usage will be high (because its requested often, logo etc...). I can also think of more uses here. I have left out to define more variables in vcl_diagram_proposal.png, but here are some examples of other "new" areas of variables: if (client.req.url.host ~ cnn.no){ backend.req.url.host = vg.no } This is rewrite :) if (backend.res.error = 503){ client.res.error = 404 } useful? Anyway, I am sure there are variables we need to be able to play with in both backend.res and client.res. client.res.error is btw the same as error in "v1" of VCL. Anyone think this might be a good way to "split" VCL up and make easier? I know you already have done alot of work in the VCL compiler Poul-Henning, and I hope/guess that to much time hasn't been "wasted". Anders Berg -------------- next part -------------- A non-text attachment was scrubbed... Name: vcl_diagram_v1.png Type: image/x-png Size: 54533 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vcl_diagram_proposal.png Type: image/x-png Size: 61537 bytes Desc: not available URL: From phk at phk.freebsd.dk Tue Mar 28 06:58:14 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 28 Mar 2006 08:58:14 +0200 Subject: VCL language In-Reply-To: Your message of "Tue, 28 Mar 2006 00:42:12 +0200." <2607.193.213.34.102.1143499332.squirrel@denise.vg.no> Message-ID: <60922.1143529094@critter.freebsd.dk> In message <2607.193.213.34.102.1143499332.squirrel at denise.vg.no>, "Anders Berg " writes: >seeing that Poul-Henning is back to the VCL compiler again in the code, I >think it is time to start a more detailed discussion about the VCL. Good time for it. The work I did yesterday was basically just getting the compiler hooked into varnishd and get the cache process to load the result. So far I don't actually use the loaded code for anything yet. >My guess is that we are gonna spend "alot" of time on it, and it could be >a natural part of a face-to-face meeting. I also acknowledge that the >sooner we "freeze" the language, the easier and less rewrite of code >Poul-Henning has to do. It's important to keep two things clear of each other here. On one hand there is "the language", this about where semicolons go and how many f's we put in 'if' and that sort of thing. On the other hand, there are the variables and operations we give the language to work with. The first part, the language, I think is pretty solid by now, and with some amount of polishing and maybe a new feature or two, that is pretty 'done' at this time. The other part, the variables and operations is in need for being hashed out, because that is the next bit that I need to start working on: Calling into the compiled VCL program from the cache process. But there is a lot of code yet to be written before this stuff gets in the critical path, so there is no need to yell "emergency" or anything like it :-) >I think our small "proof-of-concept" and the general look-and-feel of VCL, >will make it suitable and _really_ good for Varnish. I think VCL is the bit which will make people sit up and take notice :-) >I/We haven't gotten down to trying/thinking/poking/defining/documenting >the VCL yet, but I _think_ I might have come up with a "system" to make >VCL easier to understand, and possible easier to code both for >Poul-Henning and the end user. I am attaching 2 documents: >vcl_diagram_v1.png and vcl_diagram_proposal.png (*v1 is approx. what we >have today) I can't say I have thought deeply about the data model yet, my initial mock-up was based on a semi-object oriented model where we basically had four data objects: Client (Who asked) IP# Bandwidth estimate failed requests user agent ... Request (What they asked for) URL HEAD/GET/other Headers ... Object (Document in our cache) ttl length usage count refresh count ... Backend (Where we can get documents from) IP# responsetime ... >Also, the object (document if you like) has 2 sets of variables. For >example I think that backend.obj.usage and client.obj.usage makes sense. >Lets say it's a number/factor to say how often this object is >used/refreshed. A JPEG will have a low backend.obj.usage (since it typical >is not often requested from backend) but client.obj.usage will be high >(because its requested often, logo etc...). I can also think of more uses >here. I don't disagree with the two different usable numbers, but I think I do disagree with the naming. What you call backend.obj.usage isn't really a usage count, it is a refresh count, and since the client can't do that, just object.refreshcount would work without confusion. A fundamental rule in object-oriented programming is to make sure you have a good correspondence between your objects and the real world objects they represent, and I think splitting the "object" (or should we call it "document" instead ?) into a client and a backend side misses the point about the cache: It is the cached documents which are interesting here. The other thing I would like to point out is that a given document does not have a static mapping to a backend. For instance, we may pick it up from a peer server during startup and then subsequently refresh it from one of a number of backends whenever it is in danger of expiring. So the object/document clearly cannot be tied to a particular backend without severely constraining the efficiency and flexibility. >I have left out to define more variables in vcl_diagram_proposal.png, but >here are some examples of other "new" areas of variables: > >if (client.req.url.host ~ cnn.no){ > backend.req.url.host = vg.no >} > >This is rewrite :) Yes, but with the footnote that the host part has a more stringent syntax than the other half of the URL. But anyway, at the risk of sounding like a broken record, I think the best way to find out how VCL should develop is to try and use it, so lets sit down and write an actual real-life VCL program for VG's site, and see what we find out along the way. Poul-Henning -- 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 andersb at vgnett.no Tue Mar 28 17:39:09 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 28 Mar 2006 19:39:09 +0200 (CEST) Subject: VCL language In-Reply-To: <60922.1143529094@critter.freebsd.dk> References: Your message of "Tue, 28 Mar 2006 00:42:12 +0200." <2607.193.213.34.102.1143499332.squirrel@denise.vg.no> <60922.1143529094@critter.freebsd.dk> Message-ID: <1427.193.213.34.102.1143567549.squirrel@denise.vg.no> > In message <2607.193.213.34.102.1143499332.squirrel at denise.vg.no>, "Anders > Berg > " writes: > >>seeing that Poul-Henning is back to the VCL compiler again in the code, I >>think it is time to start a more detailed discussion about the VCL. > > Good time for it. I thought so :) >>My guess is that we are gonna spend "alot" of time on it, and it could be >>a natural part of a face-to-face meeting. I also acknowledge that the >>sooner we "freeze" the language, the easier and less rewrite of code >>Poul-Henning has to do. > > It's important to keep two things clear of each other here. On one hand >... > The other part, the variables and operations is in need for being > hashed out, because that is the next bit that I need to start working > on: Calling into the compiled VCL program from the cache process. Yes. I see that. > But there is a lot of code yet to be written before this stuff gets > in the critical path, so there is no need to yell "emergency" or > anything like it :-) Good. Hehe. >>I think our small "proof-of-concept" and the general look-and-feel of >> VCL, >>will make it suitable and _really_ good for Varnish. > > I think VCL is the bit which will make people sit up and take notice :-) I agree on that. Thats why we have to try and get it right the first time :) >>I/We haven't gotten down to trying/thinking/poking/defining/documenting >>the VCL yet, but I _think_ I might have come up with a "system" to make >>VCL easier to understand, and possible easier to code both for >>Poul-Henning and the end user. I am attaching 2 documents: >>vcl_diagram_v1.png and vcl_diagram_proposal.png (*v1 is approx. what we >>have today) > > I can't say I have thought deeply about the data model yet, my initial > mock-up was based on a semi-object oriented model where we basically > had four data objects: > > Client (Who asked) > IP# > Bandwidth estimate > failed requests > user agent > ... > > Request (What they asked for) > URL > HEAD/GET/other > Headers > ... > > Object (Document in our cache) > ttl > length > usage count > refresh count > ... > > Backend (Where we can get documents from) > IP# > responsetime > ... Yes, and it can work, but I think we will end up finding variables that really don't classify for either place. As you mention later, we should try and mock up some cfg's and see. >>Also, the object (document if you like) has 2 sets of variables. For >>example I think that backend.obj.usage and client.obj.usage makes sense. >>Lets say it's a number/factor to say how often this object is >>used/refreshed. A JPEG will have a low backend.obj.usage (since it >> typical >>is not often requested from backend) but client.obj.usage will be high >>(because its requested often, logo etc...). I can also think of more uses >>here. > > I don't disagree with the two different usable numbers, but I think > I do disagree with the naming. What you call backend.obj.usage isn't > really a usage count, it is a refresh count, and since the client > can't do that, just object.refreshcount would work without confusion. Okay, I see. I can imagine scenarios where the object class/variables will end up beeing used in a backend "context" and a frontend/client context. Time will show if this will be confusing. I am not "against" what we already have, just trying to categorize it a bit more, see if it works out good. > A fundamental rule in object-oriented programming is to make sure > you have a good correspondence between your objects and the real world > objects they represent, and I think splitting the "object" (or should > we call it "document" instead ?) into a client and a backend side > misses the point about the cache: It is the cached documents which > are interesting here. Agree. We should try to represent what we wanna use the object (in a object-oriented sense) for. Maybe we should call it a document. > The other thing I would like to point out is that a given document > does not have a static mapping to a backend. > > For instance, we may pick it up from a peer server during startup > and then subsequently refresh it from one of a number of backends > whenever it is in danger of expiring. > > So the object/document clearly cannot be tied to a particular > backend without severely constraining the efficiency and flexibility. Good point. I wasn't trying to map it to a specific backend (since, as you say, that is not the point). > > But anyway, at the risk of sounding like a broken record, I think the > best way to find out how VCL should develop is to try and use it, > so lets sit down and write an actual real-life VCL program for VG's > site, and see what we find out along the way. I agree. We/I should mock some up. It's just that since Squid has such "restrictions" as i has today, my squid.cfg files are not "advanced". But I am sure I could come up with a "dream-scenario" .cfg :) Not only for VG Nett (www.vg.no) but also for all the other sites (live.vg.no, tpn.vg.no etc.) that I use Bluecoat for today in 1 big .cfg file. You are far from sounding like a broken record :) > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > > From phk at phk.freebsd.dk Tue Mar 28 18:00:28 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 28 Mar 2006 20:00:28 +0200 Subject: VCL language In-Reply-To: Your message of "Tue, 28 Mar 2006 19:39:09 +0200." <1427.193.213.34.102.1143567549.squirrel@denise.vg.no> Message-ID: <63521.1143568828@critter.freebsd.dk> In message <1427.193.213.34.102.1143567549.squirrel at denise.vg.no>, "Anders Berg " writes: >I agree. We/I should mock some up. It's just that since Squid has such >"restrictions" as i has today, my squid.cfg files are not "advanced". But >I am sure I could come up with a "dream-scenario" .cfg :) Not only for VG >Nett (www.vg.no) but also for all the other sites (live.vg.no, tpn.vg.no >etc.) that I use Bluecoat for today in 1 big .cfg file. yeah, give it a shot while I implement pass-through mode... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Wed Mar 29 08:17:17 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 29 Mar 2006 10:17:17 +0200 Subject: VCL language In-Reply-To: Your message of "Tue, 28 Mar 2006 20:00:28 +0200." <63521.1143568828@critter.freebsd.dk> Message-ID: <66798.1143620237@critter.freebsd.dk> I spent most of yesterday crunching paper into small balls and throwing them out, but I think I got closer to understanding things. The problem is this: We want to give the user full control using VCL but we also want him to be able to start without having to write 2000 lines of VCL just to emulate the default behaviour. How we tackle this is deeply intertwined with the language and data model we choose for VCL. One approach we can take is to give the user a number of places where he can hook VCL code into the default processing, and that was more or less how I envisioned it originally. Unfortunately, that seems to end up rather complex and confusing once you try to actually hash out all the details. So then I took another route which said there will be only one VCL hook, and it will implement the entire thing and sufficient levels of DWIE (Do What I Expect) behind the scenes should make it simple for the user to replace this one VCL function. The learning curve for the user in this case is directly proportional with the length of the "default VCL code", so I started to look at how small we could make that while still giving the user the full flexibility to do whatever he damn well pleases. The default VCL is the one used for the case where only a backend IP# is specified: varnishd -b 10.0.0.1 If I boil it all the way down, the smallest default VCL I can come up with looks something like this: 1 backend default { 2 set backend.ip = 10.0.0.1; 3 } 4 5 proc varnish { 6 if (req.request != "GET" && req.request != "HEAD") { 7 pass 8 } 9 lookup; 10 if (!obj.valid) { 11 fetch; 12 if (obj.cacheable) { 13 insert; 14 } 15 } 16 } Now, please look at this carefully, before you read my explanation below, I want to hear your first hand impression: Is it intuitively obvious to the casual observer what goes on here ? Explanations: 1: All VCL programs must specify a backend named "default", which is the backend assigned to all requests unless the VCL explicitly assigns another one. This is more or less what the "-b IP" command line option translates to. 5: The "varnish" function could also be called "main" if we prefer. 6: Normally only GET/HEAD can be cached. 7: "pass" just pipes the request to the backend and sends the result back without inspecting anything either way and no object is created for the transaction. 9: "lookup" will hash the url and lookup an object. If no existing object is found a new (empty) one will be created. 10: If the object is not valid, we must fill it from the backend. 11: "fetch" does that. 12: If the object is cacheable, we insert it so future lookup's will find it. Obviously the variable "obj.cacheable" is actually a meta variable which implements the RFC2616 logic by inspecting the headers returned from the backend etc. 16: After "varnish" returns, an implict "finish" is executed if the VCL code didn't already do so. Does this make sense ? Could you try to embellish this "default VCL" to implement a couple of likely policies ? -- 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 andersb at vgnett.no Wed Mar 29 23:48:54 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 30 Mar 2006 01:48:54 +0200 (CEST) Subject: VCL language In-Reply-To: <66798.1143620237@critter.freebsd.dk> References: Your message of "Tue, 28 Mar 2006 20:00:28 +0200."<63521.1143568828@critter.freebsd.dk> <66798.1143620237@critter.freebsd.dk> Message-ID: <1543.193.213.34.102.1143676134.squirrel@denise.vg.no> > The problem is this: We want to give the user full control using > VCL but we also want him to be able to start without having to write > 2000 lines of VCL just to emulate the default behaviour. > [...] > The learning curve for the user in this case is directly proportional > with the length of the "default VCL code", so I started to look at > how small we could make that while still giving the user the full > flexibility to do whatever he damn well pleases. Yes, I can see why you have been crumbling paper. Hard to see this one coming, and even harder to solve out when you start thinking about it. I would have said we _have_ to have the flexibility, but you are right. This quickly becomes tricky. Seeing the default .cfg later on, we might have to consider the flexibility. Not because I don't think it is important (it's one of the main pilars!), but we need an "easy/ier" start. Darn... Is one approach to "hide" the default .cfg and say: Hey, this is probably what you wanna do. Don't look at it. ? Or is it better to let users have 2 "levels"? 1. Easy .cfg approach. Low flexibility. 2. Hard .cfg. High flex. We can provide sample .cfg files for the general needs at web-site? Just ideas, I don't like them. I have a hard time coming up with alternative approaches though. I _know_ you have wrestled the default .cfg file, so we have to come up with a solution another way. > The default VCL is the one used for the case where only a backend > IP# is specified: > > varnishd -b 10.0.0.1 > > If I boil it all the way down, the smallest default VCL I can come > up with looks something like this: > > 1 backend default { > 2 set backend.ip = 10.0.0.1; > 3 } > 4 > 5 proc varnish { > 6 if (req.request != "GET" && req.request != "HEAD") { > 7 pass > 8 } > 9 lookup; > 10 if (!obj.valid) { > 11 fetch; > 12 if (obj.cacheable) { > 13 insert; > 14 } > 15 } > 16 } > > Now, please look at this carefully, before you read my explanation > below, I want to hear your first hand impression: Is it intuitively > obvious to the casual observer what goes on here ? I did, and you are not gonna like my answer. As you mention later on, it's also a choise of semantics, but this is my head when I read it: 1-3: Fine 5: proc varnish? 6: Strange to have here, but okay, I understand it. 7: Pass. Fine. Wait, I wanna pass GET's and HEAD's or don't I? Pass? Hmm. I must read on. 9: lookup? DNS? Must read on. 10: !obj.valid, sure. When my document is not valid in cache. 11: fetch. Must mean fetch from backend. Fine. 12: Hold on, why are we still in loop. Read 10-11, and see where if ends. Okay, I now know that this must be something that must be in the loop. Not sure why. obj.cacheable, sure. 13: insert. Okay. It's cacheable, insert in cache. XX: Why is the obj.cacheable inside the loop? Could it not be outside the loop? Head crash. Heck, it probably has to be that way. lol, I am not claiming to be the sharpest tool, but I guess many may feel like how I just did. Sorry for the details of my head, but it may help us getting closer to a good solution. I could live with a .cfg like that, but I _certainly_ would not deploy it before I read some documentation. > Does this make sense ? Yes, it all does, but not the default .cfg :) > Could you try to embellish this "default VCL" to implement a couple of > likely policies ? At VG Nett we config a cache mainly to try to do 3 thing. 1. docs with ending .XXX must be cached for XX min. (.hbs 5 min, .gif 1 weekish, .jpg 1 weekish. etc...) 2. Please cache everything in this damn poorly written app for 10 sec (if it's a soccer event etc.) or 5 min in general. 3. My app is written good for once. Please confim to its expiry. So I guess I would try something like: 1 backend default { 2 set backend.ip = 10.0.0.1; 3 } 4 5 proc varnish { 6 if (req.request != "GET" && req.request != "HEAD") { 7 pass 8 } 9 lookup; 10 if (!obj.valid) { 11 fetch; 12 if (obj.url ~ .hbs){ # It feels strange to use req.url.path here! 13 obj.ttl_in_cache = 5 min # No variable to use. Not ttl. for sure. 14 insert # ? 15 } 16-28 # just like .hbs with .jpg and .gif 29 if (obj.path ~ /poor_written){ 30 obj.ttl_in_cache = 5 min 31 } 32 if (obj.path ~ /nicly_written){ 33 obey_header # No variable to use. 34 } 35 if (obj.cacheable) { 36 insert; 37 } 38 } 39 } To put it this way. I understand why you have been crumpeling paper all day. I feel bad not to come up with a solution here and now, but I really can't... I will think about this, and I am sure you and Dag will also. Beeing born in Bod?, far up in Norway, leaves me beeing overly optimistic though :) Anders Berg From andersb at vgnett.no Wed Mar 29 23:54:41 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 30 Mar 2006 01:54:41 +0200 (CEST) Subject: Good reading Message-ID: <1566.193.213.34.102.1143676481.squirrel@denise.vg.no> Found this today: http://www.cyrius.com/publications/senyard_michlmayr-successful_project.pdf I/We may wanna try to follow some of the "advise". I see parts that we are good/strong at, and parts that needs to be ironed out more. I'll follow that up later, and when the time is right. Anyway, good reading for everybody (I think). Anders Berg From phk at phk.freebsd.dk Thu Mar 30 06:40:26 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 30 Mar 2006 08:40:26 +0200 Subject: VCL language In-Reply-To: Your message of "Thu, 30 Mar 2006 01:48:54 +0200." <1543.193.213.34.102.1143676134.squirrel@denise.vg.no> Message-ID: <3646.1143700826@critter.freebsd.dk> In message <1543.193.213.34.102.1143676134.squirrel at denise.vg.no>, "Anders Berg" writes: I think a large part of the solution is to come up with some clear examples to show people how to do things. Is this an improvement ? 1 backend default { 2 set backend.ip = 10.0.0.1; 3 } 4 5 proc main { 6 if (req.request != "GET" && req.request != "HEAD") { 7 pass_through; 8 } 9 lookup_object; 10 if (obj.valid) { 11 finish; 12 } 13 fetch; 14 if (obj.url ~ "[.]hbs$") { 15 obj.ttl = 5m; 16 obj.cacheable = true; 17 } elif (obj.url ~ "[.]jpg$" || obj.url ~ "[.]gif$") { 18 obj.ttl = 1w; 19 obj.cacheable = true; 20 } elif (obj.url ~ "/poor_written") { 21 obj.ttl = 5m; 22 obj.cacheable = true; 23 } 24 if (obj.cacheable) { 25 insert; 26 } 27 } 14,17,20: a '.' in a regexp means "any character", putting it in [.] is a readable way to escape it. Because we use strings enclosed in double-quotes, the backslash-escape would be "\\.jpg$". The trailing '$' is to avoid false matches. Of course, we could also add a if (obj.suffix = ".hbs") if we wanted to make this easier/faster. 15,16: We could let the "obj.cacheable = true" be implicit when obj.ttl is set, I can't really see why we shouldn't ? 17: Another way to write it could be: if (obj.content_type ~ "image/") { So with those changes it would look like this: 1 backend default { 2 set backend.ip = 10.0.0.1; 3 } 4 5 proc main { 6 if (req.request != "GET" && req.request != "HEAD") { 7 pass_through; 8 } 9 lookup_object; 10 if (obj.valid) { 11 finish; 12 } 13 fetch; 14 if (obj.suffix = ".hbs") { 15 obj.ttl = 5m; 16 } if (obj.content_type ~ "image/") { 17 obj.ttl = 1w; 18 } elif (obj.url ~ "/poor_written") { 19 obj.ttl = 5m; 20 } 21 if (obj.cacheable) { 22 insert; 23 } 24 } -- 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 Anders.Berg at vg.no Thu Mar 30 12:02:49 2006 From: Anders.Berg at vg.no (Anders Berg) Date: Thu, 30 Mar 2006 14:02:49 +0200 Subject: SV: VCL language Message-ID: <6AD33D89A21F7B479107D712EF96FDA52EF406@VG-EXC-VIR-1.Akersgt.local> > In message > <1543.193.213.34.102.1143676134.squirrel at denise.vg.no>, > "Anders Berg" writes: > > I think a large part of the solution is to come up with some > clear examples to show people how to do things. > > Is this an improvement ? > > 1 backend default { > 2 set backend.ip = 10.0.0.1; > 3 } > 4 > 5 proc main { > 6 if (req.request != "GET" && req.request != "HEAD") { > 7 pass_through; > 8 } > 9 lookup_object; > 10 if (obj.valid) { > 11 finish; > 12 } > 13 fetch; > 14 if (obj.url ~ "[.]hbs$") { > 15 obj.ttl = 5m; > 16 obj.cacheable = true; > 17 } elif (obj.url ~ "[.]jpg$" || obj.url ~ "[.]gif$") { > 18 obj.ttl = 1w; > 19 obj.cacheable = true; > 20 } elif (obj.url ~ "/poor_written") { > 21 obj.ttl = 5m; > 22 obj.cacheable = true; > 23 } > 24 if (obj.cacheable) { > 25 insert; > 26 } > 27 } Yes, this is better, but I like the one underneath even better. > 14,17,20: a '.' in a regexp means "any character", putting it in [.] > is a readable way to escape it. Because we use strings > enclosed in double-quotes, the backslash-escape would be > "\\.jpg$". The trailing '$' is to avoid false matches. > > Of course, we could also add a > if (obj.suffix = ".hbs") > if we wanted to make this easier/faster. > > 15,16: We could let the "obj.cacheable = true" be > implicit when > obj.ttl is set, I can't really see why we shouldn't ? > > 17: Another way to write it could be: > > if (obj.content_type ~ "image/") { > > So with those changes it would look like this: > > 1 backend default { > 2 set backend.ip = 10.0.0.1; > 3 } > 4 > 5 proc main { > 6 if (req.request != "GET" && req.request != "HEAD") { > 7 pass_through; > 8 } > 9 lookup_object; > 10 if (obj.valid) { > 11 finish; > 12 } > 13 fetch; > 14 if (obj.suffix = ".hbs") { > 15 obj.ttl = 5m; > 16 } if (obj.content_type ~ "image/") { > 17 obj.ttl = 1w; > 18 } elif (obj.url ~ "/poor_written") { > 19 obj.ttl = 5m; > 20 } > 21 if (obj.cacheable) { > 22 insert; > 23 } > 24 } This looks good, apart from 1 thing. 21 if (obj.cacheable) { 22 insert; 23 } I guess most appications have a Expires header either they are right or not. So while obj.cacheable is good and we should keep it, we need maybe 1 more. So I would suggest a 21 if (obj.url ~ "/nicely_written"){ 22 trust_header; 23 } This is the same as: 21 if (obj.url ~ "/nicely_written"){ 22 if (obj.cacheable) { 23 insert; 24 } 25 } I think this is a good abstraction. Good work. This problem could maybe just be a semantic and implementation challange. Anders Berg > > -- > 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. > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From phk at phk.freebsd.dk Thu Mar 30 12:12:01 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 30 Mar 2006 14:12:01 +0200 Subject: SV: VCL language In-Reply-To: Your message of "Thu, 30 Mar 2006 14:02:49 +0200." <6AD33D89A21F7B479107D712EF96FDA52EF406@VG-EXC-VIR-1.Akersgt.local> Message-ID: <41442.1143720721@critter.freebsd.dk> In message <6AD33D89A21F7B479107D712EF96FDA52EF406 at VG-EXC-VIR-1.Akersgt.local>, "Anders Berg" writes: >> So with those changes it would look like this: >> >> 1 backend default { >> 2 set backend.ip = 10.0.0.1; >> 3 } >> 4 >> 5 proc main { >> 6 if (req.request != "GET" && req.request != "HEAD") { >> 7 pass_through; >> 8 } >> 9 lookup_object; >> 10 if (obj.valid) { >> 11 finish; >> 12 } >> 13 fetch; >> 14 if (obj.suffix = ".hbs") { >> 15 obj.ttl = 5m; >> 16 } if (obj.content_type ~ "image/") { >> 17 obj.ttl = 1w; >> 18 } elif (obj.url ~ "/poor_written") { >> 19 obj.ttl = 5m; >> 20 } >> 21 if (obj.cacheable) { >> 22 insert; >> 23 } >> 24 } > >This looks good, apart from 1 thing. > >21 if (obj.cacheable) { >22 insert; >23 } > >I guess most appications have a Expires header either they are right or >not. So while obj.cacheable is good and we should keep it, we need maybe >1 more. >So I would suggest a > >21 if (obj.url ~ "/nicely_written"){ >22 trust_header; >23 } Hmm, I think that by default we should expect non-broken behaviour, so I would rather have a "disregard_headers" sort of escape than having to explicitly mark backends which actually do work correctly. Maybe I'm na?ve here :-) >Good work. This problem could maybe just be a semantic and >implementation challange. Yes, I rather think so, I don't think there is any doubt about the basic VCL idea being the right way to go, it's just a matter of getting the actual language optimized for expressing what people want to say. -- 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 Anders.Berg at vg.no Thu Mar 30 12:41:15 2006 From: Anders.Berg at vg.no (Anders Berg) Date: Thu, 30 Mar 2006 14:41:15 +0200 Subject: VCL language Message-ID: <6AD33D89A21F7B479107D712EF96FDA52EF44B@VG-EXC-VIR-1.Akersgt.local> > -----Opprinnelig melding----- > Fra: phk at critter.freebsd.dk [mailto:phk at critter.freebsd.dk] P? vegne > > >I guess most appications have a Expires header either they > are right or > >not. So while obj.cacheable is good and we should keep it, we need > >maybe > >1 more. > >So I would suggest a > > > >21 if (obj.url ~ "/nicely_written"){ > >22 trust_header; > >23 } > > > Hmm, I think that by default we should expect non-broken behaviour, so > I would rather have a "disregard_headers" sort of escape than having > to explicitly mark backends which actually do work correctly. > > Maybe I'm na?ve here :-) Sorry, I was nesting in my head here. You are right. The default should work correctly. > >Good work. This problem could maybe just be a semantic and > >implementation challange. > > Yes, I rather think so, I don't think there is any doubt about the > basic VCL idea being the right way to go, it's just a matter of > getting the actual language optimized for expressing what people want > to say. It really looks that way. Puhh :) Anders Berg ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. *****************************************************************