From slink at schokola.de Wed Feb 2 16:33:19 2011 From: slink at schokola.de (Nils Goroll) Date: Wed, 02 Feb 2011 17:33:19 +0100 Subject: tiny [PATCH] to make e00022.vtc work on 32bit compiles In-Reply-To: <4D46AEAA.60401@schokola.de> References: <4D46AEAA.60401@schokola.de> Message-ID: <4D49874F.7090406@schokola.de> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-need-more-room-for-temporary-gzip-space-on-stack.patch URL: From tfheen at varnish-software.com Thu Feb 3 08:27:58 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Thu, 03 Feb 2011 09:27:58 +0100 Subject: tiny [PATCH] to make e00022.vtc work on 32bit compiles In-Reply-To: <4D49874F.7090406@schokola.de> (Nils Goroll's message of "Wed, 02 Feb 2011 17:33:19 +0100") References: <4D46AEAA.60401@schokola.de> <4D49874F.7090406@schokola.de> Message-ID: <87sjw5msj5.fsf@qurzaw.varnish-software.com> ]] Nils Goroll | From 6a77525a777b18eab821c9be27b0a0c43412484b Mon Sep 17 00:00:00 2001 | From: Nils Goroll | Date: Wed, 2 Feb 2011 17:15:54 +0100 | Subject: [PATCH] need more room for temporary gzip space on stack Thanks, applied! -- Tollef Fog Heen Varnish Software t: +47 21 98 92 64 From a.sebastian.w at gmail.com Sat Feb 5 09:38:30 2011 From: a.sebastian.w at gmail.com (Sebastian Wittenkamp) Date: Sat, 5 Feb 2011 01:38:30 -0800 Subject: Build Errors from 'make check' on Mac OS X 10.6.6 Message-ID: <7741680A-9722-45CE-93F3-0B991EC5787E@gmail.com> Hello, I ran 'make check' and received some errors. Please find attached my make log. Best, Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: make_check_output.log Type: application/octet-stream Size: 47977 bytes Desc: not available URL: From knan at redpill-linpro.com Tue Feb 8 16:26:11 2011 From: knan at redpill-linpro.com (=?ISO-8859-15?Q?Erik_Inge_Bols=F8?=) Date: Tue, 8 Feb 2011 17:26:11 +0100 (CET) Subject: [PATCH] fix content-length header storage allocation typo Message-ID: --- bin/varnishd/cache_center.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) In the not-even-compile-tested-but-looks-obvious category. diff --git a/bin/varnishd/cache_center.c b/bin/varnishd/cache_center.c index 25d57cb..6ff8423 100644 --- a/bin/varnishd/cache_center.c +++ b/bin/varnishd/cache_center.c @@ -654,7 +654,7 @@ cnt_fetch(struct sess *sp) * Space for producing a Content-Length: header including padding * A billion gigabytes is enough for anybody. */ - l += strlen("Content-Encoding: XxxXxxXxxXxxXxxXxx" + sizeof(void *)); + l += strlen("Content-Length: XxxXxxXxxXxxXxxXxx") + sizeof(void *); if (sp->wrk->ttl < sp->t_req + params->shortlived || sp->objcore == NULL) -- 1.7.0.4 From slink at schokola.de Fri Feb 11 11:04:16 2011 From: slink at schokola.de (Nils Goroll) Date: Fri, 11 Feb 2011 12:04:16 +0100 Subject: Values for obj.* when obj == NULL in vcl_recv // Re: Proposal/specs for backend conditional requests / aka "GET If-Modified-Since" (GET IMS)) In-Reply-To: <37265.1286198318@critter.freebsd.dk> References: <37265.1286198318@critter.freebsd.dk> Message-ID: <4D5517B0.404@schokola.de> Hi phk, > Find valid in-grace object -> vcl_miss (with obj.*) > Find nothing usable -> vcl_miss (without obj.*) Now that we (finally) got to the point to actually implement this part of the backend conditionals, the following question pops up: As obj.* may or may not exist in vcl_miss, what should the various getters (vrt_r_obj_*) return for (obj == NULL)? While I think returning the empty string for STRING attributes (obj.proto, obj.response) should be OK, I don't see what the "undefined" value for an integer (obj.status, obj.response, obj.hits ...) or a duration (obj.ttl, obj.grace, ...) would be. Could you please advise? Nils From phk at phk.freebsd.dk Fri Feb 11 12:08:52 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 11 Feb 2011 12:08:52 +0000 Subject: Values for obj.* when obj == NULL in vcl_recv // Re: Proposal/specs for backend conditional requests / aka "GET If-Modified-Since" (GET IMS)) In-Reply-To: Your message of "Fri, 11 Feb 2011 12:04:16 +0100." <4D5517B0.404@schokola.de> Message-ID: <8023.1297426132@critter.freebsd.dk> In message <4D5517B0.404 at schokola.de>, Nils Goroll writes: >Hi phk, >Could you please advise? Just for the record, we talked about this on IRC: We should have a BOOL variable allowing "if (stale_obj) {" tests and that if the object is accessed anyway, it returns: stale_obj.status == 503 stale_obj.ttl = 0 all strings NULL Further more, we add IMS to the bereq.http and if you do not want to ask your backend for IMS, you remove it in VCL before return(fetch). We may keep stale_obj.* around until vcl_deliver, so that it can be fallen back to in case of fetch failure. -- 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 seshu.vavilikolanu at RACKSPACE.COM Thu Feb 17 00:00:48 2011 From: seshu.vavilikolanu at RACKSPACE.COM (Seshu Vavilikolanu) Date: Thu, 17 Feb 2011 00:00:48 +0000 Subject: Learning Varnish Source Message-ID: <4973_1297900856_p1H00ows010223_C981C14F.1171%seshu.vavilikolanu@rackspace.com> Hi All, I am new to Varnish. I am trying to write few patches on top of varnish that are very specific to our needs. I have gone through the documentation on the varnish-cache.org and got a good idea of how varnish works and some idea on VCL. I looked at 'varnishd' code (version 2.1.5) and I see 25K+ lines of C code just in this directory alone. I have worked in C programming, but having hard time following the whole code as I couldn't find a flow chart or good documentation about the source code. Can any of you help me in answering the following questions? * Is there a flow chart or documentation about source code structure somewhere? * I see a primitive document on how to use gdb on varnish, but did any of you guys try this and in case if you have documented, could you please share your experiences? * Is there a varnish developer training in USA? I see in varnish website that the developer training is in Europe. Are there any third parties that give training about varnish development in USA? * Any suggestions on how to develop knowledge on varnish source code are welcome. Thanks in advance, I appreciate any reply. Thanks, - Seshu Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Thu Feb 17 10:05:54 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 17 Feb 2011 10:05:54 +0000 Subject: Learning Varnish Source In-Reply-To: Your message of "Thu, 17 Feb 2011 00:00:48 GMT." <4973_1297900856_p1H00ows010223_C981C14F.1171%seshu.vavilikolanu@rackspace.com> Message-ID: <50617.1297937154@critter.freebsd.dk> In message <4973_1297900856_p1H00ows010223_C981C14F.1171%seshu.vavilikolanu at rac kspace.com>, Seshu Vavilikolanu writes: hi Seshu, No, we're not that well-documented yes, so you will have to study the code. There is one bit of help though: Look in the cache_center.c file, it contains an embedded "dot" graph that shows how the central logic of varnishd works. There is a command in a comment which shows you how to format the graph. And yes, as soon as a I get a day with more than 24 hours, I will write a "source-code sight-seeing" document, but just checked, only 24h in all the days this week... 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 nils.goroll at uplex.de Thu Feb 17 12:55:37 2011 From: nils.goroll at uplex.de (Nils Goroll) Date: Thu, 17 Feb 2011 13:55:37 +0100 Subject: [PATCH] Normalizing the Host: header Message-ID: <4D5D1AC9.3000507@uplex.de> Hi, we were discussion this on VUG3: comparisons on the Host: header should be case insensitive. Reflecting on this, I think that normalizing the Host: header in Varnish would actually be the better idea and should avoid common errors. Nils -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg tel +49 40 28805731 mob +49 170 2723133 fax +49 40 42949753 http://uplex.de/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Normalize-the-Host-header-according-to-the-recommen.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From phk at phk.freebsd.dk Thu Feb 17 17:32:47 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 17 Feb 2011 17:32:47 +0000 Subject: [PATCH] Normalizing the Host: header In-Reply-To: Your message of "Thu, 17 Feb 2011 13:55:37 +0100." <4D5D1AC9.3000507@uplex.de> Message-ID: <93511.1297963967@critter.freebsd.dk> In message <4D5D1AC9.3000507 at uplex.de>, Nils Goroll writes: >we were discussion this on VUG3: comparisons on the Host: header should be case >insensitive. Reflecting on this, I think that normalizing the Host: header in >Varnish would actually be the better idea and should avoid common errors. What a great idea for a VMOD :-) But this is exactly the kind of needless text-processing we should avoid if we want to be the fastest cache on the planet: a regexp or a strncasecmp() is not measurably slower than their case-sensitive parallels and if you don't need to inspect the host-header at all, case-folding it is pure wasted effort. -- 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 Feb 17 18:47:38 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 17 Feb 2011 18:47:38 +0000 Subject: [PATCH] Normalizing the Host: header In-Reply-To: Your message of "Thu, 17 Feb 2011 19:03:52 +0100." <4D5D6308.7000304@uplex.de> Message-ID: <20000.1297968458@critter.freebsd.dk> In message <4D5D6308.7000304 at uplex.de>, Nils Goroll writes: >> a regexp or a strncasecmp() > >We don't have stncasecmp() in VCL at this point, so we need to compare >performance of pcre_exec() and strcmp(). Maybe the right solution is to make sure we do have it. >If this suggestion is not found useful, I think we should at least fix all >the wrong examples for host header comparison in the docs. It is not that it is not useful, it's just not the right way to fix it. And yes, the docs should be correct. -- 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 geoff at uplex.de Thu Feb 17 19:01:42 2011 From: geoff at uplex.de (Geoff Simmons) Date: Thu, 17 Feb 2011 20:01:42 +0100 Subject: If-Modified-Since Message-ID: <4D5D7096.6040701@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Poul-Henning, Condolences on your laptop, I hope it will get well and you'll be back up to full speed soon. I'd like to recapitulate some of the results of our discussion at VUG about backend conditional requests, to make sure that we have a common understanding. - - Instead of letting grace determine how long an object in cache can be a candidate for conditional refreshes after its TTL elapses, we'll introduce a new parameter for that. Let's say it's called refresh_ttl (since I can't think of a better name right now). A global -p parameter sets the default for all objects, and it can be set for individzal objects. I'd guess that its default default value could be the same as default_grace. Nils and I think that the semantics should be like this: - In HSH_Lookup(), if an object o is found in the objhead list such that: - o->ttl has elapsed, but o->refresh_ttl has not elapsed, and - o has a Last-Modified and/or ETag header then o is a candidate for refresh (o becomes stale_obj). - a grace candidate is determined as it is now (independently of refresh_ttl) - the cache eviction time for an object (oc->timer_when) becomes o->ttl + max(o->refresh_ttl, HSH_Grace(o->grace)) That is, an object is evicted when grace or refresh_ttl has expired, whichever is later. - - As Sky pointed out, RFC 2616 Ch. 13.3.3 does indeed say that Last-Modified is a "strong validator" only if Last-Modified from the backend is at least 60 seconds before Date in the cache entry. But I don't see any MUST or SHOULD requirement that applies to Varnish here. The idea has to do with possible clock skew between different backends that delivered the same object; and the RFC admits that the 60 seconds is arbitrary. But since Varnish tries to account for clock skew, and smart admins use NTP, I think we shouldn't worry about it. Ch 13.3 of the RFC has a lot of interesting and generally unknown stuff about the backend conditionals that we're not implementing. I wouldn't worry about that either, but we might consider adding some features in the future, for better compliance (and some of it might be useful). - - For a first implementation, we agreed to put off decisions about sharing storage between objects, until we're clear and how best to go about it, and just copy the storage from the stale object to the new object after a 304 response. Since I've encapsulated the duplication of storage in STV_dup() and stevedore-specific dup methods, we'll just have those functions copy the storage in all cases for now, and the implementation can be changed later. (Nils and I intend to implement shared storage for our private patch, which will go into production, so we'll probably have some informative results.) Comments? It was good to see everybody at VUG, hope you're all doing well and getting hit often. %^) Best, Geoff Simmons - -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNXXCWAAoJEOUwvh9pJNUReAMP/AzP/Je5fa3SFomg6UlBo6JS WnVOHuYOkTjE6CXfKCEw0Eh6yPAkGsN1FuNN58uuWFfAI9MbdLQQGQ86Kr7wV7S1 gmQQxQB4Bod+nVHJn+apeQ9ZK1xX1x4/VHgedn2ZASLJoY4JKKR1mR5jy7Lbv43K syrOPEoaabLPiTY4IydFhed7gDLv3GogvXH7RhWdfZh+rld0WrPtM4f/v8fFGRuA XYMZTpPubTpFiKPtlHInZBq4MPUz3PPQPxVH0zQCQmVKzEkUGLuwLnPRG1YvZFtc 5pDPjFps5gLQdwA4geJxsL1cvwTYJlo6ZdAojZNVyTgUjK8YgFQxZB9S+Mg/B0BS 0p4WS6wDG5mXhxtXaC5n55u4cm07GLFxNX0947WZO0OGQc1INTyK1a/uRDMOTwd7 xBfHTA2C0EqU4xsxmB/FuYCOGwWBqoppFxRIo2hDXE4uuCxJfCywshYslGbUUfhs j4I3Neo0J6zz4Urb0lSVbc9tcE8GUfuHApcu4BvRjjfCcqhTOkMGE9PmzA3Qb1uj HOE2NqFWD64ztDNU2Vv0Erj0Nd77PygF5D3gBCK0HH171+IkT7ja+660W0qOp1Bu nczTnz0OtB4krde6ZdmMafzIhiuj63ZgmCuJBEDJZLJRRijZGWFJ6aF2D4qnGsL5 HMSXOuEOyUpCfwcpVjWV =bPnF -----END PGP SIGNATURE----- From perbu at varnish-software.com Thu Feb 17 19:43:03 2011 From: perbu at varnish-software.com (Per Buer) Date: Thu, 17 Feb 2011 20:43:03 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <20000.1297968458@critter.freebsd.dk> References: <4D5D6308.7000304@uplex.de> <20000.1297968458@critter.freebsd.dk> Message-ID: On Thu, Feb 17, 2011 at 7:47 PM, Poul-Henning Kamp wrote: > > It is not that it is not useful, it's just not the right way to fix it. > > And yes, the docs should be correct. I've look through "man vcl" and I can spot any errors. Any hints on where to look for these errors? -- Per Buer,?Varnish Software Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / Skype: per.buer Varnish makes websites fly! Want to learn more about Varnish? http://www.varnish-software.com/whitepapers From perbu at varnish-software.com Thu Feb 17 19:53:15 2011 From: perbu at varnish-software.com (Per Buer) Date: Thu, 17 Feb 2011 20:53:15 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <4D5D7C09.7090408@uplex.de> References: <4D5D6308.7000304@uplex.de> <20000.1297968458@critter.freebsd.dk> <4D5D7C09.7090408@uplex.de> Message-ID: On Thu, Feb 17, 2011 at 8:50 PM, Nils Goroll wrote: > >> I've look through "man vcl" and I can spot any errors. Any hints on >> where to look for these errors? > > There are many examples for matches on the host header like > > ?if (req.http.host ~ "^(www.)?example.com$") { > ? ?set req.backend = www; > ?} > > To accept mixed case host headers, examples for matches on http.host should all > use the (?i) option setting. Right. Of course. Silly me. I'll get to work. -- Per Buer,?Varnish Software Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / Skype: per.buer Varnish makes websites fly! Want to learn more about Varnish? http://www.varnish-software.com/whitepapers From perbu at varnish-software.com Thu Feb 17 20:04:12 2011 From: perbu at varnish-software.com (Per Buer) Date: Thu, 17 Feb 2011 21:04:12 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: References: <4D5D6308.7000304@uplex.de> <20000.1297968458@critter.freebsd.dk> <4D5D7C09.7090408@uplex.de> Message-ID: On Thu, Feb 17, 2011 at 8:53 PM, Per Buer wrote: > On Thu, Feb 17, 2011 at 8:50 PM, Nils Goroll wrote: >> To accept mixed case host headers, examples for matches on http.host should all >> use the (?i) option setting. > > Right. Of course. Silly me. I'll get to work. Do you think this bears relevance for any other header treatment or just the Host: header? -- Per Buer,?Varnish Software Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / Skype: per.buer Varnish makes websites fly! Want to learn more about Varnish? http://www.varnish-software.com/whitepapers From phk at phk.freebsd.dk Thu Feb 17 20:13:26 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 17 Feb 2011 20:13:26 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Thu, 17 Feb 2011 20:01:42 +0100." <4D5D7096.6040701@uplex.de> Message-ID: <42834.1297973606@critter.freebsd.dk> In message <4D5D7096.6040701 at uplex.de>, Geoff Simmons writes: >[...]a new parameter for that. Let's say it's called refresh_ttl I would probably call it "conditional_timeout", as refresh_ttl could sound like it would actively refresh things. > - In HSH_Lookup(), if an object o is found in the objhead list such > that: > - o->ttl has elapsed, but o->refresh_ttl has not elapsed, and > - o has a Last-Modified and/or ETag header > then o is a candidate for refresh (o becomes stale_obj). yes, (presuming we have weeded out vary-non-matches first) But what about bans and objects which have had their TTL+grace set to zero as a means of purging ? Formally, the backend should DTRT and not 304 these, but that sort of pressumes the backend know about them. Imagine the backend with a PHP-bug. The bad result gets cached, problem gets fixed, cache gets purged (obj.ttl = 0s), next fetch uses this object, asks backend IMS ? and the backend, unaware that the PHP mistake was fixed, checks its database and says "Sure: 304!" In total there are three cases: bans We should not touch these ever, the current code will do ban-processing as part of the search, so that should come automatically. ttl=0, grace=0 This is a clear cut expiry, but we may still catch it before the grim reaper does, we should explicity make sure we do not. We should probably have the VRT code zero the conditional_timeout, like it does with grace, when ttl is set <= 0. ttl=0, grace>0 This is a special case, where the object is expired, but still available for grace (you have to first set obj.ttl = 0 and then set obj.grace to nonzero, as obj.ttl = 0 also clears obj.grace) I think in this case it is a candidate, the admin clearly considers the content valid enough to use in an emergency, so it should be fair game for IMS also. But if we treat conditional_timeout as grace, this follows automatically: If you set obj.ttl = 0, you have to explicitly enable grace and IMS use of the object. > - a grace candidate is determined as it is now (independently of > refresh_ttl) Yes, they should be independent. > - the cache eviction time for an object (oc->timer_when) becomes > o->ttl + max(o->refresh_ttl, HSH_Grace(o->grace)) > >That is, an object is evicted when grace or refresh_ttl has expired, >whichever is later. Correct. We may eventually have to teach the grim reaper about the difference so that LRU becomes "Least recently used, least useful" or something, but lets leave that one "for further study" >The idea has to do with possible clock skew between different backends >that delivered the same object; and the RFC admits that the 60 seconds >is arbitrary. But since Varnish tries to account for clock skew, and >smart admins use NTP, I think we shouldn't worry about it. Having thought about it: As long as we use the Last-Modified header provided by the backend in the IMS, it should not be our problem. But I guess this would apply when the client sends us a constructed timestamp (ie: not a copy of the backends L-M header). My bat-sense is tingling a little bit over this, and I may have to revisit the way we do IMS from clients to make sure we do not offer a security-wedge. But you are right: as long as we copy the backends L-M header, we need not worry. >but we might consider adding some features in >the future, for better compliance (and some of it might be useful). I'm not particular keen on adding stuff nobody is using, just to be "compliant" with one of the least coherent RFC's we have. But useful stuff I'm entirely open for. >- - For a first implementation, we agreed to put off decisions about >sharing storage between objects, until we're clear and how best to go >about it, and just copy the storage from the stale object to the new >object after a 304 response. Correct. >It was good to see everybody at VUG, hope you're all doing well and >getting hit often. %^) Yes, nothing like being able to use your hands to communicate with also :-) -- 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 seshu.vavilikolanu at RACKSPACE.COM Fri Feb 18 05:35:09 2011 From: seshu.vavilikolanu at RACKSPACE.COM (Seshu Vavilikolanu) Date: Fri, 18 Feb 2011 05:35:09 +0000 Subject: vcl_timeout in varnish 2.1.5 Message-ID: <10956_1298007314_p1I5Z98v012108_C983612C.146E%seshu.vavilikolanu@rackspace.com> Hi All, We are migrating from varnish 2.0.6 to 2.1.5. We have some VCL and C code in 'vcl_timeout' function that we need to execute whenever there is timeout event. >From the varnish-cache website, it looks like 'vcl_timeout' is not supported anymore in 2.1.*. What is the alternative? How can I capture 'vcl_timeout' in 2.1.5? Thanks in advance, Thanks, - Seshu Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Fri Feb 18 10:26:20 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 18 Feb 2011 10:26:20 +0000 Subject: [PATCH] Normalizing the Host: header In-Reply-To: Your message of "Fri, 18 Feb 2011 11:07:59 +0100." <4D5E44FF.5060302@uplex.de> Message-ID: <14026.1298024780@critter.freebsd.dk> In message <4D5E44FF.5060302 at uplex.de>, Nils Goroll writes: >Shouldn't we normalize the host header anyway to maximize cache hit rates ? Good question. List consensus ? -- 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 Feb 18 10:27:17 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 18 Feb 2011 10:27:17 +0000 Subject: [PATCH] Normalizing the Host: header In-Reply-To: Your message of "Fri, 18 Feb 2011 11:07:59 +0100." <4D5E44FF.5060302@uplex.de> Message-ID: <14070.1298024837@critter.freebsd.dk> In message <4D5E44FF.5060302 at uplex.de>, Nils Goroll writes: >Shouldn't we normalize the host header anyway to maximize cache hit rates ? Relevant question in this context: Do we know how to ? Remember that DNS names can contain ideograms in asia these days... -- 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 tfheen at varnish-software.com Fri Feb 18 12:32:51 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Fri, 18 Feb 2011 13:32:51 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <14070.1298024837@critter.freebsd.dk> (Poul-Henning Kamp's message of "Fri, 18 Feb 2011 10:27:17 +0000") References: <14070.1298024837@critter.freebsd.dk> Message-ID: <878vxdikuk.fsf@qurzaw.varnish-software.com> ]] "Poul-Henning Kamp" | In message <4D5E44FF.5060302 at uplex.de>, Nils Goroll writes: | | >Shouldn't we normalize the host header anyway to maximize cache hit rates ? | | Relevant question in this context: Do we know how to ? Normalise usually means rewriting from a list of various legal names to the canonical name, so in the general case: no. | Remember that DNS names can contain ideograms in asia these days... They're still just ascii under the hood, escaped by xn-- and the crazy IDN scheme. -- Tollef Fog Heen Varnish Software t: +47 21 98 92 64 From nils.goroll at uplex.de Thu Feb 17 18:03:52 2011 From: nils.goroll at uplex.de (Nils Goroll) Date: Thu, 17 Feb 2011 19:03:52 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <93511.1297963967@critter.freebsd.dk> References: <93511.1297963967@critter.freebsd.dk> Message-ID: <4D5D6308.7000304@uplex.de> Hi phk, > But this is exactly the kind of needless text-processing we should avoid In general: Absolutely, yes. In this case, normalizing once should pay off wherever the host header needs to be checked at least once. > a regexp or a strncasecmp() We don't have stncasecmp() in VCL at this point, so we need to compare performance of pcre_exec() and strcmp(). Besides this, my main motivation for this suggestion was to avoid wrong host header comparisons for all of those who have not spotted the right place in the docs. If this suggestion is not found useful, I think we should at least fix all the wrong examples for host header comparison in the docs. Thanks, Nils -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg tel +49 40 28805731 mob +49 170 2723133 fax +49 40 42949753 http://uplex.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From nils.goroll at uplex.de Thu Feb 17 19:50:33 2011 From: nils.goroll at uplex.de (Nils Goroll) Date: Thu, 17 Feb 2011 20:50:33 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: References: <4D5D6308.7000304@uplex.de> <20000.1297968458@critter.freebsd.dk> Message-ID: <4D5D7C09.7090408@uplex.de> > I've look through "man vcl" and I can spot any errors. Any hints on > where to look for these errors? There are many examples for matches on the host header like if (req.http.host ~ "^(www.)?example.com$") { set req.backend = www; } To accept mixed case host headers, examples for matches on http.host should all use the (?i) option setting. Nils -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg tel +49 40 28805731 mob +49 170 2723133 fax +49 40 42949753 http://uplex.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From nils.goroll at uplex.de Thu Feb 17 19:52:42 2011 From: nils.goroll at uplex.de (Nils Goroll) Date: Thu, 17 Feb 2011 20:52:42 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <4D5D7C09.7090408@uplex.de> References: <4D5D6308.7000304@uplex.de> <20000.1297968458@critter.freebsd.dk> <4D5D7C09.7090408@uplex.de> Message-ID: <4D5D7C8A.8030405@uplex.de> hope to have cought them all: haggis:~/Devel/varnish-git$ find . -name \*.rst| xargs egrep 'req.http.host *~' | grep -v '\(\?i\)' ./varnish-cache/doc/sphinx/faq/general.rst: if (req.http.host ~ "^(www.)?example.com") { ./varnish-cache/doc/sphinx/faq/general.rst: if (req.http.host ~ "^(www.)?example.com") { ./varnish-cache/doc/sphinx/tutorial/increasing_your_hitrate.rst: if (req.http.host ~ "^(www.)?varnish-?software.com") { ./varnish-cache/doc/sphinx/reference/vcl.rst: if (req.http.host ~ "^(www.)?example.com$") { ./varnish-cache/doc/sphinx/reference/vcl.rst: if (req.http.host ~ "example.com") { ./varnish-cache/doc/sphinx/reference/vcl.rst: } elsif (req.http.host ~ "example.org") { ./varnish-cache/doc/sphinx/reference/vcl.rst: if (req.http.host ~ "^(www.)?example.com$") { ./varnish-cache/doc/sphinx/reference/vcl.rst: if (req.http.host ~ "^(www.)?example.com$") { ./varnish-cache/doc/sphinx/reference/vcl.rst: } elsif (req.http.host ~ "^images.example.com$") { ./varnish-cache/doc/sphinx/reference/varnishd.rst: req.http.host ~ "^(www\.)example.com$" && obj.set-cookie ~ "USERID=1663" -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg tel +49 40 28805731 mob +49 170 2723133 fax +49 40 42949753 http://uplex.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From nils.goroll at uplex.de Thu Feb 17 20:55:42 2011 From: nils.goroll at uplex.de (Nils Goroll) Date: Thu, 17 Feb 2011 21:55:42 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: References: <4D5D6308.7000304@uplex.de> <20000.1297968458@critter.freebsd.dk> <4D5D7C09.7090408@uplex.de> Message-ID: <4D5D8B4E.90809@uplex.de> > Do you think this bears relevance for any other header treatment or > just the Host: header? Anything which can contain a host name would apply. Location comes into my mind, but that is a response header which only needs to get matched and also it will most likely be generated by the backend the varnish admin has under control. Of the request headers, Referer is probably matched sometimes. Nils P.S.: I just noticed that facebook is actually amongst the clients sending non-normalized Host headers (under the assumption that I can trust the UA). -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg tel +49 40 28805731 mob +49 170 2723133 fax +49 40 42949753 http://uplex.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From nils.goroll at uplex.de Fri Feb 18 10:07:59 2011 From: nils.goroll at uplex.de (Nils Goroll) Date: Fri, 18 Feb 2011 11:07:59 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <20000.1297968458@critter.freebsd.dk> References: <20000.1297968458@critter.freebsd.dk> Message-ID: <4D5E44FF.5060302@uplex.de> > It is not that it is not useful, it's just not the right way to fix it. Shouldn't we normalize the host header anyway to maximize cache hit rates? Nils -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg tel +49 40 28805731 mob +49 170 2723133 fax +49 40 42949753 http://uplex.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From tfheen at varnish-software.com Fri Feb 18 12:55:13 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Fri, 18 Feb 2011 13:55:13 +0100 Subject: vcl_timeout in varnish 2.1.5 In-Reply-To: <10956_1298007314_p1I5Z98v012108_C983612C.146E%seshu.vavilikolanu@rackspace.com> (Seshu Vavilikolanu's message of "Fri, 18 Feb 2011 05:35:09 +0000") References: <10956_1298007314_p1I5Z98v012108_C983612C.146E%seshu.vavilikolanu@rackspace.com> Message-ID: <874o81ijta.fsf@qurzaw.varnish-software.com> ]] Seshu Vavilikolanu | From the varnish-cache website, it looks like 'vcl_timeout' is not | supported anymore in 2.1.*. What is the alternative? How can I | capture 'vcl_timeout' in 2.1.5? You can't directly, you could have something tailing varnishlog and doing the work you need when an object is expired, depending on what you're trying to do. -- Tollef Fog Heen Varnish Software t: +47 21 98 92 64 From allan_wind at lifeintegrity.com Sat Feb 19 17:09:22 2011 From: allan_wind at lifeintegrity.com (Allan Wind) Date: Sat, 19 Feb 2011 12:09:22 -0500 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <14026.1298024780@critter.freebsd.dk> References: <4D5E44FF.5060302@uplex.de> <14026.1298024780@critter.freebsd.dk> Message-ID: <20110219170922.GB6354@vent.lifeintegrity.localnet> On 2011-02-18 10:26:20, Poul-Henning Kamp wrote: > In message <4D5E44FF.5060302 at uplex.de>, Nils Goroll writes: > > >Shouldn't we normalize the host header anyway to maximize cache hit rates ? > > Good question. > > List consensus ? Makes sense to me. Is there a reasonable use case for non-normalized host headers (without the ignore case option on regex)? /Allan -- Allan Wind Life Integrity, LLC From nils.goroll at uplex.de Fri Feb 18 15:05:36 2011 From: nils.goroll at uplex.de (Nils Goroll) Date: Fri, 18 Feb 2011 16:05:36 +0100 Subject: Host header normalization and IDNs/IDNA/punicode In-Reply-To: <14070.1298024837@critter.freebsd.dk> References: <14070.1298024837@critter.freebsd.dk> Message-ID: <4D5E8AC0.6020409@uplex.de> Hi, >> Shouldn't we normalize the host header anyway to maximize cache hit rates ? > Relevant question in this context: Do we know how to ? > Remember that DNS names can contain ideograms in asia these days... I must say that until now I have more or less ignored details of the IDN conversion implementations because from a Server/DNS perspective my understanding is that everything simply ends up in a Host header which uses xn-- encoded parts (apologies for the broad simplification). My understanding is that IDN complies with rfc3986, so we should not need any extra treatment. BUT: Does anyone on this list know IDN details well enough to confirm or correct? Under the assumption that my understanding is correct, I think we could have a VMOD for IDN conversion, but the Host header should under no circumstances get converted to unicode. Nils -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg tel +49 40 28805731 mob +49 170 2723133 fax +49 40 42949753 http://uplex.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From slink at schokola.de Mon Feb 21 16:09:57 2011 From: slink at schokola.de (Nils Goroll) Date: Mon, 21 Feb 2011 17:09:57 +0100 Subject: [PATCH] Normalizing the Host: header In-Reply-To: <878vxdikuk.fsf@qurzaw.varnish-software.com> References: <14070.1298024837@critter.freebsd.dk> <878vxdikuk.fsf@qurzaw.varnish-software.com> Message-ID: <4D628E55.3040008@schokola.de> On 02/18/11 01:32 PM, Tollef Fog Heen wrote: > | >Shouldn't we normalize the host header anyway to maximize cache hit rates ? > | Relevant question in this context: Do we know how to ? > > Normalise usually means rewriting from a list of various legal names to > the canonical name, so in the general case: no. The normalization you are referring to is site-specific, yes. The generic normalization according to rfc3986 implies case folding for percent-encodings (toupper()) and all other characters (tolower()). This would help maximize cache efficiency whenever Host headers are not normalized to some (set of) site-specific const value(s). Nils From geoff at uplex.de Mon Feb 21 18:07:04 2011 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 21 Feb 2011 19:07:04 +0100 Subject: If-Modified-Since In-Reply-To: <42834.1297973606@critter.freebsd.dk> References: <42834.1297973606@critter.freebsd.dk> Message-ID: <4D62A9C8.7050003@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/17/11 09:13 PM, Poul-Henning Kamp wrote: > In message <4D5D7096.6040701 at uplex.de>, Geoff Simmons writes: > >> [...]a new parameter for that. Let's say it's called refresh_ttl > > I would probably call it "conditional_timeout", as refresh_ttl could > sound like it would actively refresh things. All right, conditional_timeout it will be. And I assume that the per-object attribute should have the same name. While we're on the subject of naming -- we're adding two stats counters that currently have names that are probably confusing: cache_refresh_hits -- conditional backend requests that resulted in 304 cache_refresh_misses -- such requests that resulted in 200 Maybe they should be something like: cache_conditional_not_modified cache_conditional_refresh ... respectively. We should get some clarity on what Varnish should do if it gets another response besides 200 or 304 from the backend; but let's save that for another mail, this one's getting long enough. %^) Also, we're currently updating the per-object hits counter when a 304 is returned for a conditional request; but perhaps we also need the two new stats counters per object, rather than counting this event as a hit. And to come back to something that I brought up in IRC last week -- when we merge data from stale_obj into the new object after a 304 response, that has the effect of resetting the hits counter back to 0 (which of course makes incrementing the hits counter superfluous). The client at that point sees the new object with new XID for the URL, which after the 304 backend response has no hits. Intuitions don't seem to be very clear about whether this is the right idea. On the one hand, it really is a new object with no hits; but on the other hand, the cache did find an object that is verified by the backend as unchanged, and the fact that Varnish is using a new object in its place is a sort of formality, that might be unimportant to whoever's looking at obj.hits. I guess that what matters is what people are using obj.hits for in real-life VCL. Looking at it that way, it's probably better to copy over the hits counter, even though Varnish thinks of it internally as a new object, so that obj.hits keeps doing what people expect. >> - In HSH_Lookup(), if an object o is found in the objhead list such >> that: >> - o->ttl has elapsed, but o->refresh_ttl has not elapsed, and >> - o has a Last-Modified and/or ETag header >> then o is a candidate for refresh (o becomes stale_obj). > > yes, (presuming we have weeded out vary-non-matches first) > > But what about bans and objects which have had their TTL+grace set > to zero as a means of purging ? > > Formally, the backend should DTRT and not 304 these, but that sort of > pressumes the backend know about them. > > Imagine the backend with a PHP-bug. The bad result gets cached, > problem gets fixed, cache gets purged (obj.ttl = 0s), next fetch > uses this object, asks backend IMS ? and the backend, unaware that > the PHP mistake was fixed, checks its database and says "Sure: 304!" > > In total there are three cases: > > bans > We should not touch these ever, the current code will do > ban-processing as part of the search, so that should come > automatically. In HSH_Lookup(), in the loop through oh->objcs, we're checking for the candidate object after the check against BAN_CheckObject(), so as not to pick up an object with a ban. (It also comes after the check against Vary.) > ttl=0, grace=0 > This is a clear cut expiry, but we may still catch it before the > grim reaper does, we should explicity make sure we do not. OK, we don't have anything to check for this case, so in our current code it might in fact pick up such an object. All right, then we'll explicitly rule this out. > We should probably have the VRT code zero the conditional_timeout, > like it does with grace, when ttl is set <= 0. Ah, OK. > ttl=0, grace>0 > This is a special case, where the object is expired, but still > available for grace (you have to first set obj.ttl = 0 and then set > obj.grace to nonzero, as obj.ttl = 0 also clears obj.grace) > I think in this case it is a candidate, the admin clearly considers > the content valid enough to use in an emergency, so it should be > fair game for IMS also. > But if we treat conditional_timeout as grace, this follows > automatically: If you set obj.ttl = 0, you have to explicitly > enable grace and IMS use of the object. > >> - a grace candidate is determined as it is now (independently of >> refresh_ttl) > > Yes, they should be independent. I believe (have to make sure with a test) that in this situation, we attempt the conditional request. That is, if the TTL has expired, but neither conditional_timeout nor grace have expired, then the object is a candidate for the IMS request. Hm, I really need to test that, because I think it means that, in situations where grace mode had previously used (either there is a busy object or the backend is unhealthy), we might now attempt the conditional request instead of sending back the grace candidate. If so, then it's changing Varnish's behavior. Maybe that's the better solution, and since you're allowing changes in 3.0 that break backward compatibility, it might be OK. But we need to make sure of what happens, so we'll test to find out. Best, Geoff - -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNYqnIAAoJEOUwvh9pJNURlyYQAJ7MR0BSv6dOnIKzu5T7Ig6r p5NBn6eeO1o56bK8abOzK5nq/X+XZiIOUMDIeYQKaWnqKNcRjb3Y/iRz2+pSRBNa HQAVQmX5S7TXQPpJQmxVR6LSKRsr5ch/i3JEVcI8tONSewKMF/Gh2KxEAMtCveLT R2J7IaMr12JAroBpyCUgx8RsF9AqaNB3cHViGS2NjwpNLk26TxiyQ0qcRIyU4Jq7 r3e3AXy8pjK7csOseXw+bxcbiWGgCNIKW7gNwm+Xbr2DyiasJX2jhCKhN/VXcxtV V0+KhEy7IUqKvXZoBIF45iOvTW9c2YRiV1hHqBbrOSwIeF1gJZk0Pje5icWECRFi Bbd444OEGnmM6LrvMiWw9eXyzgERgUOF0SjVY3BrwYpRETT5abQQd1a9c2xIa2bt CDALZABa+tOf09Y2uysfQ3H5MxqDiKlr8qwxmEBpAB/i8xueJBJQ/D0QG199n84P fWUTo2OO+09ZJo6GcigwXDUYfE6gXF3x/MS5tPO30CxKJlxSvUfKmTYgaLkFMGlj OOuKCOxdiYhZL71CjRhD6hzYuiYeSULYDLemqmliI5ckRYJceP7jcHDuR1y02Pyi jsnbmWdqj5w6W54jFW7yyI+Xo6iONAnTTzPipHQKR8s4BXajt4BMj7TxJViIJ1pI xgjq4ztSsm4NaNZraJhS =RILD -----END PGP SIGNATURE----- From sky at crucially.net Mon Feb 21 22:02:42 2011 From: sky at crucially.net (Artur Bergman) Date: Mon, 21 Feb 2011 14:02:42 -0800 Subject: If-Modified-Since In-Reply-To: <4D62A9C8.7050003@uplex.de> References: <42834.1297973606@critter.freebsd.dk> <4D62A9C8.7050003@uplex.de> Message-ID: On Feb 21, 2011, at 10:07 AM, Geoff Simmons wrote: >> >> ttl=0, grace=0 >> This is a clear cut expiry, but we may still catch it before the >> grim reaper does, we should explicity make sure we do not. > > OK, we don't have anything to check for this case, so in our current > code it might in fact pick up such an object. All right, then we'll > explicitly rule this out. Why? I might want to force a IMS to the backend without having ttl or grace. You can set the conditional timeout to 0 if you really want it gone. Artur From tfheen at varnish-software.com Tue Feb 22 09:22:28 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Tue, 22 Feb 2011 10:22:28 +0100 Subject: [PATCH 1/2] Move all libs but libvarnishapi to a private directory, drop soname number In-Reply-To: <1298366549-6945-1-git-send-email-tfheen@varnish-software.com> References: <1298366549-6945-1-git-send-email-tfheen@varnish-software.com> Message-ID: <1298366549-6945-2-git-send-email-tfheen@varnish-software.com> As we don't want anybody linking against libvarnish, libvcl and the other libraries, move those to pkglibdir. In addition, to further emphasize that they do not have a stable ABI, drop the version from the soname. --- lib/libvarnish/Makefile.am | 4 ++-- lib/libvarnishcompat/Makefile.am | 4 ++-- lib/libvcl/Makefile.am | 4 ++-- lib/libvgz/Makefile.am | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/lib/libvarnish/Makefile.am b/lib/libvarnish/Makefile.am index 9d1056c..dcec5e1 100644 --- a/lib/libvarnish/Makefile.am +++ b/lib/libvarnish/Makefile.am @@ -2,9 +2,9 @@ INCLUDES = -I$(top_srcdir)/include @PCRE_CFLAGS@ -lib_LTLIBRARIES = libvarnish.la +pkglib_LTLIBRARIES = libvarnish.la -libvarnish_la_LDFLAGS = -version-info 1:0:0 +libvarnish_la_LDFLAGS = -avoid-version libvarnish_la_SOURCES = \ argv.c \ diff --git a/lib/libvarnishcompat/Makefile.am b/lib/libvarnishcompat/Makefile.am index 76d4986..f5b363e 100644 --- a/lib/libvarnishcompat/Makefile.am +++ b/lib/libvarnishcompat/Makefile.am @@ -2,9 +2,9 @@ INCLUDES = -I$(top_srcdir)/include -lib_LTLIBRARIES = libvarnishcompat.la +pkglib_LTLIBRARIES = libvarnishcompat.la -libvarnishcompat_la_LDFLAGS = -version-info 1:0:0 +libvarnishcompat_la_LDFLAGS = -avoid-version libvarnishcompat_la_SOURCES = \ daemon.c \ diff --git a/lib/libvcl/Makefile.am b/lib/libvcl/Makefile.am index aab8749..c594885 100644 --- a/lib/libvcl/Makefile.am +++ b/lib/libvcl/Makefile.am @@ -2,9 +2,9 @@ INCLUDES = -I$(top_srcdir)/include -I$(top_builddir)/include -lib_LTLIBRARIES = libvcl.la +pkglib_LTLIBRARIES = libvcl.la -libvcl_la_LDFLAGS = -version-info 1:0:0 +libvcl_la_LDFLAGS = -avoid-version libvcl_la_SOURCES = \ vcc_priv.h \ diff --git a/lib/libvgz/Makefile.am b/lib/libvgz/Makefile.am index ab9b561..a00e22b 100644 --- a/lib/libvgz/Makefile.am +++ b/lib/libvgz/Makefile.am @@ -1,8 +1,8 @@ # $Id$ -lib_LTLIBRARIES = libvgz.la +pkglib_LTLIBRARIES = libvgz.la -libvgz_la_LDFLAGS = -version-info 1:0:0 +libvgz_la_LDFLAGS = -avoid-version libvgz_la_CFLAGS = -D_LARGEFILE64_SOURCE=1 $(libvgz_extra_cflags) libvgz_la_SOURCES = \ -- 1.7.2.3 From tfheen at varnish-software.com Tue Feb 22 09:22:29 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Tue, 22 Feb 2011 10:22:29 +0100 Subject: [PATCH 2/2] Drop version from libvmod_std In-Reply-To: <1298366549-6945-1-git-send-email-tfheen@varnish-software.com> References: <1298366549-6945-1-git-send-email-tfheen@varnish-software.com> Message-ID: <1298366549-6945-3-git-send-email-tfheen@varnish-software.com> There is no reason for libvmod_std to have a version number, so drop it and adjust test cases accordingly. --- bin/varnishtest/tests/m00000.vtc | 2 +- bin/varnishtest/tests/m00001.vtc | 2 +- bin/varnishtest/tests/m00002.vtc | 2 +- lib/libvcl/vcc_vmod.c | 2 +- lib/libvmod_std/Makefile.am | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/bin/varnishtest/tests/m00000.vtc b/bin/varnishtest/tests/m00000.vtc index e44dbb2..c73a52e 100644 --- a/bin/varnishtest/tests/m00000.vtc +++ b/bin/varnishtest/tests/m00000.vtc @@ -8,7 +8,7 @@ server s1 { } -start varnish v1 -vcl+backend { - import std from "${topbuild}/lib/libvmod_std/.libs/libvmod_std.so.1" ; + import std from "${topbuild}/lib/libvmod_std/.libs/libvmod_std.so" ; sub vcl_deliver { set resp.http.foo = std.toupper(resp.http.foo); diff --git a/bin/varnishtest/tests/m00001.vtc b/bin/varnishtest/tests/m00001.vtc index f65dcbd..e8b11cf 100644 --- a/bin/varnishtest/tests/m00001.vtc +++ b/bin/varnishtest/tests/m00001.vtc @@ -8,7 +8,7 @@ server s1 { } -start varnish v1 -arg "-pthread_pools=1" -vcl+backend { - import std from "${topbuild}/lib/libvmod_std/.libs/libvmod_std.so.1" ; + import std from "${topbuild}/lib/libvmod_std/.libs/libvmod_std.so" ; sub vcl_deliver { set resp.http.foo = std.toupper(resp.http.foo); diff --git a/bin/varnishtest/tests/m00002.vtc b/bin/varnishtest/tests/m00002.vtc index 8b5fd16..a6193ad 100644 --- a/bin/varnishtest/tests/m00002.vtc +++ b/bin/varnishtest/tests/m00002.vtc @@ -11,7 +11,7 @@ server s1 { } -start varnish v1 -vcl+backend { - import std from "${topbuild}/lib/libvmod_std/.libs/libvmod_std.so.1" ; + import std from "${topbuild}/lib/libvmod_std/.libs/libvmod_std.so" ; sub vcl_fetch { set beresp.http.rnd1 = std.random(0,1); diff --git a/lib/libvcl/vcc_vmod.c b/lib/libvcl/vcc_vmod.c index 8e679fb..45fe1cd 100644 --- a/lib/libvcl/vcc_vmod.c +++ b/lib/libvcl/vcc_vmod.c @@ -98,7 +98,7 @@ vcc_ParseImport(struct vcc *tl) bprintf(fn, "%s", tl->t->dec); vcc_NextToken(tl); } else { - bprintf(fn, "%s/libvmod_%.*s.so.1", tl->vmod_dir, PF(mod)); + bprintf(fn, "%s/libvmod_%.*s.so", tl->vmod_dir, PF(mod)); } Fh(tl, 0, "static void *VGC_vmod_%.*s;\n", PF(mod)); diff --git a/lib/libvmod_std/Makefile.am b/lib/libvmod_std/Makefile.am index 36147fe..5437c02 100644 --- a/lib/libvmod_std/Makefile.am +++ b/lib/libvmod_std/Makefile.am @@ -5,7 +5,7 @@ INCLUDES = -I$(top_srcdir)/include -I$(top_builddir)/include vmoddir = $(pkglibdir)/vmods vmod_LTLIBRARIES = libvmod_std.la -libvmod_std_la_LDFLAGS = -version-info 1:0:0 +libvmod_std_la_LDFLAGS = -avoid-version libvmod_std_la_SOURCES = \ vcc_if.c \ -- 1.7.2.3 From tfheen at varnish-software.com Tue Feb 22 09:22:27 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Tue, 22 Feb 2011 10:22:27 +0100 Subject: Build system cleanups Message-ID: <1298366549-6945-1-git-send-email-tfheen@varnish-software.com> I've got a couple of fixes for the build system, but I'd like to run those past -dev before committing them. The purpose is to be clearer about what interfaces we do and don't support. From dmitry.panov at yahoo.co.uk Wed Feb 23 00:12:12 2011 From: dmitry.panov at yahoo.co.uk (Dmitry Panov) Date: Wed, 23 Feb 2011 00:12:12 +0000 Subject: Conditional requests to backend Message-ID: <4D6450DC.2050208@yahoo.co.uk> Hi guys, I've found an earlier thread from this maillist: http://www.gossamer-threads.com/lists/varnish/dev/15753?do=post_view_threaded#15753 and I'm just wondering if anything has been done on that yet? If not I'll probably try to add it myself :) Best regards, -- Dmitry Panov From geoff at uplex.de Wed Feb 23 07:45:18 2011 From: geoff at uplex.de (Geoff Simmons) Date: Wed, 23 Feb 2011 08:45:18 +0100 Subject: Conditional requests to backend In-Reply-To: <4D6450DC.2050208@yahoo.co.uk> References: <4D6450DC.2050208@yahoo.co.uk> Message-ID: <369CDF13-F18E-4F1F-BA49-9937390E9776@uplex.de> The work is in progress, trying to have a patch ready to submit to the trunk within the week. Best, Geoff Sent from my iPad On Feb 23, 2011, at 1:12 AM, Dmitry Panov wrote: > Hi guys, > > I've found an earlier thread from this maillist: http://www.gossamer-threads.com/lists/varnish/dev/15753?do=post_view_threaded#15753 and I'm just wondering if anything has been done on that yet? > > If not I'll probably try to add it myself :) > > Best regards, > > -- > > Dmitry Panov > > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev From geoff at uplex.de Wed Feb 23 21:14:54 2011 From: geoff at uplex.de (Geoff Simmons) Date: Wed, 23 Feb 2011 22:14:54 +0100 Subject: If-Modified-Since In-Reply-To: References: <42834.1297973606@critter.freebsd.dk> <4D62A9C8.7050003@uplex.de> Message-ID: <4D6578CE.7070708@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/21/11 11:02 PM, Artur Bergman wrote: > > On Feb 21, 2011, at 10:07 AM, Geoff Simmons wrote: > >>> >>> ttl=0, grace=0 >>> This is a clear cut expiry, but we may still catch it before the >>> grim reaper does, we should explicity make sure we do not. >> >> OK, we don't have anything to check for this case, so in our current >> code it might in fact pick up such an object. All right, then we'll >> explicitly rule this out. > > Why? > > I might want to force a IMS to the backend without having ttl or > grace. You can set the conditional timeout to 0 if you really want it gone. My understanding of phk's point here is that setting both TTL and grace to 0 is a way of deciding in VCL to remove an object from the cache. Such an object will be evicted the next time the heap is re-organized. If you set obj.ttl = 0, then obj.grace is implicitly also set to 0, because this is expected to make the object no longer cacheable. If you don't want that, then you have to explicitly set a non-zero obj.grace. Setting obj.ttl = 0 is the basis for the sample VCL code in the Wiki for implementing a PURGE method. @phk: If we also implicitly set obj.conditional_timeout = 0 when obj.ttl is set to 0, wouldn't existing VCL continue to do what people expect? I think Sky has a point here, if conditional_timeout > 0 while TTL and grace are 0, it would mean that an object shouldn't be used for grace (another object is busy or the backend is sick), but could be used for IMS requests. If we're not breaking everyone's VCL, why not make that an option? Best, Geoff - -- UPLEX Systemoptimierung Schwanenwik 24 22087 Hamburg http://uplex.de/ Mob: +49-176-63690917 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNZXjNAAoJEOUwvh9pJNURHyoP/j7gOtgtd1r2BjjI7yKjI1Xj wpROBavXMQfHaLQLHnFWFMz9ceUsBgkRmg+jydl8K/WA8t/zPPVs8vT0wYUQuomg ZmndPwYSsEKFwTJ4mhreHJLTC17bGUy7Ied0bzs80YmSD5CDR19PVig4FT/U7Tew DfcNWe/6ZPiv4B6WKO5LBvduL3zCqzLVH2IMKrmm5UIuvWJigPfl//SREAcpefiT HdAA4iRCbIcnt314pAnxG9uHHtXG++S1PM2rEXCG6gvvXjsEvTjY0EHvqsFadotZ 3stELcKAB2jsoAdNpyB2swxy3AOVryLUVIHRWnY/ZA6IUiHXItg85KlSSO26RudT gLj8k78N89gkTCRe3Gp1nvaE8p5SwerLmwi6119Sdfpj/IelH1JZKBSfNpzH2Zbm A5VNU9uvDzScSWw4WDyVVOlB7l0k40q0Uhv/n0D5X1JvwaXojunPFPp96JACRmDD 6OGYwoLERz+sSiBlSjOc3cB5kru0ascRx0BqjtyaVACGWTL71bITCmW/gFjCkZAg Bk0Wcfk6YLdQnLGPnacnvHN9MsZp5ecoMUDW9a5/0xMhj3PLfvtLxQMk388zEsIz 6b6jMqN6xHmxPXKrqiZPO8d+maVVMVlgZbBnXZsoUYl4UCN7JK6cqm8mVTgkwmDc 9M6HgRRiQ6EC8rCfGJVy =syd/ -----END PGP SIGNATURE----- From phk at phk.freebsd.dk Thu Feb 24 08:59:31 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Feb 2011 08:59:31 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Wed, 23 Feb 2011 22:14:54 +0100." <4D6578CE.7070708@uplex.de> Message-ID: <51893.1298537971@critter.freebsd.dk> In message <4D6578CE.7070708 at uplex.de>, Geoff Simmons writes: >@phk: If we also implicitly set obj.conditional_timeout = 0 when obj.ttl >is set to 0, wouldn't existing VCL continue to do what people expect? Yes, I thought I had communicated that already: when ttl is set to <= zero, grace and conditional_timeout SHALL also be set to zero. -- 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 geoff at uplex.de Thu Feb 24 10:06:28 2011 From: geoff at uplex.de (Geoff Simmons) Date: Thu, 24 Feb 2011 11:06:28 +0100 Subject: If-Modified-Since In-Reply-To: <51893.1298537971@critter.freebsd.dk> References: <51893.1298537971@critter.freebsd.dk> Message-ID: <4D662DA4.3030108@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/24/11 9:59 AM, Poul-Henning Kamp wrote: > In message <4D6578CE.7070708 at uplex.de>, Geoff Simmons writes: > >> @phk: If we also implicitly set obj.conditional_timeout = 0 when obj.ttl >> is set to 0, wouldn't existing VCL continue to do what people expect? > > Yes, I thought I had communicated that already: when ttl is set to <= zero, > grace and conditional_timeout SHALL also be set to zero. You did indeed. So then my question is, is there a disadvantage to allowing an object to be used for the IMS request if ttl and grace have both elapsed, but conditional_timeout has not yet? Someone might decide to set obj.ttl = 0 but then set obj.conditional_timeout to non-zero. Or the timers could just run out that way, if conditional_timeout > grace. In either case, nothing's happening that you wouldn't expect from the configuration, especially if by default conditional_timeout <= grace (you'd have to explicitly decide otherwise). So why not use such an object for an IMS attempt? Best, Geoff - -- UPLEX Systemoptimierung Schwanenwik 24 22087 Hamburg http://uplex.de/ Mob: +49-176-63690917 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNZi2jAAoJEOUwvh9pJNURVf4QAJ+DZ0IXRJNnyG9yskAP3cBS O7lhbmlsQcjVMdfg4ri1OFj4C/iUJPob23rB/uM5LTueW5GfHrM+x1JMh1CpTDAI HUqscpipCXj3XifgdziFVdzYBacbuv8JU4YVAqfcbbiejqDX3ZDt2JFRW+TSbqXc msmzNysqyDOgO/8tNOE5mmiLn7qLi2XNXB1Z0c1BiigpchdbYJT/wdraj3A1e7mn 44Fxe+0IOoK6jAGXPNsiunQCqUZXZ4wxr961opXuQmIyt35J9/e49l0wGoaqqdRx Qcq+wmjOFeZcQStGESRhjofAsMqfBo3GSeRWQtfQT9tBEUe5q4L//Q+kSvKPJZcF LdrdGWExuBq0DrUMVtl+joAv51AjtBGAPSIvYQOXFTmcx/8FMiRSZx70g/mZNa0V 446pUaalAkQ+JLtCe6wp01f8uMf4ETjnaGeyPb0sjRvvzOHlM+NfflahCYJ9gPpT XOiVcp8VEdvX5DP0iW0/Q/j0SiTkJKpSJ9O/CIXNiI6QfSneOeaoEf3PHdoW1DO8 9BuTGu5yf79Yzn5ss2qriLyIKYkDcH6esIv8TewJhoiLYgCwpbMi5krjs6tSVPp8 foiKKz/L8RyNZzfCGNEadp9lhoDSHwWGHaTTa3MNzJGEn04XaDAmNTmbMt/lFZh/ pq+UjebrJP+wJDAPeYhH =cZUY -----END PGP SIGNATURE----- From phk at phk.freebsd.dk Thu Feb 24 10:10:02 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Feb 2011 10:10:02 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Thu, 24 Feb 2011 11:06:28 +0100." <4D662DA4.3030108@uplex.de> Message-ID: <96840.1298542202@critter.freebsd.dk> In message <4D662DA4.3030108 at uplex.de>, Geoff Simmons writes: >On 2/24/11 9:59 AM, Poul-Henning Kamp wrote: >> In message <4D6578CE.7070708 at uplex.de>, Geoff Simmons writes: >> >>> @phk: If we also implicitly set obj.conditional_timeout = 0 when obj.ttl >>> is set to 0, wouldn't existing VCL continue to do what people expect? >> >> Yes, I thought I had communicated that already: when ttl is set to <= zero, >> grace and conditional_timeout SHALL also be set to zero. > >You did indeed. So then my question is, is there a disadvantage to >allowing an object to be used for the IMS request if ttl and grace have >both elapsed, but conditional_timeout has not yet? yes, we don't know why it was expired. Imagine a PHP error causing an object to be mis-rendered. This is discovered, the bug fixed, the object purged. Now, if you use the cached object for IMS, the backend is unlikely to know about the implications of the changed PHP file, and will just look at the timestamp and say "Sure, you can use that..." Expiry in Varnish is final, unless the user tells us otherwise. Similarly, we will not use a ban'ed object for grace or ims. -- 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 geoff at uplex.de Thu Feb 24 15:32:20 2011 From: geoff at uplex.de (Geoff Simmons) Date: Thu, 24 Feb 2011 16:32:20 +0100 Subject: If-Modified-Since In-Reply-To: <96840.1298542202@critter.freebsd.dk> References: <96840.1298542202@critter.freebsd.dk> Message-ID: <4D667A04.4070704@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/24/11 11:10 AM, Poul-Henning Kamp wrote: > In message <4D662DA4.3030108 at uplex.de>, Geoff Simmons writes: > >> On 2/24/11 9:59 AM, Poul-Henning Kamp wrote: >>> In message <4D6578CE.7070708 at uplex.de>, Geoff Simmons writes: >>> >>>> @phk: If we also implicitly set obj.conditional_timeout = 0 when obj.ttl >>>> is set to 0, wouldn't existing VCL continue to do what people expect? >>> >>> Yes, I thought I had communicated that already: when ttl is set to <= zero, >>> grace and conditional_timeout SHALL also be set to zero. >> >> You did indeed. So then my question is, is there a disadvantage to >> allowing an object to be used for the IMS request if ttl and grace have >> both elapsed, but conditional_timeout has not yet? > > yes, we don't know why it was expired. To follow up for the list, we continued the discussion on IRC, and Poul-Henning wants to be sure that if a ban has been requested for an object, either with one of the purge commands or by setting obj.ttl=0 in VCL, then it is expired and not used, regardless of the value of conditional_timeout. @phk: One more question. %^) We could do this by checking whether obj.ttl was set to 0, or whether obj.ttl+obj.grace has elapsed. (We're always passing over any object with a ban.) In other words, we could reject the object if the expiration was specifically requested, but otherwise use it if grace has not yet elapsed and there's still time left for conditional_timeout; or we could reject it if grace has elapsed for any reason. In the first case, we would reject the object for IMS if: o->ttl <= sp->t_req && HSH_Grace(o->grace) <= 0 In the second case, we reject it if: o->ttl + HSH_Grace(o->grace) <= sp->t_req In the second case, there's actually no point in having obj.conditional_timeout > obj.grace; an object is evicted when grace elapses, no matter what. In that case, we should *not* do something we were talking about last week: > - the cache eviction time for an object (oc->timer_when) becomes > o->ttl + max(o->conditional_timeout, HSH_Grace(o->grace)) If eviction is only controlled by ttl and grace, then this should stay the way it is now (oc->timer_when = o->ttl + HSH_Grace(o->grace)). Best, Geoff - -- UPLEX Systemoptimierung Schwanenwik 24 22087 Hamburg http://uplex.de/ Mob: +49-176-63690917 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNZnoDAAoJEOUwvh9pJNURHLwQAINOkjg9OgXIxGLxufMBqcgY ++udavdBucBG24OSRv8L3gs7e7IkddI4u4mBY6T1/DlhN6KwXRWGSOlax7gD4boa twG1qiAQSDtKfpV6e1ouDzjqAyu+EDfWyjT7L4fGOdWY5dsz9UkWEBgY9/OdGUv4 yOLq2lzZ+lWxFQ6iS3KlhcolsvmWJ8GD5aLcyxLZuYNulYPyTQVbqaUCrQYhCpS+ BMZOP1OVPI8BaXjR4vp0+n0DscayKoZbKe71/9qFB+8BJzHs4DBk/Q3U01FSowCp xukZXG+Tj+YNXFpbHBLaVxJkIiHw4O9t3pC26o9THEWfcfpHNzArJe7xfrB3OV5w 5PrXYHJWUfsijK3D3FlgGpYCoHqQQ1vv61So/1yVQGA2mOIgleu7lvPAWOCvvAkF qg6r2w+1qT6C+I6zm5GsoM+k+mzHD/HVfrJUIcRosMP28oDomtyJy+AZzUnDkbYL JUfV8vCHc0yjvH/M/fuS7wOiy2ESUWFm/11zWqiQQq7WvZqJsS278yg1hirtu4Ry 7QeUJIJNyHJBdKEP8F+fr0Ner8yXDWrCzMBcAPC70KLeVthlLYkmqhlJI77x24Bg MDbUm7P++HQ5cNntVhZkjnRaVVJK/9GjnQ8zyhibZ3x7GjtvTh4FRwMdBuGBmt6N SK+xmP8+rEkx80aAPY8J =TqZr -----END PGP SIGNATURE----- From phk at phk.freebsd.dk Thu Feb 24 17:34:54 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Feb 2011 17:34:54 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Thu, 24 Feb 2011 16:32:20 +0100." <4D667A04.4070704@uplex.de> Message-ID: <3255.1298568894@critter.freebsd.dk> In message <4D667A04.4070704 at uplex.de>, Geoff Simmons writes: >In the second case, there's actually no point in having >obj.conditional_timeout > obj.grace; an object is evicted when grace >elapses, no matter what. In that case, we should *not* do something we >were talking about last week: > >> - the cache eviction time for an object (oc->timer_when) becomes >> o->ttl + max(o->conditional_timeout, HSH_Grace(o->grace)) I still think we should do it this way. If people want conditionnal_timeout == grace they can set them that way. But having them separate allows us to define additional policies, where objects can linger for longer in the hope they are reused. -- 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 sky at crucially.net Thu Feb 24 18:37:01 2011 From: sky at crucially.net (Artur Bergman) Date: Thu, 24 Feb 2011 10:37:01 -0800 Subject: If-Modified-Since In-Reply-To: <3255.1298568894@critter.freebsd.dk> References: <3255.1298568894@critter.freebsd.dk> Message-ID: If someone does set obj.ttl = 0s; set obj.grace = 0s; set obj.conditional_timeout = 60s; what will happen? artur On Feb 24, 2011, at 9:34 AM, Poul-Henning Kamp wrote: > In message <4D667A04.4070704 at uplex.de>, Geoff Simmons writes: > >> In the second case, there's actually no point in having >> obj.conditional_timeout > obj.grace; an object is evicted when grace >> elapses, no matter what. In that case, we should *not* do something we >> were talking about last week: >> >>> - the cache eviction time for an object (oc->timer_when) becomes >>> o->ttl + max(o->conditional_timeout, HSH_Grace(o->grace)) > > I still think we should do it this way. If people want > conditionnal_timeout == grace > they can set them that way. > > But having them separate allows us to define additional policies, > where objects can linger for longer in the hope they are reused. > > > -- > 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 Feb 24 18:53:55 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Feb 2011 18:53:55 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Thu, 24 Feb 2011 10:37:01 PST." Message-ID: <3714.1298573635@critter.freebsd.dk> In message , Artur Bergman writes: >If someone does > >set obj.ttl = 0s; >set obj.grace = 0s; >set obj.conditional_timeout = 60s; > >what will happen? The object will not be served any more, but for the next 60 seconds it is a candidate for IMS, after 60 seconds, it will be removed. It is enough to say: set obj.ttl = 0s; set obj.conditional_timeout = 60s; obj.grace (and obj.conditional_timeout) are automatically zeroed when you zero obj.ttl -- 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 sky at crucially.net Thu Feb 24 18:59:28 2011 From: sky at crucially.net (Artur Bergman) Date: Thu, 24 Feb 2011 10:59:28 -0800 Subject: If-Modified-Since In-Reply-To: <3714.1298573635@critter.freebsd.dk> References: <3714.1298573635@critter.freebsd.dk> Message-ID: <6AED8647-3EF1-48C9-8A69-5B118C9A5313@crucially.net> On Feb 24, 2011, at 10:53 AM, Poul-Henning Kamp wrote: > In message , Artur Bergman > writes: >> If someone does >> >> set obj.ttl = 0s; >> set obj.grace = 0s; >> set obj.conditional_timeout = 60s; >> >> what will happen? > > The object will not be served any more, but for the next 60 seconds > it is a candidate for IMS, after 60 seconds, it will be removed. Ok, that is precisely what I hoped for! Thanks Artur