From varnish-bugs at varnish-cache.org Sun Jan 3 11:49:03 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 03 Jan 2016 11:49:03 -0000 Subject: [Varnish] #1834: WS_Assert(), cache/cache_ws.c line 59 Message-ID: <046.80c97970f64c1eaf8d7737ca99019770@varnish-cache.org> #1834: WS_Assert(), cache/cache_ws.c line 59 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Keywords: ----------------------+------------------- {{{ Child (26501) Panic message: Assert error in WS_Assert(), cache/cache_ws.c line 59: Condition(*ws->e == 0x15) not true. thread = (cache-worker) version = varnish-4.1.0 revision 3041728 ident = Linux,4.3.0,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433505: varnishd() [0x433505] 0x449886: varnishd(WS_Assert+0x176) [0x449886] 0x44a271: varnishd(WS_ReleaseP+0x11) [0x44a271] 0x43a3dd: varnishd(SES_RxStuff+0x1dd) [0x43a3dd] 0x44dd48: varnishd(HTTP1_Session+0x188) [0x44dd48] 0x439831: varnishd(SES_Proto_Req+0x61) [0x439831] 0x4486ca: varnishd() [0x4486ca] 0x448b2b: varnishd() [0x448b2b] 0x7f9dfcffb0a4: libpthread.so.0(+0x80a4) [0x7f9dfcffb0a4] 0x7f9dfcd3004d: libc.so.6(clone+0x6d) [0x7f9dfcd3004d] req = 0x7f9deb018020 { vxid = 0, step = R_STP_RESTART, req_body = R_BODY_INIT, restarts = 0, esi_level = 0, sp = 0x7f9deb00e220 { fd = 20, vxid = 32769, client = 2001:67c:29f4::50 52598, step = S_STP_H1NEWREQ, }, ws = 0x7f9deb018200 { id = "req", {s,f,r,e} = {0x7f9deb01a000,+32768,+57336,+57336}, }, http_conn = 0x7f9deb018128 { fd = 20, doclose = NULL, ws = 0x7f9deb018200, {rxbuf_b, rxbuf_e} = {0x7f9deb022000, 0x7f9deb029fcb}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = 0, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7f9deb018298 { ws[] = (nil), hdrs { }, }, flags = { }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 3 12:11:27 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 03 Jan 2016 12:11:27 -0000 Subject: [Varnish] #1834: WS_Assert(), cache/cache_ws.c line 59 In-Reply-To: <046.80c97970f64c1eaf8d7737ca99019770@varnish-cache.org> References: <046.80c97970f64c1eaf8d7737ca99019770@varnish-cache.org> Message-ID: <061.3412f82f7bde57250bd53847a7be8ef6@varnish-cache.org> #1834: WS_Assert(), cache/cache_ws.c line 59 ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): No new panics observed after bumping workspace_client to 96k. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 4 12:30:02 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Jan 2016 12:30:02 -0000 Subject: [Varnish] #1832: Bad request instead of RC 413 when http_max_hdr exceeded In-Reply-To: <041.6df65ccbe8964851377cf672163df7a8@varnish-cache.org> References: <041.6df65ccbe8964851377cf672163df7a8@varnish-cache.org> Message-ID: <056.75b4045a297ae8eb13cff0d2dccd4cf4@varnish-cache.org> #1832: Bad request instead of RC 413 when http_max_hdr exceeded ----------------------+---------------------------------- Reporter: vko | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: wontfix Keywords: | ----------------------+---------------------------------- Changes (by lkarsten): * status: new => closed * resolution: => wontfix Comment: Hi. The use of 413 vs 400 has been discussed a few times in the past, and I don't think there is any new information here. I don't see the client changing its behavior automatically based on the return code, so manual intervention would be required. In browsers, the user probably won't even see what we return. If you feel strongly about it, send a patch. Related: #1608 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 4 12:41:03 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Jan 2016 12:41:03 -0000 Subject: [Varnish] #1832: Bad request instead of RC 413 when http_max_hdr exceeded In-Reply-To: <041.6df65ccbe8964851377cf672163df7a8@varnish-cache.org> References: <041.6df65ccbe8964851377cf672163df7a8@varnish-cache.org> Message-ID: <056.8a599c36f368cb0413ca09dbbec84c71@varnish-cache.org> #1832: Bad request instead of RC 413 when http_max_hdr exceeded ----------------------+---------------------------------- Reporter: vko | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: wontfix Keywords: | ----------------------+---------------------------------- Comment (by lkarsten): Also related is #416, including `tests/r00416.vtc` which shows the current behavior. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 5 16:05:04 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 05 Jan 2016 16:05:04 -0000 Subject: [Varnish] #1835: 4.0 online documentation outdated? Message-ID: <046.1b5d1dfe21306aa13583e2b894e16523@varnish-cache.org> #1835: 4.0 online documentation outdated? ---------------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: unknown Severity: normal | Keywords: ---------------------------+--------------------- https://www.varnish-cache.org/docs/4.0/users-guide/increasing-your- hitrate.html says "4.0.3-rc1". Shouldn't it be 4.0.3? (originally internal VS ticket number: T137) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 6 19:14:31 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 06 Jan 2016 19:14:31 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.154a0a0d81f80d0e76c2d17f0fa5da52@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+---------------------------------------- Reporter: hamed.gholamian | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | -----------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [0be9404f18efeccd430698837c2806662b32523a]: {{{ #!CommitTicketReference repository="" revision="0be9404f18efeccd430698837c2806662b32523a" Rush the objheader if there is a waiting list when it is deref'ed. Fixes: #1823 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 7 18:25:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 07 Jan 2016 18:25:15 -0000 Subject: [Varnish] #1836: Varnish can allocate much less memory than limit Message-ID: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> #1836: Varnish can allocate much less memory than limit ---------------------------------+--------------------- Reporter: onovy | Type: defect Status: new | Priority: high Milestone: Varnish 4.0 release | Component: regress Version: 4.0.2 | Severity: major Keywords: | ---------------------------------+--------------------- Hi, i have Varnish 4.0.2 from official Debian Jessie (not your repo). cmd: /usr/sbin/varnishd -P /run/varnishd.pid -a localhost:6081 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,64G so malloc with 64 GB limit. According to varnishstat: {{{ SMA.s0.g_bytes 68719421626 . Bytes outstanding SMA.s0.g_space 55110 . Bytes available }}} all memory (64 G) is allocated. But that is not true: {{{ # free -m total used free shared buffers cached Mem: 96774 31615 65159 1 0 10205 -/+ buffers/cache: 21408 75366 Swap: 6143 0 6143 }}} Varnish allocate only 19 G: {{{ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9229 nobody 20 0 0.098t 0.018t 85376 S 4.3 19.8 145:51.35 varnishd }}} Object counts (MAIN.n_object*)[[BR]] [[Image(http://s14.postimg.org/bgovmgd4x/staz_eny_soubor.png)]] LRU (MAIN.n_lru_*)[[BR]] [[Image(http://s13.postimg.org/9tw4olqev/staz_eny_soubor_1.png)]] Thanks for help -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 7 18:27:44 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 07 Jan 2016 18:27:44 -0000 Subject: [Varnish] #1836: Varnish can allocate much less memory than limit In-Reply-To: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> References: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> Message-ID: <058.6f80e3a5c5124327dedfb67ea885ca5b@varnish-cache.org> #1836: Varnish can allocate much less memory than limit ---------------------+---------------------------------- Reporter: onovy | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: regress | Version: 4.0.2 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Comment (by onovy): this bug can be related to: https://github.com/varnish/Varnish-Cache/pull/80 but doesn't explain why the counter (g_bytes) still saying 64G since that one is being decremented -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 7 21:38:28 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 07 Jan 2016 21:38:28 -0000 Subject: [Varnish] #1836: Varnish can allocate much less memory than limit In-Reply-To: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> References: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> Message-ID: <058.5ad9abe74cb0c3d07861df943ec3c8d1@varnish-cache.org> #1836: Varnish can allocate much less memory than limit ---------------------+---------------------------------- Reporter: onovy | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: regress | Version: 4.0.2 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Comment (by onovy): this seems to be related: https://www.varnish-cache.org/trac/ticket/1617 i will try lower fetch_chunksize -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 8 16:25:53 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 08 Jan 2016 16:25:53 -0000 Subject: [Varnish] #1797: Content-Type/Content-Length should miss on 304 requests In-Reply-To: <048.25fbf3261b6557b2bc77d60ef0f32406@varnish-cache.org> References: <048.25fbf3261b6557b2bc77d60ef0f32406@varnish-cache.org> Message-ID: <063.75512bb29fdeaa4c78c8a166aa423bdb@varnish-cache.org> #1797: Content-Type/Content-Length should miss on 304 requests ------------------------+---------------------- Reporter: shakalandy | Owner: fgsch Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: invalid Keywords: | ------------------------+---------------------- Changes (by fgsch): * status: assigned => closed * resolution: => invalid Comment: I've had some long thought about this. The Content-Length part is already done in 4.1, minus the zero Content- Length case. The latter is fixed in master. Specific headers aside, as the text from RFC7232 4.1 states, the goal here is to minimize information transfer. I don't see how this could affect upstream caches and/or force unnecessary revalidations. It's also worth noting that while perhaps not ideal, it's not prohibited (SHOULD NOT as opposed to MUST NOT). As such I feel this falls into the feature request category. A better place to raise this would be: https://www.varnish-cache.org/trac/wiki/Future_Feature. If you are adamant on this point, you can always unset the headers in VCL. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 9 14:22:08 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 09 Jan 2016 14:22:08 -0000 Subject: [Varnish] #1836: Varnish can allocate much less memory than limit In-Reply-To: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> References: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> Message-ID: <058.22bea0323471a40a16991394175d3801@varnish-cache.org> #1836: Varnish can allocate much less memory than limit ---------------------+---------------------------------- Reporter: onovy | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: regress | Version: 4.0.2 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Comment (by onovy): lower fetch_chunksize helps a low. yep, it's duplicate of #1617 you can close -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 9 15:44:11 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 09 Jan 2016 15:44:11 -0000 Subject: [Varnish] #1836: Varnish can allocate much less memory than limit In-Reply-To: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> References: <043.6b4529fa2475dc404287dd45ac897fd7@varnish-cache.org> Message-ID: <058.4572127b6f42fc22d12b3cc06565ca05@varnish-cache.org> #1836: Varnish can allocate much less memory than limit ---------------------+---------------------------------- Reporter: onovy | Owner: Type: defect | Status: closed Priority: high | Milestone: Varnish 4.0 release Component: regress | Version: 4.0.2 Severity: major | Resolution: worksforme Keywords: | ---------------------+---------------------------------- Changes (by lkarsten): * status: new => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 11:36:42 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 11:36:42 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service In-Reply-To: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> References: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> Message-ID: <063.d45de40dd9db7b2bd9a8d6d9d56d7736@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service ------------------------+-------------------- Reporter: ghostshell | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ------------------------+-------------------- Comment (by fgsch): Related to #1802? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 12:05:18 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 12:05:18 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service In-Reply-To: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> References: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> Message-ID: <063.70791e54d27d4a03c170609069e0a871@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service ------------------------+-------------------- Reporter: ghostshell | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ------------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 12:05:28 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 12:05:28 -0000 Subject: [Varnish] #1802: Segfault after VCL change In-Reply-To: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> References: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> Message-ID: <061.1037be05c49fd901e97b65dbc1d4a8a1@varnish-cache.org> #1802: Segfault after VCL change ----------------------+-------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 12:08:05 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 12:08:05 -0000 Subject: [Varnish] #1835: 4.0 online documentation outdated? In-Reply-To: <046.1b5d1dfe21306aa13583e2b894e16523@varnish-cache.org> References: <046.1b5d1dfe21306aa13583e2b894e16523@varnish-cache.org> Message-ID: <061.e026f4c2de7c22b355d0c0a7ea970d5a@varnish-cache.org> #1835: 4.0 online documentation outdated? ---------------------------+----------------------- Reporter: lkarsten | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: documentation | Version: unknown Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Changes (by fgsch): * status: new => assigned * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 12:15:43 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 12:15:43 -0000 Subject: [Varnish] #1834: WS_Assert(), cache/cache_ws.c line 59 In-Reply-To: <046.80c97970f64c1eaf8d7737ca99019770@varnish-cache.org> References: <046.80c97970f64c1eaf8d7737ca99019770@varnish-cache.org> Message-ID: <061.422cef5d9fcafb229c0c635bd0149224@varnish-cache.org> #1834: WS_Assert(), cache/cache_ws.c line 59 ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): This was seen when doing bulk image uploads (pass-ed) through Varnish to a backend service that was running 10 worker threads. Most likely a lot of connections where being attempted to the backend. No connection limit set in Varnish. Reportedly also tried to pipe them, without success. (which is odd) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 12:22:11 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 12:22:11 -0000 Subject: [Varnish] #1834: WS_Assert(), cache/cache_ws.c line 59 In-Reply-To: <046.80c97970f64c1eaf8d7737ca99019770@varnish-cache.org> References: <046.80c97970f64c1eaf8d7737ca99019770@varnish-cache.org> Message-ID: <061.f9c60a720c04544a93808b4d1964bba4@varnish-cache.org> #1834: WS_Assert(), cache/cache_ws.c line 59 ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): No vmods except std. I got the part about pipe wrong, uploads are being piped now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 12:22:31 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 12:22:31 -0000 Subject: [Varnish] #1833: sphinx rendering problem for users-guide/increasing-your-hitrate.txt In-Reply-To: <047.ed8db0328b114af68978ab2326329442@varnish-cache.org> References: <047.ed8db0328b114af68978ab2326329442@varnish-cache.org> Message-ID: <062.49cad95b418f299163a0e65b98f02f7b@varnish-cache.org> #1833: sphinx rendering problem for users-guide/increasing-your-hitrate.txt ---------------------------+---------------------- Reporter: mfournier | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | ---------------------------+---------------------- Changes (by fgsch): * status: needinfo => closed * resolution: => invalid Comment: The TOC could be improved but the content is there, I don't see anything missing. If there is indeed something missing, please reopen this ticket with that information including more details. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 15:14:03 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 15:14:03 -0000 Subject: [Varnish] #1837: Compiling error if probe is defined after backend Message-ID: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> #1837: Compiling error if probe is defined after backend ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- If a probe is referenced before the backend is defined varnishd will fail to compile the VCL: {{{ Message from C-compiler: vgc.c:968:12: error: \xe2\x80\x98vgc_probe_p\xe2\x80\x99 undeclared here (not in a function) .probe = &vgc_probe_p, ^ Running C-compiler failed, exited with 1 }}} Test attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 15:16:37 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 15:16:37 -0000 Subject: [Varnish] #1837: Error compiling VCL if probe is referenced before it is defined (was: Compiling error if probe is defined after backend) In-Reply-To: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> References: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> Message-ID: <058.6e96699efc6eae4a391e61db9e1b757b@varnish-cache.org> #1837: Error compiling VCL if probe is referenced before it is defined ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 11 15:18:12 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jan 2016 15:18:12 -0000 Subject: [Varnish] #1837: Error compiling VCL if probe is referenced before it is defined In-Reply-To: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> References: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> Message-ID: <058.96cfe3c5aa14871bdfb6462ee1d6934d@varnish-cache.org> #1837: Error compiling VCL if probe is referenced before it is defined ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): FWIW, I'm not entirely sure this qualifies as a bug but calling a sub before it's defined works just fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 12 10:04:00 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 12 Jan 2016 10:04:00 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.479125a1fe64e9203d10cba03bb73017@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by thomaslc): Think I have the problem too. For me it seems a piped POST request fails when it reuses a backend connection that previously PASSed requests. It works when retrying after a failure because a new backend connection is opened. Here is the (anonymized) varnishlog output. The client does a first request that ends up in a pass, and then a second one ending up with a pipe. {{{ * << Session >> 21123429 - Begin sess 0 HTTP/1 - SessOpen CLIENT_IP 32470 :80 VARNISH_IP 80 1452591080.300133 51 - Link req 21123430 rxreq - SessClose REM_CLOSE 5.135 - End ** << Request >> 21123430 -- Begin req 21123429 rxreq -- Timestamp Start: 1452591080.300852 0.000000 0.000000 -- Timestamp Req: 1452591080.300852 0.000000 0.000000 -- ReqStart CLIENT_IP 32470 -- ReqMethod GET -- ReqURL /images/REDACTED -- ReqProtocol HTTP/1.1 -- ReqHeader Host: img.directindustry.fr -- ReqHeader Connection: keep-alive -- ReqHeader Pragma: no-cache -- ReqHeader Cache-Control: no-cache -- ReqHeader Accept: image/webp,image/*,*/*;q=0.8 -- ReqHeader User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36 -- ReqHeader DNT: 1 -- ReqHeader Referer: http://REDACTED -- ReqHeader Accept-Encoding: gzip, deflate, sdch -- ReqHeader Accept-Language: en-US,en;q=0.8,fr;q=0.6 -- ReqHeader Cookie: cookieAllowed=1; __gads=ID=8e63413b2db7cdc9:T=1445582966:S=ALNI_MbI6b5xwPjrR2dJO- 5YVDmoZxGDng; __unam=409b964-1509375ef74-804c90-9; kameleoonVisit=6l6b56grglamufva/0/1445583360532/20150708/0/; __utma=115893401.330538632.1444723972.1445582991.1448 -- ReqHeader X-Forwarded-For: CLIENT_IP -- VCL_call RECV -- ReqHeader X-Int-Backend: orig -- ReqUnset X-Forwarded-For: CLIENT_IP -- ReqHeader X-Forwarded-For: CLIENT_IP -- ReqHeader X-VE-Hops: 1 -- ReqUnset Accept-Encoding: gzip, deflate, sdch -- ReqHeader Accept-Encoding: gzip -- ReqUnset Cookie: cookieAllowed=1; __gads=ID=8e63413b2db7cdc9:T=1445582966:S=ALNI_MbI6b5xwPjrR2dJO- 5YVDmoZxGDng; __unam=409b964-1509375ef74-804c90-9; kameleoonVisit=6l6b56grglamufva/0/1445583360532/20150708/0/; __utma=115893401.330538632.1444723972.1445582991.1448 -- ReqHeader X-Host-Subdomain: img -- VCL_return pass -- VCL_call HASH -- ReqHeader X-VE-Host: img.directindustry -- VCL_return lookup -- VCL_call PASS -- ReqHeader X-Varnish-Mode: pass -- VCL_return fetch -- Link bereq 21123431 pass -- Timestamp Fetch: 1452591080.386848 0.085996 0.085996 -- RespProtocol HTTP/1.1 -- RespStatus 200 -- RespReason OK -- RespHeader Date: Tue, 12 Jan 2016 09:31:20 GMT -- RespHeader Server: Apache -- RespHeader Last-Modified: Mon, 01 Dec 2014 13:59:16 GMT -- RespHeader ETag: "2a8403d-4c8-50928041f647c" -- RespHeader Content-Length: 1224 -- RespHeader X-From: 3-10 in D=365 microseconds -- RespHeader X-Content-Type-Options: nosniff -- RespHeader X-XSS-Protection: 1; mode=block -- RespHeader Content-Type: image/gif -- RespHeader X-Varnish-Origin-TTL: 0.000 -- RespHeader X-Cache: nc[arz01/s] conn[>origin] -- RespHeader X-Host: img.directindustry.fr -- RespHeader X-Url: /images_di/REDACTED -- RespHeader X-Host-Subdomain: img -- RespHeader X-Varnish-Retries: 0 -- RespHeader X-Varnish: 21123430 -- RespHeader Age: 0 -- RespHeader Via: 1.1 varnish-v4 -- VCL_call DELIVER -- VCL_Log VEMR:- -- RespUnset X-Varnish-Retries: 0 -- RespUnset X-From: 3-10 in D=365 microseconds -- RespUnset X-Host-Subdomain: img -- RespUnset X-Url: /images_di/REDACTED -- RespUnset X-Varnish-Origin-TTL: 0.000 -- RespUnset Via: 1.1 varnish-v4 -- RespUnset X-Varnish: 21123430 -- RespUnset X-Host: img.directindustry.fr -- VCL_return deliver -- Timestamp Process: 1452591080.386898 0.086046 0.000050 -- RespHeader Accept-Ranges: bytes -- Debug "RES_MODE 2" -- RespHeader Connection: keep-alive -- Timestamp Resp: 1452591080.386958 0.086106 0.000060 -- ReqAcct 876 0 876 356 1224 1580 -- End *** << BeReq >> 21123431 --- Begin bereq 21123430 pass --- Timestamp Start: 1452591080.302007 0.000000 0.000000 --- BereqMethod GET --- BereqURL /images_di/REDACTED --- BereqProtocol HTTP/1.1 --- BereqHeader Host: img.directindustry.fr --- BereqHeader Pragma: no-cache --- BereqHeader Cache-Control: no-cache --- BereqHeader Accept: image/webp,image/*,*/*;q=0.8 --- BereqHeader User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36 --- BereqHeader DNT: 1 --- BereqHeader Referer: http://www.directindustry.fr/BACKOFFICE--- REDACTED --- BereqHeader Accept-Language: en-US,en;q=0.8,fr;q=0.6 --- BereqHeader X-Int-Backend: orig --- BereqHeader X-Forwarded-For: CLIENT_IP --- BereqHeader X-VE-Hops: 1 --- BereqHeader Accept-Encoding: gzip --- BereqHeader X-Host-Subdomain: img --- BereqHeader X-VE-Host: img.directindustry --- BereqHeader X-Varnish-Mode: pass --- BereqHeader X-Varnish: 21123431 --- VCL_call BACKEND_FETCH --- BereqProtocol HTTP/1.1 --- VCL_return fetch --- BackendOpen 56 c62563df-b4d7-421a-915e-5c448e453d00.agk01 BACKEND_IP 80 VARNISH_IP 33974 --- Timestamp Bereq: 1452591080.331480 0.029472 0.029472 --- Timestamp Beresp: 1452591080.386700 0.084693 0.055221 --- BerespProtocol HTTP/1.1 --- BerespStatus 200 --- BerespReason OK --- BerespHeader Date: Tue, 12 Jan 2016 09:31:20 GMT --- BerespHeader Server: Apache --- BerespHeader Last-Modified: Mon, 01 Dec 2014 13:59:16 GMT --- BerespHeader ETag: "2a8403d-4c8-50928041f647c" --- BerespHeader Accept-Ranges: bytes --- BerespHeader Content-Length: 1224 --- BerespHeader X-From: 3-10 in D=365 microseconds --- BerespHeader X-Content-Type-Options: nosniff --- BerespHeader X-XSS-Protection: 1; mode=block --- BerespHeader Content-Type: image/gif --- TTL RFC 432000 10 -1 1452591080 1452591080 1452591080 0 0 --- VCL_call BACKEND_RESPONSE --- BerespHeader X-Varnish-Origin-TTL: 0.000 --- TTL VCL -1 60 0 1452591080 --- BerespHeader X-Cache: conn[>origin] --- BerespUnset X-Cache: conn[>origin] --- BerespHeader X-Cache: nc[arz01/s] conn[>origin] --- BerespHeader X-Host: img.directindustry.fr --- BerespHeader X-Url: /images_di/REDACTED --- BerespHeader X-Host-Subdomain: img --- BerespHeader X-Varnish-Retries: 0 --- BerespUnset Accept-Ranges: bytes --- VCL_return deliver --- Storage malloc Transient --- ObjProtocol HTTP/1.1 --- ObjStatus 200 --- ObjReason OK --- ObjHeader Date: Tue, 12 Jan 2016 09:31:20 GMT --- ObjHeader Server: Apache --- ObjHeader Last-Modified: Mon, 01 Dec 2014 13:59:16 GMT --- ObjHeader ETag: "2a8403d-4c8-50928041f647c" --- ObjHeader Content-Length: 1224 --- ObjHeader X-From: 3-10 in D=365 microseconds --- ObjHeader X-Content-Type-Options: nosniff --- ObjHeader X-XSS-Protection: 1; mode=block --- ObjHeader Content-Type: image/gif --- ObjHeader X-Varnish-Origin-TTL: 0.000 --- ObjHeader X-Cache: nc[arz01/s] conn[>origin] --- ObjHeader X-Host: img.directindustry.fr --- ObjHeader X-Url: /images/REDACTED --- ObjHeader X-Host-Subdomain: img --- ObjHeader X-Varnish-Retries: 0 --- Fetch_Body 3 length stream --- BackendReuse 56 c62563df-b4d7-421a-915e-5c448e453d00.agk01 --- Timestamp BerespBody: 1452591080.386850 0.084843 0.000150 --- Length 1224 --- BereqAcct 603 0 603 324 1224 1548 --- End * << Session >> 73570869 - Begin sess 0 HTTP/1 - SessOpen CLIENT_IP 31052 :80 VARNISH_IP 80 1452591082.783081 64 - Link req 73570870 rxreq - SessClose TX_PIPE 10.172 - End ** << Request >> 73570870 -- Begin req 73570869 rxreq -- Timestamp Start: 1452591082.784323 0.000000 0.000000 -- Timestamp Req: 1452591082.784323 0.000000 0.000000 -- ReqStart CLIENT_IP 31052 -- ReqMethod POST -- ReqURL /AJAX---REDACTED -- ReqProtocol HTTP/1.1 -- ReqHeader Host: www.directindustry.fr -- ReqHeader Connection: keep-alive -- ReqHeader Content-Length: 280 -- ReqHeader Pragma: no-cache -- ReqHeader Cache-Control: no-cache -- ReqHeader Accept: */* -- ReqHeader Origin: http://www.directindustry.fr -- ReqHeader X-Requested-With: XMLHttpRequest -- ReqHeader User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36 -- ReqHeader Content-Type: application/x-www-form-urlencoded; charset=UTF-8 -- ReqHeader DNT: 1 -- ReqHeader Referer: http://www.directindustry.fr/BACKOFFICE--- REDACTED -- ReqHeader Accept-Encoding: gzip, deflate -- ReqHeader Accept-Language: en-US,en;q=0.8,fr;q=0.6 -- ReqHeader Cookie: REDACTED -- ReqHeader X-Forwarded-For: CLIENT_IP -- VCL_call RECV -- ReqHeader X-Int-Backend: orig -- ReqUnset X-Forwarded-For: CLIENT_IP -- ReqHeader X-Forwarded-For: CLIENT_IP -- ReqHeader X-VE-Hops: 1 -- ReqUnset Accept-Encoding: gzip, deflate -- ReqHeader Accept-Encoding: gzip -- VCL_return pipe -- VCL_call HASH -- VCL_return lookup -- Link bereq 73570871 pipe -- Timestamp Pipe: 1452591082.785460 0.001137 0.001137 -- Timestamp PipeSess: 1452591092.955365 10.171043 10.169906 -- PipeAcct 1378 1478 280 527 -- End *** << BeReq >> 73570871 --- Begin bereq 73570870 pipe --- BereqMethod POST --- BereqURL /AJAX---REDACTED --- BereqProtocol HTTP/1.1 --- BereqHeader Host: www.directindustry.fr --- BereqHeader Connection: keep-alive --- BereqHeader Content-Length: 280 --- BereqHeader Pragma: no-cache --- BereqHeader Cache-Control: no-cache --- BereqHeader Accept: */* --- BereqHeader Origin: http://www.directindustry.fr --- BereqHeader X-Requested-With: XMLHttpRequest --- BereqHeader User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36 --- BereqHeader Content-Type: application/x-www-form-urlencoded; charset=UTF-8 --- BereqHeader DNT: 1 --- BereqHeader Referer: http://www.directindustry.fr/BACKOFFICE--- REDACTED --- BereqHeader Accept-Language: en-US,en;q=0.8,fr;q=0.6 --- BereqHeader Cookie: callerLoad=function editProduct(productID,containerID){load('Product- editProduct',{productID:productID,containerID:containerID},function(request){openProduts([productID],request.getResponseHeader('containerIDs').split(','),productID); callerGet=f --- BereqHeader X-Int-Backend: orig --- BereqHeader X-Forwarded-For: CLIENT_IP --- BereqHeader X-VE-Hops: 1 --- BereqHeader Accept-Encoding: gzip --- BereqHeader X-Varnish: 73570870 --- BereqHeader Connection: close --- VCL_call PIPE --- VCL_return pipe --- BackendOpen 56 c62563df-b4d7-421a-915e-5c448e453d00.agk01 BACKEND_IP 80 VARNISH_IP 33974 --- Timestamp Bereq: 1452591082.785452 0.000000 0.000000 --- BackendClose 56 c62563df-b4d7-421a-915e-5c448e453d00.agk01 --- BereqAcct 0 0 0 0 0 0 --- End }}} The thing that got my attention was that the first request does a BackendReuse on the backend connection 56. Then, the next request starts a pipe (because ReqURL matches a specific backend URL). There, varnish does a BackendOpen on 56, not a BackendReuse. The tcpdump performed on the backend shows a rather weird sequence: {{{ 4 2016-01-12 10:16:30.494287 46.37.4.239 10.80.30.11 HTTP 669 GET /images_di/IMAGE---URL 0 HTTP/1.1 7 2016-01-12 10:16:30.498630 10.80.30.11 46.37.4.239 HTTP 247 HTTP/1.1 200 OK (GIF89a) 11 2016-01-12 10:16:42.835985 10.80.30.11 46.37.4.239 HTTP 593 HTTP/1.1 503 Service Unavailable (text/html)[Malformed Packet] 14 2016-01-12 10:16:42.864200 46.37.4.239 10.80.30.11 HTTP 346 POST /BACKOFFICE---URL HTTP/1.1 (application/x-www-form- urlencoded) }}} As you can see, the 503 error is sent by the backend BEFORE the piped request is sent by varnish. This extract shows only the HTTP stuff. I can send the complete PCAP dump with the TCP stuff by e-mail (it contains sensitive data). Thanks Thomas -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 12 12:15:46 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 12 Jan 2016 12:15:46 -0000 Subject: [Varnish] #1838: Cannot include synthetic content on ESI request if esi:include is in plaintext Message-ID: <043.b7c207dfb366eab7d8c8d9c9f7bc15a0@varnish-cache.org> #1838: Cannot include synthetic content on ESI request if esi:include is in plaintext ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Taking the existing r01688.vtc as base, changing -gzipbody to -body yields: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 12 15:23:56 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 12 Jan 2016 15:23:56 -0000 Subject: [Varnish] #1839: sml_iterator(), storage/storage_simple.c line 271 Message-ID: <046.40de9b648e4d94c6a440bb2436e90b74@varnish-cache.org> #1839: sml_iterator(), storage/storage_simple.c line 271 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Built and deployed master earlier today: {{{ Panic at: Tue, 12 Jan 2016 12:35:54 GMT "Assert error in sml_iterator(), storage/storage_simple.c line 271: Condition((((&obj->list)->vtqh_first == ((void *)0))) == 0) not true. thread = (cache-worker) version = varnish-trunk revision 7f6f2c5 ident = Linux,3.16.0-4-amd64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43a3e1: pan_backtrace+0x1d 0x43a7e6: pan_ic+0x2bc 0x47aed8: sml_iterator+0x1d5 0x437d21: ObjIterate+0xf6 0x41c5da: VDP_DeliverObj+0x8a 0x45be43: V1D_Deliver+0x43c 0x43d694: cnt_vdp+0x360 0x43dd58: cnt_deliver+0x6c2 0x44092e: CNT_Request+0x4c6 0x45d95b: HTTP1_Session+0x765 req = 0x7f1b2ca2f020 { vxid = 983123, step = R_STP_DELIVER, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7f1b2c411220 { fd = 14, vxid = 983122, client = 77.88.102.50 55101, step = S_STP_H1PROC, }, worker = 0x7f1b400f7c90 { stack = {0x7f1b400f8000 -> 0x7f1b400ec000}, ws = 0x7f1b400f7e78 { id = \"wrk\", {s,f,r,e} = {0x7f1b400f7450,0x7f1b400f7450,(nil),+2040}, }, VCL::method = DELIVER, VCL::return = deliver, VCL::methods = {RECV, HASH, MISS, DELIVER}, }, ws = 0x7f1b2ca2f200 { id = \"req\", {s,f,r,e} = {0x7f1b2ca31000,+760,+57336,+57336}, }, http_conn = 0x7f1b2ca2f128 { fd = 14, doclose = NULL, ws = 0x7f1b2ca2f200, {rxbuf_b, rxbuf_e} = {0x7f1b2ca31020, 0x7f1b2ca311f8}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = -1, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7f1b2ca2f298 { ws[req] = 0x7f1b2ca2f200, hdrs { \"GET\", \"/racing/xp38-nor15038-xpronto.html\", \"HTTP/1.1\", \"Connection: keep-alive\", \"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\", \"Upgrade-Insecure-Requests: 1\", \"User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36\", \"Referer: https://www.google.no/\", \"Accept-Language: nb-NO,nb;q=0.8,no;q=0.6,nn;q=0.4,en- US;q=0.2,en;q=0.2\", \"X-Forwarded-For: 77.88.102.50\", \"host: hyse.org\", \"Accept-Encoding: gzip\", }, }, http[resp] = 0x7f1b2ca2fb88 { ws[req] = 0x7f1b2ca2f200, hdrs { \"HTTP/1.1\", \"200\", \"OK\", \"Server: nginx/1.6.2\", \"Date: Tue, 12 Jan 2016 12:35:53 GMT\", \"Content-Type: text/html\", \"Last-Modified: Sun, 20 Dec 2015 13:57:03 GMT\", \"Content-Encoding: gzip\", \"Vary: Accept-Encoding\", \"X-Varnish: 983123\", \"Age: 0\", \"Via: 1.1 varnish-v4\", \"Accept-Ranges: bytes\", \"Transfer-Encoding: chunked\", \"Connection: keep-alive\", }, }, vcl = { temp = warm srcname = { \"/etc/varnish/default.vcl\", \"Builtin\", }, }, objcore[REQ] = 0x7f1b3501f340 { refcnt = 3, flags = 0x8, exp_flags = 0x1000, exp = { 1452602153.744026, 120.000000, 60.000000, 86400.000000 } objhead = 0x7f1b35021240, stevedore = 0x7f1b3dcee240 (malloc s0), }, busyobj = 0x7f1b2d5a6020 { ws = 0x7f1b2d5a60e0 { id = \"bo\", {s,f,r,e} = {0x7f1b2d5a7fa0,+2176,(nil),+57432}, }, refcnt = 3, retries = 0, failed = 0, state = 2, flags = {do_stream, is_gzip}, filters = TESTGUNZIP=1 V1F_CHUNKED=1 director_req = 0x7f1b3dd31ab8 { vcl_name = nginx, type = backend { display_name = boot.nginx, ipv4 = 127.0.0.1, port = 8085, hosthdr = 127.0.0.1, health=healthy, admin_health=probe, changed=1452595190.7, n_conn = 2, }, }, director_resp = director_req, http[bereq] = 0x7f1b2d5a66b0 { ws[bo] = 0x7f1b2d5a60e0, hdrs { \"GET\", \"/racing/xp38-nor15038-xpronto.html\", \"HTTP/1.1\", \"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\", \"Upgrade-Insecure-Requests: 1\", \"User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36\", \"Referer: https://www.google.no/\", \"Accept-Language: nb-NO,nb;q=0.8,no;q=0.6,nn;q=0.4,en- US;q=0.2,en;q=0.2\", \"X-Forwarded-For: 77.88.102.50\", \"host: hyse.org\", \"Accept-Encoding: gzip\", \"X-Varnish: 983124\", }, }, http[beresp] = 0x7f1b2d5a6b28 { ws[bo] = 0x7f1b2d5a60e0, hdrs { \"HTTP/1.1\", \"200\", \"OK\", \"Server: nginx/1.6.2\", \"Date: Tue, 12 Jan 2016 12:35:53 GMT\", \"Content-Type: text/html\", \"Last-Modified: Sun, 20 Dec 2015 13:57:03 GMT\", \"Transfer-Encoding: chunked\", \"Connection: keep-alive\", \"Content-Encoding: gzip\", \"Vary: Accept-Encoding\", }, }, objcore[fetch] = 0x7f1b3501f340 { refcnt = 3, flags = 0x8, exp_flags = 0x1000, exp = { 1452602153.744026, 120.000000, 60.000000, 86400.000000 } objhead = 0x7f1b35021240, stevedore = 0x7f1b3dcee240 (malloc s0), }, vcl = { temp = warm srcname = { \"/etc/varnish/default.vcl\", \"Builtin\", }, }, }, flags = { }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 13 09:38:55 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Jan 2016 09:38:55 -0000 Subject: [Varnish] #1839: sml_iterator(), storage/storage_simple.c line 271 In-Reply-To: <046.40de9b648e4d94c6a440bb2436e90b74@varnish-cache.org> References: <046.40de9b648e4d94c6a440bb2436e90b74@varnish-cache.org> Message-ID: <061.bac17592a728d4d42e3db8e952910283@varnish-cache.org> #1839: sml_iterator(), storage/storage_simple.c line 271 ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [5d04b20099d30407ee3f8f885b6bcbfd7145544d]: {{{ #!CommitTicketReference repository="" revision="5d04b20099d30407ee3f8f885b6bcbfd7145544d" This is sort of embarrasing: I forgot to lock the busyobj when changing the storage list. Fixes: #1839 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 13 15:11:32 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Jan 2016 15:11:32 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.c71992eeb767e834db03fefa16cf03dd@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by thomaslc): OK, I think the following VTC is able to reproduce the bug: {{{ server s1 { rxreq expect req.url == "/pass-me" txresp -body "I was PASSed\n" rxreq expect req.url == "/pipe-me" txresp -body "I was PIPEd\n" } -start varnish v1 -vcl+backend { sub vcl_recv { if (req.url == "/pipe-me") { return (pipe); } return (pass); } sub vcl_pipe { set bereq.http.Connection = "close"; } } -start client c1 { txreq -url /pass-me rxresp txreq -req POST -url /pipe-me -body "asdf" rxresp } -run }}} If you change the flow to do the piped POST before the passed GET, it works fine. Also, if you change the POST request to a GET, it works fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 08:18:52 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 08:18:52 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.25dc9dfbd7a27ea10e21dd0c91cb79ad@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by fgsch): I tested this against different version and this was introduced between 4.0.3 and 4.1. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 08:59:38 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 08:59:38 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.09f9f0634f3f6368e76b54119013321d@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by fgsch): Introduced in commit dd01df1a9138d6a2204a1a8de4e0dc727d8fc488 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 12:35:56 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 12:35:56 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.e1980c711535b1b805b3fb2610409b28@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by fgsch): Related to #1772. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 13:33:51 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 13:33:51 -0000 Subject: [Varnish] #1835: 4.0 online documentation outdated? In-Reply-To: <046.1b5d1dfe21306aa13583e2b894e16523@varnish-cache.org> References: <046.1b5d1dfe21306aa13583e2b894e16523@varnish-cache.org> Message-ID: <061.1a80624848404c5fac5ea50b73ac6598@varnish-cache.org> #1835: 4.0 online documentation outdated? ---------------------------+---------------------- Reporter: lkarsten | Owner: fgsch Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: unknown Severity: normal | Resolution: fixed Keywords: | ---------------------------+---------------------- Changes (by fgsch): * status: assigned => closed * resolution: => fixed Comment: Updated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1813: Duplicate -a leads to assert instead of error message. In-Reply-To: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> References: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> Message-ID: <061.69311d8b53eeb4b9c0ded6251ed3eeee@varnish-cache.org> #1813: Duplicate -a leads to assert instead of error message. ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [fc9b45f167b2b5c1b206e8bdaf4a00e06617c654]: {{{ #!CommitTicketReference repository="" revision="fc9b45f167b2b5c1b206e8bdaf4a00e06617c654" Fail if multiple -a arguments return the same suckaddr. Fixes #1813 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1795: Man page issues in 4.1 In-Reply-To: <043.3248b86a133da7a2e2f3f47447587d62@varnish-cache.org> References: <043.3248b86a133da7a2e2f3f47447587d62@varnish-cache.org> Message-ID: <058.37420af985ea2bc457cd8d56339c700c@varnish-cache.org> #1795: Man page issues in 4.1 ---------------------------+--------------------------------------------- Reporter: Dridi | Owner: Federico G. Schwindt Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [ffd37357952845336a7e5c3c4997d89480e2754c]: {{{ #!CommitTicketReference repository="" revision="ffd37357952845336a7e5c3c4997d89480e2754c" Document vcl.state and correct existing mention Partially addresses #1795. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1796: Assert error in SES_Proto_Req In-Reply-To: <045.2141fa04002dfbf25286642bf4066bde@varnish-cache.org> References: <045.2141fa04002dfbf25286642bf4066bde@varnish-cache.org> Message-ID: <060.950a0461c5a55d455da3004351130c9b@varnish-cache.org> #1796: Assert error in SES_Proto_Req --------------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: Assert error | --------------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [c9028924e230e5eb13372aedd84e81144e701d37]: {{{ #!CommitTicketReference repository="" revision="c9028924e230e5eb13372aedd84e81144e701d37" Don't attempt to allocate a V1L from the workspace if it is overflowed. Fixes: #1796 Also triggered by: The Wemm-Field }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1794: varnish*-tools do not die when terminal disconnects In-Reply-To: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> References: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> Message-ID: <056.801ade25c903d02c037b3d8777ef13cb@varnish-cache.org> #1794: varnish*-tools do not die when terminal disconnects --------------------+--------------------------------------------- Reporter: kwy | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [01a6d89a58500111d9b92749a267b3c22ae4b847]: {{{ #!CommitTicketReference repository="" revision="01a6d89a58500111d9b92749a267b3c22ae4b847" Handle terminal disconnections correctly Change SIGHUP handling depending on whether we're running in daemon mode or foreground. The former will continue rotating the logs, the latter will abort the loop and die gracefully. Fixes #1794. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1810: HTTP/1.0 EOF from backend broken In-Reply-To: <041.a4930a5c1bb922879486cb9c56f83795@varnish-cache.org> References: <041.a4930a5c1bb922879486cb9c56f83795@varnish-cache.org> Message-ID: <056.ef8f05570b1fb9a5f618018ac5947633@varnish-cache.org> #1810: HTTP/1.0 EOF from backend broken ----------------------+--------------------- Reporter: phk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [d327423897e1f49323496640224227935046ebf1]: {{{ #!CommitTicketReference repository="" revision="d327423897e1f49323496640224227935046ebf1" So one of those strange cornercases in HTTP/1 If we send the backend a HTTP/1.0 request, and it doesn't have a Content-Length, it cannot use Chunked and must fall back to EOF. However, the protocol field in the response tells us what version backend *could* have used, not what it *does* use. So we can get a response with HTTP/1.1 and EOF, following HTTP/1.0 semantics - because we asked for it. Most sensible backends avoid this, either by buffering and creation of a C-L or, smartly, returning "HTTP/1.0", even though that is strictly speaking against the apocrphal texts. Anyway, now we cope... Fixes: #1810 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1801: Fail parsing IPv6 constants In-Reply-To: <043.f269ea63a9a5a2c445c8af43e75b18dd@varnish-cache.org> References: <043.f269ea63a9a5a2c445c8af43e75b18dd@varnish-cache.org> Message-ID: <058.f88c7605e56605d312fa2f16fa7fe67f@varnish-cache.org> #1801: Fail parsing IPv6 constants ----------------------+--------------------------------------------- Reporter: fgsch | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [ed1eb987ee9c2eb6224ff37b719c0df79d93b5a2]: {{{ #!CommitTicketReference repository="" revision="ed1eb987ee9c2eb6224ff37b719c0df79d93b5a2" Relax IP constant parsing Fixes #1801. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:16 -0000 Subject: [Varnish] #1814: Documentation Bug In-Reply-To: <047.e42befd26cdc4382001f7fb34341f1e0@varnish-cache.org> References: <047.e42befd26cdc4382001f7fb34341f1e0@varnish-cache.org> Message-ID: <062.f52a2271fbc2fcf679020912992bb2c0@varnish-cache.org> #1814: Documentation Bug -------------------------------------+------------------------------------- Reporter: pprocacci | Owner: Federico G. Schwindt Type: defect | Priority: lowest | Status: closed Component: documentation | Milestone: Varnish 4.1-TP1 Severity: trivial | Version: 4.1.0 Keywords: Documentation Doc | Resolution: fixed Grammer | -------------------------------------+------------------------------------- Comment (by Lasse Karstensen ): In [2a7fbd5014340b3b4682f94d4d6bb0ebdc5de884]: {{{ #!CommitTicketReference repository="" revision="2a7fbd5014340b3b4682f94d4d6bb0ebdc5de884" Typos and grammar Fixes #1814 and more. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1795: Man page issues in 4.1 In-Reply-To: <043.3248b86a133da7a2e2f3f47447587d62@varnish-cache.org> References: <043.3248b86a133da7a2e2f3f47447587d62@varnish-cache.org> Message-ID: <058.3a1b87076f4d9dc828b5773674865353@varnish-cache.org> #1795: Man page issues in 4.1 ---------------------------+--------------------------------------------- Reporter: Dridi | Owner: Federico G. Schwindt Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [47a724bb1748a265ad6a86be4d81b2c94f34bad9]: {{{ #!CommitTicketReference repository="" revision="47a724bb1748a265ad6a86be4d81b2c94f34bad9" Add copyright notice and date where missing Also sort see also correctly. Fix #1795 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:16 -0000 Subject: [Varnish] #1821: Transient storage not freed straight away on HFP In-Reply-To: <043.a918f82391e3c733396d7817425c6488@varnish-cache.org> References: <043.a918f82391e3c733396d7817425c6488@varnish-cache.org> Message-ID: <058.05e22c5d156ff0d49970404150903d61@varnish-cache.org> #1821: Transient storage not freed straight away on HFP ----------------------+---------------------------------------- Reporter: fgsch | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [86c57392b325ec0aa616d2c5c2b07d2375c518fb]: {{{ #!CommitTicketReference repository="" revision="86c57392b325ec0aa616d2c5c2b07d2375c518fb" Always slim private & pass objects after delivery. Fixes: #1821 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1807: Assert error in cnt_deliver() In-Reply-To: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> References: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> Message-ID: <060.7603e5e31e7b3fa9450df4860f09be7f@varnish-cache.org> #1807: Assert error in cnt_deliver() --------------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: fixed Keywords: Assert error | --------------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [2dc7d093e3533008c333db9717bc0eac8050a005]: {{{ #!CommitTicketReference repository="" revision="2dc7d093e3533008c333db9717bc0eac8050a005" Return 500 if we cannot decode the stored object into the resp.* This can happen in a number of obscure corner-cases, which do not warrant a panic. Fixes: #1807 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:16 -0000 Subject: [Varnish] #1798: Varnish requests painfully slow with large files In-Reply-To: <045.b9933fc5ccad71abef136d693b22f22f@varnish-cache.org> References: <045.b9933fc5ccad71abef136d693b22f22f@varnish-cache.org> Message-ID: <060.14a9849a963282873358e6728e34b253@varnish-cache.org> #1798: Varnish requests painfully slow with large files ----------------------+---------------------------------------- Reporter: nbetham | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [a6bf9db091e8c039ecdc191a6916c72ccc5315ed]: {{{ #!CommitTicketReference repository="" revision="a6bf9db091e8c039ecdc191a6916c72ccc5315ed" Cache a checkpoint when we iterate over busy objects, so we don't have to walk the full list all the time. This is a minimal fix for backporting to 4.1.x Fixes: #1798 Fixes: #1788 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:16 -0000 Subject: [Varnish] #1788: ObjIter has terrible performance profile when busyobj != NULL In-Reply-To: <041.000537049e394809a235d0799213d1da@varnish-cache.org> References: <041.000537049e394809a235d0799213d1da@varnish-cache.org> Message-ID: <056.c571c4fa44ceb607f1f4e2eae48670a8@varnish-cache.org> #1788: ObjIter has terrible performance profile when busyobj != NULL --------------------+---------------------------------------- Reporter: tnt | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [a6bf9db091e8c039ecdc191a6916c72ccc5315ed]: {{{ #!CommitTicketReference repository="" revision="a6bf9db091e8c039ecdc191a6916c72ccc5315ed" Cache a checkpoint when we iterate over busy objects, so we don't have to walk the full list all the time. This is a minimal fix for backporting to 4.1.x Fixes: #1798 Fixes: #1788 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1809: Allow a Content-Length: 0 header on a 204 response In-Reply-To: <044.a5dc29fe0450f6da452e4791c81f5a8c@varnish-cache.org> References: <044.a5dc29fe0450f6da452e4791c81f5a8c@varnish-cache.org> Message-ID: <059.c1c71bc52e6f2589b82d3c8362630be2@varnish-cache.org> #1809: Allow a Content-Length: 0 header on a 204 response -----------------------------+--------------------------------------------- Reporter: widodh | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: 204,content- | length | -----------------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [a75a278e7ebedac0e34232e216f945881bd1d523]: {{{ #!CommitTicketReference repository="" revision="a75a278e7ebedac0e34232e216f945881bd1d523" Update RFC reference Fixes #1809. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:16 -0000 Subject: [Varnish] #1763: tolerate EINTR in accept() ? In-Reply-To: <043.6d09ee992e18ddcfd4d5c149e6684cb6@varnish-cache.org> References: <043.6d09ee992e18ddcfd4d5c149e6684cb6@varnish-cache.org> Message-ID: <058.955d8142f2cb4fc5cc793d96723fae3a@varnish-cache.org> #1763: tolerate EINTR in accept() ? ----------------------+----------------------------------------------- Reporter: slink | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Comment (by Lasse Karstensen ): In [df4ef3b99acba107fc69e1d0e07ab262bb2d1ba6]: {{{ #!CommitTicketReference repository="" revision="df4ef3b99acba107fc69e1d0e07ab262bb2d1ba6" Restart epoll_wait on EINTR error This works around a Linux kernel bug where the epoll_wait will return EINTR when the process is subjected to a ptrace or the OS wakes from suspend. Fixes: #1763 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:16 -0000 Subject: [Varnish] #1816: Return 304 for If-None-Match on weak ETag match (cache hit) In-Reply-To: <048.42c9cb84005dbc900bc1c04d266402c4@varnish-cache.org> References: <048.42c9cb84005dbc900bc1c04d266402c4@varnish-cache.org> Message-ID: <063.c4cc237ca8f6d4866f9119a8b7999194@varnish-cache.org> #1816: Return 304 for If-None-Match on weak ETag match (cache hit) ---------------------------------------------+--------------------- Reporter: teohhanhui | Owner: fgsch Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: 304 if-none-match weak etag hit | ---------------------------------------------+--------------------- Comment (by Lasse Karstensen ): In [778283389bae7809dd8fc40565ae64ba85fbfa4e]: {{{ #!CommitTicketReference repository="" revision="778283389bae7809dd8fc40565ae64ba85fbfa4e" Use a weak comparison function for If-None-Match As per RFC 7232. Fixes #1816. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1804: PROXYed client requests does not appear in varnishlog In-Reply-To: <044.b771cf3de742ae034ee8c620e1082173@varnish-cache.org> References: <044.b771cf3de742ae034ee8c620e1082173@varnish-cache.org> Message-ID: <059.177fa7e2a47c8e4e17def8b9bf579ea9@varnish-cache.org> #1804: PROXYed client requests does not appear in varnishlog ----------------------+----------------------------------------------- Reporter: trygve | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Comment (by Lasse Karstensen ): In [6b2cc56eb26da79c08c16dea5e897be3dd34fa05]: {{{ #!CommitTicketReference repository="" revision="6b2cc56eb26da79c08c16dea5e897be3dd34fa05" Log proxy related messages on the session, not on the request. The proxy log records were attempted to be logged on the request' log buffer, which at that point in time has not yet been set up and does not posess a VXID. This caused VXID==0 log records to be inserted in the beginning of the log for the first request on the session when using proxy protocol, and subsequently the VSL to fail picking them out as valid request log transactions. Fix by logging the PROXY handling related messages on the session, in which they belong. Fixes: #1804 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:16 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.73d7cdc8d99812c67cedc5fb571d6231@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+--------------------------------------------- Reporter: xrowkristina | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | --------------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [368280d4c30f28175d38dbdd9e587d0f80ed7631]: {{{ #!CommitTicketReference repository="" revision="368280d4c30f28175d38dbdd9e587d0f80ed7631" Ignore 0 Content-Lengths in 204 responses Broken implementations do it contrary to what the RFC mandates. Fixes #1826. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 14 14:15:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jan 2016 14:15:15 -0000 Subject: [Varnish] #1635: Completed bans keep accumulating In-Reply-To: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> References: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> Message-ID: <058.0b477c0f3c12ddb0ff21327718ef0a5f@varnish-cache.org> #1635: Completed bans keep accumulating ----------------------+---------------------------------------- Reporter: Sesse | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: lurker | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [2e7b89e0ea1273f881019200cf4e1748ba3a093a]: {{{ #!CommitTicketReference repository="" revision="2e7b89e0ea1273f881019200cf4e1748ba3a093a" Modify the ban_lurker so we lift oc's as far up the ban-list as we can when we check a batch of lurkable bans. For obj.* only bans, this should concentrate the entire list at the very top. If there are req.* bans, the oc's end up on the bans right below the req.* bans. Fixes #1635 (As much as we can fix it) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 15 01:32:31 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jan 2016 01:32:31 -0000 Subject: [Varnish] #1840: add beresp.backend.name field to vcl_error Message-ID: <045.b0945da6e5dc0a4631d714d8311cefa1@varnish-cache.org> #1840: add beresp.backend.name field to vcl_error ---------------------+------------------------- Reporter: jzinner | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ---------------------+------------------------- It would be nice to have access to something like beresp.backend.name from vcl_error -- so that incase a backend fails; I can return more detail in the error, such as the host that failed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 15 01:50:33 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jan 2016 01:50:33 -0000 Subject: [Varnish] #1840: add beresp.backend.name field to vcl_error In-Reply-To: <045.b0945da6e5dc0a4631d714d8311cefa1@varnish-cache.org> References: <045.b0945da6e5dc0a4631d714d8311cefa1@varnish-cache.org> Message-ID: <060.42660499baee4122a02d0e9197a01290@varnish-cache.org> #1840: add beresp.backend.name field to vcl_error -------------------------+---------------------- Reporter: jzinner | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | -------------------------+---------------------- Comment (by jzinner): Also req.backend (available during vcl_recv) is not enough since I have a very large number of backends under a director ~ 120 hosts -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 15 12:29:54 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jan 2016 12:29:54 -0000 Subject: [Varnish] #1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line 109: Message-ID: <046.6046354ab122696fa0a1985521776750@varnish-cache.org> #1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line 109: ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- When building 4.1.1-beta1 on OSX, r01801.vtc ends with a panic. {{{ Assert error in vwk_thread(), waiter/cache_waiter_kqueue.c line 109:\n Condition(n >= 0) not true.\n errno = 4 (Interrupted system call)\n thread = (cache-kqueue)\n version = varnish-4.1.1-beta1 revision 32af38d\n ident = Darwin,14.3.0,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,kqueue\n Backtrace:\n 0x10316a38e: 0 varnishd 0x000000010316a38e pan_backtrace + 46\n 0x10316a1a7: 0 varnishd 0x000000010316a1a7 pan_ic + 727\n 0x1031c34d0: 0 varnishd 0x00000001031c34d0 vwk_thread + 1296\n 0x7fff842bc268: 0 libsystem_pthread.dylib 0x00007fff842bc268 _pthread_body + 131\n 0x7fff842bc1e5: 0 libsystem_pthread.dylib 0x00007fff842bc1e5 _pthread_body + 0\n 0x7fff842ba41d: 0 libsystem_pthread.dylib 0x00007fff842ba41d thread_start + 13\n }}} {{{ FAIL: tests/r01801.vtc (exit: 2) ================================ **** top 0.0 macro def varnishd=varnishd **** top 0.0 macro def varnishadm=varnishadm **** top 0.0 macro def varnishstat=varnishstat **** top 0.0 macro def varnishhist=varnishhist **** top 0.0 macro def varnishlog=varnishlog **** top 0.0 macro def varnishncsa=varnishncsa **** top 0.0 macro def vmod_std=std from "/Users/jenkins/slave- root/workspace/varnish-4.1-build-osx- x86_64/varnish-4.1.1-beta1/lib/libvmod_std/.libs/libvmod_std.so" **** top 0.0 macro def vmod_debug=debug from "/Users/jenkins/slave- root/workspace/varnish-4.1-build-osx- x86_64/varnish-4.1.1-beta1/lib/libvmod_debug/.libs/libvmod_debug.so" **** top 0.0 macro def vmod_directors=directors from "/Users/jenkins /slave-root/workspace/varnish-4.1-build-osx- x86_64/varnish-4.1.1-beta1/lib/libvmod_directors/.libs/libvmod_directors.so" **** top 0.0 macro def pwd=/Users/jenkins/slave- root/workspace/varnish-4.1-build-osx- x86_64/varnish-4.1.1-beta1/bin/varnishtest **** top 0.0 macro def topbuild=/Users/jenkins/slave- root/workspace/varnish-4.1-build-osx-x86_64/varnish-4.1.1-beta1 **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/var/folders/8h/vqvgz9dj23j0_b4w54jcnv5w0000gp/T//vtc.87884.22921d6f * top 0.0 TEST ./tests/r01801.vtc starting ** top 0.0 === varnishtest "Test parsing IP constants" * top 0.0 TEST Test parsing IP constants ** top 0.0 === server s1 { ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=57043 **** s1 0.0 macro def s1_sock=127.0.0.1 57043 * s1 0.0 Listen on 127.0.0.1 57043 ** top 0.0 === varnish v1 -vcl+backend { ** s1 0.0 Started on 127.0.0.1 57043 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && exec ${varnishd} -d -n /var/folders/8h/vqvgz9dj23j0_b4w54jcnv5w0000gp/T//vtc.87884.22921d6f/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -p thread_pool_min=10 -p debug=+vtc_mode -a '127.0.0.1:0' -M '127.0.0.1 57044' -P /var/folders/8h/vqvgz9dj23j0_b4w54jcnv5w0000gp/T//vtc.87884.22921d6f/v1/varnishd.pid *** v1 0.0 CMD: cd /Users/jenkins/slave-root/workspace/varnish-4.1 -build-osx-x86_64/varnish-4.1.1-beta1/bin/varnishtest && exec varnishd -d -n /var/folders/8h/vqvgz9dj23j0_b4w54jcnv5w0000gp/T//vtc.87884.22921d6f/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -p thread_pool_min=10 -p debug=+vtc_mode -a '127.0.0.1:0' -M '127.0.0.1 57044' -P /var/folders/8h/vqvgz9dj23j0_b4w54jcnv5w0000gp/T//vtc.87884.22921d6f/v1/varnishd.pid *** v1 0.0 PID: 87902 **** v1 0.0 macro def v1_pid=87902 **** v1 0.0 macro def v1_name=/var/folders/8h/vqvgz9dj23j0_b4w54jcnv5w0000gp/T//vtc.87884.22921d6f/v1 *** v1 0.1 debug| Debug: Platform: Darwin,14.3.0,x86_64,-jnone,-smalloc,-smalloc,-hcritbit\n *** v1 0.1 debug| \n *** v1 0.1 debug| 200 279 \n *** v1 0.1 debug| -----------------------------\n *** v1 0.1 debug| Varnish Cache CLI 1.0\n *** v1 0.1 debug| -----------------------------\n *** v1 0.1 debug| Darwin,14.3.0,x86_64,-jnone,-smalloc,-smalloc,-hcritbit\n *** v1 0.1 debug| varnish-4.1.1-beta1 revision 32af38d\n *** v1 0.1 debug| \n *** v1 0.1 debug| Type 'help' for command list.\n *** v1 0.1 debug| Type 'quit' to close CLI session.\n *** v1 0.1 debug| Type 'start' to launch worker process.\n *** v1 0.1 debug| \n **** v1 0.2 CLIPOLL 1 0x1 0x0 *** v1 0.2 CLI connection fd = 9 *** v1 0.2 CLI RX 107 **** v1 0.2 CLI RX| cqmckqjwijreqwzngqsujyzridvgodmr\n **** v1 0.2 CLI RX| \n **** v1 0.2 CLI RX| Authentication required.\n **** v1 0.2 CLI TX| auth 29e5d57cb9bcaf141ed17040096b7c24239dc9ad0e22734436bb1f2dce58b5e9\n *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| -----------------------------\n **** v1 0.2 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.2 CLI RX| -----------------------------\n **** v1 0.2 CLI RX| Darwin,14.3.0,x86_64,-jnone,-smalloc,-smalloc,-hcritbit\n **** v1 0.2 CLI RX| varnish-4.1.1-beta1 revision 32af38d\n **** v1 0.2 CLI RX| \n **** v1 0.2 CLI RX| Type 'help' for command list.\n **** v1 0.2 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.2 CLI RX| Type 'start' to launch worker process.\n **** v1 0.2 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.2 CLI TX| vcl 4.0;\n **** v1 0.2 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "57043"; }\n **** v1 0.2 CLI TX| \n **** v1 0.2 CLI TX| \n **** v1 0.2 CLI TX| \timport std from "/Users/jenkins/slave- root/workspace/varnish-4.1-build-osx- x86_64/varnish-4.1.1-beta1/lib/libvmod_std/.libs/libvmod_std.so";\n **** v1 0.2 CLI TX| \n **** v1 0.2 CLI TX| \tsub vcl_deliver {\n **** v1 0.2 CLI TX| \t\tset resp.http.foo1 = std.ip("..", "1.2.3.4");\n **** v1 0.2 CLI TX| \t\tset resp.http.foo2 = std.ip("..", "1.2.3.4:8000");\n **** v1 0.2 CLI TX| \t\tset resp.http.foo3 = std.ip("..", "1.2.3.4 8000");\n **** v1 0.2 CLI TX| \t\tset resp.http.foo4 = std.ip("..", "::1");\n **** v1 0.2 CLI TX| \t\tset resp.http.foo5 = std.ip("..", "[::1]");\n **** v1 0.2 CLI TX| \t\tset resp.http.foo6 = std.ip("..", "[::1]:8000");\n **** v1 0.2 CLI TX| \t\tset resp.http.bar1 = std.port("1.2.3.4");\n **** v1 0.2 CLI TX| \t\tset resp.http.bar2 = std.port("1.2.3.4:8000");\n **** v1 0.2 CLI TX| \t\tset resp.http.bar3 = std.port("1.2.3.4 8000");\n **** v1 0.2 CLI TX| \t\tset resp.http.bar4 = std.port("::1");\n **** v1 0.2 CLI TX| \t\tset resp.http.bar5 = std.port("[::1]");\n **** v1 0.2 CLI TX| \t\tset resp.http.bar6 = std.port("[::1]:8000");\n **** v1 0.2 CLI TX| \t}\n **** v1 0.2 CLI TX| \n **** v1 0.2 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| VCL compiled.\n **** v1 0.3 CLI TX| vcl.use vcl1 *** v1 0.3 CLI RX 200 ** v1 0.3 Start **** v1 0.3 CLI TX| start *** v1 0.3 debug| Debug: Child (87924) Started\n *** v1 0.3 debug| Info: Child (87924) said Child starts\n *** v1 0.3 CLI RX 200 *** v1 0.3 wait-running **** v1 0.3 CLI TX| status *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| Child in state running **** v1 0.3 CLI TX| debug.xid 999 *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| XID is 999 **** v1 0.3 CLI TX| debug.listen_address *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| 127.0.0.1 57045\n ** v1 0.3 Listen on 127.0.0.1 57045 **** v1 0.3 macro def v1_addr=127.0.0.1 **** v1 0.3 macro def v1_port=57045 **** v1 0.3 macro def v1_sock=127.0.0.1 57045 ** top 0.3 === client c1 { ** c1 0.3 Starting client ** c1 0.3 Waiting for client *** c1 0.3 Connect to 127.0.0.1 57045 *** c1 0.3 connected fd 10 from 127.0.0.1 57049 to 127.0.0.1 57045 ** c1 0.3 === txreq **** c1 0.3 txreq| GET / HTTP/1.1\r\n **** c1 0.3 txreq| \r\n ** c1 0.3 === rxresp **** v1 0.3 vsl| 0 CLI - Rd vcl.load "vcl1" vcl_vcl1/vgc.so 1auto **** v1 0.3 vsl| 0 CLI - Wr 200 34 Loaded "vcl_vcl1/vgc.so" as "vcl1" **** v1 0.3 vsl| 0 CLI - Rd vcl.use "vcl1" **** v1 0.3 vsl| 0 CLI - Wr 200 0 **** v1 0.3 vsl| 0 CLI - Rd start **** v1 0.3 vsl| 0 CLI - Wr 200 0 **** v1 0.3 vsl| 0 CLI - Rd debug.xid 999 **** v1 0.3 vsl| 0 CLI - Wr 200 10 XID is 999 **** v1 0.3 vsl| 0 CLI - Rd debug.listen_address **** v1 0.3 vsl| 0 CLI - Wr 200 16 127.0.0.1 57045 *** s1 0.4 accepted fd 11 ** s1 0.4 === rxreq **** s1 0.4 rxhdr| GET / HTTP/1.1\r\n **** s1 0.4 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 0.4 rxhdr| Accept-Encoding: gzip\r\n **** s1 0.4 rxhdr| X-Varnish: 1002\r\n **** s1 0.4 rxhdr| Host: 127.0.0.1\r\n **** s1 0.4 rxhdr| \r\n **** s1 0.4 rxhdrlen = 103 **** s1 0.4 http[ 0] | GET **** s1 0.4 http[ 1] | / **** s1 0.4 http[ 2] | HTTP/1.1 **** s1 0.4 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 0.4 http[ 4] | Accept-Encoding: gzip **** s1 0.4 http[ 5] | X-Varnish: 1002 **** s1 0.4 http[ 6] | Host: 127.0.0.1 **** s1 0.4 bodylen = 0 ** s1 0.4 === txresp **** s1 0.4 txresp| HTTP/1.1 200 OK\r\n **** s1 0.4 txresp| Content-Length: 0\r\n **** s1 0.4 txresp| \r\n *** s1 0.4 shutting fd 11 ** s1 0.4 Ending **** v1 0.4 vsl| 1000 Begin c sess 0 HTTP/1 **** v1 0.4 vsl| 1000 SessOpen c 127.0.0.1 57049 127.0.0.1:57045 127.0.0.1 57045 1452859801.400176 10 **** v1 0.4 vsl| 1000 Link c req 1001 rxreq **** v1 0.4 vsl| 0 ExpKill - EXP_Inbox p=0x7fe0b85025e0 e=0.000000000 f=0x8 **** v1 0.4 vsl| 0 ExpKill - EXP_When p=0x7fe0b85025e0 e=1452859931.401523113 f=0x1c10 **** v1 0.4 vsl| 1002 Begin b bereq 1001 fetch **** v1 0.4 vsl| 1002 Timestamp b Start: 1452859801.400502 0.000000 0.000000 **** v1 0.4 vsl| 1002 BereqMethod b GET **** v1 0.4 vsl| 1002 BereqURL b / **** v1 0.4 vsl| 1002 BereqProtocol b HTTP/1.1 **** v1 0.4 vsl| 1002 BereqHeader b X-Forwarded-For: 127.0.0.1 **** v1 0.4 vsl| 1002 BereqHeader b Accept-Encoding: gzip **** v1 0.4 vsl| 1002 BereqHeader b X-Varnish: 1002 **** v1 0.4 vsl| 1002 VCL_call b BACKEND_FETCH **** v1 0.4 vsl| 1002 VCL_return b fetch **** v1 0.4 vsl| 1002 BereqHeader b Host: 127.0.0.1 **** v1 0.4 vsl| 1002 BackendOpen b 12 vcl1.s1 127.0.0.1 57043 127.0.0.1 57050 **** v1 0.4 vsl| 1002 Timestamp b Bereq: 1452859801.400846 0.000344 0.000344 **** v1 0.4 vsl| 1002 Timestamp b Beresp: 1452859801.401523 0.001021 0.000677 **** v1 0.4 vsl| 1002 BerespProtocol b HTTP/1.1 **** v1 0.4 vsl| 1002 BerespStatus b 200 **** v1 0.4 vsl| 1002 BerespReason b OK **** v1 0.4 vsl| 1002 BerespHeader b Content-Length: 0 **** v1 0.4 vsl| 1002 BerespHeader b Date: Fri, 15 Jan 2016 12:10:01 GMT **** v1 0.4 vsl| 1002 TTL b RFC 120 10 -1 1452859801 1452859801 1452859801 0 0 **** v1 0.4 vsl| 1002 VCL_call b BACKEND_RESPONSE **** v1 0.4 vsl| 1002 VCL_return b deliver **** v1 0.4 vsl| 1002 Storage b malloc s0 **** v1 0.4 vsl| 1002 ObjProtocol b HTTP/1.1 **** v1 0.4 vsl| 1002 ObjStatus b 200 **** v1 0.4 vsl| 1002 ObjReason b OK **** v1 0.4 vsl| 1002 ObjHeader b Content-Length: 0 **** v1 0.4 vsl| 1002 ObjHeader b Date: Fri, 15 Jan 2016 12:10:01 GMT **** v1 0.4 vsl| 1002 Fetch_Body b 0 none - **** v1 0.4 vsl| 1002 BackendReuse b 12 vcl1.s1 **** v1 0.4 vsl| 1002 Timestamp b BerespBody: 1452859801.412254 0.011752 0.010731 **** v1 0.4 vsl| 1002 Length b 0 **** v1 0.4 vsl| 1002 BereqAcct b 103 0 103 38 0 38 **** v1 0.4 vsl| 1002 End b ---- c1 0.7 HTTP rx EOF (fd:10 read: Undefined error: 0) * top 0.7 RESETTING after ./tests/r01801.vtc ** s1 0.7 Waiting for server (4/-1) **** s1 0.7 macro undef s1_addr **** s1 0.7 macro undef s1_port **** s1 0.7 macro undef s1_sock ** v1 0.7 Wait **** v1 0.7 CLI TX| backend.list *** v1 0.7 debug| Error: Child (87924) died signal=6\n *** v1 0.7 debug| Error: Child (87924) Last panic at: Fri, 15 Jan 2016 12:10:01 GMT\n *** v1 0.7 debug| "Assert error in vwk_thread(), waiter/cache_waiter_kqueue.c line 109:\n *** v1 0.7 debug| Condition(n >= 0) not true.\n *** v1 0.7 debug| errno = 4 (Interrupted system call)\n *** v1 0.7 debug| thread = (cache-kqueue)\n *** v1 0.7 debug| version = varnish-4.1.1-beta1 revision 32af38d\n *** v1 0.7 debug| ident = Darwin,14.3.0,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,kqueue\n *** v1 0.7 debug| Backtrace:\n *** v1 0.7 debug| 0x10316a38e: 0 varnishd 0x000000010316a38e pan_backtrace + 46\n *** v1 0.7 debug| 0x10316a1a7: 0 varnishd 0x000000010316a1a7 pan_ic + 727\n *** v1 0.7 debug| 0x1031c34d0: 0 varnishd 0x00000001031c34d0 vwk_thread + 1296\n *** v1 0.7 debug| 0x7fff842bc268: 0 libsystem_pthread.dylib 0x00007fff842bc268 _pthread_body + 131\n *** v1 0.7 debug| 0x7fff842bc1e5: 0 libsystem_pthread.dylib 0x00007fff842bc1e5 _pthread_body + 0\n *** v1 0.7 debug| 0x7fff842ba41d: 0 libsystem_pthread.dylib 0x00007fff842ba41d thread_start + 13\n *** v1 0.7 debug| \n *** v1 0.7 debug| "\n *** v1 0.7 debug| Debug: Child cleanup complete\n *** v1 0.7 CLI RX 101 **** v1 0.7 CLI RX| Unknown request in manager process (child not running).\n **** v1 0.7 CLI RX| Type 'help' for more info. **** v1 1.5 STDOUT poll 0x11 ** v1 1.5 R 87902 Status: 0000 (u 0.097042 s 0.057885) * top 1.6 TEST ./tests/r01801.vtc FAILED # top TEST ./tests/r01801.vtc FAILED (1.568) exit=1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 15 13:29:12 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jan 2016 13:29:12 -0000 Subject: [Varnish] #1802: Segfault after VCL change In-Reply-To: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> References: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> Message-ID: <061.81546ad05161fc1026744f2716995592@varnish-cache.org> #1802: Segfault after VCL change ----------------------+-------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): Side effect of commit 25417c3. We no longer generate a temporary file so -C ends up clobbering the loaded so file. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 16 14:05:01 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 16 Jan 2016 14:05:01 -0000 Subject: [Varnish] #1842: Assert error in hsh_rush() Message-ID: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> #1842: Assert error in hsh_rush() ---------------------+-------------------- Reporter: Sesse | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ---------------------+-------------------- Hi, I ran 4.1.1-beta1 on Debian jessie (from your packages). Immediately as the load increased, it started crashing repeatedly. I picked out the last panic, and got this: Last panic at: Sat, 16 Jan 2016 13:39:46 GMT "Assert error in hsh_rush(), cache/cache_hash.c line 526: Condition((wl) != NULL) not true. errno = 11 (Resource temporarily unavailable) thread = (cache-worker) version = varnish-4.1.1-beta1 revision 1fd0d39 ident = Linux,4.3.0,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433985: varnishd() [0x433985] 0x427e5a: varnishd() [0x427e5a] 0x428fc1: varnishd(HSH_DerefObjHead+0xa1) [0x428fc1] 0x4299c5: varnishd(HSH_Lookup+0x825) [0x4299c5] 0x436989: varnishd(CNT_Request+0x5b9) [0x436989] 0x44e713: varnishd(HTTP1_Session+0xe3) [0x44e713] 0x439d4d: varnishd(SES_Proto_Req+0x5d) [0x439d4d] 0x449062: varnishd() [0x449062] 0x4494db: varnishd() [0x4494db] 0x7f1c43b940a4: libpthread.so.0(+0x80a4) [0x7f1c43b940a4] req = 0x7f1c2f00f020 { vxid = 229379, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7f1c30c0e420 { fd = 35, vxid = 229377, client = 84.211.184.160 49650, step = S_STP_H1PROC, }, worker = 0x7f1c434c5c80 { stack = {0x7f1c434c6000 -> 0x7f1c434ba000}, ws = 0x7f1c434c5e78 { id = \"wrk\", {s,f,r,e} = {0x7f1c434c5420,0x7f1c434c5420,(nil),+2040}, }, VCL::method = HASH, VCL::return = lookup, VCL::methods = {}, }, ws = 0x7f1c2f00f200 { id = \"req\", {s,f,r,e} = {0x7f1c2f011000,+608,+90104,+90104}, }, http_conn = 0x7f1c2f00f128 { fd = 35, doclose = NULL, ws = 0x7f1c2f00f200, {rxbuf_b, rxbuf_e} = {0x7f1c2f011000, 0x7f1c2f0111a3}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = -1, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7f1c2f00f298 { ws[req] = 0x7f1c2f00f200, hdrs { \"GET\", \"/analysis.pl?ims=1452951576000&unique=0.15300315176136792\", \"HTTP/1.1\", \"Host: analysis.sesse.net\", \"Connection: keep-alive\", \"Accept: */*\", \"X-Requested-With: XMLHttpRequest\", \"User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36\", \"Referer: http://analysis.sesse.net/\", \"Accept-Language: en-US,en;q=0.8,nb;q=0.6\", \"DNT: 1\", \"X-Forwarded-For: 84.211.184.160, 84.211.184.160\", \"x-analysis-backend: backend1\", \"Accept-Encoding: gzip\", }, }, vcl = { temp = warm srcname = { \"/etc/varnish/default.vcl\", \"Builtin\", }, }, flags = { }, }, " -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 16 14:06:35 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 16 Jan 2016 14:06:35 -0000 Subject: [Varnish] #1842: Assert error in hsh_rush() In-Reply-To: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> References: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> Message-ID: <058.686d3791e344a1eb654d763b59a24f18@varnish-cache.org> #1842: Assert error in hsh_rush() ----------------------+---------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------- Changes (by lkarsten): * component: build => varnishd Old description: > Hi, > > I ran 4.1.1-beta1 on Debian jessie (from your packages). Immediately as > the load increased, it started crashing repeatedly. I picked out the last > panic, and got this: > > Last panic at: Sat, 16 Jan 2016 13:39:46 GMT > "Assert error in hsh_rush(), cache/cache_hash.c line 526: > Condition((wl) != NULL) not true. > errno = 11 (Resource temporarily unavailable) > thread = (cache-worker) > version = varnish-4.1.1-beta1 revision 1fd0d39 > ident = Linux,4.3.0,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll > Backtrace: > 0x433985: varnishd() [0x433985] > 0x427e5a: varnishd() [0x427e5a] > 0x428fc1: varnishd(HSH_DerefObjHead+0xa1) [0x428fc1] > 0x4299c5: varnishd(HSH_Lookup+0x825) [0x4299c5] > 0x436989: varnishd(CNT_Request+0x5b9) [0x436989] > 0x44e713: varnishd(HTTP1_Session+0xe3) [0x44e713] > 0x439d4d: varnishd(SES_Proto_Req+0x5d) [0x439d4d] > 0x449062: varnishd() [0x449062] > 0x4494db: varnishd() [0x4494db] > 0x7f1c43b940a4: libpthread.so.0(+0x80a4) [0x7f1c43b940a4] > req = 0x7f1c2f00f020 { > vxid = 229379, step = R_STP_LOOKUP, > req_body = R_BODY_NONE, > restarts = 0, esi_level = 0, > sp = 0x7f1c30c0e420 { > fd = 35, vxid = 229377, > client = 84.211.184.160 49650, > step = S_STP_H1PROC, > }, > worker = 0x7f1c434c5c80 { > stack = {0x7f1c434c6000 -> 0x7f1c434ba000}, > ws = 0x7f1c434c5e78 { > id = \"wrk\", > {s,f,r,e} = {0x7f1c434c5420,0x7f1c434c5420,(nil),+2040}, > }, > VCL::method = HASH, > VCL::return = lookup, > VCL::methods = {}, > }, > ws = 0x7f1c2f00f200 { > id = \"req\", > {s,f,r,e} = {0x7f1c2f011000,+608,+90104,+90104}, > }, > http_conn = 0x7f1c2f00f128 { > fd = 35, > doclose = NULL, > ws = 0x7f1c2f00f200, > {rxbuf_b, rxbuf_e} = {0x7f1c2f011000, 0x7f1c2f0111a3}, > {pipeline_b, pipeline_e} = {(nil), (nil)}, > content_length = -1, > body_status = none, > first_byte_timeout = 0.000000, > between_bytes_timeout = 0.000000, > }, > http[req] = 0x7f1c2f00f298 { > ws[req] = 0x7f1c2f00f200, > hdrs { > \"GET\", > \"/analysis.pl?ims=1452951576000&unique=0.15300315176136792\", > \"HTTP/1.1\", > \"Host: analysis.sesse.net\", > \"Connection: keep-alive\", > \"Accept: */*\", > \"X-Requested-With: XMLHttpRequest\", > \"User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 > Safari/537.36\", > \"Referer: http://analysis.sesse.net/\", > \"Accept-Language: en-US,en;q=0.8,nb;q=0.6\", > \"DNT: 1\", > \"X-Forwarded-For: 84.211.184.160, 84.211.184.160\", > \"x-analysis-backend: backend1\", > \"Accept-Encoding: gzip\", > }, > }, > vcl = { > temp = warm > srcname = { > \"/etc/varnish/default.vcl\", > \"Builtin\", > }, > }, > flags = { > }, > }, > > " New description: Hi, I ran 4.1.1-beta1 on Debian jessie (from your packages). Immediately as the load increased, it started crashing repeatedly. I picked out the last panic, and got this: {{{ Last panic at: Sat, 16 Jan 2016 13:39:46 GMT "Assert error in hsh_rush(), cache/cache_hash.c line 526: Condition((wl) != NULL) not true. errno = 11 (Resource temporarily unavailable) thread = (cache-worker) version = varnish-4.1.1-beta1 revision 1fd0d39 ident = Linux,4.3.0,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433985: varnishd() [0x433985] 0x427e5a: varnishd() [0x427e5a] 0x428fc1: varnishd(HSH_DerefObjHead+0xa1) [0x428fc1] 0x4299c5: varnishd(HSH_Lookup+0x825) [0x4299c5] 0x436989: varnishd(CNT_Request+0x5b9) [0x436989] 0x44e713: varnishd(HTTP1_Session+0xe3) [0x44e713] 0x439d4d: varnishd(SES_Proto_Req+0x5d) [0x439d4d] 0x449062: varnishd() [0x449062] 0x4494db: varnishd() [0x4494db] 0x7f1c43b940a4: libpthread.so.0(+0x80a4) [0x7f1c43b940a4] req = 0x7f1c2f00f020 { vxid = 229379, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7f1c30c0e420 { fd = 35, vxid = 229377, client = 84.211.184.160 49650, step = S_STP_H1PROC, }, worker = 0x7f1c434c5c80 { stack = {0x7f1c434c6000 -> 0x7f1c434ba000}, ws = 0x7f1c434c5e78 { id = \"wrk\", {s,f,r,e} = {0x7f1c434c5420,0x7f1c434c5420,(nil),+2040}, }, VCL::method = HASH, VCL::return = lookup, VCL::methods = {}, }, ws = 0x7f1c2f00f200 { id = \"req\", {s,f,r,e} = {0x7f1c2f011000,+608,+90104,+90104}, }, http_conn = 0x7f1c2f00f128 { fd = 35, doclose = NULL, ws = 0x7f1c2f00f200, {rxbuf_b, rxbuf_e} = {0x7f1c2f011000, 0x7f1c2f0111a3}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = -1, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7f1c2f00f298 { ws[req] = 0x7f1c2f00f200, hdrs { \"GET\", \"/analysis.pl?ims=1452951576000&unique=0.15300315176136792\", \"HTTP/1.1\", \"Host: analysis.sesse.net\", \"Connection: keep-alive\", \"Accept: */*\", \"X-Requested-With: XMLHttpRequest\", \"User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36\", \"Referer: http://analysis.sesse.net/\", \"Accept-Language: en-US,en;q=0.8,nb;q=0.6\", \"DNT: 1\", \"X-Forwarded-For: 84.211.184.160, 84.211.184.160\", \"x-analysis-backend: backend1\", \"Accept-Encoding: gzip\", }, }, vcl = { temp = warm srcname = { \"/etc/varnish/default.vcl\", \"Builtin\", }, }, flags = { }, }, }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 16 14:07:25 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 16 Jan 2016 14:07:25 -0000 Subject: [Varnish] #1842: Assert error in hsh_rush() In-Reply-To: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> References: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> Message-ID: <058.bf0ad818f9170ee0b97e7498420c22b4@varnish-cache.org> #1842: Assert error in hsh_rush() ----------------------+-------------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------------- Changes (by lkarsten): * version: unknown => 4.1.1-beta1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 16 14:09:52 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 16 Jan 2016 14:09:52 -0000 Subject: [Varnish] #1842: Assert error in hsh_rush() In-Reply-To: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> References: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> Message-ID: <058.fbaf3c7ffe729cbf18d2f17f5daed146@varnish-cache.org> #1842: Assert error in hsh_rush() ----------------------+-------------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------------- Comment (by lkarsten): Note for Monday: verify that 32af38d43c9cefa10ef24775ef999fbd61fd49ed does what it was supposed to do. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 16 14:55:26 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 16 Jan 2016 14:55:26 -0000 Subject: [Varnish] #1842: Assert error in hsh_rush() In-Reply-To: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> References: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> Message-ID: <058.9f8a98a5947cf4dd0a825735854b02de@varnish-cache.org> #1842: Assert error in hsh_rush() ----------------------+-------------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------------- Comment (by lkarsten): https://gist.github.com/lkarsten/18d35c409d2227bd7d74 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 17 07:30:27 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 17 Jan 2016 07:30:27 -0000 Subject: [Varnish] #1843: HTTP/1.0 POST without C-L should error out earlier Message-ID: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> #1843: HTTP/1.0 POST without C-L should error out earlier ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- In a6a6e97a we allowed POST without a body. For HTTP/1.0 however, the Content-Length must be present. Currently, we will pass the request and assume chunked, which is incorrect for HTTP/1.0. We should error out earlier. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 17 07:34:26 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 17 Jan 2016 07:34:26 -0000 Subject: [Varnish] #1843: HTTP/1.0 POST without C-L should error out earlier In-Reply-To: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> References: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> Message-ID: <058.1797d0626203f46b987f025c374f339e@varnish-cache.org> #1843: HTTP/1.0 POST without C-L should error out earlier ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Description changed by fgsch: Old description: > In a6a6e97a we allowed POST without a body. > For HTTP/1.0 however, the Content-Length must be present. > > Currently, we will pass the request and assume chunked, which is > incorrect for HTTP/1.0. We should error out earlier. New description: In a6a6e97a we allowed POST without a body. For HTTP/1.0 however, the Content-Length must be present. Currently, we will pass the request and assume chunked, which is incorrect for HTTP/1.0. Since there is no body, we timeout eventually: {{{ 1002 FetchError b req.body read error: 11 (Resource temporarily unavailable) 1002 FetchError b backend write error: 11 (Resource temporarily unavailable) }}} We should error out earlier. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 17 18:18:14 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 17 Jan 2016 18:18:14 -0000 Subject: [Varnish] #1843: HTTP/1.0 POST without C-L should error out earlier In-Reply-To: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> References: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> Message-ID: <058.0294a4a64d9e09fd2a7b583fbf636caa@varnish-cache.org> #1843: HTTP/1.0 POST without C-L should error out earlier ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): Fix attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 17 19:02:04 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 17 Jan 2016 19:02:04 -0000 Subject: [Varnish] #1843: HTTP/1.0 POST without C-L should error out earlier In-Reply-To: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> References: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> Message-ID: <058.d2b8e0ad20381b71eda92ebb053befa3@varnish-cache.org> #1843: HTTP/1.0 POST without C-L should error out earlier ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): After some more reading I think this should cover PUT and POST. Revised patch attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 18 13:59:49 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jan 2016 13:59:49 -0000 Subject: [Varnish] #1842: Assert error in hsh_rush() In-Reply-To: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> References: <043.597ee610527269b4f3a178c6a0d9a716@varnish-cache.org> Message-ID: <058.7f8c92e6e33125da0ed5507350abc05c@varnish-cache.org> #1842: Assert error in hsh_rush() ----------------------+-------------------------------------------- Reporter: Sesse | Owner: Lasse Karstensen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.1-beta1 Severity: normal | Resolution: fixed Keywords: | ----------------------+-------------------------------------------- Changes (by Lasse Karstensen ): * status: new => closed * owner: => Lasse Karstensen * resolution: => fixed Comment: In [d8ac05a3c4b7b5838eee2d94150e6853cfc64d43]: {{{ #!CommitTicketReference repository="" revision="d8ac05a3c4b7b5838eee2d94150e6853cfc64d43" Handle missing waiting list gracefully. In 5c8268062bf06a2700dd27331c29c48d650c9197 the checks are relaxed, but this commit (or part of) was not brought into 4.1. Fixes: #1842 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 18 14:07:28 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jan 2016 14:07:28 -0000 Subject: [Varnish] #1802: Segfault after VCL change In-Reply-To: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> References: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> Message-ID: <061.f19f8be98f0063f6b0d1dc765ba542f7@varnish-cache.org> #1802: Segfault after VCL change ----------------------+--------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [00736b717316cac500c9508d6d46ac5fb6e0eca4]: {{{ #!CommitTicketReference repository="" revision="00736b717316cac500c9508d6d46ac5fb6e0eca4" Use a unique (and now reserved) VCL name of -C testing. Fixes: #1802 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 18 15:53:39 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jan 2016 15:53:39 -0000 Subject: [Varnish] #1820: Assert error in SES_Delete In-Reply-To: <045.e76209f816c7781b0f5ad7c7524e235d@varnish-cache.org> References: <045.e76209f816c7781b0f5ad7c7524e235d@varnish-cache.org> Message-ID: <060.cc9cfa3b0a2ecd89c77fc457653deb3c@varnish-cache.org> #1820: Assert error in SES_Delete --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: invalid Keywords: assert error | --------------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 18 15:54:43 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jan 2016 15:54:43 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service In-Reply-To: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> References: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> Message-ID: <063.a846c6da17e030592e21dc66e3dd3d93@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service ------------------------+--------------------- Reporter: ghostshell | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: fixed Keywords: | ------------------------+--------------------- Changes (by fgsch): * status: new => closed * resolution: => fixed Comment: We believe this is the same as #1802. Commit 00736b717316cac500c9508d6d46ac5fb6e0eca4 and 7d979720f14d7c22a5a3b3498fa4dd173af94958 should address it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 18 16:38:18 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jan 2016 16:38:18 -0000 Subject: [Varnish] #1802: Segfault after VCL change In-Reply-To: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> References: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> Message-ID: <061.4481876f61ec9b5bc47bc1b213978e4a@varnish-cache.org> #1802: Segfault after VCL change ----------------------+--------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [8de208636c4425cbc3257e1ce509794835dfdd73]: {{{ #!CommitTicketReference repository="" revision="8de208636c4425cbc3257e1ce509794835dfdd73" Use a unique (and now reserved) VCL name of -C testing. Fixes: #1802 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 18 21:22:43 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jan 2016 21:22:43 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code Message-ID: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code ------------------------------------------+-------------------- Reporter: geoff | Type: defect Status: new | Priority: high Milestone: Later | Component: vmod Version: trunk | Severity: major Keywords: vmod,object,enum,string_list | ------------------------------------------+-------------------- If the signature of an object constructor specifies an ENUM followed by a STRING_LIST, then illegal C code is emitted as the translation of VCL that uses it in "new". This has been tested against current trunk (as of today). The patch that I'll be attaching demonstrates the problem: {{{ $ ./varnishtest -i tests/m00000.vtc [...] **** v1 0.7 CLI RX| Message from C-compiler:\n **** v1 0.7 CLI RX| vgc.c:1081:8: error: unknown type name \xe2\x80\x98STRING_LIST\xe2\x80\x99\n **** v1 0.7 CLI RX| static STRING_LIST *vo_list;\n **** v1 0.7 CLI RX| ^\n **** v1 0.7 CLI RX| vgc.c: In function \xe2\x80\x98VGC_function_vcl_init\xe2\x80\x99:\n **** v1 0.7 CLI RX| vgc.c:1325:44: error: passing argument 2 of \xe2\x80\x98Vmod_debug_Func.enum_list__init\xe2\x80\x99 from incompatible pointer type [-Werror]\n **** v1 0.7 CLI RX| Vmod_debug_Func.enum_list__init(ctx, &vo_list, "list",\n **** v1 0.7 CLI RX| ^\n **** v1 0.7 CLI RX| vgc.c:1325:44: note: expected \xe2\x80\x98struct vmod_debug_enum_list **\xe2\x80\x99 but argument is of type \xe2\x80\x98int **\xe2\x80\x99\n **** v1 0.7 CLI RX| vgc.c: In function \xe2\x80\x98VGC_Discard\xe2\x80\x99:\n **** v1 0.7 CLI RX| vgc.c:1571:31: error: expected identifier or \xe2\x80\x98(\xe2\x80\x99 before \xe2\x80\x98&\xe2\x80\x99 token\n **** v1 0.7 CLI RX| [3 lines truncated]\n **** v1 0.7 CLI RX| Running C-compiler failed, exited with 1\n **** v1 0.7 CLI RX| VCL compilation failed [...] }}} The sequences `\xe2\x80\x98` and `\xe2\x80\x99` are hex encodings of Unicode open and close quotation marks, which the compiler is emitting on my terminal for some reason. So the compiler is saying that it encountered the declaration `static STRING_LIST *vo_list;`, which I suspect was emitted by `parse_new()` in `vcc_action.c` (line 216). I believe that can't ever be right, since a STRING_LIST should always be turned into `const char *, ...`. This problem apparently *only* happens with this combination: constructor, ENUM and STRING_LIST. I get no problems with any of the following: * ENUM followed by STRING_LIST in a VMOD function. * STRING_LIST by itself in an object constructor * INT followed by STRING_LIST in a constructor * STRING followed by a STRING_LIST in a constructor -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 09:40:14 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 09:40:14 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. Message-ID: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. -------------------------+------------------------ Reporter: xcir | Type: defect Status: new | Priority: normal Milestone: | Component: varnishlog Version: 4.1.1-beta1 | Severity: normal Keywords: vsl-query | -------------------------+------------------------ VSL-query was using the VNUM when vsl-query parse the float.[[BR]] https://github.com/varnish/Varnish- Cache/blob/1628f0b93e4ba725f2f26ca82a6e794229517475/lib/libvarnishapi/vsl_query.c#L148 But, VNUM does not care a string of multiple field. (ex: - Timestamp Resp: 1453185650.045902 0.000848 0.000031 )[[BR]] https://github.com/varnish/Varnish- Cache/blob/c24650d0f19faaa2f9c629c9d79ccebb940f585b/lib/libvarnish/vnum.c#L104-L105 Therefore, vsl-query can only capture last field. '''Unpatched(not have output)''' {{{ [root at ws01 httpd]# varnishlog -q "timestamp:resp[2] > 0." -graw ^C[root at ws01 httpd]# }}} '''Patched(value is floats)''' {{{ xcir at varnish-trunk:~$ sudo /opt/varnish-411/bin/varnishlog -q "timestamp:resp[2] > 0." -graw 32776 Timestamp c Resp: 1453194103.565767 0.001798 0.000025 ^Cxcir at varnish-trunk:~$ }}} '''Patched(value is not floats/not have output)''' {{{ xcir at varnish-trunk:~sudo /opt/varnish-411/bin/varnishlog -q "respheader:b" -graw 2 RespHeader c B: 2.427602foo 4.001516bar 6.000027mage ^Cxcir at varnish-trunk:~$ sudo /opt/varnish-411/bin/varnishlog -q "respheader:b[1] > 0" -graw ^Cxcir at varnish-trunk:~$ }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 10:06:12 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 10:06:12 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.c0fbca1f63b2181315af98e21994f07b@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by xcir): Sorry, mistake.[[BR]] '''Patched(value is not floats/not have output)''' {{{ xcir at varnish-trunk:~$ xcir at varnish-trunk:~$ sudo /opt/varnish-411/bin/varnishlog -q "respheader:b" -graw 32782 RespHeader c B: 2.427602foo 4.001516bar 6.000027mage ^Cxcir at varnish-trunk:~$ sudo /opt/varnish-411/bin/varnishlog -q "respheader:b[1] > 0." -graw ^Cxcir at varnish-trunk:~$ }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 12:31:01 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 12:31:01 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code In-Reply-To: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> References: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> Message-ID: <058.0545bcfc979537103b30676507ae50e7@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code ------------------------------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: high | Milestone: Later Component: vmod | Version: trunk Severity: major | Resolution: Keywords: vmod,object,enum,string_list | ------------------------------------------+-------------------- Comment (by fgsch): Proposed patch attached. I think this is enough but we could check for "struct". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 12:54:19 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 12:54:19 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code In-Reply-To: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> References: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> Message-ID: <058.4f358c60a3e0755bb21917c8af75919c@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code ------------------------------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: high | Milestone: Later Component: vmod | Version: trunk Severity: major | Resolution: Keywords: vmod,object,enum,string_list | ------------------------------------------+-------------------- Comment (by geoff): The patch works for me -- my own patch above for the Varnish tree runs without an error, and the VMOD I was working on now gets past the C-compile step. Can't say if the check for "struct" is necessary. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 17:47:33 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 17:47:33 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.cc455561050b92486384e9cb5622ddd3@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by fgsch): Broken in 9bb8f96223d248beb5962961b493b16dcc8ecc2a. VNUMpfx() will skip trailing whitespaces so I don't think this patch is correct. It is passing the tests because what was after the space was a digit/+/-. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 18:02:51 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 18:02:51 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.8d7996b0bd6b51a0fd743ef138f60954@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by fgsch): Proposed patch attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 18:23:05 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 18:23:05 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.1704ef9fa316746176f18553e566e503@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by xcir): r01845.patch is change some other function action, if string including spaces. (std.duration, VNUM, VNUM_2bytes) Impact range is worrisome. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 19 23:08:19 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jan 2016 23:08:19 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.b8ea4e6c4e5900cb30875a22b42ee28f@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by fgsch): I should have added, I've checked all instances and I couldn't find any issues. Specifically for the functions you have mentioned: 1. std.duration() does the skipping in the code. 2. VNUM_2bytes() allows for a space after the number. 3. VNUM is mostly used for converting arguments so the space is a non- issue. If this is a concern we could use VNUMpfx() and do the whitespace skipping dance explicitly, however. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 20 12:21:08 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Jan 2016 12:21:08 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.74568f68ca5024ecf4f1a1072ce91eda@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by fgsch): Actually, my previous patch had a bug. I've also reconsidered the approach and to remain inline with the previous behaviour I've moved the whitespace skipping out of VNUMpfx and into the functions that call it. Attached is a revisited patch that should address xcir concerns and the bug itself. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 20 15:25:00 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Jan 2016 15:25:00 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.8ca25f89754fdad83de7b38c10054a79@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by xcir): I tried this patch. looks good to me. :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 20 15:56:36 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Jan 2016 15:56:36 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.931d625bb97baf8ff9e6e7b65659fca7@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by xcir): Sorry, I found a problem at std.real -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 20 16:04:33 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Jan 2016 16:04:33 -0000 Subject: [Varnish] #1846: varnishlog assert in vslc_vtx_next Message-ID: <046.789c878f2dbf132c8b9339747a6ab0d8@varnish-cache.org> #1846: varnishlog assert in vslc_vtx_next ------------------------+-------------------- Reporter: felipewd | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.1.0 | Severity: normal Keywords: varnishlog | ------------------------+-------------------- When using varnish with 20k/sec requests and a small log, varnishlog crashes after a few minutes. {{{ (gdb) bt #0 0x00007ffff6c77f97 in raise () from /lib64/libc.so.6 #1 0x00007ffff6c79bfa in abort () from /lib64/libc.so.6 #2 0x00007ffff79ace0c in VAS_Fail_default (func=0x7ffff79cc577 <__func__.4093> "vslc_vtx_next", file=0x7ffff79cbbaa "vsl_dispatch.c", line=285, cond=0x7ffff79cbc78 "c->offset <= c->vtx->len", kind=VAS_ASSERT) at ../libvarnish/vas.c:69 #3 0x00007ffff79ba463 in vslc_vtx_next (cursor=0x60b738) at vsl_dispatch.c:285 #4 0x00007ffff79b8ddb in VSL_Next (cursor=0x60b738) at vsl_cursor.c:479 #5 0x00007ffff79c193d in VSL_PrintTransactions (vsl=0x60a030, pt=0x7fffffffdfd0, fo=0x7ffff7007740 <_IO_2_1_stdout_>) at vsl.c:382 #6 0x000000000040253c in vut_dispatch (vsl=0x60a030, trans=0x7fffffffdfd0, priv=0x0) at ../../lib/libvarnishtools/vut.c:99 #7 0x00007ffff79bd84d in vslq_callback (vslq=0x60a200, vtx=0x0, func=0x4024ca , priv=0x0) at vsl_dispatch.c:980 #8 0x00007ffff79bebe4 in vslq_process_ready (vslq=0x60a200, func=0x4024ca , priv=0x0) at vsl_dispatch.c:1302 #9 0x00007ffff79befa8 in VSLQ_Dispatch (vslq=0x60a200, func=0x4024ca , priv=0x0) at vsl_dispatch.c:1368 #10 0x00000000004035d0 in VUT_Main () at ../../lib/libvarnishtools/vut.c:386 #11 0x0000000000402451 in main (argc=1, argv=0x7fffffffe2b8) at varnishlog.c:173 (gdb) f 3 #3 0x00007ffff79ba463 in vslc_vtx_next (cursor=0x60b738) at vsl_dispatch.c:285 285 in vsl_dispatch.c (gdb) p c->offset $5 = 6951 (gdb) p c->vtx->len $7 = 650 }}} The full backtrace is: {{{ (gdb) bt full #0 0x00007ffff6c77f97 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007ffff6c79bfa in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007ffff79ace0c in VAS_Fail_default (func=0x7ffff79cc577 <__func__.4093> "vslc_vtx_next", file=0x7ffff79cbbaa "vsl_dispatch.c", line=285, cond=0x7ffff79cbc78 "c->offset <= c->vtx->len", kind=VAS_ASSERT) at ../libvarnish/vas.c:69 err = 0 #3 0x00007ffff79ba463 in vslc_vtx_next (cursor=0x60b738) at vsl_dispatch.c:285 c = 0x60b730 ptr = 0x20f653d564 __func__ = "vslc_vtx_next" #4 0x00007ffff79b8ddb in VSL_Next (cursor=0x60b738) at vsl_cursor.c:479 tbl = 0x7ffff7bd4320 __func__ = "VSL_Next" #5 0x00007ffff79c193d in VSL_PrintTransactions (vsl=0x60a030, pt=0x7fffffffdfd0, fo=0x7ffff7007740 <_IO_2_1_stdout_>) at vsl.c:382 t = 0x7fffffffdff0 i = 0 delim = 1 verbose = 0 __func__ = "VSL_PrintTransactions" #6 0x000000000040253c in vut_dispatch (vsl=0x60a030, trans=0x7fffffffdfd0, priv=0x0) at ../../lib/libvarnishtools/vut.c:99 i = 0 __func__ = "vut_dispatch" #7 0x00007ffff79bd84d in vslq_callback (vslq=0x60a200, vtx=0x0, func=0x4024ca , priv=0x0) at vsl_dispatch.c:980 n = 1 vtxs = 0x7fffffffe020 trans = 0x7fffffffdff0 ptrans = 0x7fffffffdfd0 i = 1 j = 1 __func__ = "vslq_callback" #8 0x00007ffff79bebe4 in vslq_process_ready (vslq=0x60a200, func=0x4024ca , priv=0x0) at vsl_dispatch.c:1302 ---Type to continue, or q to quit--- vtx = 0x60b590 i = 0 __func__ = "vslq_process_ready" #9 0x00007ffff79befa8 in VSLQ_Dispatch (vslq=0x60a200, func=0x4024ca , priv=0x0) at vsl_dispatch.c:1368 i = 1 r = 0 now = 2847820.978886629 vtx = 0x60a310 __func__ = "VSLQ_Dispatch" #10 0x00000000004035d0 in VUT_Main () at ../../lib/libvarnishtools/vut.c:386 c = 0x0 i = 1 __func__ = "VUT_Main" #11 0x0000000000402451 in main (argc=1, argv=0x7fffffffe2b8) at varnishlog.c:173 opt = -1 __func__ = "main" }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 20 16:34:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Jan 2016 16:34:16 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.a122317c7c01452c813c52783ec5a10d@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+-------------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: Keywords: vsl-query | ------------------------+-------------------------- Comment (by fgsch): Good catch! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 21 13:49:38 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 21 Jan 2016 13:49:38 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code In-Reply-To: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> References: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> Message-ID: <058.76bce4512ccad1bb3d40399a9ee80c31@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code ------------------------------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: high | Milestone: Later Component: vmod | Version: trunk Severity: major | Resolution: Keywords: vmod,object,enum,string_list | ------------------------------------------+-------------------- Comment (by fgsch): Just to clarify, this is a backward compatible approach. In the long run we might want to revisit how we deal with ENUMs in general. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 21 14:51:33 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 21 Jan 2016 14:51:33 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code In-Reply-To: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> References: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> Message-ID: <058.159feeacd90fdc4cef94318935909985@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code ------------------------------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: high | Milestone: Later Component: vmod | Version: trunk Severity: major | Resolution: Keywords: vmod,object,enum,string_list | ------------------------------------------+-------------------- Comment (by geoff): I agree, the way ENUMs work now is kludgy. But we'll need the bugfix for the time being. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 22 12:15:30 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Jan 2016 12:15:30 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.a9faa7d435c69afb8ca50229dacce9d7@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+--------------------------------------------- Reporter: xcir | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: fixed Keywords: vsl-query | ------------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: new => closed * resolution: => fixed Comment: In [0e0b37412e1766bccb8e0db447784ce2f23fb307]: {{{ #!CommitTicketReference repository="" revision="0e0b37412e1766bccb8e0db447784ce2f23fb307" Handle whitespace after floats in test fields Broken in 9bb8f96223d248beb5962961b493b16dcc8ecc2a. Committed solution proposed by phk@, discussed with phk@ and martin at . Fixes #1845. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 22 15:47:00 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Jan 2016 15:47:00 -0000 Subject: [Varnish] #1845: VSL-query can only capture last field, if using floats operand. In-Reply-To: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> References: <042.a55103a8eac41227bce003de55c83361@varnish-cache.org> Message-ID: <057.68a32daf9c0c5f4c432a7c8221a487ec@varnish-cache.org> #1845: VSL-query can only capture last field, if using floats operand. ------------------------+--------------------------------------------- Reporter: xcir | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 4.1.1-beta1 Severity: normal | Resolution: fixed Keywords: vsl-query | ------------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [152dd84ad66717e2b248d57840cf6c26269d3648]: {{{ #!CommitTicketReference repository="" revision="152dd84ad66717e2b248d57840cf6c26269d3648" Handle whitespace after floats in test fields Broken in 9bb8f96223d248beb5962961b493b16dcc8ecc2a. Committed solution proposed by phk@, discussed with phk@ and martin at . Fixes #1845. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jan 23 09:17:53 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 23 Jan 2016 09:17:53 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code In-Reply-To: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> References: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> Message-ID: <058.3e07896d7f4b6cc2243c78b4eeac0bc0@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code -------------------------------------+------------------------------------- Reporter: geoff | Owner: Federico G. Schwindt Type: defect | Priority: high | Status: closed Component: vmod | Milestone: Later Severity: major | Version: trunk Keywords: | Resolution: fixed vmod,object,enum,string_list | -------------------------------------+------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: new => closed * resolution: => fixed Comment: In [84a2903805580973c59635bacb99df5da901c02c]: {{{ #!CommitTicketReference repository="" revision="84a2903805580973c59635bacb99df5da901c02c" Correct ENUM handling in object constructors Discussed with phk at . Fix confirmed by geoff at . Fixes #1844. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 25 08:35:05 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Jan 2016 08:35:05 -0000 Subject: [Varnish] #1843: HTTP/1.0 POST without C-L should error out earlier In-Reply-To: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> References: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> Message-ID: <058.47c771f56adf07739546e8370e0c7530@varnish-cache.org> #1843: HTTP/1.0 POST without C-L should error out earlier ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): Version 3 attached after discussing with phk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 25 12:59:12 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Jan 2016 12:59:12 -0000 Subject: [Varnish] #1837: Error compiling VCL if probe is referenced before it is defined In-Reply-To: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> References: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> Message-ID: <058.6877e28c93253cf7810fa80909ce7e36@varnish-cache.org> #1837: Error compiling VCL if probe is referenced before it is defined ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): Patch including testcase attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 26 16:10:18 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 26 Jan 2016 16:10:18 -0000 Subject: [Varnish] #1847: HTTP1_DissectRequest doesn't handle https Message-ID: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> #1847: HTTP1_DissectRequest doesn't handle https -----------------------+---------------------- Reporter: gquintard | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -----------------------+---------------------- With 4.1 handling https with the PROXY protocol, we sould handle https:// url in the status line. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 27 05:56:10 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Jan 2016 05:56:10 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code In-Reply-To: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> References: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> Message-ID: <058.8af9187f51e6bc0292dc4ffcd0ee6ea3@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code -------------------------------------+------------------------------------- Reporter: geoff | Owner: Federico G. Schwindt Type: defect | Priority: high | Status: closed Component: vmod | Milestone: Later Severity: major | Version: trunk Keywords: | Resolution: fixed vmod,object,enum,string_list | -------------------------------------+------------------------------------- Comment (by geoff): I can confirm that the VMOD I'm currently working on, which has this kind of declaration, has no problems in a build against master with this fix. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 27 18:14:06 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Jan 2016 18:14:06 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.573e402e2f06cdcb7605684d137e63d2@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by slink): * status: closed => reopened * resolution: invalid => Comment: This issue still exists at least for {{{workspace_backend == http_resp_size}}}, reproducible on Solaris with a backend on loopback (may be relevant because the default loopback MTU on solaris is 8k): {{{V1F_FetchRespHdr}}} calls {{{SES_RxInit}}} with {{{cache_param->http_resp_size}}}, so if the actual backend read is large enough to use up the reservation on {{{htc->ws == bo->ws}}}, there may be no space left on the ws for the VFPs. Maybe we should estimate the space required by the VFPs and reduce the SES_RxInit allocation by that amount. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 27 23:31:03 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Jan 2016 23:31:03 -0000 Subject: [Varnish] #1848: vev's asynchronous signal handling poses problems for manager process Message-ID: <041.f84eac65c56431298bf761e9d0af53b4@varnish-cache.org> #1848: vev's asynchronous signal handling poses problems for manager process ------------------------+---------------------- Reporter: dho | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: minor Keywords: vev signal | ------------------------+---------------------- Long version is available at [https://www.varnish- cache.org/lists/pipermail/varnish-dev/2016-January/008758.html] Vev handles signals by recording them, and processing them as "events" asynchronously in its main event loop. When consumers of vev use syscalls that cannot be restarted, the behavior they should exhibit is unclear (consider the manager getting SIGCHLD while waiting for a CLI response, perhaps). In particular, the manager process receiving a signal while waiting for a response from a stuck CLI can cause both the manager and child processes to hang indefinitely. Depending on the state of the system, behaviors range from "works as expected" to CLI desync to hung processes. Not sure what the best strategy for patching is; the issue probably doesn't matter much. The best thing I've come up with so far is to have a flag on vevsig that allows one to force vev to handle that signal synchronously. Thoughts? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 28 14:25:56 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Jan 2016 14:25:56 -0000 Subject: [Varnish] #1847: HTTP1_DissectRequest doesn't handle https In-Reply-To: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> References: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> Message-ID: <062.a6dfa1e94b2d1c0b34fcc5a13da03a2a@varnish-cache.org> #1847: HTTP1_DissectRequest doesn't handle https -----------------------+-------------------- Reporter: gquintard | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by Dridi): Regardless of PROXY protocol, if we have a trusted HTTPS or TLS proxy in front of Varnish, shouldn't we treat the https scheme as a hint to the web application that the end-user connected through a secure channel? I think it's the same intent as putting an X-Forwarded-Proto:https header field. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 29 09:18:59 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Jan 2016 09:18:59 -0000 Subject: [Varnish] #1847: HTTP1_DissectRequest doesn't handle https In-Reply-To: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> References: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> Message-ID: <062.3462a58d59ea0d1eda96b2a6d8b1903c@varnish-cache.org> #1847: HTTP1_DissectRequest doesn't handle https -----------------------+-------------------- Reporter: gquintard | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by gquintard): My main concern about this one is that we won't hash the correct string because varnish can't split it correctly, leading to duplication. But it also screws up logs tht use requrl. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 29 12:25:55 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Jan 2016 12:25:55 -0000 Subject: [Varnish] #1847: HTTP1_DissectRequest doesn't handle https In-Reply-To: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> References: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> Message-ID: <062.b0253b2b0af4bd357dc3c63f2f433cc9@varnish-cache.org> #1847: HTTP1_DissectRequest doesn't handle https -----------------------+-------------------- Reporter: gquintard | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by fgsch): This is specially an issue when you have both http and https traffic going to the same instance. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 29 16:25:07 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Jan 2016 16:25:07 -0000 Subject: [Varnish] #1849: Panic running s00002.vtc on travis Message-ID: <043.a5a9edefc26b146b1981774bd9837b70@varnish-cache.org> #1849: Panic running s00002.vtc on travis ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 31 11:12:03 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 31 Jan 2016 11:12:03 -0000 Subject: [Varnish] #1794: varnish*-tools do not die when terminal disconnects In-Reply-To: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> References: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> Message-ID: <056.fbe3a0a67d137932b12d1940a5dac4da@varnish-cache.org> #1794: varnish*-tools do not die when terminal disconnects --------------------+--------------------------------------------- Reporter: kwy | Owner: Federico G. Schwindt Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 4.0.3 Severity: normal | Resolution: Keywords: | --------------------+--------------------------------------------- Changes (by lkarsten): * status: closed => reopened * resolution: fixed => Comment: Reopening this. In 4.1.1 packaging we changed the startup options when running under systemd to not let varnishncsa fork by itself. This makes packaging easier since we don't have to bother with a writeable location for the pid file, and so on. With this change, logrotation hup-ing varnishncsa running "in foreground mode" leads to the daemon shutting down on SIGHUP. Short term fix is to roll back the systemd service file change and run new 4.1.1 packages, but I find the simplicity of not writing a pid file appealing. We should consider if a better indicator can be used than -D. -- Ticket URL: Varnish The Varnish HTTP Accelerator