From mike at weck.us Thu Feb 1 05:24:21 2007 From: mike at weck.us (Michael Weck) Date: Thu, 01 Feb 2007 00:24:21 -0500 Subject: 1.02 children die under high load Message-ID: <45C17985.3070105@weck.us> Hi, Just stumbled across Varnish from a link on WikiPedia. I found someone who had built a Debian Sarge compatible package as I did not have much luck compiling it from source. I can get Varnish to run and forward requests to the backend server and serve up those requests, however the process seems to reset itself under load. When I run varnishstat the counter gets to about 10 seconds, then it resets. That is at around 130 requests/second. The backend server is Lighttpd 1.4.11 Should I try building a version from SVN? Or is this a known issue? Best Regards, Michael Weck From phk at phk.freebsd.dk Thu Feb 1 07:37:21 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 01 Feb 2007 07:37:21 +0000 Subject: 1.02 children die under high load In-Reply-To: Your message of "Thu, 01 Feb 2007 00:24:21 EST." <45C17985.3070105@weck.us> Message-ID: <56665.1170315441@critter.freebsd.dk> In message <45C17985.3070105 at weck.us>, Michael Weck writes: >I can get Varnish to run and forward requests to the backend server and >serve up those requests, however the process seems to reset itself under >load. When I run varnishstat the counter gets to about 10 seconds, then >it resets. That is at around 130 requests/second. The backend server is >Lighttpd 1.4.11 Run varnishd with "-d -d" arguments and type "param.show" Make sure the threadpool maximum is larger than 1 -- 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 steinove at vg.no Mon Feb 5 08:44:50 2007 From: steinove at vg.no (Stein Ove Rosseland) Date: Mon, 05 Feb 2007 09:44:50 +0100 Subject: 1.02 children die under high load In-Reply-To: <56665.1170315441@critter.freebsd.dk> References: <56665.1170315441@critter.freebsd.dk> Message-ID: <45C6EE82.8020903@vg.no> Poul-Henning Kamp wrote: > In message <45C17985.3070105 at weck.us>, Michael Weck writes: > >> I can get Varnish to run and forward requests to the backend server and >> serve up those requests, however the process seems to reset itself under >> load. When I run varnishstat the counter gets to about 10 seconds, then >> it resets. That is at around 130 requests/second. The backend server is >> Lighttpd 1.4.11 > Thats the same problem as we have, when running lighttpd 1.4.13 as the backend, varnish resets when the traffic load gets high enough. > Run varnishd with "-d -d" arguments and type "param.show" > > Make sure the threadpool maximum is larger than 1 Ive set threadpool max to 1000, we are not close to that number of threads, it usually stays between 100-200. Stein ***************************************************************** 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 Feb 5 12:16:25 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 Feb 2007 12:16:25 +0000 Subject: 1.02 children die under high load In-Reply-To: Your message of "Mon, 05 Feb 2007 09:44:50 +0100." <45C6EE82.8020903@vg.no> Message-ID: <85701.1170677785@critter.freebsd.dk> In message <45C6EE82.8020903 at vg.no>, Stein Ove Rosseland writes: >Poul-Henning Kamp wrote: >> In message <45C17985.3070105 at weck.us>, Michael Weck writes: >> >>> I can get Varnish to run and forward requests to the backend server and >>> serve up those requests, however the process seems to reset itself under >>> load. When I run varnishstat the counter gets to about 10 seconds, then >>> it resets. That is at around 130 requests/second. The backend server is >>> Lighttpd 1.4.11 >> >Thats the same problem as we have, when running lighttpd 1.4.13 as the >backend, varnish resets when the traffic load gets high enough. Ok, then it's probably some of the missing error handling code on the backend connections. It's on the list. -- 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 Feb 5 21:18:29 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 Feb 2007 21:18:29 +0000 Subject: [RFC] Changes to pass mode Message-ID: <87491.1170710309@critter.freebsd.dk> The original intent was that pass-mode should be able to handle PUT and POST requests (if invoked from vcl_recv{} and should allow reuse of the backend connection afterwards. Judging from the feedback and requests I have received, this is unnecessary generality. POST and PUT seems to be heavily tangled in authentication and cookies which disable caching anyway, so using pipe-mode for those, does not seem to hurt anybody to any extent that matters. Discarding the PUT/POST handling requirement from pass, allows me to treat pass more or less as a miss, and thus avoid a special case of the functions for talking to the backend, and it gives us one of the much asked for facilities: slow-client mitigation for CGI content done in pass mode, almost for free. This results in some some subtle and some not so subtle changes, which I am looking for feedback on. It will help if you have this dot(1) plot open in a window while reading the rest of this email: http://phk.freebsd.dk/misc/varnish.gif Take a moment to follow the green/blue paths which are the normal hit/miss scenarios. Pass can take two variants in this new world order, from vcl_recv{} or from anywhere else. If vcl_recv{} does pass, an object is created which is not inserted into the hash table, and it is marked as not cacheable. (The object will not be inserted in the hash, even if vcl_fetch() invokes "insert".) We then proceed as a normal cache-miss. Since the object is not inserted in the hash, the next client to ask for this url will not find this object and unless that client also gets a pass in vcl_recv{}, normal processing will happen. The upshot of this is, that certain clients can be forced to do a pass in vcl_recv{} without forcing all clients to do this. If pass is invoked from vcl_miss{} or vcl_fetch{}, an entry will be inserted into the hash marking this object as a "obj.pass" object which cannot be cached. If vcl_hit{} invokes pass, the request will be serviced as a pass, even if we had found a good cached object. If vcl_hit{} finds a "obj.pass" hit in the hash, the request will also be handled as a pass. The other change ---------------- The other change to be aware of, is that the entire object is fetched from the backend before vcl_fetch() is called, previously we only had the headers at that point. This allows us to detect backend errors in vcl_fetch{}, and once we implement "retry lookup" we can aim the request at another backend or whatever error-recovery we prefer. It also paves the way for gzip'ing things in vcl_fetch() later on. Does this make sense ? Any better ideas ? Does anybody even read this mail-list anymore ? :-) Poul-Henning PS: if you want to see the current state diagram, the instructions for how to create it is at the top of bin/varnishd/cache_center.c -- 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 aapke at krugle.com Mon Feb 5 23:16:51 2007 From: aapke at krugle.com (Alex Apke) Date: Mon, 5 Feb 2007 15:16:51 -0800 Subject: cache backend using 10X the amount of space Message-ID: <20070205231651.GA26813@avon.geekhive.net> I was wonding if it's normal that varnish uses 10X the amount of space for small 3Kb pages? It seems that the cache ends up using between 28-30Kb for each 3Kb webpage. I can understand there being some overhead, but 10 times the size, seems a bit much. A related question, when the cache backend storagefile reaches the maximum size, the whole cache seems to get invalidated and the contents gets lost, and needs re-priming. Are there any options for using LRU or other cache algorithms for handling the maximum backend storage file size. I haven't found anything in the documentation or the website related to this issue. Thanks -- Alex From gaute at pht.no Tue Feb 6 09:57:43 2007 From: gaute at pht.no (Gaute Amundsen) Date: Tue, 6 Feb 2007 10:57:43 +0100 Subject: [RFC] Changes to pass mode In-Reply-To: <87491.1170710309@critter.freebsd.dk> References: <87491.1170710309@critter.freebsd.dk> Message-ID: <200702061057.44146.gaute@pht.no> On Monday 05 February 2007 22:18, Poul-Henning Kamp wrote: > Does anybody even read this mail-list anymore ? ?:-) It's a rather quiet place yes, but closely watched. I'm not quite at the level where I feel I have any technical comments, but I am happy to se progress. I just read the Fielding Dissertation, so I expect to be working with Varnish for quite a while :) Regards Gaute Amundsen -- Programmerer - Pixelhospitalet AS T?rkoppveien 10, 1570 Dilling Tlf. 24 12 97 81 - 9074 7344 From andersb at vg.no Tue Feb 6 16:11:17 2007 From: andersb at vg.no (Anders Berg) Date: Tue, 6 Feb 2007 17:11:17 +0100 Subject: SV: [RFC] Changes to pass mode Message-ID: Jepp :) Anders Berg www.vg.no // VG Nett -----Opprinnelig melding----- Fra: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] P? vegne av Poul-Henning Kamp Sendt: 5. februar 2007 22:18 Til: varnish-misc at projects.linpro.no Emne: [RFC] Changes to pass mode Does anybody even read this mail-list anymore ? :-) Poul-Henning PS: if you want to see the current state diagram, the instructions for how to create it is at the top of bin/varnishd/cache_center.c -- 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-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc ***************************************************************** 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 ingvar at linpro.no Wed Feb 7 08:01:47 2007 From: ingvar at linpro.no (Ingvar Hagelund) Date: Wed, 07 Feb 2007 09:01:47 +0100 Subject: SV: [RFC] Changes to pass mode In-Reply-To: References: Message-ID: <45C9876B.7090702@linpro.no> * Poul-Henning > Does anybody even read this mail-list anymore ? :-) *hand* Ingvar -- N?r alt annet feiler: Symlink From des at linpro.no Wed Feb 7 10:54:34 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed, 07 Feb 2007 11:54:34 +0100 Subject: [RFC] Changes to pass mode In-Reply-To: <87491.1170710309@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 05 Feb 2007 21:18:29 +0000") References: <87491.1170710309@critter.freebsd.dk> Message-ID: Poul-Henning Kamp writes: > Does this make sense ? Yes. 1) I've had trouble with PASS vs. PIPE in the past which have led me to conclude that PASS as it is today is not very useful. There is one downside to PIPE: we can't insert a header telling the backend that we're acting on behalf of a client, which makes logging difficult. We *can* do so with PASS, though I believe we currently don't. 2) The current backend code is fragile, and the separate code paths make debugging it difficult; as I understand your proposal, the backend code will become more unified, which will help improve robustness and error handling and facilitate debugging. > Any better ideas ? Not off the top of my head... > Does anybody even read this mail-list anymore ? :-) Yes :) DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Wed Feb 7 11:14:29 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 07 Feb 2007 11:14:29 +0000 Subject: [RFC] Changes to pass mode In-Reply-To: Your message of "Wed, 07 Feb 2007 11:54:34 +0100." Message-ID: <99448.1170846869@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >Poul-Henning Kamp writes: > There is one downside to PIPE: we can't insert a header telling the > backend that we're acting on behalf of a client, which makes > logging difficult. We *can* do so with PASS, though I believe we > currently don't. Well, it should be (will be) possible to do that in vcl_recv{} but it may make sense to have a vcl_pipe{} for that job, to avoid repetitions in vcl_recv{}. -- 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 Wed Feb 7 13:48:17 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed, 07 Feb 2007 14:48:17 +0100 Subject: [RFC] Changes to pass mode In-Reply-To: <99448.1170846869@critter.freebsd.dk> (Poul-Henning Kamp's message of "Wed, 07 Feb 2007 11:14:29 +0000") References: <99448.1170846869@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Dag-Erling Sm?rgrav writes: > > There is one downside to PIPE: we can't insert a header telling the > > backend that we're acting on behalf of a client, which makes > > logging difficult. We *can* do so with PASS, though I believe we > > currently don't. > Well, it should be (will be) possible to do that in vcl_recv{} but > it may make sense to have a vcl_pipe{} for that job, to avoid > repetitions in vcl_recv{}. Well, by definition we *can't* do it in PIPE since PIPE is supposed to pass traffic back and forth unaltered. We *can* (and IMHO *should*) do it in PASS. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Wed Feb 7 14:26:20 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 07 Feb 2007 14:26:20 +0000 Subject: [RFC] Changes to pass mode In-Reply-To: Your message of "Wed, 07 Feb 2007 14:48:17 +0100." Message-ID: <172.1170858380@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> Dag-Erling Sm=F8rgrav writes: >> > There is one downside to PIPE: we can't insert a header telling the >> > backend that we're acting on behalf of a client, which makes >> > logging difficult. We *can* do so with PASS, though I believe we >> > currently don't. >> Well, it should be (will be) possible to do that in vcl_recv{} but >> it may make sense to have a vcl_pipe{} for that job, to avoid >> repetitions in vcl_recv{}. > >Well, by definition we *can't* do it in PIPE since PIPE is supposed to >pass traffic back and forth unaltered. We *can* (and IMHO *should*) >do it in PASS. Weeeell, We can do it in the _first_ PIPE transaction, and that could maybe be used to force the backend to close after that transaction, so we avoid piping more than that one transaction. -- 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 ask at develooper.com Thu Feb 8 01:10:44 2007 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Wed, 7 Feb 2007 17:10:44 -0800 Subject: SV: [RFC] Changes to pass mode In-Reply-To: <45C9876B.7090702@linpro.no> References: <45C9876B.7090702@linpro.no> Message-ID: On Feb 7, 2007, at 0:01, Ingvar Hagelund wrote: > * Poul-Henning >> Does anybody even read this mail-list anymore ? :-) > > *hand* Here too. :-) The changes proposed looked good, but I didn't feel qualified to reply. I'm not actually using Varnish yet. My favorite (upcoming) features are deflate, vary support and eventually ESI. Another thing that we need (but I don't think Varnish does yet) is buffering the response so the backend can be freed up while slow clients retrieve the data at their leisure. (Apologies if we talked about this before...) - ask -- http://develooper.com/ - http://askask.com/ From phk at phk.freebsd.dk Thu Feb 8 07:03:25 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Feb 2007 07:03:25 +0000 Subject: SV: [RFC] Changes to pass mode In-Reply-To: Your message of "Wed, 07 Feb 2007 17:10:44 PST." Message-ID: <4025.1170918205@critter.freebsd.dk> In message , =?ISO-8859-1? Q?Ask_Bj=F8rn_Hansen?= writes: >Another thing that we need (but I don't think Varnish does yet) is >buffering the response so the backend can be freed up while slow >clients retrieve the data at their leisure. (Apologies if we talked >about this before...) It already does this in the normal case, with the change I proposed, pass will also do that. -- 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 ff at partyticket.net Thu Feb 8 16:20:37 2007 From: ff at partyticket.net (Flemming Frandsen) Date: Thu, 08 Feb 2007 17:20:37 +0100 Subject: cache backend using 10X the amount of space Message-ID: <45CB4DD5.5080405@partyticket.net> Someone please set the Reply-to header to varnish-misc at projects.linpro.no for this list? Alternatively I'd like a recommendation for a mailer that knows about mailing lists and can add the header for me. -------- Original Message -------- Subject: Re: cache backend using 10X the amount of space Date: Wed, 7 Feb 2007 11:37:43 -0800 From: Alex Apke To: Flemming Frandsen References: <20070205231651.GA26813 at avon.geekhive.net> <45C97FDA.5040606 at partyticket.net> On Wed, Feb 07, 2007 at 08:29:30AM +0100, Flemming Frandsen wrote: > Alex Apke wrote: > >A related question, when the cache backend storagefile reaches the > >maximum size, > > What did you set that size to? > At first, I set it to 20MB, then 200MB, and currently I am testing it with 6GB. With 20 and 200, the backend seems to rollover. I haven't yet filled all 6GB so I don't know if it will happen, but I assume it will. Watching the varnishstat when this happens, all the numbers reset to zero including cache hits, misses, etc... I also noticed that when the stats reset and the cache invalidates itself, a new child processes replaces the original child. Note: I am using the precompiled rpms for RHEL4, which I assume are ok. -- Alex -- Regards Flemming Frandsen - YAPH - http://dion.swamp.dk From des at linpro.no Thu Feb 8 16:28:41 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 08 Feb 2007 17:28:41 +0100 Subject: cache backend using 10X the amount of space In-Reply-To: <45CB4DD5.5080405@partyticket.net> (Flemming Frandsen's message of "Thu, 08 Feb 2007 17:20:37 +0100") References: <45CB4DD5.5080405@partyticket.net> Message-ID: Flemming Frandsen writes: > Someone please set the Reply-to header to > varnish-misc at projects.linpro.no for this list? http://www.unicom.com/pw/reply-to-harmful.html > Alternatively I'd like a recommendation for a mailer that knows about > mailing lists and can add the header for me. Check to see if your MUA has a feature called "wide reply" or "group reply" or "followup", which replies to the sender *and* all recipients of the original message. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Feb 12 12:38:28 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 12 Feb 2007 12:38:28 +0000 Subject: [RFC] version 2 state diagram (take 2) Message-ID: <6231.1171283908@critter.freebsd.dk> I would appreciate if you call could take a moment to look at this diagram and see if it makes sense: http://phk.freebsd.dk/misc/varnish.png One way or another, something like this will be the cornerstone in explaning VCL to Varnish users, so I would appreciate feedback from you guys that this is actually understandable. The plot has gotten simpler, partly because I did it by hand instead of using dot(1), but more so because I found out that I needed to trust VCL to do more things. I think the result is an improvement. There are some new vcl functions as a result, so let me present them all: vcl_recv{} Good place to check ACLs, rewrite URLS and generally fix up things. Pipe must be selected from here if necessary. If you select pass from here it will not result in a cached "pass this one" entry. This is useful for giving a limited subset of clients direct access to the backend. vcl_hash{} Place holder for the idea that it might be desirable to hash on more or different fields than (URL+Host:). Not fully thought through yet, may or may not happen. vcl_hit{} Not really sure what you would do here, but you get the chance if you dream up something. One possible thing would be to react to high hitrates and initiate compression. vcl_miss{} Fix up headers before requesting from backend vcl_pass{} Fix up headers before requesting from backend vcl_fetch{} Fix up headers received from backend. Decide if object gets cached or not. Determine Time To Live vcl_pipe{} Fix up headers before requesting from backend Hint: Insert "Connection: close" header to terminate pipe session after one request. vcl_error{} Issue error object to client. Poul-Henning PS: Computer Science connoisseurs will recognize, the graph as inspired by figure 3 in the 1975 paper by S?ren Lauesen "A Large Semaphore Based Operating System": All the arrows point downwards as intuitive proof that no loops are possible. -- 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 Feb 12 12:57:31 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 12 Feb 2007 13:57:31 +0100 Subject: [RFC] version 2 state diagram (take 2) In-Reply-To: <6231.1171283908@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 12 Feb 2007 12:38:28 +0000") References: <6231.1171283908@critter.freebsd.dk> Message-ID: Poul-Henning Kamp writes: > I would appreciate if you call could take a moment to look at this > diagram and see if it makes sense: > > http://phk.freebsd.dk/misc/varnish.png It certainly is a lot more readable than the complete diagram (http://phk.freebsd.dk/misc/varnish.gif). I assume all the red arrows point to vcl_error()? > The plot has gotten simpler, partly because I did it by hand instead > of using dot(1), but more so because I found out that I needed to > trust VCL to do more things. Absolutely. > vcl_hash{} > Place holder for the idea that it might be desirable to > hash on more or different fields than (URL+Host:). > > Not fully thought through yet, may or may not happen. Strictly speaking, you need to hash on every header mentioned in Vary:, but you don't even have that information until you've retrieved at least one version of the document from the backend - and even then, when a new request comes in, you need to identify the requested document to know which headers to hash on - so it looks like we need a two-level hash. > vcl_hit{} > Not really sure what you would do here, but you get > the chance if you dream up something. > > One possible thing would be to react to high hitrates > and initiate compression. ...or check the time remaining before expiry and initiate a prefetch? You don't mention vcl_timeout, which in any case isn't called until after the document has expired. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Feb 12 14:42:22 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 12 Feb 2007 14:42:22 +0000 Subject: [RFC] version 2 state diagram (take 2) In-Reply-To: Your message of "Mon, 12 Feb 2007 13:57:31 +0100." Message-ID: <6547.1171291342@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >I assume all the red arrows point to vcl_error()? Yes, I didn't want to clutter the drawing with them. >> vcl_hash{} >> Place holder for the idea that it might be desirable to >> hash on more or different fields than (URL+Host:). >> >> Not fully thought through yet, may or may not happen. > >Strictly speaking, you need to hash on every header mentioned in >Vary:, but you don't even have that information until you've retrieved >at least one version of the document from the backend - and even then, >when a new request comes in, you need to identify the requested >document to know which headers to hash on - so it looks like we need a >two-level hash. You can't hash on Vary, it's a response side header. Vary must be handled by traversing the list of possible objects looking for matches. >> vcl_hit{} >> Not really sure what you would do here, but you get >> the chance if you dream up something. >> >> One possible thing would be to react to high hitrates >> and initiate compression. > >...or check the time remaining before expiry and initiate a prefetch? >You don't mention vcl_timeout, which in any case isn't called until >after the document has expired. My plans for vcl_timeout{} are not firm yet, but the idea is to call vcl_timeout{} before expiry to decide on prefetching and possibly compression. The comment above therefore hints at the vcl_hit{} being able to reduce the timeout for an object, so vcl_timeout{} can get a shot at compressing it. But lets concentrate on the "traffic" part for now, vcl_timeout{} needs a bit more time with the thinking cap. -- 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 denis at startsiden.no Mon Feb 12 22:38:09 2007 From: denis at startsiden.no (=?utf-8?Q?Denis_Br=C3=A6khus?=) Date: Mon, 12 Feb 2007 23:38:09 +0100 (CET) Subject: Current Varnish status? Message-ID: <6736260.30521171319889538.JavaMail.root@ms1.startsiden.no> Hi list, I have scanned the pretty light backlogs on the Varnish lists, and I haven't seen much discussion on the current state of Varnish. There was mention of problems with lighthttpd, but other than that I couldn't find much.. So, my question is, how stable do you consider the current release to be? Is SVN more stable or is the release the way to go? Anyone using Varnish in a production environment at all? Is that even something I should contemplate? My environment would consist of an app running on Apache 2.0.x with php, so lighthttpd issues are not a concern. If it is not advisable to use Varnish (yet) does anyone have tips as to alternative solutions? (Squid is of course the ugly but well known alternative.) Any input would be helpful, we could really use something like Varnish, now! ABC Startsiden AS might also be interested in sponsoring the development work soonish. Regards -- Denis Braekhus - Teknisk Ansvarlig ABC Startsiden AS http://www.startsiden.no From Kenneth.Rorvik at hio.no Tue Feb 13 07:57:03 2007 From: Kenneth.Rorvik at hio.no (=?UTF-8?B?S2VubmV0aCBSw7hydmlr?=) Date: Tue, 13 Feb 2007 08:57:03 +0100 Subject: Current Varnish status? In-Reply-To: <6736260.30521171319889538.JavaMail.root@ms1.startsiden.no> References: <6736260.30521171319889538.JavaMail.root@ms1.startsiden.no> Message-ID: <45D16F4F.1010901@hio.no> Denis Br?khus wrote: > So, my question is, how stable do you consider the current release to be? I cannot comment on the code itself, but I can give a couple of comments on how I perceive varnish as an end-user: I have been using varnish in a production environment (http://www.hio.no) for three weeks + now. In that time, there's been one major incident, in which varnish suddenly started dropping all incoming connections, possibly resetting, with clients ending up simply with blank pages. At the same time, our main gateway (hio-gw.uninett.no) was also restarted - which probably SHOULD not affect varnish or the web server, but my knowledge of TCP and IP is not perfect. Furthermore, the same problem was actually worse (in test) for the latest stable Red Hat RPM - I am currently running on SVN code (Jan 18). Varnish has been running smoothly after that incident. Still, I am keeping a close eye on things as I do not trust varnish 100% - call it gut feeling, anyway, I AM using it for production on a college site. I don't wan't to get my hands dirty with squid, and varnish is refreshingly simple. My setup is not perfect, I have a major leak on a popular page (due to a redirect that varnish does not yet handle), but some graphs are at http://statisk.hio.no/stat/graph/ - varnish was implemented late week 3, and the "anomaly" mentioned was medio week 5. I am keeping a close eye on this list - and the varnish work is being much appreciated. Keep it up :) -- Kenneth R?rvik, IT HiO Tlf 22 45 20 83 Kenneth.Rorvik at hio.no From phk at phk.freebsd.dk Tue Feb 13 09:32:11 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Feb 2007 09:32:11 +0000 Subject: Current Varnish status? In-Reply-To: Your message of "Tue, 13 Feb 2007 08:57:03 +0100." <45D16F4F.1010901@hio.no> Message-ID: <10695.1171359131@critter.freebsd.dk> In message <45D16F4F.1010901 at hio.no>, =?UTF-8?B?S2VubmV0aCBSw7hydmlr?= writes: >Denis Br??khus wrote: >> So, my question is, how stable do you consider the current release to be? > >I cannot comment on the code itself, but I can give a couple of comments >on how I perceive varnish as an end-user: I have always myself been cautions about software with an odd numbered release, 1.0, 3.0, 5.0 etc. I have too much statistical evidence to call this a superstition :-) I've seen "productionquality" software fare worse than Varnish and I have seen much software with better error handling than varnish presently have, but all in all, Varnish is an average 1.0 release. The good news is that Varnish doesn't suffer from anything that cannot, and will not, get fixed, given time & money to do so. I've spent my "Varnish-time" this month plotting the way ahead and hopefully Per Buer from Linpro will soon tell me that we have the necessary sponsors for version 2 lined up, allowing us to really move forward. 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 Feb 13 09:52:23 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 13 Feb 2007 10:52:23 +0100 Subject: Current Varnish status? In-Reply-To: <6736260.30521171319889538.JavaMail.root@ms1.startsiden.no> (Denis =?iso-8859-1?Q?Br=E6khus's?= message of "Mon, 12 Feb 2007 23:38:09 +0100 (CET)") References: <6736260.30521171319889538.JavaMail.root@ms1.startsiden.no> Message-ID: Denis Br?khus writes: > I have scanned the pretty light backlogs on the Varnish lists, and I > haven't seen much discussion on the current state of Varnish. There > was mention of problems with lighthttpd, but other than that I > couldn't find much.. We are currently winding up for the next development phase. > So, my question is, how stable do you consider the current release > to be? Is SVN more stable or is the release the way to go? Anyone > using Varnish in a production environment at all? Is that even > something I should contemplate? My environment would consist of an > app running on Apache 2.0.x with php, so lighthttpd issues are not a > concern. The differences between the released version and the svn trunk are currently very small (a few bug fixes). Whether Varnish is usable in a production environment depends on the nature of your application. Varnish currently does not respect Vary: headers and interacts poorly with cookies, but if you don't use either, you'll be fine. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From denis at startsiden.no Tue Feb 13 10:31:25 2007 From: denis at startsiden.no (=?utf-8?Q?Denis_Br=C3=A6khus?=) Date: Tue, 13 Feb 2007 11:31:25 +0100 (CET) Subject: Current Varnish status? In-Reply-To: Message-ID: <14949960.32811171362685467.JavaMail.root@ms1.startsiden.no> ----- Dag-Erling Sm?rgrav wrote: > The differences between the released version and the svn trunk are > currently very small (a few bug fixes). So SVN would actually be more stable then? > Whether Varnish is usable in a production environment depends on the > nature of your application. Varnish currently does not respect Vary: > headers and interacts poorly with cookies, but if you don't use > either, you'll be fine. Is it possible to define "interacts poorly with cookies"? I do think our application relies quite heavily on cookies for session handling. Does interacting poorly imply that any site where cookies are used do not work well with Varnish, or simply that Varnish does not handle caching well when cookies are involved? Regards -- Denis Braekhus - Teknisk Ansvarlig ABC Startsiden AS http://www.startsiden.no From phk at phk.freebsd.dk Tue Feb 13 10:32:54 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Feb 2007 10:32:54 +0000 Subject: Current Varnish status? In-Reply-To: Your message of "Tue, 13 Feb 2007 11:31:25 +0100." <14949960.32811171362685467.JavaMail.root@ms1.startsiden.no> Message-ID: <11146.1171362774@critter.freebsd.dk> In message <14949960.32811171362685467.JavaMail.root at ms1.startsiden.no>, =?utf- 8?Q?Denis_Br=C3=A6khus?= writes: >----- Dag-Erling Sm=C3=B8rgrav wrote: >> The differences between the released version and the svn trunk are >> currently very small (a few bug fixes). > >So SVN would actually be more stable then? > >> Whether Varnish is usable in a production environment depends on the >> nature of your application. Varnish currently does not respect Vary: >> headers and interacts poorly with cookies, but if you don't use >> either, you'll be fine. > >Is it possible to define "interacts poorly with cookies"? "Doesn't cache if it sees one" This is policy you can change with your own vcl. -- 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 Feb 13 12:51:43 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 13 Feb 2007 13:51:43 +0100 Subject: Current Varnish status? In-Reply-To: <14949960.32811171362685467.JavaMail.root@ms1.startsiden.no> (Denis =?iso-8859-1?Q?Br=E6khus's?= message of "Tue, 13 Feb 2007 11:31:25 +0100 (CET)") References: <14949960.32811171362685467.JavaMail.root@ms1.startsiden.no> Message-ID: Denis Br?khus writes: > Dag-Erling Sm?rgrav wrote: > > The differences between the released version and the svn trunk are > > currently very small (a few bug fixes). > So SVN would actually be more stable then? Possibly, if your environment triggers the bugs that have been fixed since the last release. > > Whether Varnish is usable in a production environment depends on the > > nature of your application. Varnish currently does not respect Vary: > > headers and interacts poorly with cookies, but if you don't use > > either, you'll be fine. > Is it possible to define "interacts poorly with cookies"? I do think > our application relies quite heavily on cookies for session > handling. Does interacting poorly imply that any site where cookies > are used do not work well with Varnish, or simply that Varnish does > not handle caching well when cookies are involved? Basically, if a page uses cookies, you can't cache it. That goes for any proxy, not just Varnish. By default, Varnish goes into PASS mode if the client includes a cookie in the request. It will however cache a page delivered from the backend even if it contains a cookie, so everybody gets the same cookie until the page expires... In Varnish 1.0, this is a feature, as it was not intended for sites that use cookies. I expect that in Varnish 2.0 - perhaps even in 1.1 if we decide to do a 1.1 - it will be reclassified as a bug, and fixed. Workaround: if only part of your site uses cookies, you can configure Varnish to always use PASS mode for that part, and cache the rest. BTW, I've looked at startsiden.no and did not find any cookies on any page I visited. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Feb 13 12:56:19 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Feb 2007 12:56:19 +0000 Subject: Current Varnish status? In-Reply-To: Your message of "Tue, 13 Feb 2007 13:51:43 +0100." Message-ID: <13190.1171371379@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >Denis Br=E6khus writes: >> Dag-Erling Sm=F8rgrav wrote: >> > The differences between the released version and the svn trunk are >> > currently very small (a few bug fixes). >> So SVN would actually be more stable then? > >Possibly, if your environment triggers the bugs that have been fixed >since the last release. I should warn though, that SVN will go into active development shortly, so you will have to pay attention to when you grab a copy. -- 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 denis at startsiden.no Tue Feb 13 14:15:36 2007 From: denis at startsiden.no (=?utf-8?Q?Denis_Br=C3=A6khus?=) Date: Tue, 13 Feb 2007 15:15:36 +0100 (CET) Subject: Current Varnish status? In-Reply-To: Message-ID: <3613370.37431171376136547.JavaMail.root@ms1.startsiden.no> ----- Dag-Erling Sm?rgrav wrote: > Basically, if a page uses cookies, you can't cache it. That goes for > any proxy, not just Varnish. Yes I know that. > By default, Varnish goes into PASS mode if the client includes a > cookie in the request. It will however cache a page delivered from > the backend even if it contains a cookie, so everybody gets the same > cookie until the page expires... In Varnish 1.0, this is a feature, > as it was not intended for sites that use cookies. I expect that in > Varnish 2.0 - perhaps even in 1.1 if we decide to do a 1.1 - it will > be reclassified as a bug, and fixed. Thanks for the clarification. I actually think I can live with that for some time. > Workaround: if only part of your site uses cookies, you can configure > Varnish to always use PASS mode for that part, and cache the rest. Thanks for the tip. > BTW, I've looked at startsiden.no and did not find any cookies on any > page I visited. Well, we are looking into using Varnish at Startsiden, but this is a different project than those pages. And I might have expressed myself a little vague, but I do definitely know that we use Cookies for this app.. Best Regards -- Denis Braekhus - Teknisk Ansvarlig ABC Startsiden AS http://www.startsiden.no From ccripy at gmail.com Tue Feb 13 17:24:02 2007 From: ccripy at gmail.com (cripy) Date: Tue, 13 Feb 2007 12:24:02 -0500 Subject: HTTP Authorization Message-ID: Hello, I am curious to know whether anybody has had any success with caching files with HTTP authorization and still authorizing correctly. I have tried to implement the following VLC: ---------------------- sub vcl_recv { if (req.url ~ "\.jpg$|\.mpg$|\.wmv$") { lookup; } if (req.http.Cookie) { pipe; } lookup; } ---------------------- This will correctly pipe all cookie and authorization attempts, and allow correct caching of mpg's/wmv's/jpg's-- however, once it has been cached anybody can wget the full url to the mpg/wmv/jpg and varnish will hand it over from the cache without checking authorization since my vlc is kind of 'skipping' that part. I'm trying to figure out a why to somehow make it pass all authorizations to a server first to check if it's kosher THEN send the file from cache ... not sure if this is currently possible. Anybody have any advice? Any comments are greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at startsiden.no Tue Feb 13 19:13:04 2007 From: denis at startsiden.no (=?utf-8?Q?Denis_Br=C3=A6khus?=) Date: Tue, 13 Feb 2007 20:13:04 +0100 (CET) Subject: Current Varnish status? In-Reply-To: <45D16F4F.1010901@hio.no> Message-ID: <16348416.39891171393984701.JavaMail.root@ms1.startsiden.no> ----- Kenneth R?rvik wrote: > Denis Br?khus wrote: > > So, my question is, how stable do you consider the current release > to be? > (http://www.hio.no) for three weeks + now. In that time, there's been > one major incident, in which varnish suddenly started dropping all > incoming connections, possibly resetting, with clients ending up > simply with blank pages. Thanks for the info. I added a content script check to my alteons, checking for the length of a particular object through http. This should eliminate any major mishaps I guess. So my setup ended up being : VarnishServer1 VarnishServer2 | | AppServer1 AppServer2 If VarnishServer1 or 2 fails the alteon falls back to using the relevant appserver directly instead.. Looking forward to see how this performs under load. I have high expectations for Varnish actually :) Regards -- Denis Braekhus - Teknisk Ansvarlig ABC Startsiden AS http://www.startsiden.no From ask at develooper.com Tue Feb 13 19:42:09 2007 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Tue, 13 Feb 2007 11:42:09 -0800 Subject: HTTP Authorization In-Reply-To: References: Message-ID: On Feb 13, 2007, at 9:24, cripy wrote: > Hello, I am curious to know whether anybody has had any success > with caching files with HTTP authorization and still authorizing > correctly. I have tried to implement the following VLC: I don't know if it can be done with VLC, but I'd like to point to the perlbal "re-proxy" feature (for potential inspiration to varnish). The idea is that the proxy sends the request to the backend server, the backend server (typically a "smart" server with DB access and heavy memory footprint) authorizes the request and gives the proxy another URL. The proxy then fetches the file from that URL (typically on a "dumb" server) and sends it to the client. - ask -- http://develooper.com/ - http://askask.com/ From dwetzel at nerim.net Wed Feb 14 16:09:34 2007 From: dwetzel at nerim.net (Damien Wetzel) Date: Wed, 14 Feb 2007 17:09:34 +0100 Subject: HTTP Authorization In-Reply-To: References: Message-ID: <17875.13374.254592.812000@dwetzel@nerim.net> For Authorisations, why don't pass the requests to the backend for the matching URLs as HEAD requests with Cookie: or Authorisation: headers in it then if the backend sends 200, Varnish send back the cached URL, if backend sends 403, the response is forwarded back to the enduser ? Ask Bj?rn Hansen writes: > > On Feb 13, 2007, at 9:24, cripy wrote: > > > Hello, I am curious to know whether anybody has had any success > > with caching files with HTTP authorization and still authorizing > > correctly. I have tried to implement the following VLC: > > I don't know if it can be done with VLC, but I'd like to point to the > perlbal "re-proxy" feature (for potential inspiration to varnish). > > The idea is that the proxy sends the request to the backend server, > the backend server (typically a "smart" server with DB access and > heavy memory footprint) authorizes the request and gives the proxy > another URL. The proxy then fetches the file from that URL > (typically on a "dumb" server) and sends it to the client. > > > - ask > > -- > http://develooper.com/ - http://askask.com/ > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From ccripy at gmail.com Wed Feb 14 18:17:33 2007 From: ccripy at gmail.com (cripy) Date: Wed, 14 Feb 2007 13:17:33 -0500 Subject: HTTP Authorization In-Reply-To: <-8936116376080268097@unknownmsgid> References: <-8936116376080268097@unknownmsgid> Message-ID: That's a clever idea, but how do you change req.request in VCL? I have tried doing set req.request = 'HEAD' but I receive the following error: ------------------------- In VCL code Line 7 Pos 17 set req.request = "HEAD"; -----------------#-------- Also, I don't believe it's possible to process a web servers return codes (200 or 403) in VCL. On 2/14/07, Damien Wetzel wrote: > > For Authorisations, why don't pass the requests to the backend > for the matching URLs as HEAD requests with Cookie: or Authorisation: > headers in it then if the backend sends 200, Varnish send back the cached > URL, if backend sends 403, the response is forwarded back to the enduser ? > > Ask Bj?rn Hansen writes: > > > > On Feb 13, 2007, at 9:24, cripy wrote: > > > > > Hello, I am curious to know whether anybody has had any success > > > with caching files with HTTP authorization and still authorizing > > > correctly. I have tried to implement the following VLC: > > > > I don't know if it can be done with VLC, but I'd like to point to the > > perlbal "re-proxy" feature (for potential inspiration to varnish). > > > > The idea is that the proxy sends the request to the backend server, > > the backend server (typically a "smart" server with DB access and > > heavy memory footprint) authorizes the request and gives the proxy > > another URL. The proxy then fetches the file from that URL > > (typically on a "dumb" server) and sends it to the client. > > > > > > - ask > > > > -- > > http://develooper.com/ - http://askask.com/ > > > > > > _______________________________________________ > > varnish-misc mailing list > > varnish-misc at projects.linpro.no > > http://projects.linpro.no/mailman/listinfo/varnish-misc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish at kepp.net Sat Feb 17 02:20:07 2007 From: varnish at kepp.net (Arne) Date: Fri, 16 Feb 2007 21:20:07 -0500 Subject: Urchin Message-ID: <45D66657.7000207@kepp.net> I think the previous analysis regarding Urchin / Google Analytics may be incorrect. Urchin is client-side, it loads urchin.js from http://www.googleanalytics.com and reports its findings back to one of Googles servers. However, it also hands out 4 cookies to every visitor, and those look like they have been placed by the original domain. So if I understand you correctly (the list and the man-page) , then practically nothing on my website would be cached using the default configuration, due to (req.request == "GET" && req.http.cookie) ? Is there any way to ignore *only* the Google-cookies? They're consistently named __utma, __utmb, __utmc and __utmz I think Google Analytics appeals to the same crowd that would benefit from using Varnish, so if there's no elegant way of doing it now it should be considered for 2.x. Fingers crossed you get the funding, I'd love to see it run Wikipedia. -Arne From stonorn at giraffen.dk Sat Feb 17 08:02:16 2007 From: stonorn at giraffen.dk (Anton Stonor) Date: Sat, 17 Feb 2007 09:02:16 +0100 Subject: Urchin In-Reply-To: <45D66657.7000207@kepp.net> References: <45D66657.7000207@kepp.net> Message-ID: <45D6B688.3020800@giraffen.dk> Arne wrote: > So if I understand you correctly (the list and the man-page) , then > practically nothing on my website would be cached using the default > configuration, due to (req.request == "GET" && req.http.cookie) ? > > Is there any way to ignore *only* the Google-cookies? They're > consistently named __utma, __utmb, __utmc and __utmz You might want to place this default vcl statement.... if (req.http.Authenticate || req.http.Cookie) { ... with something in the neighborhood of this if (req.http.Authenticate || req.http.Cookie ~ "__ut=") { /Anton From stonorn at giraffen.dk Sat Feb 17 08:43:12 2007 From: stonorn at giraffen.dk (Anton Stonor) Date: Sat, 17 Feb 2007 09:43:12 +0100 Subject: Urchin In-Reply-To: <45D6B688.3020800@giraffen.dk> References: <45D66657.7000207@kepp.net> <45D6B688.3020800@giraffen.dk> Message-ID: <45D6C020.20206@giraffen.dk> I wrote: > You might want to place this default vcl statement.... Please ignore that - it will have the opposite effect as intended. Sorry. /Anton From varnish at kepp.net Sat Feb 17 18:17:32 2007 From: varnish at kepp.net (Arne) Date: Sat, 17 Feb 2007 13:17:32 -0500 Subject: Urchin In-Reply-To: <45D6C020.20206@giraffen.dk> References: <45D66657.7000207@kepp.net> <45D6B688.3020800@giraffen.dk> <45D6C020.20206@giraffen.dk> Message-ID: <45D746BC.5090501@kepp.net> But then, if I know that all my cookies are named "mycookieA" and "mycookieB", I could use if (req.http.Authenticate || req.http.cookie "mycookie=") { ? That would work too, for the types of sites that I run, it just requires a bit more maintenance. I didn't realize that req.http.cookie is a string, based on the examples I thought it was a boolean. -Arne Anton Stonor wrote: > Please ignore that - it will have the opposite effect as intended. Sorry. > > /Anton From stonorn at giraffen.dk Tue Feb 20 20:01:27 2007 From: stonorn at giraffen.dk (Anton Stonor) Date: Tue, 20 Feb 2007 21:01:27 +0100 Subject: Any way to control caching based on http status code? Message-ID: <45DB5397.3030301@giraffen.dk> Hi there, I'm looking for a way to avoid caching http responses from the backend with specific status codes such as 302. Is there any way to express that with vcl? Regards, Anton From phk at phk.freebsd.dk Tue Feb 20 20:04:17 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 20 Feb 2007 20:04:17 +0000 Subject: Any way to control caching based on http status code? In-Reply-To: Your message of "Tue, 20 Feb 2007 21:01:27 +0100." <45DB5397.3030301@giraffen.dk> Message-ID: <26608.1172001857@critter.freebsd.dk> In message <45DB5397.3030301 at giraffen.dk>, Anton Stonor writes: >Hi there, > >I'm looking for a way to avoid caching http responses from the backend >with specific status codes such as 302. > >Is there any way to express that with vcl? Not right now, please open a ticket so we don't forget. -- 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 ccripy at gmail.com Wed Feb 21 03:45:44 2007 From: ccripy at gmail.com (cripy) Date: Tue, 20 Feb 2007 22:45:44 -0500 Subject: Any way to control caching based on http status code? In-Reply-To: <26608.1172001857@critter.freebsd.dk> References: <45DB5397.3030301@giraffen.dk> <26608.1172001857@critter.freebsd.dk> Message-ID: On 2/20/07, Poul-Henning Kamp wrote: > > In message <45DB5397.3030301 at giraffen.dk>, Anton Stonor writes: > >Hi there, > > > >I'm looking for a way to avoid caching http responses from the backend > >with specific status codes such as 302. > > > >Is there any way to express that with vcl? > > Not right now, please open a ticket so we don't forget. > > -- > 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-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > I recently had this same issue as far as Authorizations are concerned. We were having an issue where let's say an authorized file was accessed with an unauthorized access attempt it would cache the unauthorized attempt [Code: 401] and return that to a valid credential holding user. I got around it like this. (patch attached) [probably not the best method] In your case you would replace the 401 with 302. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: filterRespCode.patch Type: application/octet-stream Size: 390 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 21 12:26:03 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 21 Feb 2007 13:26:03 +0100 Subject: Missing files in the varnish 1.0.3 release Message-ID: <20070221132603.7966e1d8@python3.es.egwn.lan> Hi, It seems that 1.0.3 has finally been made with "make dist", unfortunately, both "etc" and "redhat" directories are missing from the EXTRA_DIST line of Makefile.am, thus weren't included in the released tarball. Was this intentional? The "etc" directory contained the example vcl.conf which was quite useful to have. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.60 0.60 0.76 From ingvar at linpro.no Wed Feb 21 13:21:55 2007 From: ingvar at linpro.no (Ingvar Hagelund) Date: Wed, 21 Feb 2007 14:21:55 +0100 Subject: Missing files in the varnish 1.0.3 release In-Reply-To: <20070221132603.7966e1d8@python3.es.egwn.lan> References: <20070221132603.7966e1d8@python3.es.egwn.lan> Message-ID: <45DC4773.4080204@linpro.no> * Matthias Saou > It seems that 1.0.3 has finally been made with "make dist", > unfortunately, both "etc" and "redhat" directories are missing from the > EXTRA_DIST line of Makefile.am, thus weren't included in the released > tarball. > > Was this intentional? The "etc" directory contained the example > vcl.conf which was quite useful to have. I can't speak for the main release, but I'll roll RPMS of 1.0.3 "real soon now". The files should be available from svn anyhow. By the way, does this mean that varnish is going into the rpmforge repos? Ingvar -- N?r alt annet feiler: Symlink From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 21 13:40:29 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 21 Feb 2007 14:40:29 +0100 Subject: Missing files in the varnish 1.0.3 release In-Reply-To: <45DC4773.4080204@linpro.no> References: <20070221132603.7966e1d8@python3.es.egwn.lan> <45DC4773.4080204@linpro.no> Message-ID: <20070221144029.3e0930d5@python3.es.egwn.lan> Ingvar Hagelund wrote : > * Matthias Saou > > It seems that 1.0.3 has finally been made with "make dist", > > unfortunately, both "etc" and "redhat" directories are missing from the > > EXTRA_DIST line of Makefile.am, thus weren't included in the released > > tarball. > > > > Was this intentional? The "etc" directory contained the example > > vcl.conf which was quite useful to have. > > I can't speak for the main release, but I'll roll RPMS of 1.0.3 "real > soon now". The files should be available from svn anyhow. Yeah, the "redhat" files aren't that useful for typical end-users, it's for the example vcl.conf that it's more or a problem. > By the way, does this mean that varnish is going into the rpmforge repos? Eventually. I saw that the redhat/TODO file contained "Add the package to Fedora Extras", so I guess you've already thought about publishing packages for a wider audience, right? ;-) But for me there are currently some quite major issues : - Varnish doesn't "work well" on 32bit architectures (ouch!), see #85. - Varnish isn't "reliable", see #67, #70 and #87. - Varnish requires a C compiler at runtime... design decision, sure, but opinions about this are quite mixed, and I know this won't help get varnish into Fedora. Last night, I had varnish crash twice on me. Not just the worker child dying and another one being spawned, but a real nasty crash with no more varnishd processes left running and nothing whatsoever on the console where I had launched it with -d -d (this was with varnish svn trunk, so pretty much 1.0.3, I think). This was on 64bit RHEL4, 1G storage file, pushing 50 to 150Mbps. I really think varnish has a huge potential, but I still find it quite rough around the edges. I'd really like to have : - Useful logging of critical errors like "Too many open files" or "Worker child died, spawning a new one" etc. - A rock solid handling of memory allocation to avoid the issues mentioned above, which seem to occur when memory allocation fails (cache full? max addressable memory all used? ...). Keep up the great work :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.42 0.54 0.75 From Kenneth.Rorvik at hio.no Wed Feb 21 13:53:16 2007 From: Kenneth.Rorvik at hio.no (=?ISO-8859-1?Q?Kenneth_R=F8rvik?=) Date: Wed, 21 Feb 2007 14:53:16 +0100 Subject: Missing files in the varnish 1.0.3 release In-Reply-To: <20070221144029.3e0930d5@python3.es.egwn.lan> References: <20070221132603.7966e1d8@python3.es.egwn.lan> <45DC4773.4080204@linpro.no> <20070221144029.3e0930d5@python3.es.egwn.lan> Message-ID: <45DC4ECC.7020007@hio.no> Matthias Saou wrote: > But for me there are currently some quite major issues : > - Varnish doesn't "work well" on 32bit architectures (ouch!), see #85. > - Varnish isn't "reliable", see #67, #70 and #87. > - Varnish requires a C compiler at runtime... design decision, sure, but > opinions about this are quite mixed, and I know this won't help get > varnish into Fedora. > > Last night, I had varnish crash twice on me. Not just the worker child > dying and another one being spawned, but a real nasty crash with no more > varnishd processes left running and nothing whatsoever on the console > where I had launched it with -d -d (this was with varnish svn trunk, so > pretty much 1.0.3, I think). > This was on 64bit RHEL4, 1G storage file, pushing 50 to 150Mbps. Hmm. I am currently running on the same system, though 64 bit, same storage file size, at an average network throughput of around only 1Mbps though. It's on a gigabit link though, so peaks can be much,much higher. The slashdot crowd is fortunately not interested though... ;) I've been running for around five weeks, and in that period had one incident where varnish suddenly started dropping all incoming for some hours. Since then (restart after update to svn code), it's been running quite smoothly with a couple of similar (but much shorter) glitches. I'm running svn code though, not the standard RH rpm, since that one crashed more frequently than useful "live". Anyway, much looking forward to later versions, looking OK so far, with promising plans. Will stay tuned ;) -- Kenneth R?rvik, IT HiO Tlf 22 45 20 83 Kenneth.Rorvik at hio.no From gaute at pht.no Wed Feb 21 15:35:08 2007 From: gaute at pht.no (Gaute Amundsen) Date: Wed, 21 Feb 2007 16:35:08 +0100 Subject: Missing files in the varnish 1.0.3 release In-Reply-To: <45DC4773.4080204@linpro.no> References: <20070221132603.7966e1d8@python3.es.egwn.lan> <45DC4773.4080204@linpro.no> Message-ID: <200702211635.09441.gaute@pht.no> Hi. Just today, I got asked by our server guy, if he should upgrade from 1.0.1 to 1.0.3, to se if that would fix some problems we have had reported. I am not yet convinced that those glitches are related to varnish and not the customers IE7, but if you have some RPM's right around the corner, then I guess we wil wait for that :) Wil you be building for rhel4 as well? Gaute On Wednesday 21 February 2007 14:21, Ingvar Hagelund wrote: > * Matthias Saou > > > It seems that 1.0.3 has finally been made with "make dist", > > unfortunately, both "etc" and "redhat" directories are missing from the > > EXTRA_DIST line of Makefile.am, thus weren't included in the released > > tarball. > > > > Was this intentional? The "etc" directory contained the example > > vcl.conf which was quite useful to have. > > I can't speak for the main release, but I'll roll RPMS of 1.0.3 "real > soon now". The files should be available from svn anyhow. > > By the way, does this mean that varnish is going into the rpmforge repos? > > Ingvar -- Programmerer - Pixelhospitalet AS T?rkoppveien 10, 1570 Dilling Tlf. 24 12 97 81 - 9074 7344 From ccripy at gmail.com Wed Feb 21 16:39:10 2007 From: ccripy at gmail.com (cripy) Date: Wed, 21 Feb 2007 11:39:10 -0500 Subject: HTTP Authorization Patch Message-ID: Hello, we recently ran into an issue with varnish when http authorizations were concerned so I created this patch [ it can probably be done a whole lot better ]. The attached patch has a function cnt_auth which calls an external function that you must insert yourself. It passes the external function the username and password base64 encoded, the users ip, and the path of the filename. It is up to your external function to decide whether the credentials presented are correct or not and return a 1 or -1. (true or false). If false it sets the sp->handling to VCL_RET_PASS which will pass it off to the server. The patch also modifies cnt_fetch function to check for a 401 status code to prevent us from caching an actual 401 Unauthorized status and serving that to a legitimate client. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish-auth-0.1.patch Type: text/x-patch Size: 1480 bytes Desc: not available URL: From ingvar at linpro.no Wed Feb 21 22:37:04 2007 From: ingvar at linpro.no (Ingvar Hagelund) Date: Wed, 21 Feb 2007 23:37:04 +0100 Subject: Missing files in the varnish 1.0.3 release In-Reply-To: <200702211635.09441.gaute@pht.no> References: <20070221132603.7966e1d8@python3.es.egwn.lan> <45DC4773.4080204@linpro.no> <200702211635.09441.gaute@pht.no> Message-ID: <45DCC990.1020806@linpro.no> * Gaute Amundsen > Just today, I got asked by our server guy, if he should upgrade from 1.0.1 to > 1.0.3, to se if that would fix some problems we have had reported. > > I am not yet convinced that those glitches are related to varnish and not the > customers IE7, but if you have some RPM's right around the corner, then I > guess we wil wait for that :) > > Wil you be building for rhel4 as well? RHEL4/x86_64 is my main target. I may build i386, ppc and ppc64 too, all for RHEL4. I don't know if I ever will get the package into Fedora. I haven't even started the process. It should be quite easy to make a SuSE package too, though I probably won't have the time (unless some customer should want to pay for it). Ingvar -- When everything else fail: Symlink From phk at phk.freebsd.dk Thu Feb 22 08:14:04 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 22 Feb 2007 08:14:04 +0000 Subject: HTTP Authorization Patch In-Reply-To: Your message of "Wed, 21 Feb 2007 11:39:10 EST." Message-ID: <1107.1172132044@critter.freebsd.dk> In message , cripy writes: >Hello, we recently ran into an issue with varnish when http authorizations >were concerned so I created this patch [ it can probably be done a whole lot >better ]. The attached patch has a function cnt_auth which calls an >external function that you must insert yourself. One of the most damanging accusations ever launched against any programming language was in one of the historical attacks on PASCAL. I can't remember who exactly wrote it, but the operative sentence was: "Worst of all, there is no escape." VCL has a planned escape mechanism, but I have not said anything about it yet, wanting to see if anybody actually needed it. The concept is that hat arbitrary C-code can be inserted into VCL programs, possibly something like: sub vcl_recv { C{ { char *p = VRT_GetHdr(sp, 1, "\005Host:"); ... } }C } That should allow you to do what your patch does, entirely from within VCL. -- 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 ccripy at gmail.com Thu Feb 22 23:54:45 2007 From: ccripy at gmail.com (cripy) Date: Thu, 22 Feb 2007 18:54:45 -0500 Subject: HTTP Authorization Patch In-Reply-To: <1107.1172132044@critter.freebsd.dk> References: <1107.1172132044@critter.freebsd.dk> Message-ID: On 2/22/07, Poul-Henning Kamp wrote: > > In message , > cripy > writes: > > >Hello, we recently ran into an issue with varnish when http > authorizations > >were concerned so I created this patch [ it can probably be done a whole > lot > >better ]. The attached patch has a function cnt_auth which calls an > >external function that you must insert yourself. > > One of the most damanging accusations ever launched against any > programming language was in one of the historical attacks on PASCAL. > > I can't remember who exactly wrote it, but the operative sentence was: > > "Worst of all, there is no escape." > > VCL has a planned escape mechanism, but I have not said anything > about it yet, wanting to see if anybody actually needed it. > > The concept is that hat arbitrary C-code can be inserted into VCL > programs, possibly something like: > > sub vcl_recv { > C{ > { > char *p = VRT_GetHdr(sp, 1, "\005Host:"); > > ... > } > }C > } > > That should allow you to do what your patch does, entirely > from within VCL. > > -- > 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. > Hey Poul, Thanks for the prompt response and help. However, I can't seem to get this to work properly I am receiving the following error upon varnishd startup: Expected action, 'if' or '}' In VCL code Line 7 Pos 16 C{ ----------------#- Any help is appreciated as I believe that VCL is the best approach for implementing this until something similar is implemented in varnish. Thanks again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ask at develooper.com Fri Feb 23 01:28:01 2007 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Thu, 22 Feb 2007 17:28:01 -0800 Subject: HTTP Authorization Patch In-Reply-To: <1107.1172132044@critter.freebsd.dk> References: <1107.1172132044@critter.freebsd.dk> Message-ID: <02769D74-A35A-4BD5-82D4-5280E2D1EAD9@develooper.com> On Feb 22, 2007, at 12:14 AM, Poul-Henning Kamp wrote: > The concept is that hat arbitrary C-code can be inserted into VCL > programs, possibly something like: I can't decide if I want to say "neat" or "avoid avoid avoid!". I understand that you don't want to embed a better memory managed (etc) language, but if you go the "C in the config file" route at the very least we'll need some tools to test the configuration file (say throw random data at it to test for basic buffer overflows etc). - ask -- http://develooper.com/ - http://askask.com/ From phk at phk.freebsd.dk Fri Feb 23 09:03:18 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 23 Feb 2007 09:03:18 +0000 Subject: HTTP Authorization Patch In-Reply-To: Your message of "Thu, 22 Feb 2007 18:54:45 EST." Message-ID: <4343.1172221398@critter.freebsd.dk> In message , cripy writes: >Hey Poul, > Thanks for the prompt response and help. However, I can't seem to get >this to work properly I am receiving the following error upon varnishd >startup: Easy does it, I said it was a plan I had, not that I had done it yet. -- 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 ingvar at linpro.no Fri Feb 23 09:36:11 2007 From: ingvar at linpro.no (Ingvar Hagelund) Date: Fri, 23 Feb 2007 10:36:11 +0100 Subject: RPM packages of varnish-1.0.3 available Message-ID: <45DEB58B.2070102@linpro.no> I have just uploaded rpm packages of varnish-1.0.3 to sourceforge. x86_64, i386 and src flavours available. They should spread to worldwide mirrors in a few hours. I'll see if I get around to build some ppc64 packages too. Most relevant changes in the rpm package: It's now three packages, varnish, libvarnish1 and libvarnish1-devel. This way it conforms more to the RedHat/Fedora standards. There are also some other small changes to make it pass the needle eye of rpmlint. Most intrusive, I converted the manpages to utf8. Dag-Erling, you might want to consider this for the upstream package too. Ingvar -- When everything else fail: Symlink From Kenneth.Rorvik at hio.no Fri Feb 23 09:42:21 2007 From: Kenneth.Rorvik at hio.no (=?ISO-8859-1?Q?Kenneth_R=F8rvik?=) Date: Fri, 23 Feb 2007 10:42:21 +0100 Subject: RPM packages of varnish-1.0.3 available In-Reply-To: <45DEB58B.2070102@linpro.no> References: <45DEB58B.2070102@linpro.no> Message-ID: <45DEB6FD.8010808@hio.no> Ingvar Hagelund wrote: > I have just uploaded rpm packages of varnish-1.0.3 to sourceforge. Excellent work :) I will run a test this weekend when the students are out drinking ;) -- Kenneth R?rvik, IT HiO Tlf 22 45 20 83 Kenneth.Rorvik at hio.no From phk at phk.freebsd.dk Fri Feb 23 09:44:14 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 23 Feb 2007 09:44:14 +0000 Subject: HTTP Authorization Patch In-Reply-To: Your message of "Thu, 22 Feb 2007 17:28:01 PST." <02769D74-A35A-4BD5-82D4-5280E2D1EAD9@develooper.com> Message-ID: <4689.1172223854@critter.freebsd.dk> In message <02769D74-A35A-4BD5-82D4-5280E2D1EAD9 at develooper.com>, =?ISO-8859-1? Q?Ask_Bj=F8rn_Hansen?= writes: > >On Feb 22, 2007, at 12:14 AM, Poul-Henning Kamp wrote: > >> The concept is that hat arbitrary C-code can be inserted into VCL >> programs, possibly something like: > >I can't decide if I want to say "neat" or "avoid avoid avoid!". Right, that's why I didn't even mention it, until somebody else brought forth a need for it. The article I refered to is worth a read as background reading at this point: http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz >I understand that you don't want to embed a better memory managed >(etc) language, but if you go the "C in the config file" route at the >very least we'll need some tools to test the configuration file (say >throw random data at it to test for basic buffer overflows etc). >From a philosophical point of view, if you use the C{ }C escape mechanism, you get what you ask for, so don't expect me to spend a lot of time trying to protect you from yourself, that would defeat the purpose. >From a more practical point of view, writing a stress-tester for unspecified C-code is not tricky, it is virtually impossible. -- 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 Feb 23 10:07:51 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Fri, 23 Feb 2007 11:07:51 +0100 Subject: RPM packages of varnish-1.0.3 available In-Reply-To: <45DEB58B.2070102@linpro.no> (Ingvar Hagelund's message of "Fri, 23 Feb 2007 10:36:11 +0100") References: <45DEB58B.2070102@linpro.no> Message-ID: Ingvar Hagelund writes: > Most relevant changes in the rpm package: It's now three packages, > varnish, libvarnish1 and libvarnish1-devel. This way it conforms more to > the RedHat/Fedora standards. There are also some other small changes to > make it pass the needle eye of rpmlint. Most intrusive, I converted the > manpages to utf8. Dag-Erling, you might want to consider this for the > upstream package too. Fixed in trunk. Amusingly, the only non-ASCII characters were in my name... DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Fri Feb 23 10:11:28 2007 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Fri, 23 Feb 2007 11:11:28 +0100 Subject: cache backend using 10X the amount of space In-Reply-To: <20070205231651.GA26813@avon.geekhive.net> (Alex Apke's message of "Mon, 5 Feb 2007 15:16:51 -0800") References: <20070205231651.GA26813@avon.geekhive.net> Message-ID: Alex Apke writes: > A related question, when the cache backend storagefile reaches the > maximum size, the whole cache seems to get invalidated and the contents > gets lost, and needs re-priming. Actually, when the cache fills up, the Varnish child process crashes and gets restarted... It's a feature, not a bug :) I promise this will be fixed in 2.0 (and possibly in 1.1 if we decide to do a 1.1 release) DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Feb 24 11:14:07 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 24 Feb 2007 12:14:07 +0100 Subject: RPM packages of varnish-1.0.3 available In-Reply-To: <45DEB58B.2070102@linpro.no> References: <45DEB58B.2070102@linpro.no> Message-ID: <20070224121407.3a7c09a7@python3.es.egwn.lan> Ingvar Hagelund wrote : > Most relevant changes in the rpm package: It's now three packages, > varnish, libvarnish1 and libvarnish1-devel. This way it conforms more to > the RedHat/Fedora standards. Actually, this doesn't conform with Fedora/RedHat. I'd say it's Mandrake-ish. For Fedora/RedHat, you should have split it as : - varnish-libs - varnish-devel - varnish But if nothing rebuilds against varnish, this split isn't really useful. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.05 0.06 0.02 From phk at phk.freebsd.dk Mon Feb 26 09:52:19 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 26 Feb 2007 09:52:19 +0000 Subject: Logo In-Reply-To: Your message of "Fri, 10 Feb 2006 17:15:29 +0100." Message-ID: <31864.1172483539@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgra v?= writes: >Anders sent me a copy of a logo proposal which he submitted to one of >VG's designers. The designer is sick, but I slapped together a >vectorized version of Anders's proposal in Inkscape; the result is all >over the web site. Enjoy! Maybe I'm stupid, but I can't find the logo sources in 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.