From varnish-bugs at projects.linpro.no Sun Feb 1 20:23:38 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 01 Feb 2009 20:23:38 -0000 Subject: [Varnish] #432: Multiple lines of Set-Cookie in response headers aren't reflected in obj.http.Set-Cookie Message-ID: <053.1462d71fa5ff32c1ceb5a5db8975f3dc@projects.linpro.no> #432: Multiple lines of Set-Cookie in response headers aren't reflected in obj.http.Set-Cookie ----------------------+----------------------------------------------------- Reporter: Mitchua | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: Set-Cookie ----------------------+----------------------------------------------------- My backend server returns headers like this: HTTP/1.1?200?OK(CR)(LF)[[BR]] Connection:?close(CR)(LF)[[BR]] Date:?Sun,?01?Feb?2009?20:19:18?GMT(CR)(LF)[[BR]] Server:?Microsoft-IIS/6.0(CR)(LF)[[BR]] X-Powered-By:?ASP.NET(CR)(LF)[[BR]] X-AspNet-Version:?2.0.50727(CR)(LF)[[BR]] Set- Cookie:?ASP.NET_SessionId=6js5wg45dby44ujan0de1zit;?path=/;?HttpOnly(CR)(LF)[[BR]] Set-Cookie:?ThreadId=2688;?path=/(CR)(LF)[[BR]] Set- Cookie:?Invite=;?expires=Fri,?30-Jan-2009?20:19:18?GMT;?path=/(CR)(LF)[[BR]] Cache-Control:?no-cache(CR)(LF)[[BR]] Pragma:?no-cache(CR)(LF)[[BR]] Expires:?-1(CR)(LF)[[BR]] Content-Type:?text/html;?charset=utf-8(CR)(LF)[[BR]] Content-Length:?17739(CR)(LF)[[BR]] (CR)(LF)[[BR]] Note that there are 3 cookies being set on 3 Set-Cookie headers. I would like to remove the ASP.NET_SessionId cookie, but keep the others. I found the regsub technique from http://varnish.projects.linpro.no/wiki/VCLExampleRemovingSomeCookies to be helpful, but obj.http.Set-Cookie only appears to have the first cookie in it i.e. everything before the first carriage-return. All other Set-Cookie headers are removed if I do a "set obj.http.Set-Cookie". It looks like it might be a bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 3 14:19:06 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 03 Feb 2009 14:19:06 -0000 Subject: [Varnish] #433: crashes in ESI parsing Message-ID: <054.1a851799d77a8c88d306505c05a1f0be@projects.linpro.no> #433: crashes in ESI parsing ----------------------+----------------------------------------------------- Reporter: nicholas | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- When enabling esi parsing varnish crashes frequently with a panic message: Feb 3 13:19:07 rabbla varnishd\[20240\]: Child (21744) Panic message: Assert error in VRT_ESI(), cache_vrt_esi.c line 761: Condition(q == ew->t.e) not true. coredumps and debug information available. -nicholas -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 3 14:59:49 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 03 Feb 2009 14:59:49 -0000 Subject: [Varnish] #433: crashes in ESI parsing In-Reply-To: <054.1a851799d77a8c88d306505c05a1f0be@projects.linpro.no> References: <054.1a851799d77a8c88d306505c05a1f0be@projects.linpro.no> Message-ID: <063.1d6a14e49c61f67451f63968e5645313@projects.linpro.no> #433: crashes in ESI parsing ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: This is a XML comment spanning two storage elements containing a '>'. The preparser stops at the '>' but the real parser expects '-->' and gives up, leading to the panic. The easy fix is not solid, as comments can be arbitrary length. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 3 21:51:22 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 03 Feb 2009 21:51:22 -0000 Subject: [Varnish] #433: crashes in ESI parsing In-Reply-To: <054.1a851799d77a8c88d306505c05a1f0be@projects.linpro.no> References: <054.1a851799d77a8c88d306505c05a1f0be@projects.linpro.no> Message-ID: <063.f9b24a43eb3d5e4ef2b6280d3632281f@projects.linpro.no> #433: crashes in ESI parsing ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r3575 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 3 22:40:12 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 03 Feb 2009 22:40:12 -0000 Subject: [Varnish] #434: Critbit crash: Assert error in hcb_delete Message-ID: <052.353eed9a394c1c1c65c805e20fcbf6b0@projects.linpro.no> #434: Critbit crash: Assert error in hcb_delete ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Running Varnish trunk/3534 in FreeBSD/amd64 7.1-RELEASE, I got: {{{ Feb 3 22:33:00 cache2 varnishd[15978]: Child (15979) Panic message: Assert error in hcb_delete(), hash_critbit.c line 266: Condition(hcb_is_y(*p)) not true. thread = (cache-timeout) }}} Unfortunately, I have no core-dump. :( -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 4 09:06:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 04 Feb 2009 09:06:43 -0000 Subject: [Varnish] #428: Sending badly formed parameters to the management console kills Varnish In-Reply-To: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> References: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> Message-ID: <061.0e47b48b3db036d56e3c4117026966b9@projects.linpro.no> #428: Sending badly formed parameters to the management console kills Varnish ----------------------+----------------------------------------------------- Reporter: petter | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > While working on the web gui, I suddenly made Varnish die when sending > bad input to the management port. Here is the backtrace > > [Switching to Thread 0xb7de36b0 (LWP 23570)] > 0x08050b88 in VCA_tweak_acceptor (cli=0xb7c0c628, arg=0xb7c05210 > "HASH(0x8839c4c)") at cache_acceptor.c:371 > 371 for (i = 0; vca_acceptors[i]->name; i++) { > (gdb) bt > #0 0x08050b88 in VCA_tweak_acceptor (cli=0xb7c0c628, arg=0xb7c05210 > "HASH(0x8839c4c)") at cache_acceptor.c:371 > #1 0x0807d3c3 in tweak_acceptor (cli=0xb7c0c628, par=0x809bb3c, > arg=0xb7c05210 "HASH(0x8839c4c)") at mgt_param.c:421 > #2 0x0807d843 in MCF_ParamSet (cli=0xb7c0c628, param=0xb7c05200 > "acceptor", val=0xb7c05210 "HASH(0x8839c4c)") > at mgt_param.c:860 > #3 0x0807d8fa in mcf_param_set (cli=0xb7c0c628, av=0xb7c2e140, priv=0x0) > at mgt_param.c:884 > #4 0xb7fc8652 in cli_dispatch (cli=0xb7c0c628, clp=0x80a1d60, > line=0xb7c79000 "param.set acceptor HASH(0x8839c4c)") > at cli.c:133 > #5 0x0807b706 in mgt_cli_vlu (priv=0xb7c0c610, p=0xb7c79000 "param.set > acceptor HASH(0x8839c4c)") at mgt_cli.c:252 > #6 0xb7fcbda0 in LineUpProcess (l=0xb7c071e0) at vlu.c:97 > #7 0xb7fcbf9b in VLU_Fd (fd=9, l=0xb7c071e0) at vlu.c:122 > #8 0x0807bce7 in mgt_cli_callback (e=0xb7c76290, what=1) at > mgt_cli.c:347 > #9 0xb7fcba9f in vev_schedule_one (evb=0xb7c0c5b0) at vev.c:500 > #10 0xb7fcb2b6 in vev_schedule (evb=0xb7c0c5b0) at vev.c:365 > #11 0x0807a0e3 in mgt_run (dflag=0, T_arg=0xbfce8745 ":9002") at > mgt_child.c:560 > #12 0x080870d2 in main (argc=0, argv=0xbfce6a84) at varnishd.c:639 New description: While working on the web gui, I suddenly made Varnish die when sending bad input to the management port. Here is the backtrace {{{ [Switching to Thread 0xb7de36b0 (LWP 23570)] 0x08050b88 in VCA_tweak_acceptor (cli=0xb7c0c628, arg=0xb7c05210 "HASH(0x8839c4c)") at cache_acceptor.c:371 371 for (i = 0; vca_acceptors[i]->name; i++) { (gdb) bt #0 0x08050b88 in VCA_tweak_acceptor (cli=0xb7c0c628, arg=0xb7c05210 "HASH(0x8839c4c)") at cache_acceptor.c:371 #1 0x0807d3c3 in tweak_acceptor (cli=0xb7c0c628, par=0x809bb3c, arg=0xb7c05210 "HASH(0x8839c4c)") at mgt_param.c:421 #2 0x0807d843 in MCF_ParamSet (cli=0xb7c0c628, param=0xb7c05200 "acceptor", val=0xb7c05210 "HASH(0x8839c4c)") at mgt_param.c:860 #3 0x0807d8fa in mcf_param_set (cli=0xb7c0c628, av=0xb7c2e140, priv=0x0) at mgt_param.c:884 #4 0xb7fc8652 in cli_dispatch (cli=0xb7c0c628, clp=0x80a1d60, line=0xb7c79000 "param.set acceptor HASH(0x8839c4c)") at cli.c:133 #5 0x0807b706 in mgt_cli_vlu (priv=0xb7c0c610, p=0xb7c79000 "param.set acceptor HASH(0x8839c4c)") at mgt_cli.c:252 #6 0xb7fcbda0 in LineUpProcess (l=0xb7c071e0) at vlu.c:97 #7 0xb7fcbf9b in VLU_Fd (fd=9, l=0xb7c071e0) at vlu.c:122 #8 0x0807bce7 in mgt_cli_callback (e=0xb7c76290, what=1) at mgt_cli.c:347 #9 0xb7fcba9f in vev_schedule_one (evb=0xb7c0c5b0) at vev.c:500 #10 0xb7fcb2b6 in vev_schedule (evb=0xb7c0c5b0) at vev.c:365 #11 0x0807a0e3 in mgt_run (dflag=0, T_arg=0xbfce8745 ":9002") at mgt_child.c:560 #12 0x080870d2 in main (argc=0, argv=0xbfce6a84) at varnishd.c:639 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 4 09:19:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 04 Feb 2009 09:19:19 -0000 Subject: [Varnish] #428: Sending badly formed parameters to the management console kills Varnish In-Reply-To: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> References: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> Message-ID: <061.91e404ea5a2924d4a055b8c170e45732@projects.linpro.no> #428: Sending badly formed parameters to the management console kills Varnish ----------------------+----------------------------------------------------- Reporter: petter | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Do you have any idea what you sent on the CLI ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 4 21:24:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 04 Feb 2009 21:24:56 -0000 Subject: [Varnish] #435: Expose -n to VCL Message-ID: <049.f988b0c545d2a86bc1db75f0765a1023@projects.linpro.no> #435: Expose -n to VCL --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Expose the instance name to vcl as server.name -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 5 02:26:59 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Feb 2009 02:26:59 -0000 Subject: [Varnish] #436: 2.0.2 crashes on os X with default configuration Message-ID: <053.de24599fd2dfd02431a96c17d161db8a@projects.linpro.no> #436: 2.0.2 crashes on os X with default configuration ---------------------+------------------------------------------------------ Reporter: josh3io | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ This happens when I install from macports or build from source. {{{ sudo /opt/local/sbin/varnishd -a *:80 -u nobody -T 88 -f /opt/local/etc/varnish/default.vcl storage_file: filename: ./varnish.HAcsnR (unlinked) size 226 MB. Using old SHMFILE }}} messages log: {{{ 2/4/09 6:23:49 PM sudo[97583] jgoldberg : TTY=ttys001 ; PWD=/opt/local/etc/varnish ; USER=root ; COMMAND=/opt/local/sbin/varnishd -a *:80 -u nobody -T 88 -f /opt/local/etc/varnish/default.vcl 2/4/09 6:23:49 PM sudo[97583] jgoldberg : TTY=ttys001 ; PWD=/opt/local/etc/varnish ; USER=root ; COMMAND=/opt/local/sbin/varnishd -a *:80 -u nobody -T 88 -f /opt/local/etc/varnish/default.vcl 2/4/09 6:23:49 PM ReportCrash[97592] Formulating crash report for process varnishd[97591] 2/4/09 6:23:49 PM ReportCrash[97592] Saved crashreport to /Library/Logs/CrashReporter/varnishd_2009-02-04-182349_MFF109.crash using uid: 0 gid: 0, euid: 0 egid: 0 }}} crashReporter log: {{{ Process: varnishd [97526] Path: /opt/local/sbin/varnishd Identifier: varnishd Version: ??? (???) Code Type: X86 (Native) Parent Process: launchd [1] Date/Time: 2009-02-04 18:20:59.800 -0800 OS Version: Mac OS X 10.5.6 (9G55) Report Version: 6 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 libSystem.B.dylib 0x94137e42 __kill + 10 1 libSystem.B.dylib 0x941aa23a raise + 26 2 libSystem.B.dylib 0x941b6679 abort + 73 3 libvarnish.1.dylib 0x0006bfdd lbv_assert_default + 189 4 varnishd 0x0003612c mgt_cli_telnet + 572 5 varnishd 0x00033342 mgt_run + 82 6 varnishd 0x00041ffc main + 1756 7 varnishd 0x00001a56 start + 54 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x941b6639 ecx: 0xbffff4bc edx: 0x94137e42 edi: 0x00049b87 esi: 0x00000031 ebp: 0xbffff4d8 esp: 0xbffff4bc ss: 0x0000001f efl: 0x00000286 eip: 0x94137e42 cs: 0x00000007 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00049b80 Binary Images: 0x1000 - 0x4efff +varnishd ??? (???) /opt/local/sbin/varnishd 0x6b000 - 0x72fff +libvarnish.1.dylib ??? (???) /opt/local/lib/libvarnish.1.dylib 0x77000 - 0x77ffa +libvarnishcompat.1.dylib ??? (???) /opt/local/lib/libvarnishcompat.1.dylib 0x7b000 - 0x8eff7 +libvcl.1.dylib ??? (???) /opt/local/lib/libvcl.1.dylib 0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <100d362e03410f181a34e04e94189ae5> /usr/lib/dyld 0x900a1000 - 0x900a8fe9 libgcc_s.1.dylib ??? (???) /usr/lib/libgcc_s.1.dylib 0x940c9000 - 0x94230ff3 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0x9437b000 - 0x9437ffff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 5 03:17:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Feb 2009 03:17:27 -0000 Subject: [Varnish] #437: Varnish 2.0.2 hanging with large amounts of traffic Message-ID: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> #437: Varnish 2.0.2 hanging with large amounts of traffic -------------------+-------------------------------------------------------- Reporter: ajt | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: critical Keywords: | -------------------+-------------------------------------------------------- Varnish 2.0.2 stops accepting connections after a couple of hours of accepting 55-60Mbits of traffic. This is on an ubuntu 8.04 LTS server build from the 2.0.2 source. Ulimit is set to 200000. Uname: {{{ Linux ded203 2.6.24-16-server #1 SMP Thu Apr 10 13:15:38 UTC 2008 x86_64 GNU/Linux }}} Here is a varnishstat: {{{ 0+09:18:17 ded203 Hitrate ratio: 1 1 1 Hitrate avg: 0.6119 0.6119 0.6119 526888 0.00 15.73 Client connections accepted 964084 0.00 28.78 Client requests received 115238 0.00 3.44 Cache hits 1 0.00 0.00 Cache hits for pass 73091 0.00 2.18 Cache misses 848889 0.00 25.34 Backend connections success 0 0.00 0.00 Backend connections not attempted 0 0.00 0.00 Backend connections too many 5 0.00 0.00 Backend connections failures 8246 0.00 0.25 Backend connections reuses 11101 0.00 0.33 Backend connections recycles 0 0.00 0.00 Backend connections unused 1324 . . N struct srcaddr 18446744073709551613 . . N active struct srcaddr 671 . . N struct sess_mem 1 . . N struct sess 33041 . . N struct object 28096 . . N struct objecthead 72658 . . N struct smf }}} Here is an iostat: {{{ iostat -x -k 5 Linux 2.6.24-16-server (ded203) 02/04/2009 avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.00 0.18 0.09 0.00 99.63 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.45 7.24 0.26 1.08 7.28 33.26 60.90 0.10 74.04 3.12 0.42 avg-cpu: %user %nice %system %iowait %steal %idle 0.19 0.00 0.19 0.05 0.00 99.58 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.00 0.40 0.00 2.40 0.00 12.00 0.00 5.00 5.00 0.20 avg-cpu: %user %nice %system %iowait %steal %idle 0.09 0.00 0.24 0.14 0.00 99.53 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 2.40 0.00 0.40 0.00 11.20 0.00 56.00 0.00 10.00 10.00 0.40 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 5 03:19:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Feb 2009 03:19:34 -0000 Subject: [Varnish] #437: Varnish 2.0.2 hanging with large amounts of traffic In-Reply-To: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> References: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> Message-ID: <058.5de3b3ea2d8f72abd4364049a4f341a6@projects.linpro.no> #437: Varnish 2.0.2 hanging with large amounts of traffic ----------------------+----------------------------------------------------- Reporter: ajt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by ajt): Here is a varnishlog during the connection disruption: {{{ 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233794889 1.0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233794892 1.0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233794895 1.0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233794898 1.0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233794901 1.0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 5 05:58:54 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Feb 2009 05:58:54 -0000 Subject: [Varnish] #437: Varnish 2.0.2 hanging with large amounts of traffic In-Reply-To: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> References: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> Message-ID: <058.9f833e164b6e2e76bc1605be4c589cea@projects.linpro.no> #437: Varnish 2.0.2 hanging with large amounts of traffic ----------------------+----------------------------------------------------- Reporter: ajt | Owner: perbu Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by perbu): * owner: => perbu Comment: You might want to give trunk a whirl to see if this can be reproduced. There have been som relevant fixes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 5 10:29:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Feb 2009 10:29:19 -0000 Subject: [Varnish] #368: getting errors while loading vcl causes instant death In-Reply-To: <051.817a8f1a81f6e0fcba8155610af6c117@projects.linpro.no> References: <051.817a8f1a81f6e0fcba8155610af6c117@projects.linpro.no> Message-ID: <060.b23cbfdd8815b20bd6db3c515442b983@projects.linpro.no> #368: getting errors while loading vcl causes instant death ----------------------+----------------------------------------------------- Reporter: pj0tr | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3602]) Merge r3378 + 3389: Make sure the VCL we try to load is a regular file Fixes #368 r3389 | phk | 2008-11-11 21:40:37 +0100 (ti., 11 nov. 2008) | 4 lines Fix this test-case to not rely on being able to compile /dev/null now that this is no longer possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 5 11:02:45 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Feb 2009 11:02:45 -0000 Subject: [Varnish] #210: The binary heap implementation does not scale In-Reply-To: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> References: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> Message-ID: <058.59182a06eb80153b6c9cd07aeb6a0ece@projects.linpro.no> #210: The binary heap implementation does not scale -------------------------+-------------------------------------------------- Reporter: phk | Owner: phk Type: enhancement | Status: closed Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Comment (by tfheen): (In [3606]) Merge r3390: Rework the binary heap we use for expiry processing Rework the binary heap, we use for expiry processing, to deal more gracefully with large number of objects. Previously we kept all objects in a single array which resultined in increasingly infrequent but increasingly demanding calls to calloc(3) with the consequent massive memory copies. We also did not release memory again if unused. Now we stripe the array into rows of 64k objects each. This number is a compromise between space wastage, max 1MB on a 64bit machine, and the desire to not add and delete rows all the time. With 64k objects in a row, even on a very busy server would only add a new row every 5...10 seconds during ramp up. Delete unused rows, but keep a hysteresis of an entire empty row to avoid silly add-delete-add-delete-add-delete behaviour at row boundaries. Streamline some of the functions a bit. Fixes #210 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 5 16:53:09 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Feb 2009 16:53:09 -0000 Subject: [Varnish] #437: Varnish 2.0.2 hanging with large amounts of traffic In-Reply-To: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> References: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> Message-ID: <058.8c9dad512e28ec0cde08f84a32f94b74@projects.linpro.no> #437: Varnish 2.0.2 hanging with large amounts of traffic ----------------------+----------------------------------------------------- Reporter: ajt | Owner: perbu Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by ajt): I have upgraded to trunk this morning and the issues continues. Here is some more information but I have noticed that the n_srcadd_acct is 18446744073709551614 as reported by varnishstat -1 at the time of the issue. I should point out also that I am using round robin. {{{ uptime 7946 . Child uptime client_conn 96406 12.13 Client connections accepted client_req 155875 19.62 Client requests received cache_hit 21343 2.69 Cache hits cache_hitpass 2980 0.38 Cache hits for pass cache_miss 13930 1.75 Cache misses backend_conn 134541 16.93 Backend connections success backend_unhealthy 0 0.00 Backend connections not attempted backend_busy 0 0.00 Backend connections too many backend_fail 2 0.00 Backend connections failures backend_reuse 0 0.00 Backend connections reuses backend_recycle 0 0.00 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_srcaddr 1188 . N struct srcaddr n_srcaddr_act 18446744073709551614 . N active struct srcaddr n_sess_mem 528 . N struct sess_mem n_sess 1 . N struct sess n_object 7962 . N struct object n_objecthead 8277 . N struct objecthead n_smf 17386 . N struct smf n_smf_frag 1507 . N small free smf n_smf_large 40 . N large free smf n_vbe_conn 6 . N struct vbe_conn n_bereq 489 . N struct bereq n_wrk 116 . N worker threads n_wrk_create 675 0.08 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 2380 0.30 N overflowed work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 2 . N backends n_expired 5998 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 13442 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 149164 18.77 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 96405 12.13 Total Sessions s_req 155886 19.62 Total Requests s_pipe 0 0.00 Total pipe s_pass 120613 15.18 Total pass s_fetch 134461 16.92 Total fetch s_hdrbytes 109487062 13778.89 Total header bytes s_bodybytes 1241045694 156184.96 Total body bytes sess_closed 7246 0.91 Session Closed sess_pipeline 22 0.00 Session Pipeline sess_readahead 7 0.00 Session Read Ahead sess_linger 0 0.00 Session Linger sess_herd 149706 18.84 Session herd shm_records 13421027 1689.03 SHM records shm_writes 747891 94.12 SHM writes shm_flushes 20 0.00 SHM flushes due to overflow shm_cont 378 0.05 SHM MTX contention shm_cycles 6 0.00 SHM cycles through buffer sm_nreq 267091 33.61 allocator requests sm_nobj 15839 . outstanding allocations sm_balloc 212172800 . bytes allocated sm_bfree 22959534080 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free sms_nreq 82 0.01 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 38212 . SMS bytes allocated sms_bfree 38212 . SMS bytes freed backend_req 134542 16.93 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_purge 1 . N total active purges n_purge_add 1 0.00 N new purges added n_purge_retire 0 0.00 N old purges deleted n_purge_obj_test 0 0.00 N objects tested n_purge_re_test 0 0.00 N regexps tested against n_purge_dups 0 0.00 N duplicate purges removed hcb_nolock 0 0.00 HCB Lookups without lock hcb_lock 0 0.00 HCB Lookups with lock hcb_insert 0 0.00 HCB Inserts esi_parse 0 0.00 Objects ESI parsed (unlock) esi_errors 0 0.00 ESI parse errors (unlock) }}} Varnishlog: {{{ 0 WorkThread - 0x7f1b9c2fbbe0 end 0 WorkThread - 0x7f1ba84e7be0 end 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233852234 1.0 0 WorkThread - 0x7f1b5d0fdbe0 end 0 WorkThread - 0x7f1bef2e7be0 end 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233852237 1.0 0 WorkThread - 0x7f1b930eebe0 end 0 WorkThread - 0x7f1b754d7be0 end 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233852240 1.0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 6 12:54:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Feb 2009 12:54:34 -0000 Subject: [Varnish] #400: HTTP/1.0 404 Not Found + no Content-Length => no content In-Reply-To: <053.c18029fa6fb3d7c60156a7702c8fa2a5@projects.linpro.no> References: <053.c18029fa6fb3d7c60156a7702c8fa2a5@projects.linpro.no> Message-ID: <062.769f39b59d8769111da8d90ce0b78ee2@projects.linpro.no> #400: HTTP/1.0 404 Not Found + no Content-Length => no content ----------------------+----------------------------------------------------- Reporter: jfbubus | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3663]) Merge r3470: Change the logic that decides when we attempt EOF fetches from the backend. The new logic is: If (HEAD) /* happens only on pass */ do not fetch body. else if (Content-Length) fetch body according to length else if (chunked) fetch body as chunked else if (other transfer-encoding) fail else if (Connection: keep-alive) fetch no body, set Length = 0 else if (Connection: close) fetch body until EOF else if (HTTP < 1.1) fetch body until EOF else fetch no body, set Length = 0 let me know if this breaks anything that should work. Fixes #400 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 6 13:22:03 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Feb 2009 13:22:03 -0000 Subject: [Varnish] #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used In-Reply-To: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> References: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> Message-ID: <070.ade6604952e3077c4b80154b28fec124@projects.linpro.no> #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used -----------------------------+---------------------------------------------- Reporter: anders at fupp.net | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Comment (by tfheen): (In [3666]) Merge r3473: Only fail -T argument if none of the addresses it resolves to can be listend on. Fixes #97 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 6 15:03:22 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Feb 2009 15:03:22 -0000 Subject: [Varnish] #416: Segfault In-Reply-To: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> References: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> Message-ID: <058.9a2ebd462619c169364bec82ee511435@projects.linpro.no> #416: Segfault --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment (by tfheen): (In [3687]) Merge r3498: Handle too many headers more gracefully If we get more HTTP headers than we have room for (default: 28) we used to ignore the rest. This is not a bright solution if crucial HTTP headers like "Content-Length" or "Transfer-Encoding" are last and get ignored. In general, it is highly suspect to randomly ignore HTTP headers, as opposed to deliberately ignoring them, either by having first looked at them and found them uninteresting, or by having looked for the headers we care about, and having not matched some others. Change too many headers to firm error condition: 400 if from the client, and 503 (like every other trouble) if from the backend. Fixes #416 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 6 15:10:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Feb 2009 15:10:34 -0000 Subject: [Varnish] #387: Varnish crashes on Missing errorhandling code in fetch_chunked In-Reply-To: <052.22bfa1b1cfef87b231048e0ed3d9726b@projects.linpro.no> References: <052.22bfa1b1cfef87b231048e0ed3d9726b@projects.linpro.no> Message-ID: <061.1843582cb407e67221f5eaa5fe459e7c@projects.linpro.no> #387: Varnish crashes on Missing errorhandling code in fetch_chunked ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3689]) Merge r3500: Fail long chunked transactions, don't panic Don't panic if the chunked header is ridiculously long, just fail the transaction. Fixes #387 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 6 15:27:35 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Feb 2009 15:27:35 -0000 Subject: [Varnish] #376: Varnish core-dumps on ctrl-c In-Reply-To: <052.e6b196f75eb9cb191e0cd030b908f316@projects.linpro.no> References: <052.e6b196f75eb9cb191e0cd030b908f316@projects.linpro.no> Message-ID: <061.4c460acbd1fefdc618859047c74a995a@projects.linpro.no> #376: Varnish core-dumps on ctrl-c ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3690]) Merge r3501+r3502: Don't panic if we fail to delete shared objects in atexit(). Fixes #376 Addendum to r3501: remove the file from the list. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 7 15:44:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 07 Feb 2009 15:44:42 -0000 Subject: [Varnish] #430: Varnish crashes with Assert error in HSH_Deref In-Reply-To: <052.240c1acf64980e7d5debe86f76e68fc0@projects.linpro.no> References: <052.240c1acf64980e7d5debe86f76e68fc0@projects.linpro.no> Message-ID: <061.a04adeb8a2c68e5191ad4b4004a1ae87@projects.linpro.no> #430: Varnish crashes with Assert error in HSH_Deref ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): This keeps happening, also with trunk/3563: {{{ Child (16962) Panic message: Assert error in HSH_Deref(), cache_hash.c line 430: Condition((oh)->magic == 0x1b96615d) not true. thread = (cache-timeout) }}} But no core dump was generated. Sigh. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 7 16:57:03 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 07 Feb 2009 16:57:03 -0000 Subject: [Varnish] #438: varnish hangs upon hot reconfiguration Message-ID: <053.dba0b7fe61d70346b1a6b6563506acb7@projects.linpro.no> #438: varnish hangs upon hot reconfiguration ----------------------+----------------------------------------------------- Reporter: solatis | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: critical | Keywords: ----------------------+----------------------------------------------------- Hello, I'm trying to deploy varnish, and when I'm trying to do a hot reconfiguration of the config files under a high load, it seems like the child processes hang at some point. Steps to reproduce: 1. Add or remove server to/from attached configuration file 2. varnishadm load new /config 3. varnishadm use new 4. Notice that, for a brief moment, the new configuration file is used (new server configuration is noticable) 5. Varnish stops responding (does accept socket), while backends still work fine To get varnish back in a working state, I have to 'varnishadm stop && varnishadm start'. I've ran varnish under gdb and killed it while it was in the unresponsive state, but it wasn't really helpful: (gdb) bt #0 0x0000003bff2c8fdf in poll () from /lib64/libc.so.6 #1 0x00002af806f67e91 in vev_schedule_one (evb=0x2af80760c540) at vev.c:478 #2 0x00002af806f678c4 in vev_schedule (evb=0x2af80760c540) at vev.c:365 #3 0x000000000043226e in mgt_run (dflag=0, T_arg=0x7fffa3b61c46 "127.0.0.1:8081") at mgt_child.c:560 #4 0x000000000043e0d2 in main (argc=0, argv=0x7fffa3b61588) at varnishd.c:639 (gdb) thread 2 Thread ID 2 not known. Please note that, as long as there is no load, nothing goes wrong. Also note that loading a new configuration file that is unchanged, works fine too. Other than that, the steps above always reproduce my problem. The version I'm running is trunk from a few hours ago. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 7 17:14:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 07 Feb 2009 17:14:57 -0000 Subject: [Varnish] #438: varnish hangs upon hot reconfiguration In-Reply-To: <053.dba0b7fe61d70346b1a6b6563506acb7@projects.linpro.no> References: <053.dba0b7fe61d70346b1a6b6563506acb7@projects.linpro.no> Message-ID: <062.f94f613cdc6b6b31dce52fbad181f08e@projects.linpro.no> #438: varnish hangs upon hot reconfiguration ----------------------+----------------------------------------------------- Reporter: solatis | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > Hello, > > I'm trying to deploy varnish, and when I'm trying to do a hot > reconfiguration of the config files under a high load, it seems like the > child processes hang at some point. > > Steps to reproduce: > 1. Add or remove server to/from attached configuration file > 2. varnishadm load new /config > 3. varnishadm use new > 4. Notice that, for a brief moment, the new configuration file is used > (new server configuration is noticable) > 5. Varnish stops responding (does accept socket), while backends still > work fine > > To get varnish back in a working state, I have to 'varnishadm stop && > varnishadm start'. > > I've ran varnish under gdb and killed it while it was in the unresponsive > state, but it wasn't really helpful: > > (gdb) bt > #0 0x0000003bff2c8fdf in poll () from /lib64/libc.so.6 > #1 0x00002af806f67e91 in vev_schedule_one (evb=0x2af80760c540) at > vev.c:478 > #2 0x00002af806f678c4 in vev_schedule (evb=0x2af80760c540) at vev.c:365 > #3 0x000000000043226e in mgt_run (dflag=0, T_arg=0x7fffa3b61c46 > "127.0.0.1:8081") at mgt_child.c:560 > #4 0x000000000043e0d2 in main (argc=0, argv=0x7fffa3b61588) at > varnishd.c:639 > (gdb) thread 2 > Thread ID 2 not known. > > Please note that, as long as there is no load, nothing goes wrong. > > Also note that loading a new configuration file that is unchanged, works > fine too. > > Other than that, the steps above always reproduce my problem. > > The version I'm running is trunk from a few hours ago. New description: Hello, I'm trying to deploy varnish, and when I'm trying to do a hot reconfiguration of the config files under a high load, it seems like the child processes hang at some point. Steps to reproduce: 1. Add or remove server to/from attached configuration file 2. varnishadm load new /config 3. varnishadm use new 4. Notice that, for a brief moment, the new configuration file is used (new server configuration is noticable) 5. Varnish stops responding (does accept socket), while backends still work fine To get varnish back in a working state, I have to 'varnishadm stop && varnishadm start'. I've ran varnish under gdb and killed it while it was in the unresponsive state, but it wasn't really helpful: {{{ (gdb) bt #0 0x0000003bff2c8fdf in poll () from /lib64/libc.so.6 #1 0x00002af806f67e91 in vev_schedule_one (evb=0x2af80760c540) at vev.c:478 #2 0x00002af806f678c4 in vev_schedule (evb=0x2af80760c540) at vev.c:365 #3 0x000000000043226e in mgt_run (dflag=0, T_arg=0x7fffa3b61c46 "127.0.0.1:8081") at mgt_child.c:560 #4 0x000000000043e0d2 in main (argc=0, argv=0x7fffa3b61588) at varnishd.c:639 (gdb) thread 2 Thread ID 2 not known. }}} Please note that, as long as there is no load, nothing goes wrong. Also note that loading a new configuration file that is unchanged, works fine too. Other than that, the steps above always reproduce my problem. The version I'm running is trunk from a few hours ago. Comment (by tfheen): fix up summary markup. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 9 10:58:13 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 09 Feb 2009 10:58:13 -0000 Subject: [Varnish] #439: adding several cookie will remove redirection Message-ID: <056.a60faa3b741776d321e3406485e54948@projects.linpro.no> #439: adding several cookie will remove redirection ------------------------+--------------------------------------------------- Reporter: scouzinier | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ------------------------+--------------------------------------------------- header Location is remove by varnish if we use several time Set-Cookie. this header will should redirect the user. It's work without varnish, not with varnish. HTTP/1.1 302 Found Date: Mon, 09 Feb 2009 10:52:43 GMT Server: Apache Set-Cookie: SiteNameClient=qmdjrt7t1gp79elac25vhf8bg5; path=/; domain=.toto.fr Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache Last-Modified: Mon, 09 Feb 2009 10:52:43 GMT X-Powered-By: eZ Publish Served-by: org-www.toto.fr Content-language: fr-FR Set-Cookie: user_logged=non; path=/; domain=.toto.fr Set-Cookie: session_user_logged=non; path=/; domain=.toto.fr Set-Cookie: user_info=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: EZ_TICKET=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr:80 Set-Cookie: cine1=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: id1=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: cine2=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: id2=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: cine3=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: id3=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: cine4=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: id4=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: user_logged=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: username=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: clubtoto_grade=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: clubtoto_action=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: clubtoto_points=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: clubtoto_grade_id=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr Set-Cookie: avatar_toto=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr:80 Set-Cookie: toto_fileavatar=deleted; expires=Sun, 10-Feb-2008 10:52:42 GMT; path=/; domain=.toto.fr:80 Location: http://org-www.toto.fr Content-Length: 200 Connection: close Content-Type: text/html; charset=utf-8 Sample page: When max value for $i is 17, the page will work with varnish When max value for $i is 18, the page won't work with varnish -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 10 14:32:12 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 10 Feb 2009 14:32:12 -0000 Subject: [Varnish] #425: Object pass'ed in vcl_fetch with TTL=0s can serialize that object In-Reply-To: <049.4b99dfd23383049079de7b680316dab4@projects.linpro.no> References: <049.4b99dfd23383049079de7b680316dab4@projects.linpro.no> Message-ID: <058.092bfe6fa793e11f09dde9d758e209b1@projects.linpro.no> #425: Object pass'ed in vcl_fetch with TTL=0s can serialize that object ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3719]) Merge r3537: Enforce a minimum ttl for "hit for pass" objects to prevent a value of zero from serializing access to an object with very draconian backend cache-control headers. We could get far even with a one second TTL, but following our general "there is a reason people put Varnish there in the first place" logic we use the default_ttl parameter (default: 120 s) for this value. If another value is desired, this can be set in vcl_fetch, even if it looks somewhat counter-intuitive: sub vcl_fetch { if (obj.http.set-cookie) { set obj.ttl = 10s; pass; } } Fixes #425 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 10 15:01:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 10 Feb 2009 15:01:04 -0000 Subject: [Varnish] #440: Script Using telnet Message-ID: <055.0f60ebef3051feb32d319c46c543adcb@projects.linpro.no> #440: Script Using telnet -------------------------+-------------------------------------------------- Reporter: commandos | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- I saw the example here http://varnish.projects.linpro.no/ticket/332 about varnish and sending queries using telnet . Started varnish using the -T 127.0.0.1:8787 When i send a query using : echo "purge.url 'test.html'" | telnet localhost 8787 i get Connected to localhost Escape character is '^]' Connection closed by foreign host but when i try it directly it works and i get "200 0" is this normal ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 10 16:09:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 10 Feb 2009 16:09:34 -0000 Subject: [Varnish] #441: ESI and varnish Message-ID: <049.4baaf80ff9ab5843e662e305f11ce296@projects.linpro.no> #441: ESI and varnish -------------------+-------------------------------------------------------- Reporter: Tom | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Hello I'm using the lastest varnish version , and trying to integrate ESI example of usage : when i test it , nothing happens and in the source code of the browser i see it as is . -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 10 16:33:08 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 10 Feb 2009 16:33:08 -0000 Subject: [Varnish] #440: Script Using telnet In-Reply-To: <055.0f60ebef3051feb32d319c46c543adcb@projects.linpro.no> References: <055.0f60ebef3051feb32d319c46c543adcb@projects.linpro.no> Message-ID: <064.68489d4df9706b1b21a85f896727ef5d@projects.linpro.no> #440: Script Using telnet -------------------------+-------------------------------------------------- Reporter: commandos | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Tom): echo "purge.url 'test.html'" | nc localhost 8787 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 10 16:37:55 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 10 Feb 2009 16:37:55 -0000 Subject: [Varnish] #441: ESI and varnish In-Reply-To: <049.4baaf80ff9ab5843e662e305f11ce296@projects.linpro.no> References: <049.4baaf80ff9ab5843e662e305f11ce296@projects.linpro.no> Message-ID: <058.ac98e8ff8e04278ef11f4cfebea76bc0@projects.linpro.no> #441: ESI and varnish --------------------+------------------------------------------------------- Reporter: Tom | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by Tom): I Think esi cant be called directly , i need to call it from a HTML TAG -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 10 16:49:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 10 Feb 2009 16:49:25 -0000 Subject: [Varnish] #441: ESI and varnish In-Reply-To: <049.4baaf80ff9ab5843e662e305f11ce296@projects.linpro.no> References: <049.4baaf80ff9ab5843e662e305f11ce296@projects.linpro.no> Message-ID: <058.5c723f7e3282e4cadc45bc97ed9344a2@projects.linpro.no> #441: ESI and varnish --------------------+------------------------------------------------------- Reporter: Tom | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by perbu): * status: new => closed * resolution: => invalid Comment: Hi Tom. I think you have misunderstood what ESI is all about. You can only use ESI with text objects. Please take a moment to read about basic about ESI. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 11 08:46:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 11 Feb 2009 08:46:57 -0000 Subject: [Varnish] #278: Backend connection does not timeout In-Reply-To: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> References: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> Message-ID: <057.3a1526ec86f09915c58cbc66a65c8528@projects.linpro.no> #278: Backend connection does not timeout ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: PURGE | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r3406. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 11 15:20:23 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 11 Feb 2009 15:20:23 -0000 Subject: [Varnish] #442: bar instead of baz Message-ID: <049.56346f60fa9b027d0fd0c2e19969cf45@projects.linpro.no> #442: bar instead of baz -------------------+-------------------------------------------------------- Reporter: Tom | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- In this doc : http://varnish.projects.linpro.no/wiki/LoadBalancing sub vcl_recv { if (req.http.host ~ "^(www.)?mysite.com$") { set req.backend = baz; } } set req.backend = bar (not baz) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 11 19:36:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 11 Feb 2009 19:36:31 -0000 Subject: [Varnish] #442: bar instead of baz In-Reply-To: <049.56346f60fa9b027d0fd0c2e19969cf45@projects.linpro.no> References: <049.56346f60fa9b027d0fd0c2e19969cf45@projects.linpro.no> Message-ID: <058.56f443895bae903b72998f70d2d51d1d@projects.linpro.no> #442: bar instead of baz ---------------------------+------------------------------------------------ Reporter: Tom | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | ---------------------------+------------------------------------------------ Changes (by perbu): * status: new => closed * resolution: => invalid Comment: baz is actually a (backend) director and you set the director as a backend for the relevant request. This is how the whole load balancing thingy works. http://varnish.projects.linpro.no/wiki/VCLExampleDirector is another example. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 11 19:37:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 11 Feb 2009 19:37:44 -0000 Subject: [Varnish] #442: bar instead of baz In-Reply-To: <049.56346f60fa9b027d0fd0c2e19969cf45@projects.linpro.no> References: <049.56346f60fa9b027d0fd0c2e19969cf45@projects.linpro.no> Message-ID: <058.d48fae621a9da2a724e216e83965ce2e@projects.linpro.no> #442: bar instead of baz ---------------------------+------------------------------------------------ Reporter: Tom | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | ---------------------------+------------------------------------------------ Comment (by perbu): btw, thank you very much for actually filing a ticket! Per. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 12 14:15:54 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 12 Feb 2009 14:15:54 -0000 Subject: [Varnish] #443: solaris --enable-tests breaks Message-ID: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> #443: solaris --enable-tests breaks ---------------------+------------------------------------------------------ Reporter: kapilt | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: solaris | ---------------------+------------------------------------------------------ solaris 10, sun studio 12, probably a gcc'ism, varnish 2.0.3 ./configure --enable-tests && make make make all-recursive Making all in include Making all in lib Making all in libvarnish source='argv.c' object='argv.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o argv.lo argv.c mkdir .libs cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c argv.c -KPIC -DPIC -o .libs/argv.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c argv.c -o argv.o >/dev/null 2>&1 source='assert.c' object='assert.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o assert.lo assert.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c assert.c -KPIC -DPIC -o .libs/assert.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c assert.c -o assert.o >/dev/null 2>&1 source='binary_heap.c' object='binary_heap.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o binary_heap.lo binary_heap.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c binary_heap.c -KPIC -DPIC -o .libs/binary_heap.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c binary_heap.c -o binary_heap.o >/dev/null 2>&1 source='subproc.c' object='subproc.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o subproc.lo subproc.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c subproc.c -KPIC -DPIC -o .libs/subproc.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c subproc.c -o subproc.o >/dev/null 2>&1 source='cli.c' object='cli.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o cli.lo cli.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c cli.c -KPIC -DPIC -o .libs/cli.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c cli.c -o cli.o >/dev/null 2>&1 source='cli_common.c' object='cli_common.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o cli_common.lo cli_common.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c cli_common.c -KPIC -DPIC -o .libs/cli_common.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c cli_common.c -o cli_common.o >/dev/null 2>&1 source='crc32.c' object='crc32.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o crc32.lo crc32.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c crc32.c -KPIC -DPIC -o .libs/crc32.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c crc32.c -o crc32.o >/dev/null 2>&1 source='flopen.c' object='flopen.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o flopen.lo flopen.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c flopen.c -KPIC -DPIC -o .libs/flopen.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c flopen.c -o flopen.o >/dev/null 2>&1 source='num.c' object='num.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o num.lo num.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c num.c -KPIC -DPIC -o .libs/num.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c num.c -o num.o >/dev/null 2>&1 source='time.c' object='time.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o time.lo time.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c time.c -KPIC -DPIC -o .libs/time.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c time.c -o time.o >/dev/null 2>&1 source='tcp.c' object='tcp.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o tcp.lo tcp.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c tcp.c -KPIC -DPIC -o .libs/tcp.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c tcp.c -o tcp.o >/dev/null 2>&1 source='vct.c' object='vct.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o vct.lo vct.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vct.c -KPIC -DPIC -o .libs/vct.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vct.c -o vct.o >/dev/null 2>&1 source='version.c' object='version.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o version.lo version.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c version.c -KPIC -DPIC -o .libs/version.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c version.c -o version.o >/dev/null 2>&1 source='vev.c' object='vev.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o vev.lo vev.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vev.c -KPIC -DPIC -o .libs/vev.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vev.c -o vev.o >/dev/null 2>&1 source='vlu.c' object='vlu.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o vlu.lo vlu.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vlu.c -KPIC -DPIC -o .libs/vlu.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vlu.c -o vlu.o >/dev/null 2>&1 source='vpf.c' object='vpf.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o vpf.lo vpf.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vpf.c -KPIC -DPIC -o .libs/vpf.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vpf.c -o vpf.o >/dev/null 2>&1 source='vsb.c' object='vsb.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o vsb.lo vsb.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vsb.c -KPIC -DPIC -o .libs/vsb.o cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vsb.c -o vsb.o >/dev/null 2>&1 source='vsha256.c' object='vsha256.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c -o vsha256.lo vsha256.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -c vsha256.c -KPIC -DPIC -o .libs/vsha256.o "../../include/vsha256.h", line 41: warning: old-style declaration or incorrect type for: __BEGIN_DECLS "../../include/vsha256.h", line 41: syntax error before or at: void "vsha256.c", line 48: warning: old-style declaration or incorrect type for: __END_DECLS "vsha256.c", line 48: syntax error before or at: static "vsha256.c", line 48: warning: no explicit type given "vsha256.c", line 59: warning: no explicit type given "vsha256.c", line 59: syntax error before or at: void "vsha256.c", line 80: warning: no explicit type given "vsha256.c", line 80: syntax error before or at: uint32_t cc: acomp failed for vsha256.c *** Error code 1 make: Fatal error: Command failed for target `vsha256.lo' Current working directory /opt/wdl/tmp/varnish-2.0.3/lib/libvarnish *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='libvarnish libvarnishapi libvarnishcompat libvcl'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /opt/wdl/tmp/varnish-2.0.3/lib *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='include lib bin man etc doc redhat'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /opt/wdl/tmp/varnish-2.0.3 *** Error code 1 make: Fatal error: Command failed for target `all' -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 12 14:20:06 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 12 Feb 2009 14:20:06 -0000 Subject: [Varnish] #443: solaris --enable-tests breaks In-Reply-To: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> References: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> Message-ID: <061.ba6174bce9ed26e6c8e9da9255297186@projects.linpro.no> #443: solaris --enable-tests breaks ---------------------+------------------------------------------------------ Reporter: kapilt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: solaris | ---------------------+------------------------------------------------------ Comment (by kapilt): same error applies to --enable-debugging-symbols, error to follow. make make all-recursive Making all in include Making all in lib Making all in libvarnish source='argv.c' object='argv.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o argv.lo argv.c mkdir .libs cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c argv.c -KPIC -DPIC -o .libs/argv.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c argv.c -o argv.o >/dev/null 2>&1 source='assert.c' object='assert.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o assert.lo assert.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c assert.c -KPIC -DPIC -o .libs/assert.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c assert.c -o assert.o >/dev/null 2>&1 source='binary_heap.c' object='binary_heap.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o binary_heap.lo binary_heap.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c binary_heap.c -KPIC -DPIC -o .libs/binary_heap.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c binary_heap.c -o binary_heap.o >/dev/null 2>&1 source='subproc.c' object='subproc.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o subproc.lo subproc.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c subproc.c -KPIC -DPIC -o .libs/subproc.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c subproc.c -o subproc.o >/dev/null 2>&1 source='cli.c' object='cli.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o cli.lo cli.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c cli.c -KPIC -DPIC -o .libs/cli.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c cli.c -o cli.o >/dev/null 2>&1 source='cli_common.c' object='cli_common.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o cli_common.lo cli_common.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c cli_common.c -KPIC -DPIC -o .libs/cli_common.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c cli_common.c -o cli_common.o >/dev/null 2>&1 source='crc32.c' object='crc32.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o crc32.lo crc32.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c crc32.c -KPIC -DPIC -o .libs/crc32.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c crc32.c -o crc32.o >/dev/null 2>&1 source='flopen.c' object='flopen.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o flopen.lo flopen.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c flopen.c -KPIC -DPIC -o .libs/flopen.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c flopen.c -o flopen.o >/dev/null 2>&1 source='num.c' object='num.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o num.lo num.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c num.c -KPIC -DPIC -o .libs/num.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c num.c -o num.o >/dev/null 2>&1 source='time.c' object='time.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o time.lo time.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c time.c -KPIC -DPIC -o .libs/time.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c time.c -o time.o >/dev/null 2>&1 source='tcp.c' object='tcp.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o tcp.lo tcp.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c tcp.c -KPIC -DPIC -o .libs/tcp.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c tcp.c -o tcp.o >/dev/null 2>&1 source='vct.c' object='vct.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o vct.lo vct.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vct.c -KPIC -DPIC -o .libs/vct.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vct.c -o vct.o >/dev/null 2>&1 source='version.c' object='version.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o version.lo version.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c version.c -KPIC -DPIC -o .libs/version.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c version.c -o version.o >/dev/null 2>&1 source='vev.c' object='vev.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o vev.lo vev.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vev.c -KPIC -DPIC -o .libs/vev.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vev.c -o vev.o >/dev/null 2>&1 source='vlu.c' object='vlu.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o vlu.lo vlu.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vlu.c -KPIC -DPIC -o .libs/vlu.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vlu.c -o vlu.o >/dev/null 2>&1 source='vpf.c' object='vpf.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o vpf.lo vpf.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vpf.c -KPIC -DPIC -o .libs/vpf.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vpf.c -o vpf.o >/dev/null 2>&1 source='vsb.c' object='vsb.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o vsb.lo vsb.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vsb.c -KPIC -DPIC -o .libs/vsb.o cc: Warning: illegal option -fno-inline cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vsb.c -o vsb.o >/dev/null 2>&1 source='vsha256.c' object='vsha256.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c -o vsha256.lo vsha256.c cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O0 -g -fno-inline -c vsha256.c -KPIC -DPIC -o .libs/vsha256.o cc: Warning: illegal option -fno-inline "../../include/vsha256.h", line 41: warning: old-style declaration or incorrect type for: __BEGIN_DECLS "../../include/vsha256.h", line 41: syntax error before or at: void "vsha256.c", line 48: warning: old-style declaration or incorrect type for: __END_DECLS "vsha256.c", line 48: syntax error before or at: static "vsha256.c", line 48: warning: no explicit type given "vsha256.c", line 59: warning: no explicit type given "vsha256.c", line 59: syntax error before or at: void "vsha256.c", line 80: warning: no explicit type given "vsha256.c", line 80: syntax error before or at: uint32_t cc: acomp failed for vsha256.c *** Error code 1 make: Fatal error: Command failed for target `vsha256.lo' Current working directory /opt/wdl/tmp/varnish-2.0.3/lib/libvarnish *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='libvarnish libvarnishapi libvarnishcompat libvcl'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /opt/wdl/tmp/varnish-2.0.3/lib *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='include lib bin man etc doc redhat'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /opt/wdl/tmp/varnish-2.0.3 *** Error code 1 make: Fatal error: Command failed for target `all' -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 12 14:22:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 12 Feb 2009 14:22:15 -0000 Subject: [Varnish] #443: solaris --enable-tests breaks In-Reply-To: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> References: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> Message-ID: <061.2fb226bf3f050d7ec9ae0801a0abc69b@projects.linpro.no> #443: solaris --enable-tests breaks ---------------------+------------------------------------------------------ Reporter: kapilt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: solaris | ---------------------+------------------------------------------------------ Comment (by kapilt): actually it looks varnish doesn't even compile anymore at all.. without any configure flags, using make distclean between compilations. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 12 23:25:49 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 12 Feb 2009 23:25:49 -0000 Subject: [Varnish] #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit In-Reply-To: <052.a34c2c991e339001ae66cdaed7e49c57@projects.linpro.no> References: <052.a34c2c991e339001ae66cdaed7e49c57@projects.linpro.no> Message-ID: <061.4e5a7cfcbabb1bdfc37995f948fb644b@projects.linpro.no> #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit -------------------------+-------------------------------------------------- Reporter: hajile | Owner: phk Type: enhancement | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by hajile): * status: closed => reopened * resolution: fixed => Comment: broken in trunk. --- bin/varnishd/cache_center.c (revision 3756) +++ bin/varnishd/cache_center.c (working copy) @@ -406,7 +406,17 @@ switch (sp->handling) { case VCL_RET_RESTART: - HSH_Drop(sp); + if (sp->obj->ttl == 0) { + sp->obj->cacheable = 0; + } + if (sp->obj->objhead != NULL && sp->obj->cacheable == 1) { + VRY_Create(sp); + EXP_Insert(sp->obj); + HSH_Unbusy(sp); + HSH_Deref(&sp->obj); + } else { + HSH_Drop(sp); + } sp->director = NULL; sp->restarts++; sp->step = STP_RECV; -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 13 00:17:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 13 Feb 2009 00:17:15 -0000 Subject: [Varnish] #444: allow to handle non-GET req in vcl_miss Message-ID: <052.421175f448383bd901fcccf9d81bf397@projects.linpro.no> #444: allow to handle non-GET req in vcl_miss --------------------+------------------------------------------------------- Reporter: hajile | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | --------------------+------------------------------------------------------- Right now the request is forcibly set to be 'GET'. As far as I understand the reason http_FilterHeader(sp, HTTPH_R_FETCH) forces request to be 'GET' is to correctly cache objects for 'HEAD' requests. This may be better done in default vcl or somewhere else. This is not complete patch, it works for me, but it'll break some setups. In essence, all this is needed to invalidate a cache object when POST/DELETE/PUT arrives. This is very useful feature to transparently cache REST-ful services, which are very popular today. See an example .vcl below, after patch sketch @@ -650,7 +660,7 @@ CHECK_OBJ_NOTNULL(sp->obj, OBJECT_MAGIC); CHECK_OBJ_NOTNULL(sp->vcl, VCL_CONF_MAGIC); - http_FilterHeader(sp, HTTPH_R_FETCH); + http_FilterHeader(sp, HTTPH_R_PASS); VCL_miss_method(sp); AZ(sp->obj->cacheable); switch(sp->handling) { ---------------------------------------- backend test { .host = "127.0.0.1"; .port = "8081"; } sub vcl_recv { if (req.request == "POST" || req.request == "PUT" || req.request == "DELETE") { lookup; } } sub vcl_hit { if (req.request == "POST" || req.request == "PUT" || req.request == "DELETE") { set obj.ttl = 0s; set obj.cacheable = false; pass; } } sub vcl_miss { if (req.request == "POST" || req.request == "PUT" || req.request == "DELETE") { pass; } } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 13 00:18:54 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 13 Feb 2009 00:18:54 -0000 Subject: [Varnish] #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit In-Reply-To: <052.a34c2c991e339001ae66cdaed7e49c57@projects.linpro.no> References: <052.a34c2c991e339001ae66cdaed7e49c57@projects.linpro.no> Message-ID: <061.5e4d41f2e385c6121e1489b4398e8656@projects.linpro.no> #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit -------------------------+-------------------------------------------------- Reporter: hajile | Owner: phk Type: enhancement | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by hajile): always forget clicking that preview button :/ {{{ --- bin/varnishd/cache_center.c (revision 3756) +++ bin/varnishd/cache_center.c (working copy) @@ -406,7 +406,17 @@ switch (sp->handling) { case VCL_RET_RESTART: - HSH_Drop(sp); + if (sp->obj->ttl == 0) { + sp->obj->cacheable = 0; + } + if (sp->obj->objhead != NULL && sp->obj->cacheable == 1) { + VRY_Create(sp); + EXP_Insert(sp->obj); + HSH_Unbusy(sp); + HSH_Deref(&sp->obj); + } else { + HSH_Drop(sp); + } sp->director = NULL; sp->restarts++; sp->step = STP_RECV; }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 13 00:21:07 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 13 Feb 2009 00:21:07 -0000 Subject: [Varnish] #444: allow to handle non-GET req in vcl_miss In-Reply-To: <052.421175f448383bd901fcccf9d81bf397@projects.linpro.no> References: <052.421175f448383bd901fcccf9d81bf397@projects.linpro.no> Message-ID: <061.ff5eb836fecc5fbff39543e90025136c@projects.linpro.no> #444: allow to handle non-GET req in vcl_miss -------------------------+-------------------------------------------------- Reporter: hajile | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by hajile): excuse me for bad formatting {{{ --- bin/varnishd/cache_center.c (revision 3756) +++ bin/varnishd/cache_center.c (working copy) @@ -650,7 +660,7 @@ CHECK_OBJ_NOTNULL(sp->obj, OBJECT_MAGIC); CHECK_OBJ_NOTNULL(sp->vcl, VCL_CONF_MAGIC); - http_FilterHeader(sp, HTTPH_R_FETCH); + http_FilterHeader(sp, HTTPH_R_PASS); // root of evil (was FETCH), must handle HEAD in vcl VCL_miss_method(sp); AZ(sp->obj->cacheable); switch(sp->handling) { }}} {{{ backend test { .host = "127.0.0.1"; .port = "8081"; } sub vcl_recv { if (req.request == "POST" || req.request == "PUT" || req.request == "DELETE") { lookup; } } sub vcl_hit { if (req.request == "POST" || req.request == "PUT" || req.request == "DELETE") { set obj.ttl = 0s; set obj.cacheable = false; pass; } } sub vcl_miss { if (req.request == "POST" || req.request == "PUT" || req.request == "DELETE") { pass; } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 13 09:18:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 13 Feb 2009 09:18:31 -0000 Subject: [Varnish] #445: ESI Processor failing when including empty document Message-ID: <051.d9cc4c2d964ecaeec4fef3ec70a47eaa@projects.linpro.no> #445: ESI Processor failing when including empty document ----------------------+----------------------------------------------------- Reporter: Skade | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- When including an ESI fragment with an empty body, ESI stops working and delivers a broken document. Varnish version: {{{HIPE-Machine:varnish-2.0.3 skade$ /usr/local/sbin/varnishd -V varnishd (varnish-2.0.3) Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS}}} Document: {{{ }}} Expected Document: {{{ }}} Delivered Document: {{{ }}} I tested on both OS X and Gentoo Linux. I doesn't look like varnish is crashing. My vcl and a demo server using ruby/sinatra is attached. Regards, Florian Gilcher -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 13 11:57:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 13 Feb 2009 11:57:14 -0000 Subject: [Varnish] #446: r00387 fails from time to time Message-ID: <052.daab10e68b4faa97dda03a193d86727e@projects.linpro.no> #446: r00387 fails from time to time --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: low | Milestone: Component: build | Version: 2.0 Severity: minor | Keywords: 2.0.3 --------------------+------------------------------------------------------- I got r00387 to fail a few times yesterday. Not 100% reprodusible, though. It went through on the third attempt without errors. x86_64: http://koji.fedoraproject.org/koji/getfile?taskID=1122099&name=build.log ppc : http://koji.fedoraproject.org/koji/getfile?taskID=1123003&name=build.log It also occured locally on my i386 system. I did not keep the logs for that, though. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 13 12:02:53 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 13 Feb 2009 12:02:53 -0000 Subject: [Varnish] #446: r00387 fails from time to time In-Reply-To: <052.daab10e68b4faa97dda03a193d86727e@projects.linpro.no> References: <052.daab10e68b4faa97dda03a193d86727e@projects.linpro.no> Message-ID: <061.25e27c331ce85bbc6350aecc9a830128@projects.linpro.no> #446: r00387 fails from time to time --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: low | Milestone: Component: build | Version: 2.0 Severity: minor | Resolution: Keywords: 2.0.3 | --------------------+------------------------------------------------------- Comment (by phk): Please check your /tmp/__v1 directory for core dumps and provide backtrace if possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 14 15:32:55 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 14 Feb 2009 15:32:55 -0000 Subject: [Varnish] #431: Crash in fetch In-Reply-To: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> References: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> Message-ID: <058.a338867a885ed2015bc708a8f398dec9@projects.linpro.no> #431: Crash in fetch --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ (gdb) bt #0 0x00007f615d3ee095 in raise () from /lib/libc.so.6 #1 0x00007f615d3efaf0 in abort () from /lib/libc.so.6 #2 0x0000000000420c0c in pan_ic (func=0x44e27e "Tcheck", file=0x44e290 "cache.h", line=647, cond=0x44e285 "(t.b) != 0", err=104, xxx=0) at cache_panic.c:317 #3 0x000000000041b821 in Tcheck (t={b = 0x0, e = 0x0}) at cache.h:647 #4 0x000000000041b8d8 in http_findhdr (hp=0x7f601d9090b8, l=13, hdr=0x663f71 "Cache-Control:") at cache_http.c:155 #5 0x000000000041ba47 in http_GetHdr (hp=0x7f601d9090b8, hdr=0x663f71 "Cache-Control:", ptr=0x7f41b1785978) at cache_http.c:177 #6 0x000000000041bb2c in http_GetHdrField (hp=0x7f601d9090b8, hdr=0x663f70 "\016Cache-Control:", field=0x457fe2 "s-maxage", ptr=0x7f41b1785a38) at cache_http.c:206 #7 0x0000000000437aec in RFC2616_Ttl (sp=0x7f3f7ab41008, hp=0x7f601d9090b8, obj=0x7f601d909000) at rfc2616.c:95 #8 0x0000000000437f7e in RFC2616_cache_policy (sp=0x7f3f7ab41008, hp=0x7f601d9090b8) at rfc2616.c:199 #9 0x000000000041274b in cnt_fetch (sp=0x7f3f7ab41008) at cache_center.c:400 #10 0x0000000000414679 in CNT_Session (sp=0x7f3f7ab41008) at steps.h:41 #11 0x00000000004224c5 in wrk_do_cnt_sess (w=0x7f41b178dc00, priv=0x7f3f7ab41008) at cache_pool.c:398 #12 0x0000000000421f0f in wrk_thread (priv=0x7f615d00a150) at cache_pool.c:310 #13 0x00007f615dbbe3f7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f615d493b3d in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Feb 15 18:01:08 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 15 Feb 2009 18:01:08 -0000 Subject: [Varnish] #447: ESI chunked output fails if included content served via HTTP/1.0 Message-ID: <050.3392d3a760cc095c5ed11cd573e59fa3@projects.linpro.no> #447: ESI chunked output fails if included content served via HTTP/1.0 ----------------------+----------------------------------------------------- Reporter: jayk | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Not sure if this is considered a bug or if it's known. When varnish is talking to a HTTP/1.0 web server, and using ESI, the chunked Transfer-Encoding used by the ESI engine does not work. This seems to be because when processing ESI - varnish keeps the HTTP/1.0 of the original response, but tries to use Transfer-Encoding which is an HTTP/1.1 feature. Many browsers can cope with this (Command line tools such as curl, wget, LWPs GET) Webkit based browsers also cope with it. But Firefox and Internet Explorer obey the HTTP spec and ignore the chunked encoding. This results in the hex content-lengths for each chunk being displayed in the browser. Please feel free to contact me if you need any more information. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 16 14:49:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 16 Feb 2009 14:49:57 -0000 Subject: [Varnish] #431: Crash in fetch In-Reply-To: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> References: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> Message-ID: <058.8de3cb09f0aa367f19cf64287e5faf6c@projects.linpro.no> #431: Crash in fetch --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ (gdb) bt #0 0x00007ffea0306095 in raise () from /lib/libc.so.6 #1 0x00007ffea0307af0 in abort () from /lib/libc.so.6 #2 0x0000000000420c0c in pan_ic (func=0x44e27e "Tcheck", file=0x44e290 "cache.h", line=647, cond=0x44e285 "(t.b) != 0", err=0, xxx=0) at cache_panic.c:317 #3 0x000000000041b821 in Tcheck (t={b = 0x0, e = 0x0}) at cache.h:647 #4 0x000000000041b8d8 in http_findhdr (hp=0x7ff17cf140b8, l=3, hdr=0x663f51 "Age:") at cache_http.c:155 #5 0x000000000041ba47 in http_GetHdr (hp=0x7ff17cf140b8, hdr=0x663f51 "Age:", ptr=0x7fdd65b95a38) at cache_http.c:177 #6 0x0000000000437b44 in RFC2616_Ttl (sp=0x7fd67c744008, hp=0x7ff17cf140b8, obj=0x7ff17cf14000) at rfc2616.c:100 #7 0x0000000000437f7e in RFC2616_cache_policy (sp=0x7fd67c744008, hp=0x7ff17cf140b8) at rfc2616.c:199 #8 0x000000000041274b in cnt_fetch (sp=0x7fd67c744008) at cache_center.c:400 #9 0x0000000000414679 in CNT_Session (sp=0x7fd67c744008) at steps.h:41 #10 0x00000000004224c5 in wrk_do_cnt_sess (w=0x7fdd65b9dc00, priv=0x7fd67c744008) at cache_pool.c:398 #11 0x0000000000421f0f in wrk_thread (priv=0x7ffe9ff0a100) at cache_pool.c:310 #12 0x00007ffea0ad63f7 in start_thread () from /lib/libpthread.so.0 #13 0x00007ffea03abb3d in clone () from /lib/libc.so.6 #14 0x0000000000000000 in ?? () }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 16 14:56:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 16 Feb 2009 14:56:57 -0000 Subject: [Varnish] #431: Crash in fetch In-Reply-To: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> References: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> Message-ID: <058.d2be2f70b77523adb9ef63cabc741fda@projects.linpro.no> #431: Crash in fetch --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ $5 = {magic = 1680389577, ws = 0x7ff17cf14028, conds = 0 '\0', logtag = HTTP_Obj, status = 200, protover = 0, hd = {{b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b = 0x7ff17cf14358 "HTTP/1.1", e = 0x7ff17cf14360 ""}, {b = 0x7ff17cf14361 "200", e = 0x7ff17cf14364 ""}, {b = 0x7ff17cf14365 "OK", e = 0x7ff17cf14367 ""}, {b = 0x7ff17cf14368 "Date: Sun, 15 Feb 2009 01:47:21 GMT", e = 0x7ff17cf1438b ""}, {b = 0x7ff17cf1438c "Server: Apache", e = 0x7ff17cf1439a ""}, { b = 0x7ff17cf1439b "X-Powered-By: PHP/5.2.6", e = 0x7ff17cf143b2 ""}, { b = 0x7ff17cf143b3 "Content-language: en", e = 0x7ff17cf143c7 ""}, { b = 0x7ff17cf143c8 "X-CPU-Time: 0.016", e = 0x7ff17cf143d9 ""}, { b = 0x7ff17cf143da "X-Real-Time: 0.162", e = 0x7ff17cf143ec ""}, { b = 0x7ff17cf143ed "X-Served-By-Backend: apxx", e = 0x7ff17cf14406 ""}, { b = 0x7ff17cf14407 "X-User-Id: xxxxxxx", e = 0x7ff17cf14419 ""}, { b = 0x7ff17cf1441a "X-Article-Id: xxxx", e = 0x7ff17cf1442c ""}, { b = 0x7ff17cf1442d "X-Namespace-Number: 0", e = 0x7ff17cf14442 ""}, { b = 0x7ff17cf14443 "Set-Cookie: wikicitiesrecentlyvisited=a%3A4%3A%7Bi%3A0%3Ba%3A2%3A%7Bs%3A3%3A%22url%22%3Bs%3A19%3A%22starcraft.wikia.com%22%3Bs%3A4%3A%22name%22%3Bs%3A14%3A%22StarCraft+Wiki%22%3B%7Di%3A1%3Ba%3A2%3A%7B"..., e = 0x7ff17cf146d8 ""}, { b = 0x7ff17cf146d9 "Set-Cookie: wikicitiesrecentlyvisited=a%3A4%3A%7Bi%3A0%3Ba%3A2%3A%7Bs%3A3%3A%22url%22%3Bs%3A19%3A%22starcraft.wikia.com%22%3Bs%3A4%3A%22name%22%3Bs%3A14%3A%22StarCraft+Wiki%22%3B%7Di%3A1%3Ba%3A2%3A%7B"..., e = 0x7ff17cf1496e ""}, { b = 0x7ff17cf1496f "Set-Cookie: wikicitiesrecentlyvisited=a%3A4%3A%7Bi%3A0%3Ba%3A2%3A%7Bs%3A3%3A%22url%22%3Bs%3A19%3A%22starcraft.wikia.com%22%3Bs%3A4%3A%22name%22%3Bs%3A14%3A%22StarCraft+Wiki%22%3B%7Di%3A1%3Ba%3A2%3A%7B"..., e = 0x7ff17cf14c04 ""}, { b = 0x7ff17cf14c05 "Set-Cookie: wikicitiesrecentlyvisited=a%3A4%3A%7Bi%3A0%3Ba%3A2%3A%7Bs%3A3%3A%22url%22%3Bs%3A19%3A%22starcraft.wikia.com%22%3Bs%3A4%3A%22name%22%3Bs%3A14%3A%22StarCraft+Wiki%22%3B%7Di%3A1%3Ba%3A2%3A%7B"..., e = 0x7ff17cf14e9a ""}, {b = 0x7ff17cf14e9b "Vary: Accept- Encoding,Cookie", e = 0x7ff17cf14eb7 ""}, { b = 0x7ff17cf14eb8 "X-Vary-Options: Accept-Encoding;list- contains=gzip,Cookie;string-contains=wikicitiesToken;string- contains=wikicitiesLoggedOut;string-contains=wikicities_session", e = 0x7ff17cf14f58 ""}, { b = 0x7ff17cf14f59 "Expires: Thu, 01 Jan 1970 00:00:00 GMT", e = 0x7ff17cf14f7f ""}, { b = 0x7ff17cf14f80 "Cache-Control: private, must-revalidate, max- age=0", e = 0x7ff17cf14fb2 ""}, { b = 0x7ff17cf14fb3 "Last-modified: Sat, 14 Feb 2009 15:40:12 GMT", e = 0x7ff17cf14fdf ""}, { b = 0x7ff17cf14fe0 "Content-Encoding: gzip", e = 0x7ff17cf14ff6 ""}, {b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}}, hdf = '\0' , nhd = 26} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 16 15:12:21 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 16 Feb 2009 15:12:21 -0000 Subject: [Varnish] #448: Allow caching with past-date Expires (without cache-control) Message-ID: <052.231975af1f2f90f9a363156d9b36c5d3@projects.linpro.no> #448: Allow caching with past-date Expires (without cache-control) ----------------------+----------------------------------------------------- Reporter: stonor | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- In some cases you want aggressive caching, e.g. if the site is slashdotted and you want to take as much possible load off the backend. It works fairly well today be playing with set obj.ttl, but I've faced a case where it was not possible to set obj.ttl by hand without changing the backend headers -- and where I really missed the option: I have the "Expires" header is set to a past-date (to prevent in-browser caching) and no cache-controls headers. In that case the objects are set to non-cacheable. Adding a "cache-control" header with a max-age works, but I want to avoid tampering with the backend in this case. So: Could it be possible to set handmade obj.ttl on responses with past- date "Expires" headers (without additional cache related headers)? First request: {{{ 9 ReqStart c 127.0.0.1 36351 1202324732 9 RxRequest c GET 9 RxURL c /test_varnish 9 RxProtocol c HTTP/1.1 9 RxHeader c Host: localhost:8010 9 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6 9 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 RxHeader c Accept-Language: en-us,en;q=0.5 9 RxHeader c Accept-Encoding: gzip,deflate 9 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 RxHeader c Keep-Alive: 300 9 RxHeader c Connection: keep-alive 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 VCL_call c miss 9 VCL_return c fetch 10 BackendOpen b backend_0 127.0.0.1 48693 127.0.0.1 8080 9 Backend c 10 backend_0 backend_0 10 TxRequest b GET 10 TxURL b /test_varnish 10 TxProtocol b HTTP/1.1 10 TxHeader b Host: localhost:8010 10 TxHeader b User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6 10 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 TxHeader b Accept-Language: en-us,en;q=0.5 10 TxHeader b Accept-Encoding: gzip,deflate 10 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 10 TxHeader b X-Varnish: 1202324732 10 TxHeader b X-Forwarded-For: 127.0.0.1 10 RxProtocol b HTTP/1.1 10 RxStatus b 200 10 RxResponse b OK 10 RxHeader b Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 10 RxHeader b Date: Mon, 16 Feb 2009 15:08:21 GMT 10 RxHeader b Content-Length: 4 10 RxHeader b Expires: Tue, 27 Jan 2000 15:26:36 GMT 10 RxHeader b Content-Type: text/plain; charset=utf-8 9 ObjProtocol c HTTP/1.1 9 ObjStatus c 200 9 ObjResponse c OK 9 ObjHeader c Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 9 ObjHeader c Date: Mon, 16 Feb 2009 15:08:21 GMT 9 ObjHeader c Expires: Tue, 27 Jan 2000 15:26:36 GMT 9 ObjHeader c Content-Type: text/plain; charset=utf-8 10 BackendReuse b backend_0 9 TTL c 1202324732 RFC 0 1234796901 1234796901 948986796 0 0 9 VCL_call c fetch 9 TTL c 1202324732 VCL 86400 1234796901 9 VCL_return c pass 9 Length c 4 9 VCL_call c deliver 9 VCL_return c deliver 9 TxProtocol c HTTP/1.1 9 TxStatus c 200 9 TxResponse c OK 9 TxHeader c Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 9 TxHeader c Expires: Tue, 27 Jan 2000 15:26:36 GMT 9 TxHeader c Content-Type: text/plain; charset=utf-8 9 TxHeader c Content-Length: 4 9 TxHeader c X-Varnish-Action: FETCH (pass - not cacheable) 9 TxHeader c Date: Mon, 16 Feb 2009 15:08:21 GMT 9 TxHeader c X-Varnish: 1202324732 9 TxHeader c Age: 0 9 TxHeader c Via: 1.1 varnish 9 TxHeader c Connection: keep-alive 9 ReqEnd c 1202324732 1234796901.329282761 1234796901.334547043 0.000193834 0.005165339 0.000098944 }}} Second request, not cache hit: {{{ 9 ReqStart c 127.0.0.1 36353 1202324733 9 RxRequest c GET 9 RxURL c /test_varnish 9 RxProtocol c HTTP/1.1 9 RxHeader c Host: localhost:8010 9 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6 9 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 RxHeader c Accept-Language: en-us,en;q=0.5 9 RxHeader c Accept-Encoding: gzip,deflate 9 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 RxHeader c Keep-Alive: 300 9 RxHeader c Connection: keep-alive 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 HitPass c 1202324732 9 VCL_call c pass 9 VCL_return c pass 9 Backend c 10 backend_0 backend_0 10 TxRequest b GET 10 TxURL b /test_varnish 10 TxProtocol b HTTP/1.1 10 TxHeader b Host: localhost:8010 10 TxHeader b User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6 10 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 TxHeader b Accept-Language: en-us,en;q=0.5 10 TxHeader b Accept-Encoding: gzip,deflate 10 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 10 TxHeader b X-Varnish: 1202324733 10 TxHeader b X-Forwarded-For: 127.0.0.1 10 RxProtocol b HTTP/1.1 10 RxStatus b 200 10 RxResponse b OK 10 RxHeader b Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 10 RxHeader b Date: Mon, 16 Feb 2009 15:08:28 GMT 10 RxHeader b Content-Length: 4 10 RxHeader b Expires: Tue, 27 Jan 2000 15:26:36 GMT 10 RxHeader b Content-Type: text/plain; charset=utf-8 9 ObjProtocol c HTTP/1.1 9 ObjStatus c 200 9 ObjResponse c OK 9 ObjHeader c Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 9 ObjHeader c Date: Mon, 16 Feb 2009 15:08:28 GMT 9 ObjHeader c Expires: Tue, 27 Jan 2000 15:26:36 GMT 9 ObjHeader c Content-Type: text/plain; charset=utf-8 10 BackendReuse b backend_0 9 TTL c 1202324733 RFC 0 1234796908 1234796908 948986796 0 0 9 VCL_call c fetch 9 TTL c 1202324733 VCL 86400 1234796909 9 VCL_return c pass 9 Length c 4 9 VCL_call c deliver 9 VCL_return c deliver 9 TxProtocol c HTTP/1.1 9 TxStatus c 200 9 TxResponse c OK 9 TxHeader c Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 9 TxHeader c Expires: Tue, 27 Jan 2000 15:26:36 GMT 9 TxHeader c Content-Type: text/plain; charset=utf-8 9 TxHeader c Content-Length: 4 9 TxHeader c X-Varnish-Action: FETCH (pass - not cacheable) 9 TxHeader c Date: Mon, 16 Feb 2009 15:08:28 GMT 9 TxHeader c X-Varnish: 1202324733 9 TxHeader c Age: 0 9 TxHeader c Via: 1.1 varnish 9 TxHeader c Connection: keep-alive 9 ReqEnd c 1202324733 1234796908.797154903 1234796908.800419807 0.000104427 0.003054142 0.000210762 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 17 13:49:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 17 Feb 2009 13:49:26 -0000 Subject: [Varnish] #449: Crash in cache_ws.c with Varnish 2.0.3 Message-ID: <052.22242a63723f99d4f3e13e394d7f20f2@projects.linpro.no> #449: Crash in cache_ws.c with Varnish 2.0.3 ----------------------+----------------------------------------------------- Reporter: stonor | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Vanish dies everyone 2 - 4 hour - example debug message below. Platform: Debian Etch 64bit (2.6.18-6-xen-amd64) {{{ Child (14777) died signal=6 Child (14777) Panic message: Assert error in WS_Release(), cache_ws.c line 170: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker)sp = 0x2aaaece49008 { fd = 65, id = 65, xid = 1867801018, client = 127.0.0.1:48252, step = STP_HIT, handling = error, ws = 0x2aaaece49078 { id = "sess", {s,f,r,e} = {0x2aaaece49808,,+1191,(nil),+16384}, }, worker = 0x44807cf0 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x2aaaaaeae000 { refcnt = 2, xid = 1867715893, ws = 0x2aaaaaeae028 { id = "obj", {s,f,r,e} = {0x2aaaaaeae358,,+7292,+7336,+7336}, }, http = { ws = 0x2aaaaaeae028 { id = "obj", {s,f,r,e} = {0x2aaaaaeae358,,+7292,+7336,+7336}, }, hd = { "Server: Zope/(Zope 2.9.6-final, python 2.4.4, linux2) ZServer/1.1 Plone/2.5.3-final", "Date: Tue, 17 Feb 2009 12:05:44 GMT", "X-Cache-Headers-Set-By: CachingPolicyManager: /portal/caching_policy_manager", "Expires: Wed, 17 Feb 2010 12:05:44 GMT", "Last-Modified: Tue, 17 Feb 2009 12:05:44 GMT", "X-Caching-Rule-Id: resource-registries", "Cache-Control: max-age=31536000, s-maxage=31536000, public", "Content-Type: text/css;charset=utf-8", "X-Header-Set-Id: cache-in-browser-forever", "Content-Length: 15147", "X-Varnish-Action: HIT (deliver - from cache)", }, }, len = 15147, store = { 15147 { 0a 2f 2a 20 2d 20 4b 46 46 2d 68 6f 6d 65 70 61 |./* - KFF-homepa| 67 65 2e 63 73 73 20 2d 20 2a 2f 0a 40 6d 65 64 |ge.css - */. at med| 69 61 20 61 6c 6c 20 7b 0a 2f 2a 20 68 74 74 70 |ia all {./* http| 3a 2f 2f 77 77 77 2e 6b 75 6c 74 75 72 68 75 73 |://www.kulturhus| [15083 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 17 16:06:17 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 17 Feb 2009 16:06:17 -0000 Subject: [Varnish] #450: Varnish 2.0.3 compile using SunStudio 12 (w/ latest patches applied) Message-ID: <054.815087577ad79d2c94b8baad670dad3e@projects.linpro.no> #450: Varnish 2.0.3 compile using SunStudio 12 (w/ latest patches applied) -------------------------------+-------------------------------------------- Reporter: whocares | Type: defect Status: new | Priority: low Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: SunStudio Solaris | -------------------------------+-------------------------------------------- Compiling varnish using !SunStudio 12 always did require some tweaking of the compiler options, but with varnish 2.0.3 the newly added SHA256 stuff completely breaks compilation with !SunStudio 12. I've identified two reasons for that. 1) in /include/vsha256.h, !SunStudio chockes on this code: {{{ __BEGIN_DECLS void SHA256_Init(SHA256_CTX *); void SHA256_Update(SHA256_CTX *, const void *, size_t); void SHA256_Final(unsigned char [32], SHA256_CTX *); void SHA256_Test(void); __END_DECLS }}} 2) in /lib/libvarnish/vsha256.c, functions are declared with __inline I fixed both problems by adding the following code to the beginning of include/vsha256.h: {{{ #ifdef __SUNPRO_C #ifdef __cplusplus # ifndef __BEGIN_DECLS # define __BEGIN_DECLS extern "C" { # endif # ifndef __END_DECLS # define __END_DECLS } # endif #else # ifndef __BEGIN_DECLS # define __BEGIN_DECLS # endif # ifndef __END_DECLS # define __END_DECLS # endif #endif #define __inline #endif }}} Maybe there's a better place to put that, but it works for me right now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 17 20:17:07 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 17 Feb 2009 20:17:07 -0000 Subject: [Varnish] #430: Varnish crashes with Assert error in HSH_Deref In-Reply-To: <052.240c1acf64980e7d5debe86f76e68fc0@projects.linpro.no> References: <052.240c1acf64980e7d5debe86f76e68fc0@projects.linpro.no> Message-ID: <061.29688f0582dc21260b533f8b8b0bfa80@projects.linpro.no> #430: Varnish crashes with Assert error in HSH_Deref ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Still happening: {{ Feb 17 16:46:35 cache12 kernel: varnishd(pid 10221 uid 0) aborted: Assert error in HSH_Deref(), cache_hash.c line 430: Condition((oh)->magic == 0x1b96615d) not true. thread = (cache-timeout) (0x54a940) }} Anything I can do about this? I am using -h critbit. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 17 20:58:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 17 Feb 2009 20:58:25 -0000 Subject: [Varnish] #451: No X-Forwaded-For on piped requests Message-ID: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> #451: No X-Forwaded-For on piped requests -------------------+-------------------------------------------------------- Reporter: joel | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- When using pipe to handle a request, Varnish does not add X-Forwarded-For header Tested on 2.0.2 and 2.0.3 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 17 21:31:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 17 Feb 2009 21:31:20 -0000 Subject: [Varnish] #451: No X-Forwaded-For on piped requests In-Reply-To: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> References: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> Message-ID: <059.b2e8db6ed22ce4d4cbfb04b684562900@projects.linpro.no> #451: No X-Forwaded-For on piped requests --------------------+------------------------------------------------------- Reporter: joel | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by joel): It seemos no extra header is added, X-Varnish isn?t added -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 18 01:43:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 18 Feb 2009 01:43:25 -0000 Subject: [Varnish] #451: No X-Forwaded-For on piped requests In-Reply-To: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> References: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> Message-ID: <059.424c18e2def84ec15dc1952291ba4cbf@projects.linpro.no> #451: No X-Forwaded-For on piped requests --------------------+------------------------------------------------------- Reporter: joel | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by joel): Some more info on this subject: If varnish just started the first post request DOES contain X-Forwarded-For and X-Varnish headers, but not subsequent requests. After a few minutes the request will again get the headers once, provided you don?t access that specific URL for some time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 18 03:25:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 18 Feb 2009 03:25:43 -0000 Subject: [Varnish] #452: Support for chunked transfers on client requests Message-ID: <050.93acef03d0f4f2015972fae3662b5932@projects.linpro.no> #452: Support for chunked transfers on client requests ------------------+--------------------------------------------------------- Reporter: joel | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | ------------------+--------------------------------------------------------- HTTP/1.1 allows for clients to send chunked requests. Varnish does not support this silently drops de content. It should support chunked POST requests in order to be RFC compliant. References: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. Similar issue with nginx: http://www.ruby-forum.com/topic/141307 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 18 12:07:12 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 18 Feb 2009 12:07:12 -0000 Subject: [Varnish] #453: Assert error in WS_Release(), cache_ws.c line 170 Message-ID: <049.082c25eebb1351993cafbd750e5b4d24@projects.linpro.no> #453: Assert error in WS_Release(), cache_ws.c line 170 --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- {{{ Child (6824) Panic message: Assert error in WS_Release(), cache_ws.c line 170: Condition(bytes <= ws->e - ws->f) not true. errno = 107 (Transport endpoint is not connected) thread = (cache-worker)sp = 0x7faedda86008 { fd = 379, id = 379, xid = 433628655, client = 83.223.112.138:17948, step = STP_FETCH, handling = error, err_code = 200, err_reason = (null), ws = 0x7faedda86078 { id = "sess", {s,f,r,e} = {0x7faedda86808,,+3180,(nil),+131072}, }, worker = 0x7fb5385fcc00 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7fc6ace39000 { refcnt = 1, xid = 433628655, ws = 0x7fc6ace39028 { id = "obj", {s,f,r,e} = {0x7fc6ace39358,,+3211,+3240,+3240}, }, http = { ws = 0x7fc6ace39028 { id = "obj", {s,f,r,e} = {0x7fc6ace39358,,+3211,+3240,+3240}, }, hd = { "Server: Apache", "Content-language: en", "X-Article-Id: 0", }}} Segfault after roughly 24 hours of running. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 18 12:13:18 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 18 Feb 2009 12:13:18 -0000 Subject: [Varnish] #451: No X-Forwaded-For on piped requests In-Reply-To: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> References: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> Message-ID: <059.8cded8ffb795245291d1a713767955ed@projects.linpro.no> #451: No X-Forwaded-For on piped requests --------------------+------------------------------------------------------- Reporter: joel | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by joel): It?s not a bug, it?s by design: Varnish only alters the initial connection, all subsequent ones get passed through in pipe. Using set bereq.http.Connection = "Close"; on vcl_pipe solved the problem, forcing every connection to be the first one. thanks for the help on #varnish -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 18 20:40:08 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 18 Feb 2009 20:40:08 -0000 Subject: [Varnish] #451: No X-Forwaded-For on piped requests In-Reply-To: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> References: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> Message-ID: <059.58a528e420c60777d52ef54aa633cbd3@projects.linpro.no> #451: No X-Forwaded-For on piped requests --------------------+------------------------------------------------------- Reporter: joel | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by perbu): * owner: => phk Comment: I suggest we add the fix to the default VCL. pipe is to error-prone without it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 19 14:38:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 19 Feb 2009 14:38:25 -0000 Subject: [Varnish] #451: No X-Forwaded-For on piped requests In-Reply-To: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> References: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> Message-ID: <059.f91a8416473015e698c0884ea7177941@projects.linpro.no> #451: No X-Forwaded-For on piped requests --------------------+------------------------------------------------------- Reporter: joel | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): I can not determine if {{{Connection: Close}}} by default is a good idea, we need somebody with webmaster-clue to chime in on it. My fear is that it would ruin the "pipe will always work" property by breaking sessions that hold state etc. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 19 23:28:30 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 19 Feb 2009 23:28:30 -0000 Subject: [Varnish] #434: Critbit crash: Assert error in hcb_delete In-Reply-To: <052.353eed9a394c1c1c65c805e20fcbf6b0@projects.linpro.no> References: <052.353eed9a394c1c1c65c805e20fcbf6b0@projects.linpro.no> Message-ID: <061.3438e3a3b90b28862e20b886fed1dce9@projects.linpro.no> #434: Critbit crash: Assert error in hcb_delete ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): This just happened again, with trunk/3534 in FreeBSD/amd64 7.1-RELEASE: {{{ Feb 19 22:08:52 cache3 varnishd[4650]: Child (4651) Panic message: Assert error in hcb_delete(), hash_critbit.c line 266: Condition(hcb_is_y(*p)) not true. thread = (cache-timeout) }}} What to do? No core dump was attempted. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 20 17:05:51 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 20 Feb 2009 17:05:51 -0000 Subject: [Varnish] #451: No X-Forwaded-For on piped requests In-Reply-To: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> References: <050.462f53ad036d807bb4c71ce294a1ab4f@projects.linpro.no> Message-ID: <059.a5b7553f25d06747a7639eea10b7e22b@projects.linpro.no> #451: No X-Forwaded-For on piped requests --------------------+------------------------------------------------------- Reporter: joel | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by joel): Any HTTP connection by RFC SHOULD degrade gracefully to non Keep-Alive (Close) connections, as connection close is the default behaviour As long as it is with HTTP in mind there probably shouldn?t be any problem unless you are trying to use varnish with a custom made backend that requires persistant connections. Even without connection: close by default, the connection does get closed eventually. Or if this http://varnish.projects.linpro.no/ticket/452 worked we probably wouldn?t need pipe for post requests, only for non-standard request methods. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 20 18:07:49 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 20 Feb 2009 18:07:49 -0000 Subject: [Varnish] #414: Another Varnish crash with -h critbit In-Reply-To: <052.d1b5f20b8f9b6ec243165098c2b9a912@projects.linpro.no> References: <052.d1b5f20b8f9b6ec243165098c2b9a912@projects.linpro.no> Message-ID: <061.93fb88c98beddb69d403dafae5b984fd@projects.linpro.no> #414: Another Varnish crash with -h critbit ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): commit r3799 fixes a problem in trunk which has similar symptoms. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 21 16:45:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 21 Feb 2009 16:45:02 -0000 Subject: [Varnish] #454: Generating graphs takes to long Message-ID: <051.ded88af6345cd7ebad88ba647052c271@projects.linpro.no> #454: Generating graphs takes to long --------------------+------------------------------------------------------- Reporter: perbu | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: webgui | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- When generating a graph with a summary of the last day or week the application takes a long time to generate the graph. A "generating graph" would be nice. Maybe some sort of RRD database should be used or the graphs should be pregenerated?hhhhhhh -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 21 20:08:41 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 21 Feb 2009 20:08:41 -0000 Subject: [Varnish] #374: Implement restart in vcl_error In-Reply-To: <053.fd2fc11de17ab07a4a0b42ad6d8273db@projects.linpro.no> References: <053.fd2fc11de17ab07a4a0b42ad6d8273db@projects.linpro.no> Message-ID: <062.f5163811b58dcaf0d6af4bf76d954cd0@projects.linpro.no> #374: Implement restart in vcl_error -------------------------------+-------------------------------------------- Reporter: tcouery | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: restart vcl_error | -------------------------------+-------------------------------------------- Comment (by mtempels): Yes.. this would be a great feature! Cheers Matthijs -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Feb 22 16:33:48 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 22 Feb 2009 16:33:48 -0000 Subject: [Varnish] #455: Make HTTP_HDR_MAX a ./configure option Message-ID: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> #455: Make HTTP_HDR_MAX a ./configure option -------------------------+-------------------------------------------------- Reporter: whocares | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: max headers -------------------------+-------------------------------------------------- While test driving varnish we ran into the "503 if too many headers received from backend" problem. Now, I don't want to start a discussion about how many headers a backend application may / should send. But it would be really nice if this could be configured while buildling varnish, so that I wouldn't have to patch up the code for every new release/build. Making HTTP_HDR_MAX configurable by the user (with a sensible default and also a sensible cap) would "solve" this problem for those users for whom the default just isn't enough and who can't fix the backend app (like in my case, closed software, no chance to fix anything :-(). So, an --with-max-header-fields= option to the configure script would be highly appreciated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Feb 22 22:32:45 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 22 Feb 2009 22:32:45 -0000 Subject: [Varnish] #455: Make HTTP_HDR_MAX a ./configure option In-Reply-To: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> References: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> Message-ID: <063.b5be491a7e7a305dbd0ee9d29716be28@projects.linpro.no> #455: Make HTTP_HDR_MAX a ./configure option -------------------------+-------------------------------------------------- Reporter: whocares | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: max headers | -------------------------+-------------------------------------------------- Comment (by whocares): Well, I gave it a try and here's what I came up with: {{{ # Define HTTP_HDR_MAX AC_ARG_WITH(max-header-fields, AS_HELP_STRING([--with-max-header-fields=NUM], [How many header fields to support (default=32)]), [], [with_max_header_fields=32]) if test $with_max_header_fields -lt 32; then with_max_header_fields=32 AC_MSG_WARN([--with-max-header-fields increased to 32]) fi if test $with_max_header_fields -gt 256; then with_max_header_fields=256 AC_MSG_WARN([--with-max-header-fields decreased to 256]) fi AC_DEFINE_UNQUOTED(HTTP_HDR_MAX, $with_max_header_fields, [Define maximum number of header fields supported by v arnish ]) }}} Adapt and edit as you feel fit (I guess 256 is way too high, just used that for testing) and add to configure.ac. And if this snippet above is ugly as hell and makes any autoconf guru freak out: Sorry, that's my first go at this stuff - works for me, ymmv ;) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 23 08:19:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 23 Feb 2009 08:19:15 -0000 Subject: [Varnish] #455: Make HTTP_HDR_MAX a ./configure option In-Reply-To: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> References: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> Message-ID: <063.0bdb4f0f4a277f9c3f978601369efecc@projects.linpro.no> #455: Make HTTP_HDR_MAX a ./configure option -------------------------+-------------------------------------------------- Reporter: whocares | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: max headers | -------------------------+-------------------------------------------------- Comment (by whocares): Forgot to mention some details for those who want to apply the above snippet manually: * I added this to {{{configure.ac}}} right before the test for {{{jemalloc}}} * It will write the value for {{{HTTP_HDR_MAX}}} to {{{config.h}}} * Thus you'll have to delete the {{{#define HTTP_HDR_MAX 32}}} from {{{bin/varnishd/cache.h}}} to really make it work, otherwise the value from {{{config.h}}} will get overwritten by the one in {{{cache.h}}} which is included at a later point during compilation -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 23 09:58:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 23 Feb 2009 09:58:42 -0000 Subject: [Varnish] #455: Make HTTP_HDR_MAX a ./configure option In-Reply-To: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> References: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> Message-ID: <063.bef9380c3bab39cd62cf6ac9d3e34277@projects.linpro.no> #455: Make HTTP_HDR_MAX a ./configure option -------------------------+-------------------------------------------------- Reporter: whocares | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: max headers | -------------------------+-------------------------------------------------- Comment (by whocares): Sorry again, it must have been too late yesterday. Please replace all {{{HTTP_HDR_MAX}}} in the code snippet and the addition above with {{{HTTP_HDR_MAX_VAL}}}. I packed the whole stuff into the attached patch file. The patch also add's the "fix" for Sun Studio 12 not recognizing the {{{__inline}}} statements in {{{vsha256.c}}}. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 23 13:28:18 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 23 Feb 2009 13:28:18 -0000 Subject: [Varnish] #456: mixture of malloc, and file storage Message-ID: <053.6ba11517800860bbf4a44ee483fcda97@projects.linpro.no> #456: mixture of malloc, and file storage -------------------------+-------------------------------------------------- Reporter: dotmind | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- Hello, Is there a way to limit the phisical memory what varnish uses, while having a file storage for the not so recently used objects? I have the backend on the same computer which varnish running, and I don't want varnish eats up the memory from apache. It happened with file storage, but when I use malloc, I cannot set up a file storage for 'varnish swap'. I use varnish 2.0.3, on Debian Etch 64bit. Thanks, sorry for my english.. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 23 13:47:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 23 Feb 2009 13:47:27 -0000 Subject: [Varnish] #454: Generating graphs takes to long In-Reply-To: <051.ded88af6345cd7ebad88ba647052c271@projects.linpro.no> References: <051.ded88af6345cd7ebad88ba647052c271@projects.linpro.no> Message-ID: <060.7c3703fb1239b558b39ecdd9774ca02f@projects.linpro.no> #454: Generating graphs takes to long --------------------+------------------------------------------------------- Reporter: perbu | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: webgui | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by petter): r3812 and r3805 should have added some speed to the graph generation, at least for minute, hour and day graphs. If week graphs are slow some aggregation will be added. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 24 23:36:38 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 24 Feb 2009 23:36:38 -0000 Subject: [Varnish] #437: Varnish 2.0.2 hanging with large amounts of traffic In-Reply-To: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> References: <049.251897e59bb49a5cfc6b8575603422fc@projects.linpro.no> Message-ID: <058.0d576cfd90499aa9a82fadc7bb5946dd@projects.linpro.no> #437: Varnish 2.0.2 hanging with large amounts of traffic ----------------------+----------------------------------------------------- Reporter: ajt | Owner: perbu Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by rafailowski): I had a similary problem with varnish 2.0.2, it just stop working near ~900 users without any message but exactly the same symptom like yours. {{{ 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233794898 1.0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1233794901 1.0 }}} After an upgrade to 2.0.3, varnish runs without any problem and now all is fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 09:37:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 09:37:24 -0000 Subject: [Varnish] #426: Can't get the occurrences using "regsub". In-Reply-To: <058.887f38c4ba01f04859a3493305742721@projects.linpro.no> References: <058.887f38c4ba01f04859a3493305742721@projects.linpro.no> Message-ID: <067.98fe5a68841d077f94bb0a63e0a116ab@projects.linpro.no> #426: Can't get the occurrences using "regsub". ----------------------------------+----------------------------------------- Reporter: basilio.vera | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: duplicate Keywords: regsub occurrence $n | ----------------------------------+----------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate * component: build => varnishd Comment: The syntax is \n, not $n, this is documented correctly in 2.0.3 and newer. Resolving as duplicate of the previous bug report. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 09:51:58 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 09:51:58 -0000 Subject: [Varnish] #428: Sending badly formed parameters to the management console kills Varnish In-Reply-To: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> References: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> Message-ID: <061.5dcd2f247b95d79422a510660823d575@projects.linpro.no> #428: Sending badly formed parameters to the management console kills Varnish ----------------------+----------------------------------------------------- Reporter: petter | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * owner: phk => tfheen Comment: Sending param.set acceptor HASH(0x8839c4c) currently makes it hiccup. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 09:55:32 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 09:55:32 -0000 Subject: [Varnish] #428: Sending badly formed parameters to the management console kills Varnish In-Reply-To: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> References: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> Message-ID: <061.277603bb4bf5c5397cde95c0c9cd3113@projects.linpro.no> #428: Sending badly formed parameters to the management console kills Varnish ----------------------+----------------------------------------------------- Reporter: petter | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): Make that param.set waiter HASH(0x8839c4c) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 10:25:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 10:25:44 -0000 Subject: [Varnish] #428: Sending badly formed parameters to the management console kills Varnish In-Reply-To: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> References: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> Message-ID: <061.ac5fb49204112db3b6976350e755f3d5@projects.linpro.no> #428: Sending badly formed parameters to the management console kills Varnish ----------------------+----------------------------------------------------- Reporter: petter | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [3825]) Stop segfaulting when trying to set a nonexistant waiter We failed to properly check for the end of the list of waiters. Handle this correctly and add a test case Fixes #428 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 10:30:55 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 10:30:55 -0000 Subject: [Varnish] #439: adding several cookie will remove redirection In-Reply-To: <056.a60faa3b741776d321e3406485e54948@projects.linpro.no> References: <056.a60faa3b741776d321e3406485e54948@projects.linpro.no> Message-ID: <065.e59606badfbadf08080fbdc9f1ccc060@projects.linpro.no> #439: adding several cookie will remove redirection ------------------------+--------------------------------------------------- Reporter: scouzinier | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by tfheen): Try increasing the session and/or object workspaces. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 10:35:45 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 10:35:45 -0000 Subject: [Varnish] #443: solaris --enable-tests breaks In-Reply-To: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> References: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> Message-ID: <061.039da1cd372deea8eca697085a2dd468@projects.linpro.no> #443: solaris --enable-tests breaks ---------------------+------------------------------------------------------ Reporter: kapilt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: solaris | ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: The first bug has been fixed in r3777, I'll merge it to 2.0 as well. Any chance you could give -trunk a spin? It should at least compile now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 10:46:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 10:46:02 -0000 Subject: [Varnish] #454: Generating graphs takes to long In-Reply-To: <051.ded88af6345cd7ebad88ba647052c271@projects.linpro.no> References: <051.ded88af6345cd7ebad88ba647052c271@projects.linpro.no> Message-ID: <060.29d7385a5520c84fbee0c7bc28d28280@projects.linpro.no> #454: Generating graphs takes to long --------------------+------------------------------------------------------- Reporter: perbu | Owner: petter Type: defect | Status: closed Priority: normal | Milestone: Component: webgui | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by petter): * status: new => closed * resolution: => fixed Comment: Consider it fixed until proven otherwise. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 12:00:58 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 12:00:58 -0000 Subject: [Varnish] #443: solaris --enable-tests breaks In-Reply-To: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> References: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> Message-ID: <061.4780cccc9c18f64b48d612cf0cd536a3@projects.linpro.no> #443: solaris --enable-tests breaks ---------------------+------------------------------------------------------ Reporter: kapilt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: solaris | ---------------------+------------------------------------------------------ Comment (by whocares): The latest source from trunk doesn't compile - at least not when using Sun Studio 12 instead of gcc. With gcc it does compile fine. The reason for the problems with Sun Studio still is the {{{__inline}}} definition of the functions in vsha256.c as outlined in #450. Here's the script I'm using to compile varnish: {{{ #!/usr/bin/bash cd varnish.svn/varnish-cache export CFLAGS="-fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -xlibmil -xcrossfile -Kpic" export CPPFLAGS="-fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -xlibmil -xcrossfile -Kpic" export LDFLAGS="-fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -xlibmil -xcrossfile -Kpic" export VCC_CC="cc -fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -Kpic -c -o %o %s" ./autogen.sh if [ -f config.log ]; then gmake distclean 2>&1 >> /dev/null fi ./configure --prefix=/opt/soft/varnish \ --localstatedir=/cache/varnish \ --sysconfdir=/opt/conf \ --enable-diagnostics \ --with-max-header-fields=48 \ gmake }}} The result is: {{{ /bin/bash ../../libtool --tag=CC --mode=compile /opt/SUNWspro/bin/cc -xc99=all -DHAVE_CONFIG_H -I. -I../.. -I../../include -fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -xlibmil -xcrossfile -Kpic -fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -xlibmil -xcrossfile -Kpic -DDIAGNOSTICS -c -o vsha256.lo vsha256.c /opt/SUNWspro/bin/cc -xc99=all -DHAVE_CONFIG_H -I. -I../.. -I../../include -fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -xlibmil -xcrossfile -Kpic -fast -xtarget=opteron -m64 -xpagesize=2M -mt -xlibmopt -xlibmil -xcrossfile -Kpic -DDIAGNOSTICS -c vsha256.c -KPIC -DPIC -o .libs/vsha256.o "vsha256.c", line 48: warning: no explicit type given "vsha256.c", line 48: syntax error before or at: void "vsha256.c", line 59: warning: no explicit type given "vsha256.c", line 59: syntax error before or at: void "vsha256.c", line 80: warning: no explicit type given "vsha256.c", line 80: syntax error before or at: uint32_t cc: acomp failed for vsha256.c gmake[3]: *** [vsha256.lo] Error 1 gmake[3]: Leaving directory `/storage/soft/varnish.svn/varnish- cache/lib/libvarnish' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/storage/soft/varnish.svn/varnish-cache/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/storage/soft/varnish.svn/varnish-cache' gmake: *** [all] Error 2 }}} Verion of {{{cc}}} used: {{{ #root at soldev:idgsoft# cc -V cc: Sun C 5.9 SunOS_i386 Patch 124868-08 2008/11/25 usage: cc [ options] files. Use 'cc -flags' for details }}} My current solution is to add this to {{{include/vsha256.c}}}: {{{ #ifdef __SUNPRO_C #define __inline #endif }}} Would be nice if this little tidbit could be included. It's also part of the patch I attached to #455. If access to a solaris machine with Sun Studio is needed to do some testing whether this breaks the code, I could provide that, too. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 12:03:46 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 12:03:46 -0000 Subject: [Varnish] #443: solaris --enable-tests breaks In-Reply-To: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> References: <052.0d51a64ee3258d020bd6209138c48706@projects.linpro.no> Message-ID: <061.94a62d5a4e3a6c05bb5bf03a82c2fd69@projects.linpro.no> #443: solaris --enable-tests breaks ---------------------+------------------------------------------------------ Reporter: kapilt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: solaris | ---------------------+------------------------------------------------------ Comment (by whocares): Ok, forget that. I got called away while typing and in the meantime you fixed it ;) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 25 19:56:59 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 25 Feb 2009 19:56:59 -0000 Subject: [Varnish] #456: mixture of malloc, and file storage In-Reply-To: <053.6ba11517800860bbf4a44ee483fcda97@projects.linpro.no> References: <053.6ba11517800860bbf4a44ee483fcda97@projects.linpro.no> Message-ID: <062.383fdaa93bba1a423d6161166ebdd8b8@projects.linpro.no> #456: mixture of malloc, and file storage -------------------------+-------------------------------------------------- Reporter: dotmind | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by perbu): * status: new => closed * resolution: => invalid Comment: Hello, You can limit the amount of memory by using a small cache. Varnish will probably never support a two tier caching scheme. See http://varnish.projects.linpro.no/wiki/ArchitectNotes for an explanation of why. Per. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 27 11:16:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 27 Feb 2009 11:16:24 -0000 Subject: [Varnish] #457: Doesn't work when cil_banner is on Message-ID: <052.8068a3839384c29f74be95e5c18c1882@projects.linpro.no> #457: Doesn't work when cil_banner is on ------------------------+--------------------------------------------------- Reporter: petter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- The CLI banner breaks varnishadm, as it doesn't expect it. A workaround is to manually telnet to the management port and do a {{{ param.set cli_banner off }}} to diasable the CLI banner. -- Ticket URL: Varnish The Varnish HTTP Accelerator From ajian521 at gmail.com Fri Feb 27 17:41:21 2009 From: ajian521 at gmail.com (Ajian) Date: Sat, 28 Feb 2009 01:41:21 +0800 Subject: help me , Solve the problem about purge cache Message-ID: <9ab009b80902270941v456908coc439a5d0d6768f17@mail.gmail.com> This is not the varnish bug. But I don't know how to solve it ,and the document is few.Please help me .Thanks. The problem is about how to purge the cache by the http. When my hash is the fellow ,I can solve it sub vcl_hash { set req.hash += req.url; hash; } I have write a php file to purge the cache But, I change the hash, use the similar way but can't clear it ,output "tHTTP/1.1 404 Not in cache " sub vcl_hash { set req.hash += req.url; if (req.http.host) { set req.hash += req.http.host; } else { set req.hash += server.ip; } if (req.http.Accept-Encoding) { set req.hash += req.http.Accept-Encoding; } hash; } who can tell me how to purge the hash cache ,how to write the php ,I need through remote empty cache ,thanks. I hope you can understand what I mean, my English is pool. Ajian I -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at projects.linpro.no Sat Feb 28 19:49:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 28 Feb 2009 19:49:02 -0000 Subject: [Varnish] #458: b17 and c22 tests fail: SEGV on Solaris if VRT_error called with reason==NULL Message-ID: <051.3991c000d3d368d8291f8a4b03cf43ab@projects.linpro.no> #458: b17 and c22 tests fail: SEGV on Solaris if VRT_error called with reason==NULL ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- If VRT_error is called with reason==NULL, WSL() will eventually call strlen(0), which will cause a SEGV on (Open)Solaris. The workaround is, in a VCL, not to call error with a reason, e.g. error(888,"My fatal abort"); rather than just error(888); -- Ticket URL: Varnish The Varnish HTTP Accelerator