From varnish-bugs at projects.linpro.no Sat Mar 1 19:14:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 01 Mar 2008 19:14:04 -0000 Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a patch provided In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> Message-ID: <064.47b4f92723328f29d8794e42c70fd10a@projects.linpro.no> #202: Compile Fails on OpenBSD -current / Half a patch provided -----------------------+---------------------------------------------------- Reporter: bonetruck | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 1.2 Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Comment (by bonetruck): I haven't tried porting the math.h stuffs from FreeBSD. My guess is if the core team hasn't already done so, it's beyond me... Regardless, I did append the following to bin/varnishd/cache.h #ifndef NAN #define NAN (0.0/0.0) #endif then proceeded to compile successfully on a Netra T1 running sparc64 OpenBSD-4.3-beta. Haven't tried running it though. Next step is to flesh out a port of 1.1.2 with the two patches and try running it. Later I would like to try -trunk. I will have to figure out all the autoconf stuff though. Might be helpful to add those instructions to the debugging page on your wiki to facilitate other people helping with the toolset slowing them down. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 1 19:15:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 01 Mar 2008 19:15:14 -0000 Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a patch provided In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> Message-ID: <064.1315414c5d90465f8ad55c1daa73c978@projects.linpro.no> #202: Compile Fails on OpenBSD -current / Half a patch provided -----------------------+---------------------------------------------------- Reporter: bonetruck | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 1.2 Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Comment (by bonetruck): FYI, the wrapping got hosed on the #ifndef, #define, #endif in my previous post. I trust you can get my drift. ;-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 1 20:30:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 01 Mar 2008 20:30:16 -0000 Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a patch provided In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> Message-ID: <064.d8672081e14e58ff48feba1bbd859377@projects.linpro.no> #202: Compile Fails on OpenBSD -current / Half a patch provided -----------------------+---------------------------------------------------- Reporter: bonetruck | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 1.2 Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Comment (by phk): Please test-run that patch, It would not help us if it takes an exception when it does the divide. You might be better off defining NAN as a "magic" number like 3.141592e-23 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 3 10:49:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 03 Mar 2008 10:49:07 -0000 Subject: [Varnish] #197: HTTP/1.0 query return no content In-Reply-To: <051.fc35504a2f711886fdf4302b5c601a42@projects.linpro.no> References: <051.fc35504a2f711886fdf4302b5c601a42@projects.linpro.no> Message-ID: <060.c38821e0ecef72f0cdc26f4595c0fcf9@projects.linpro.no> #197: HTTP/1.0 query return no content ----------------------+----------------------------------------------------- Reporter: chr79 | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: closed => reopened * resolution: fixed => Comment: Not fixed in 1.1 nor 1.2. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 3 11:16:59 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 03 Mar 2008 11:16:59 -0000 Subject: [Varnish] #197: HTTP/1.0 query return no content In-Reply-To: <051.fc35504a2f711886fdf4302b5c601a42@projects.linpro.no> References: <051.fc35504a2f711886fdf4302b5c601a42@projects.linpro.no> Message-ID: <060.1699283a041995551686fd341e7489f0@projects.linpro.no> #197: HTTP/1.0 query return no content ----------------------+----------------------------------------------------- Reporter: chr79 | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: reopened => closed * resolution: => fixed Comment: Fixed in trunk with r2091 (before 1.2 was branched) and in 1.1 with r2545. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 8 18:49:26 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Mar 2008 18:49:26 -0000 Subject: [Varnish] #188: thread pileup In-Reply-To: <054.501398c9432dffc43debd3778be2327e@projects.linpro.no> References: <054.501398c9432dffc43debd3778be2327e@projects.linpro.no> Message-ID: <063.106f39d2dd35a319f16708074ca57fec@projects.linpro.no> #188: thread pileup ----------------------+----------------------------------------------------- Reporter: steinove | Owner: phk Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.1.1 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by akv): I still see this problem. I created a script that several times a second checks the load of the machine, if it rises over 2 it restarts varnish. This keeps us up and running, but it's an ugly hack :) /Anders -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 10 09:13:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Mar 2008 09:13:04 -0000 Subject: [Varnish] #216: String concatenation in functions Message-ID: <051.d8162fcb19c67b07da17c0349a8c725c@projects.linpro.no> #216: String concatenation in functions ----------------------+----------------------------------------------------- Reporter: teddy | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- As according to DES, string concatenation seems to be working only in assignments and not in functions. An example of when this is wanted:[[BR]] purge_hash(req.url "#" req.http.host "#"); Throws:[[BR]] Expected ')' got '"#"', -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Mar 11 22:38:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 11 Mar 2008 22:38:17 -0000 Subject: [Varnish] #217: varnishtop freeze Message-ID: <049.a5bcd9b08e2b26a91152e804621bfcd7@projects.linpro.no> #217: varnishtop freeze ------------------------+--------------------------------------------------- Reporter: akv | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- varnishtop -i VCL_return uses 100% cpu. It can't be stopped with ctrl-c but needs to be killed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Mar 12 11:13:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 12 Mar 2008 11:13:17 -0000 Subject: [Varnish] #218: ACL matching needs IPv6 support Message-ID: <052.5c90c1ec7e1b5eef0e43290b275cf225@projects.linpro.no> #218: ACL matching needs IPv6 support -------------------------+-------------------------------------------------- Reporter: hucker | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Keywords: ipv6 acl -------------------------+-------------------------------------------------- ACL matching from cache_vrt_acl.c currently does not handle IPv6 addresses. As more networks start using IPv6, this would be a useful addition. -- Ticket URL: Varnish The Varnish HTTP Accelerator From andre.ease at 163.com Mon Mar 10 02:49:35 2008 From: andre.ease at 163.com (andre.ease) Date: Mon, 10 Mar 2008 10:49:35 +0800 (CST) Subject: pid 29779 (varnishd), uid 65534: exited on signal 11 Message-ID: <20600078.666731205117375494.JavaMail.coremail@bj163app38.163.com> HI ALL: My varnish ran on FreeBSD7, and i used dmesg see lots of message like these "pid xxxx(varnishd), uid 65534: exited on signal 11", then the mgr-vanishd exit on signal 6. Used GDB i found these: [Thread 0xa84419650 (LWP 100874) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xa83404090 (LWP 100648)] vbe_sock_conn (ai=0x0) at cache_backend.c:162 162 s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); (gdb) bt #0 vbe_sock_conn (ai=0x0) at cache_backend.c:162 #1 0x0000000000408c05 in VBE_GetFd (sp=0xa856bd008) at cache_backend.c:190 #2 0x000000000040b0b2 in Fetch (sp=0xa856bd008) at cache_fetch.c:278 #3 0x0000000000409851 in CNT_Session (sp=0xa856bd008) at cache_center.c:300 #4 0x0000000000410e81 in wrk_do_one (w=0x7fffc1208ad0) at cache_pool.c:194 #5 0x00000000004110ae in wrk_thread (priv=Variable "priv" is not available. ) at cache_pool.c:248 #6 0x0000000800a83a88 in pthread_getprio () from /lib/libthr.so.3 #7 0x0000000000000000 in ?? () Error accessing memory address 0x7fffc120b000: Bad address. (gdb) The ai pointed to NULL, and process exited. Any idea, thanks~~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at projects.linpro.no Wed Mar 12 22:02:28 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 12 Mar 2008 22:02:28 -0000 Subject: [Varnish] #219: Overflow when calculating remaining disk space on big disk (32 bits server) Message-ID: <054.0a73771b24e0a77c48efe47a3dc4b7a1@projects.linpro.no> #219: Overflow when calculating remaining disk space on big disk (32 bits server) ----------------------+----------------------------------------------------- Reporter: pcarrier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: overflow ondisk disk space remaining ----------------------+----------------------------------------------------- Varnishd seem to exhibite some kind of an overflow when calculating remaining disk space at startup. More precisely, when it create the on disk cache file. # '''df''' [[BR]] Filesystem 1K-blocks Used Available Use% Mounted on[[BR]] /dev/sda1 238656420 29305924 197227448 13% / [[BR]] # '''df -h'''[[BR]] Filesystem Size Used Avail Use% Mounted on[[BR]] /dev/sda1 228G 28G 189G 13%[[BR]] # ''' varnishd -f /etc/varnish/minimum.vcl -s file,/var/lib/varnish/varnish_cache_file,256M''' [[BR]] WARNING: storage file size reduced to 77925580 (80% of available disk space)file /var/lib/varnish/varnish_cache_file size 77922304 bytes (19053 fs-blocks, 19053 pages)[[BR]] Strong indicator of the overflow theory: # '''dd if=/dev/zero of=/test bs=1M count=1500'''[[BR]] [[...]][[BR]] # '''rm /var/lib/varnish/varnish_cache_file''' [[BR]] # '''varnishd -f /etc/varnish/minimum.vcl -s file,/var/lib/varnish/varnish_cache_file,256M''' [[BR]] file /var/lib/varnish/varnish_cache_file size 268435456 bytes (65536 fs- blocks, 65536 pages) Using old SHMFILE[[BR]] # '''df'''[[BR]] /dev/sda1 238656420 30843452 195689920 14% /[[BR]] [[...]][[BR]] Version used: 1.1.2, official release, compiled with defaults options on a 32 bits Debian 4.0 [[BR]] Reproducibles: yes [[BR]] Step to reproduce: start varnish with "-s file,/file.cache,256M" on a disk with 197227568 KB free with the cache file not already created[[BR]] Temporary fix: create your cache file with `dd` -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 13 17:49:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 13 Mar 2008 17:49:58 -0000 Subject: [Varnish] #220: varnishtop segfaults Message-ID: <049.46ec2aa69c7071bdb978c4c5876a4d4c@projects.linpro.no> #220: varnishtop segfaults ------------------------+--------------------------------------------------- Reporter: akv | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- When using varnishtop on a 2500hit/s server, it crashes every time after a minute or so... http://lnxbx.dk/~akv/varnishtop_segfault_1.png http://pastebin.com/m616f8544 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 13 19:43:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 13 Mar 2008 19:43:48 -0000 Subject: [Varnish] #220: varnishtop segfaults In-Reply-To: <049.46ec2aa69c7071bdb978c4c5876a4d4c@projects.linpro.no> References: <049.46ec2aa69c7071bdb978c4c5876a4d4c@projects.linpro.no> Message-ID: <058.6c1bfd6f2b8c3bbf2678dd401ccf3e35@projects.linpro.no> #220: varnishtop segfaults ------------------------+--------------------------------------------------- Reporter: akv | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by phk): It may simply not be able to keep up, try running varnishd a larger size shmlog file (-l argument) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 14 19:18:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 14 Mar 2008 19:18:23 -0000 Subject: [Varnish] #221: Add a link for mod_extract_forwarded to FAQ Message-ID: <051.432c340d6e11a4a159772edb0bee1ce9@projects.linpro.no> #221: Add a link for mod_extract_forwarded to FAQ ---------------------------+------------------------------------------------ Reporter: nejko | Owner: des Type: documentation | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Keywords: ---------------------------+------------------------------------------------ It might be a good idea to add a link to mod_extract_forwarded for Apache 2.0* to the answer to the question "How can I log the client IP address on the backend?": http://www.openinfo.co.uk/apache/index.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 14 23:58:51 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 14 Mar 2008 23:58:51 -0000 Subject: [Varnish] #222: On Solaris, request is not sent to the backend and varnish reports 503 Message-ID: <050.ca6dba8e263646410802591b85306447@projects.linpro.no> #222: On Solaris, request is not sent to the backend and varnish reports 503 --------------------+------------------------------------------------------- Reporter: jyri | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: major | Keywords: --------------------+------------------------------------------------------- Compiled varnish on Solaris (from trunk, currently @r2605) and I see it doesn't send any request traffic to the backend server (no network traffic generated) and it just comes back with a 503 error. Problem turned out to be that WRK_Flush() attempts to writev() more than IOV_MAX elements, which fails (unlike glibc, in Solaris that's a hard limit). The root cause is that in cache.h where MAX_IOVS is defined, it checks #if (IOV_MAX < (HTTP_HDR_MAX * 2)) but at this point HTTP_HDR_MAX isn't yet defined, so unless IOV_MAX is < 0, that's never true ;-) Attached is a patch that defines a HTTP_HDR_MAX_VAL so it is available to the preprocessor. With this change, MAX_IOVS gets set compatibly on Solaris and requests now make it to the backend server. As an aside, this wasn't immediately obvious because WRK_Flush() doesn't check for error (-1) from writev. I didn't touch this part in the attached patch yet, but would like to suggest some error logging at that point, if (i != w->liov) { w->werr++; if (i < 0) { ...log write error... } } Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Mar 16 14:12:40 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 16 Mar 2008 14:12:40 -0000 Subject: [Varnish] #222: On Solaris, request is not sent to the backend and varnish reports 503 In-Reply-To: <050.ca6dba8e263646410802591b85306447@projects.linpro.no> References: <050.ca6dba8e263646410802591b85306447@projects.linpro.no> Message-ID: <059.da18323b01b68fdac714a4ed81b28be5@projects.linpro.no> #222: On Solaris, request is not sent to the backend and varnish reports 503 --------------------+------------------------------------------------------- Reporter: jyri | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by des): * status: new => assigned Comment: Committed to trunk as r2606. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Mar 18 09:54:09 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 18 Mar 2008 09:54:09 -0000 Subject: [Varnish] #135: default.vcl out of sync In-Reply-To: <052.c196e75db5c13b3f37ec0b3a55dd4ad7@projects.linpro.no> References: <052.c196e75db5c13b3f37ec0b3a55dd4ad7@projects.linpro.no> Message-ID: <061.8b6e76e661f6488ace3eac8587f60b17@projects.linpro.no> #135: default.vcl out of sync ---------------------------+------------------------------------------------ Reporter: anders | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: documentation | Version: 1.1 Severity: normal | Resolution: Keywords: default.vcl | ---------------------------+------------------------------------------------ Changes (by ay): * status: closed => reopened * resolution: fixed => Comment: Both default.vcl and manpage is out of sync with mgt_vcc.c -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Mar 18 22:10:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 18 Mar 2008 22:10:47 -0000 Subject: [Varnish] #223: fixed redhat varnishlog init script and added one for varnishncsa Message-ID: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> #223: fixed redhat varnishlog init script and added one for varnishncsa -----------------------+---------------------------------------------------- Reporter: hillct | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: packaging | Version: trunk Severity: normal | Keywords: varnishlog varnishncsa redhat -----------------------+---------------------------------------------------- The redhat init script for varnishlog was calling the init shell script functions with improper args. The attached patch corrects these errors as well as adds an init script for varnishncsa in case the user wants to directly generate ncsa-style logs for persing. Associated additions to varnish.logrotate, Makefile.in and varnish.spec. The attached patch has been tested on Fedora Core 8 and is consistant with Centos/RHEL4. It's probably appropriate to be merged from Trunk into the 1.1.2 branch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Mar 18 22:18:02 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 18 Mar 2008 22:18:02 -0000 Subject: [Varnish] #223: fixed redhat varnishlog init script and added one for varnishncsa In-Reply-To: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> References: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> Message-ID: <061.66d7c4cb76615e6483e69cadeaf40df8@projects.linpro.no> #223: fixed redhat varnishlog init script and added one for varnishncsa -------------------------------------------+-------------------------------- Reporter: hillct | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: packaging | Version: trunk Severity: normal | Resolution: Keywords: varnishlog varnishncsa redhat | -------------------------------------------+-------------------------------- Comment (by hillct): To be clear, the previous version of varnishlog.initrc was non-functional on Fedora Core 8 and Centos/RHEL4 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 24 04:27:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 24 Mar 2008 04:27:41 -0000 Subject: [Varnish] #191: Varnish won't cache if apache keepalive is set to on In-Reply-To: <057.afbf7964f5f8580f04cb9d3e7d90da6b@projects.linpro.no> References: <057.afbf7964f5f8580f04cb9d3e7d90da6b@projects.linpro.no> Message-ID: <066.329394e304b14a200c4c533284534d6f@projects.linpro.no> #191: Varnish won't cache if apache keepalive is set to on -------------------------+-------------------------------------------------- Reporter: michael.lee | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 1.1.1 Severity: normal | Resolution: Keywords: keepalive | -------------------------+-------------------------------------------------- Comment (by victori): Replying to [comment:1 des]: > You haven't provided nearly enough information to debug this issue. At the very least, full logs from the working and non-working case are needed. I can confirm this bug is real. I am using nginx behind varnish which proxies for jetty. If keep alives are enabled on nginx varnish refuses to cache dynamic content. So my setup is, varnish (80) -> nginx (8060) -> jetty (8080) , If keep alives are enabled on nginx caching with varnish is random, I still see resource requests get through down to jetty. The crazy thing is I did not see any "misses" for those files in varnishlog. -Victor -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Mar 26 14:08:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Mar 2008 14:08:49 -0000 Subject: [Varnish] #224: Improved logging Message-ID: <049.b840548eba4d9d14102064bf6f789678@projects.linpro.no> #224: Improved logging -------------------------+-------------------------------------------------- Reporter: des | Owner: des Type: enhancement | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Backend requests should have their own transaction ID instead of reusing that of the client request that triggered them. {{{ReqStart}}} and {{{ReqEnd}}} lines should be generated for backend requests as well as client requests. Every log line should be tagged with the XID of the request it belongs to, or 0 if it's not directly related to a request. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 31 22:09:27 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 31 Mar 2008 22:09:27 -0000 Subject: [Varnish] #225: VCL: Allow "Expires" time to be easily specified / calculated Message-ID: <055.0cde52996ac6ba2ef45b86c02b1cf8be@projects.linpro.no> #225: VCL: Allow "Expires" time to be easily specified / calculated -------------------------+-------------------------------------------------- Reporter: cyberduck | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- In some situations it would make sense to alter or set an "Expires: " entry in the header to alter how browsers will cache objects. Currently this is not possible because there is no way of calculating Expires timestamps from VCL. A workaround that in limited testing seems to work (using C) is : C{ #include char l_str_buf[64]; time_t l_expire = time(NULL)+(60*15); /* Expire after 15 minutes */ size_t l_retval = strftime(l_str_buf, 64, "%a, %d %b %Y %H:%M:%S GMT", gmtime(&l_expire) ); if (l_retval) { VRT_SetHdr(sp, HDR_OBJ, "\010Expires:", l_str_buf, 0); } }C -- Ticket URL: Varnish The Varnish HTTP Accelerator