From varnish-bugs at varnish-cache.org Fri May 2 09:20:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 May 2014 09:20:59 -0000 Subject: [Varnish] #1484: Extra provides in 4.0.0 RPM packages In-Reply-To: <046.737980f5728501ca8500dd42baa96c66@varnish-cache.org> References: <046.737980f5728501ca8500dd42baa96c66@varnish-cache.org> Message-ID: <061.535de914145196fa735fc789680183e1@varnish-cache.org> #1484: Extra provides in 4.0.0 RPM packages -----------------------+----------------------- Reporter: lkarsten | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | -----------------------+----------------------- Changes (by Lasse Karstensen ): * status: new => closed * resolution: => fixed Comment: In [292e70eb6f5bc91299419b63f25b8714ac119f60]: {{{ #!CommitTicketReference repository="" revision="292e70eb6f5bc91299419b63f25b8714ac119f60" RPM: find-provides should not call find-requires. Also remove the libvarnishapi "workaround" we put in place earlier. Found by: Ingvar Hagelund Fixes: #1484 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 2 11:17:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 May 2014 11:17:21 -0000 Subject: [Varnish] #1492: obj.hits is misleading after ban Message-ID: <046.41121bab9ff04df170ab46e76cf45c8d@varnish-cache.org> #1492: obj.hits is misleading after ban ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- In master and 4.0.0, the use of obj.hits is misleading after a ban. Expected result: obj.hits is reset after a ban removes an object. What happens: obj.hits is persisted as long as the ban is evaluated in the request context. Martin noted that if it is the ban lurker that cleans it out, and there are no other vary-ants, the oh is removed and the expected result happens. This was (to my knowledge) first reported by neurox on IRC. Test case that illustrates this is attached. Output from test case: {{{ **** c1 0.4 EXPECT resp.status (200) == "200" match *** c1 0.4 expect **** c1 0.4 EXPECT resp.body (foo) == "foo" match *** c1 0.4 expect ---- c1 0.4 EXPECT resp.http.hits (2) == "0" failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 5 07:02:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 May 2014 07:02:13 -0000 Subject: [Varnish] #1492: obj.hits is misleading after ban In-Reply-To: <046.41121bab9ff04df170ab46e76cf45c8d@varnish-cache.org> References: <046.41121bab9ff04df170ab46e76cf45c8d@varnish-cache.org> Message-ID: <061.3d3ef9eb347d19a6ad33f8e80d32fb27@varnish-cache.org> #1492: obj.hits is misleading after ban ----------------------+---------------------------------------- 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 ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [278d90fdc0008a55405550482ccf9bc4d74f18dc]: {{{ #!CommitTicketReference repository="" revision="278d90fdc0008a55405550482ccf9bc4d74f18dc" Update the documentation for obj.hits to reflect code reality. In 4.x we changed obj.hits to be read-only, and to count all variants under the same hash-key (= same objhdr). Since we cannot trivially tell if a ban hits all Vary: values or just some of them, there is no sane heuristic to fiddle obj.hits on bans that would Do The Right Thing. Fixes #1492 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 5 08:42:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 May 2014 08:42:27 -0000 Subject: [Varnish] #1490: Is not release destroyed thread In-Reply-To: <042.e0788bb7b0c6545200090cf88772c403@varnish-cache.org> References: <042.e0788bb7b0c6545200090cf88772c403@varnish-cache.org> Message-ID: <057.eb411db9bb25b257c5c08295d0efa276@varnish-cache.org> #1490: Is not release destroyed thread ----------------------+----------------------------------------------- Reporter: xcir | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [5c12ec5f2568b43fc1f4cc68d76e9c9889462595]: {{{ #!CommitTicketReference repository="" revision="5c12ec5f2568b43fc1f4cc68d76e9c9889462595" Remember to signal the thread to exit when decimating the flock The pool herder didn't signal the thread when decimating the flock, causing the thread to be leaked. Spotted by: xcir Fixes: #1490 Also close a couple of other races: When pthread_cond_timedwait returns ETIMEDOUT, the predicate (wrk->task.func == NULL) could still have changed while reacquiring the mutex. If so, the signal would've been lost and the thread leaked. Changed the idle wait loop in Pool_Work_Thread() to always check the predicate before resuming the cond_wait. The update of the predicate (wrk->task.func) from e.g. Pool_Task() is done without holding the mutex. This opens a race on the predicate, and the possibility of the worker going back on cond_wait loosing the signal. Changed to update the predicate while holding the mutex. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 5 09:03:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 May 2014 09:03:51 -0000 Subject: [Varnish] #1487: VCL flow outdated In-Reply-To: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> References: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> Message-ID: <058.cc04045f79b2490ede688e027f26a7ea@varnish-cache.org> #1487: VCL flow outdated ---------------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: low | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Comment (by phk): The real question is if it isn't time to decouple that diagram from the source file. It ended up there because at the time we had no credible way to include graphics in the .TXT based documentation, and I needed to keep track of it. Today we have multiple flowgraphs which extend outside that single source- file, so I'm somewhat tempted to rather spend the time to get the flow- graphs into the docs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 5 10:16:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 May 2014 10:16:03 -0000 Subject: [Varnish] #1487: VCL flow outdated In-Reply-To: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> References: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> Message-ID: <058.0060dec807227ebdf0601c93b382eb2e@varnish-cache.org> #1487: VCL flow outdated ---------------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: low | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Comment (by lkarsten): Consensus from bugwash today: * we should move these out of the source files and into the documentation. * other state engines needs to be documented as well. This is a low-effort and low-complexity task, open for volunteers to take this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 5 10:19:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 May 2014 10:19:42 -0000 Subject: [Varnish] #1491: Test case e00017.vtc is brittle. In-Reply-To: <046.e964a6a9d17977fc0d422bf127eb6f2c@varnish-cache.org> References: <046.e964a6a9d17977fc0d422bf127eb6f2c@varnish-cache.org> Message-ID: <061.aa8d46cf87a3fca6d7bbc4c0060e50a8@varnish-cache.org> #1491: Test case e00017.vtc is brittle. -------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by lkarsten): Discussed on bugwash today. Martin has a theory, and will try to reorder the backend release code as a test and see if this improves the test case robustness. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 5 15:49:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 May 2014 15:49:08 -0000 Subject: [Varnish] #1493: fetch and synth are the same in vcl_purge Message-ID: <042.04391b2ffa97cfddefa1e0394a6b47e5@varnish-cache.org> #1493: fetch and synth are the same in vcl_purge -------------------+---------------------- Reporter: xcir | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | -------------------+---------------------- Hi, In vcl_purge can set return(fetch). But, req->req_step set to fixed value R_STP_SYNTH at cnt_purge. It seems like fetch isn't enabled. in lib/libvcc/generate.py {{{ ('purge', "C", ('synth', 'fetch',) ), }}} in cnt_purge(bin/varnishd/cache/cache_req_fsm.c) {{{ VCL_purge_method(req->vcl, wrk, req, NULL, req->http->ws); req->req_step = R_STP_SYNTH; return (REQ_FSM_MORE); }}} return(fetch) //Is not fetch to backend. {{{ * << Request >> 2 - Begin req 1 rxreq - Timestamp Start: 1399304734.267941 0.000000 0.000000 - Timestamp Req: 1399304734.267941 0.000000 0.000000 - ReqStart 192.168.1.199 43521 - ReqMethod GET - ReqURL /rand.php - ReqProtocol HTTP/1.0 - ReqHeader User-Agent: Wget/1.12 (linux-gnu) - ReqHeader Accept: */* - ReqHeader Host: 192.168.1.45 - ReqHeader Connection: Keep-Alive - ReqHeader purge: 1 - ReqHeader fetch: 1 - ReqHeader X-Forwarded-For: 192.168.1.199 - VCL_call RECV - VCL_return purge - VCL_call HASH - VCL_return lookup - VCL_call PURGE - VCL_return fetch - Timestamp Process: 1399304734.268233 0.000292 0.000292 - RespProtocol HTTP/1.1 - RespStatus 501 - RespHeader Date: Mon, 05 May 2014 15:45:34 GMT - RespHeader Server: Varnish - RespHeader X-Varnish: 2 - RespResponse Not Implemented - VCL_call SYNTH - RespHeader Content-Type: text/html; charset=utf-8 - RespHeader Retry-After: 5 - VCL_return deliver - RespHeader Content-Length: 398 - Debug "RES_MODE 2" - RespHeader Connection: keep-alive - Timestamp Resp: 1399304734.268498 0.000558 0.000266 - ReqAcct 138 0 138 201 398 599 - End }}} return(synth(200, "Purged")) {{{ * << Request >> 32770 - Begin req 32769 rxreq - Timestamp Start: 1399304835.110713 0.000000 0.000000 - Timestamp Req: 1399304835.110713 0.000000 0.000000 - ReqStart 192.168.1.199 43522 - ReqMethod GET - ReqURL /rand.php - ReqProtocol HTTP/1.0 - ReqHeader User-Agent: Wget/1.12 (linux-gnu) - ReqHeader Accept: */* - ReqHeader Host: 192.168.1.45 - ReqHeader Connection: Keep-Alive - ReqHeader purge: 1 - ReqHeader X-Forwarded-For: 192.168.1.199 - VCL_call RECV - VCL_return purge - VCL_call HASH - VCL_return lookup - VCL_call PURGE - Debug "VCL_error(200, Purged)" - VCL_return synth - Timestamp Process: 1399304835.110802 0.000089 0.000089 - RespProtocol HTTP/1.1 - RespStatus 200 - RespHeader Date: Mon, 05 May 2014 15:47:15 GMT - RespHeader Server: Varnish - RespHeader X-Varnish: 32770 - RespResponse Purged - VCL_call SYNTH - RespHeader Content-Type: text/html; charset=utf-8 - RespHeader Retry-After: 5 - VCL_return deliver - RespHeader Content-Length: 375 - Debug "RES_MODE 2" - RespHeader Connection: keep-alive - RespHeader Accept-Ranges: bytes - Timestamp Resp: 1399304835.110910 0.000197 0.000108 - ReqAcct 128 0 128 218 375 593 - End }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 02:12:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 02:12:49 -0000 Subject: [Varnish] #1492: obj.hits is misleading after ban In-Reply-To: <046.41121bab9ff04df170ab46e76cf45c8d@varnish-cache.org> References: <046.41121bab9ff04df170ab46e76cf45c8d@varnish-cache.org> Message-ID: <061.174e061ec414d585f73f99dd44467691@varnish-cache.org> #1492: obj.hits is misleading after ban ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by fgsch): This is also true when updating a grace'd object. Can we at least reset hits if refcnt in objhead is 1? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 08:46:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 08:46:03 -0000 Subject: [Varnish] #1491: Test case e00017.vtc is brittle. In-Reply-To: <046.e964a6a9d17977fc0d422bf127eb6f2c@varnish-cache.org> References: <046.e964a6a9d17977fc0d422bf127eb6f2c@varnish-cache.org> Message-ID: <061.00af7df8e3fdd319ba9d8b08e69649ce@varnish-cache.org> #1491: Test case e00017.vtc is brittle. -------------------------+----------------------------------------------- Reporter: lkarsten | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [2baa8754fe4a0fc3e4efc9865bddc265fae13690]: {{{ #!CommitTicketReference repository="" revision="2baa8754fe4a0fc3e4efc9865bddc265fae13690" Recycle backend connection before setting BOS_FINISHED (take two) This to give predictable backend reuse behavior for varnishtest, making the test cases non-racy. 2nd version of this patch. This version will only deal with recyclable backend connections before BOS_FINISHED, leaving the slower close path to the clean up code that is run after the BOS_FINISHED state. Fixes: #1491 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 09:16:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 09:16:12 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.9b525f856b6fdf899b2b072dd2c31fa5@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+------------------------ Reporter: basile@? | Owner: scoof Type: defect | Status: Need info Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Comment (by slink): See https://www.varnish-cache.org/lists/pipermail/varnish- dev/2014-May/007823.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 09:17:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 09:17:21 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.2ebe9659750fd9dc88f12394765f9236@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+------------------------ Reporter: basile@? | Owner: scoof Type: defect | Status: Need info Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Comment (by slink): Note on the patch attached here: The fix to the Makefile is correct but insufficient. The real issue here is the include from rst files. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 13:51:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 13:51:03 -0000 Subject: [Varnish] #1494: panic on retry in vcl_backend_response Message-ID: <049.aed8fbca60dcb5815d19e9ac04e56fef@varnish-cache.org> #1494: panic on retry in vcl_backend_response -------------------------+-------------------- Reporter: g.gerritsen | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: | -------------------------+-------------------- {{{#!python vcl_backend_response { if(beresp.status == 500) { return(retry); } } }}} gives the following panic on centos 6.5 when encountering a 503 status {{{#!python Child (30201) died signal=6 (core dumped) Child (30201) Panic message: Assert error in vbf_stp_startfetch(), cache/cache_fetch.c line 258: Condition((bo->should_close) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-431.11.2.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43a536: /usr/sbin/varnishd() [0x43a536] 0x43a846: /usr/sbin/varnishd() [0x43a846] 0x422e26: /usr/sbin/varnishd() [0x422e26] 0x425273: /usr/sbin/varnishd() [0x425273] 0x43c343: /usr/sbin/varnishd(Pool_Work_Thread+0x416) [0x43c343] 0x454ce2: /usr/sbin/varnishd() [0x454ce2] 0x454e0b: /usr/sbin/varnishd(WRK_thread+0x27) [0x454e0b] 0x3f25c079d1: /lib64/libpthread.so.0() [0x3f25c079d1] 0x3f258e8b6d: /lib64/libc.so.6(clone+0x6d) [0x3f258e8b6d] busyobj = 0x7f7fd00b7020 { ws = 0x7f7fd00b70e8 { id = "bo", {s,f,r,e} = {0x7f7fd00b8ff0,+552,(nil),+57392}, }, refcnt = 2 retries = 1 failed = 0 state = 1 is_do_stream is_should_close bodystatus = 3 (length), }, http[bereq] = { ws = 0x7f7fd00b70e8[bo] "GET", "/503.php", "HTTP/1.1", "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-US,en;q=0.5", "X-Forwarded-For: 127.0.0.1, 127.0.0.1", "Host: monitor.nl.local", "Accept-Encoding: gzip", "X-Varnish: 3", }, http[beresp] = { ws = 0x7f7fd00b70e8[bo] "HTTP/1.1", "503", "Internal Server Error", "Date: Tue, 06 May 2014 13:45:30 GMT", "Server: Apache/2.2.15 (CentOS)", "X-Powered-By: PHP/5.4.26", "Content-Length: 0", "Connection: close", "Content-Type: text/html; charset=UTF-8", }, ws = 0x7f7fd00b7270 { BAD_MAGIC(0x00000000) }, }, objcore (FETCH) = 0x7f7fcb028080 { refcnt = 2 flags = 0x2 objhead = 0x7f7fcb02a080 } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 20:57:39 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 20:57:39 -0000 Subject: [Varnish] #1495: WRK_SumStat lock contention with high number of thread pools Message-ID: <046.4488ac6b747ee86e9e256ea0d96628aa@varnish-cache.org> #1495: WRK_SumStat lock contention with high number of thread pools ----------------------+-------------------- Reporter: dormando | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ----------------------+-------------------- May also be increasing just as active threads increase. Increasing thread_stats_rate did improve speed but not as much as I expected. More context: https://gist.github.com/dormando/05689cdc5709881b382a Can run tests or provide more details if needed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 21:04:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 21:04:42 -0000 Subject: [Varnish] #1496: vsl_mask is annoying to use from varnishadm commandline Message-ID: <046.c76e21fce937e4088417d9b25e37904e@varnish-cache.org> #1496: vsl_mask is annoying to use from varnishadm commandline ----------------------+------------------------ Reporter: dormando | Type: defect Status: new | Priority: normal Milestone: | Component: varnishadm Version: unknown | Severity: normal Keywords: | ----------------------+------------------------ varnishadm -T :6082 param.set vsl_mask "-Voo,-Var" will say something like "Unknown command -V" Backslashing it doesn't help either: $ varnishadm -T :6082 param.set vsl_mask "\-VCL_trace,\-WorkThread,\-Hash,\-ReqHeader" Unknown request. Type 'help' for more info. Syntax Error: Invalid backslash sequence I'm sure there's some way to do it, but it's not obvious and typical. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 21:05:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 21:05:13 -0000 Subject: [Varnish] #1495: WRK_SumStat lock contention with high number of thread pools In-Reply-To: <046.4488ac6b747ee86e9e256ea0d96628aa@varnish-cache.org> References: <046.4488ac6b747ee86e9e256ea0d96628aa@varnish-cache.org> Message-ID: <061.f78fb267acb3d872a38359ff7fae28eb@varnish-cache.org> #1495: WRK_SumStat lock contention with high number of thread pools ----------------------+---------------------- Reporter: dormando | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------- Changes (by dormando): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 21:27:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 21:27:50 -0000 Subject: [Varnish] #1497: Varnish 3.0.5 does not handle 204 No Content response from backend Message-ID: <043.3fbe073afee8426fa0dd41adb6e7f251@varnish-cache.org> #1497: Varnish 3.0.5 does not handle 204 No Content response from backend -----------------------------+-------------------- Reporter: oskar | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: 3.0.5 | Severity: normal Keywords: | -----------------------------+-------------------- I have a service that returns a 204 No Content response with response headers, newline, but no response body. Basically the response looks like this: {{{ Escape character is '^]'. OPTIONS HTTP/1.1 Connection: close HTTP/1.1 204 No Content X-Powered-By: Express Access-Control-Allow-Methods: GET,HEAD,PUT,POST,DELETE Date: Tue, 06 May 2014 21:20:46 GMT Connection: close Connection closed by foreign host. }}} But Varnish instead returns 503 Service Unavailable. This is what is logged: {{{ 3 SessionOpen c 127.0.0.1 38740 :6081 3 ReqStart c 127.0.0.1 38740 1170395206 3 RxRequest c OPTIONS 3 RxURL c 3 RxProtocol c 3 RxHeader c User-Agent: Wget/1.15 (linux-gnu) 3 RxHeader c Accept: */* 3 RxHeader c Host: ... 3 RxHeader c Connection: close 3 VCL_call c recv pass 3 VCL_call c hash 3 Hash c 3 Hash c account.psplugin.com 3 VCL_return c hash 3 VCL_call c pass pass 3 Backend c 25 nodejs_director nodejs_app1 3 FetchError c http first read error: -1 0 (Success) 3 VCL_call c error deliver 3 VCL_call c deliver deliver 3 TxProtocol c HTTP/1.1 3 TxStatus c 503 3 TxResponse c Service Unavailable 3 TxHeader c Server: Varnish 3 TxHeader c Content-Type: text/html; charset=utf-8 3 TxHeader c Retry-After: 5 3 TxHeader c Content-Length: 419 3 TxHeader c Accept-Ranges: bytes 3 TxHeader c Date: Tue, 06 May 2014 20:52:46 GMT 3 TxHeader c Age: 0 3 TxHeader c Connection: close 3 TxHeader c X-Cache: MISS 3 Length c 419 3 ReqEnd c 1170395206 1399409566.629074335 1399409566.630136251 0.000033617 0.001033306 0.000028610 }}} Regards, Oskar Liljeblad -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 6 21:36:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 May 2014 21:36:21 -0000 Subject: [Varnish] #1497: Varnish 3.0.5 does not handle 204 No Content response from backend In-Reply-To: <043.3fbe073afee8426fa0dd41adb6e7f251@varnish-cache.org> References: <043.3fbe073afee8426fa0dd41adb6e7f251@varnish-cache.org> Message-ID: <058.07be4c747b90ef9c386823cb9df872dc@varnish-cache.org> #1497: Varnish 3.0.5 does not handle 204 No Content response from backend --------------------+------------------------------ Reporter: oskar | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: 3.0.5 Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by oskar): I shall retract this bug report! It appears the problem is in HAProxy, not Varnish... Sorry! Oskar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 7 07:38:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 May 2014 07:38:42 -0000 Subject: [Varnish] #1497: Varnish 3.0.5 does not handle 204 No Content response from backend In-Reply-To: <043.3fbe073afee8426fa0dd41adb6e7f251@varnish-cache.org> References: <043.3fbe073afee8426fa0dd41adb6e7f251@varnish-cache.org> Message-ID: <058.c04d54ce7ce2174f8bf115d56afee51f@varnish-cache.org> #1497: Varnish 3.0.5 does not handle 204 No Content response from backend --------------------+------------------------------ Reporter: oskar | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: 3.0.5 Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------ Changes (by scoof): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 7 09:35:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 May 2014 09:35:43 -0000 Subject: [Varnish] #1498: Naming a director static makes the vcl compiler fail. Message-ID: <053.80f10a32e5cf0887bf5199326ef5247b@varnish-cache.org> #1498: Naming a director static makes the vcl compiler fail. ---------------------------------------------+---------------------- Reporter: comebackoneyear | Type: defect Status: new | Priority: low Milestone: | Component: varnishd Version: 4.0.0 | Severity: minor Keywords: static director vcl compilation | ---------------------------------------------+---------------------- Naming your backend static gives unhelpful error. {{{ vcl 4.0; import directors; backend s1 { .host = "127.0.0.1"; .port = "80"; } sub vcl_init { new static = directors.random(); static.add_backend(s1, 100.0); } }}} Results in {{{ ./vcl.fdbOLDiQ.c:589:38: error: expected identifier or '(' static struct vmod_directors_random *static; ^ ./vcl.fdbOLDiQ.c:1021:46: error: expected expression Vmod_directors_Func.random__init(ctx, &static, "static"); ^ ./vcl.fdbOLDiQ.c:1022:51: error: expected expression Vmod_directors_Func.random_add_backend(ctx, static, ^ [4 lines truncated] Running C-compiler failed, exit 1 VCL compilation failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 8 15:38:09 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 May 2014 15:38:09 -0000 Subject: [Varnish] #1499: Varnish 4 object leak on IMS update Message-ID: <044.5c5d1d394b8874fecdf1b3c04ec61527@varnish-cache.org> #1499: Varnish 4 object leak on IMS update ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Keywords: ----------------------+------------------- Varnish 4 leaks an objcore ref on the old object when HSH_Lookup returns an expired (not in grace) object. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 8 15:48:20 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 May 2014 15:48:20 -0000 Subject: [Varnish] #1499: Varnish 4 object leak on IMS update In-Reply-To: <044.5c5d1d394b8874fecdf1b3c04ec61527@varnish-cache.org> References: <044.5c5d1d394b8874fecdf1b3c04ec61527@varnish-cache.org> Message-ID: <059.bd1421940f989771eb1a2dd74cf91053@varnish-cache.org> #1499: Varnish 4 object leak on IMS update ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): Test case and patch attached -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat May 10 16:40:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 10 May 2014 16:40:25 -0000 Subject: [Varnish] #1500: Possible bug in 4.0.0 with Range+do_stream=true Message-ID: <049.e06f300085772a9d4aec9d7530952cf7@varnish-cache.org> #1500: Possible bug in 4.0.0 with Range+do_stream=true -------------------------+-------------------- Reporter: moseleymark | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: | -------------------------+-------------------- I noticed in testing Range requests (to an Apache 2.2 backend, Ubuntu Precise 64-bit) that in sufficiently large requests, Range requests on *uncached* content were often returning 200s with the full content. The larger the request, the more likely it was that this would happen. See https://www.varnish-cache.org/comment/1654#comment-1654 for details on some testing I did. In the VCL below, if I uncomment the do_stream=false, I seem to get 206s on uncached large files every time. I need to test this further, but so far, with it commented out (since I guess do_stream is true by default now), on a 10meg file, I was getting 200s on uncached content almost 100% of the time; with it uncommented, I haven't seen a 200 yet. Dropping in some debugging statements, it looks like that for streaming large-ish files, this 'if' statement in v1d_dorange (bin/varnishd/cache/cache_http1_deliver.c, about line 105 or so) fails: if (low >= req->obj->len) return; because req->obj->len is 0. I'm guessing that with a big enough file, streaming causes v1d_dorange to get called before len gets set to non- zero, since it's still downloading the file from the backend (which considering how streaming works, kind of makes sense). Without streaming (this is my debug statement, via varnishlog): - Debug "IN v1d_dorange 3: low=1, len=10240000" With streaming: - Debug "IN v1d_dorange 3: low=1, len=0" I'm still trying to trace why req->obj->len would be 0 in this case. I'm not a C guy, so I couldn't even begin to offer a patch that wouldn't make your eyes bleed :) Testcase is just using a very stripped down VCL: {{{ vcl 4.0; import std; backend test_http { .host = "127.0.0.1"; .port = "80"; } sub vcl_backend_response { # Commented, I get 200s; uncommented, I get 206s # set beresp.do_stream = false; return( deliver ); } sub vcl_recv { # Set backend dynamically set req.backend_hint = test_http; # Default action is to look up object in cache return( hash ); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 07:15:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 07:15:48 -0000 Subject: [Varnish] #1500: Possible bug in 4.0.0 with Range+do_stream=true In-Reply-To: <049.e06f300085772a9d4aec9d7530952cf7@varnish-cache.org> References: <049.e06f300085772a9d4aec9d7530952cf7@varnish-cache.org> Message-ID: <064.8fa4a0bb496bcfc8499a78dfaea7a44f@varnish-cache.org> #1500: Possible bug in 4.0.0 with Range+do_stream=true -------------------------+-------------------- Reporter: moseleymark | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by phk): I was sort of vaguely aware of this, and left the code as is for lack of any better ideas. The basic problem is that a ranged response must commit to how many bytes it will send in the Content-Range response header. You report is on the low end of the range, but it's even more icky for an object with an unbounded upper end. Say you ask for the range "200-". At the time we process the Range header, we have received 5k of the 1M object, so even if the low end clears fine, the high end truncates to 5k, returning you a response you can most likely not use. The only solid & correct way to work around this issue, would be to postpone the response until we have seen enough of the object from the backend to know how we can satisfy both ends of the range request, but that seems counter productive from a response-time point of view, as we'd have to wait for the full 1M object before starting to respond from byte 200 onwards. A more heuristic handling would reply optimistically to the range request, setting Content-Range based on the range request, and fail the client connection if that optimism was unfounded. That of course only works for range requests with a finite end. So all in all, I don't see any solutions significantly better than the present one. One possible workaround, would be a VMOD.std function you could call in vcl_response{} which looks for a range request and waits for the streaming from the backend until that range request can be properly processed. More when we have talked about this ticket at todays bugwash. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 07:55:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 07:55:11 -0000 Subject: [Varnish] #1498: Naming a director static makes the vcl compiler fail. In-Reply-To: <053.80f10a32e5cf0887bf5199326ef5247b@varnish-cache.org> References: <053.80f10a32e5cf0887bf5199326ef5247b@varnish-cache.org> Message-ID: <068.8f6f7bf23279b01f9da25d236229da5c@varnish-cache.org> #1498: Naming a director static makes the vcl compiler fail. -------------------------------------+------------------------------------- Reporter: comebackoneyear | Owner: Poul-Henning Kamp Type: defect | Priority: low | Status: closed Component: varnishd | Milestone: Severity: minor | Version: 4.0.0 Keywords: static director vcl | Resolution: fixed compilation | -------------------------------------+------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [6b27b8c35c090df1dd61eead77184ac98e402f1f]: {{{ #!CommitTicketReference repository="" revision="6b27b8c35c090df1dd61eead77184ac98e402f1f" Prefix the C-symbol of VCL objects with "vo_" to avoid issues with reserved C keywords. Fixes #1498 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 08:56:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 08:56:46 -0000 Subject: [Varnish] #1499: Varnish 4 object leak on IMS update In-Reply-To: <044.5c5d1d394b8874fecdf1b3c04ec61527@varnish-cache.org> References: <044.5c5d1d394b8874fecdf1b3c04ec61527@varnish-cache.org> Message-ID: <059.e4a5c1dd32dc32fb0a033dfd22df8172@varnish-cache.org> #1499: Varnish 4 object leak on IMS update ----------------------+----------------------------------------------- Reporter: martin | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [36c5d3a7daee2a4088f9408ad92e3eb9c4468463]: {{{ #!CommitTicketReference repository="" revision="36c5d3a7daee2a4088f9408ad92e3eb9c4468463" Deref the old object after finishing with it in cnt_miss() Fixes: #1499 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 08:57:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 08:57:16 -0000 Subject: [Varnish] #1493: fetch and synth are the same in vcl_purge In-Reply-To: <042.04391b2ffa97cfddefa1e0394a6b47e5@varnish-cache.org> References: <042.04391b2ffa97cfddefa1e0394a6b47e5@varnish-cache.org> Message-ID: <057.0a2e8fc68252c8a021fdc0d7825cb082@varnish-cache.org> #1493: fetch and synth are the same in vcl_purge ----------------------+---------------------------------------- Reporter: xcir | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [1dc303aac59deb4ec1ed0e9b491f4016aba2bcfb]: {{{ #!CommitTicketReference repository="" revision="1dc303aac59deb4ec1ed0e9b491f4016aba2bcfb" The vcl_purge{} method can return synth or restart. (Remember to change the "PURGE" to "GET" if you do this.) Fixes #1493 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 11:37:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 11:37:56 -0000 Subject: [Varnish] #1476: Build failures on Debian GNU/kFreeBSD In-Reply-To: <041.70dfa72ba3eef70143ec6b80ce0ffc03@varnish-cache.org> References: <041.70dfa72ba3eef70143ec6b80ce0ffc03@varnish-cache.org> Message-ID: <056.a1d4d6f4a35990b5d3b9dad2b016b16e@varnish-cache.org> #1476: Build failures on Debian GNU/kFreeBSD --------------------+--------------------- Reporter: ssm | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This should be fixed in 2fbac3f212d858a55fe3ad11848fb2bfbee65671 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 11:51:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 11:51:12 -0000 Subject: [Varnish] #1496: vsl_mask is annoying to use from varnishadm commandline In-Reply-To: <046.c76e21fce937e4088417d9b25e37904e@varnish-cache.org> References: <046.c76e21fce937e4088417d9b25e37904e@varnish-cache.org> Message-ID: <061.fff7e763cec14501de9f87ca1eb59327@varnish-cache.org> #1496: vsl_mask is annoying to use from varnishadm commandline ------------------------+---------------------- Reporter: dormando | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: unknown Severity: normal | Resolution: Keywords: | ------------------------+---------------------- Comment (by martin): Problem stems from the -Tag argument to param.set being interpreted as a command line argument by getopt(). This can be worked around by using '--' to end argument parsing before the 'param.set'. E.g.: {{{ $ varnishadm -T :6082 -- param.set vsl_mask -WorkThread }}} During the discussion in bugwash today it was decided to change varnishadm so that no options after the first non-argument is considered. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 12:07:09 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 12:07:09 -0000 Subject: [Varnish] #1496: vsl_mask is annoying to use from varnishadm commandline In-Reply-To: <046.c76e21fce937e4088417d9b25e37904e@varnish-cache.org> References: <046.c76e21fce937e4088417d9b25e37904e@varnish-cache.org> Message-ID: <061.6d3555e98db1b75ec8df38cd32441848@varnish-cache.org> #1496: vsl_mask is annoying to use from varnishadm commandline ------------------------+---------------------------------------- Reporter: dormando | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishadm | Version: unknown Severity: normal | Resolution: fixed Keywords: | ------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [1af9e045df49393eba0951c67b65c924ab128f8f]: {{{ #!CommitTicketReference repository="" revision="1af9e045df49393eba0951c67b65c924ab128f8f" By default linux::getopt(3) mangles the argv order, such that varnishadm -n bla param.set foo -bar gets interpreted as varnishadm -n bla -bar param.set foo This is counterintuitive and invites random script breaking if people don't know they have to add an ornamental '--' in front of the CLI command in Linux systems. This commit makes Linux work the same way as every other POSIX system. Fixes #1496 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 12:23:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 12:23:38 -0000 Subject: [Varnish] #1494: panic on retry in vcl_backend_response In-Reply-To: <049.aed8fbca60dcb5815d19e9ac04e56fef@varnish-cache.org> References: <049.aed8fbca60dcb5815d19e9ac04e56fef@varnish-cache.org> Message-ID: <064.6b1f2d3e9950b1ad485cf4d0a9acf9f2@varnish-cache.org> #1494: panic on retry in vcl_backend_response -------------------------+------------------------ Reporter: g.gerritsen | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+------------------------ Changes (by phk): * status: new => Need info Comment: We have not been able to reproduce this, can you give us a more concrete example og how to do it ? Also, varnishlog output would be helpfull -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 14:35:00 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 14:35:00 -0000 Subject: [Varnish] #1494: panic on retry in vcl_backend_response In-Reply-To: <049.aed8fbca60dcb5815d19e9ac04e56fef@varnish-cache.org> References: <049.aed8fbca60dcb5815d19e9ac04e56fef@varnish-cache.org> Message-ID: <064.b0b64c3c690ed1ea22b0ac42b9b94fce@varnish-cache.org> #1494: panic on retry in vcl_backend_response -------------------------+------------------------ Reporter: g.gerritsen | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+------------------------ Comment (by g.gerritsen): On receiving the request http://monitor.nl.local/500.php (simple php script returning status 500) using the 1494.vcl, varnishlog tells me {{{#!python * << BeReq >> 3 - Begin bereq 2 fetch - Timestamp Start: 1399905220.620958 0.000000 0.000000 - BereqMethod GET - BereqURL /500.php - BereqProtocol HTTP/1.1 - BereqHeader Host: monitor.nl.local - BereqHeader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 - BereqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 - BereqHeader Accept-Language: en-US,en;q=0.5 - BereqHeader X-Forwarded-For: 172.16.10.136 - BereqHeader Accept-Encoding: gzip - BereqHeader X-Varnish: 3 - VCL_call BACKEND_FETCH - VCL_return fetch - BackendOpen 17 default(172.16.10.224,,80) 10.16.19.81 25819 - Backend 17 default default(172.16.10.224,,80) - Timestamp Bereq: 1399905220.631030 0.010072 0.010072 - Timestamp Beresp: 1399905220.643308 0.022349 0.012277 - BerespProtocol HTTP/1.1 - BerespStatus 500 - BerespResponse Internal Server Error - BerespHeader Date: Mon, 12 May 2014 14:33:40 GMT - BerespHeader Server: Apache/2.2.15 (CentOS) - BerespHeader X-Powered-By: PHP/5.4.27 - BerespHeader Content-Length: 0 - BerespHeader Connection: close - BerespHeader Content-Type: text/html; charset=UTF-8 - TTL RFC -1 -1 -1 1399905221 1399905221 1399905220 0 0 - VCL_call BACKEND_RESPONSE - VCL_Log retrying - VCL_return retry - BackendClose 17 default(172.16.10.224,,80) - Timestamp Retry: 1399905220.643467 0.022509 0.000159 - Link bereq 32769 retry - End * << Session >> 1 - Begin sess 0 HTTP/1 - SessOpen 172.16.10.136 52579 :80 10.16.19.81 80 1399905220.620053 12 - Link req 2 rxreq - VSL flush - End synth * << BeReq >> 32769 - Begin bereq 3 retry - Timestamp Start: 1399905220.643467 0.022509 0.000000 - VSL flush - End synth Log abandoned Log reaquired }}} panic.show {{{#!python # varnishadm panic.show Last panic at: Mon, 12 May 2014 14:33:41 GMT Assert error in vbf_stp_startfetch(), cache/cache_fetch.c line 258: Condition((bo->should_close) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-431.11.2.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43a536: /usr/sbin/varnishd() [0x43a536] 0x43a846: /usr/sbin/varnishd() [0x43a846] 0x422e26: /usr/sbin/varnishd() [0x422e26] 0x425273: /usr/sbin/varnishd() [0x425273] 0x43c343: /usr/sbin/varnishd(Pool_Work_Thread+0x416) [0x43c343] 0x454ce2: /usr/sbin/varnishd() [0x454ce2] 0x454e0b: /usr/sbin/varnishd(WRK_thread+0x27) [0x454e0b] 0x7f0866ef19d1: /lib64/libpthread.so.0(+0x79d1) [0x7f0866ef19d1] 0x7f0866c3eb6d: /lib64/libc.so.6(clone+0x6d) [0x7f0866c3eb6d] busyobj = 0x7f0855828020 { ws = 0x7f08558280e8 { id = "bo", {s,f,r,e} = {0x7f0855829ff0,+544,(nil),+57392}, }, refcnt = 2 retries = 1 failed = 0 state = 1 is_do_stream is_should_close bodystatus = 3 (length), }, http[bereq] = { ws = 0x7f08558280e8[bo] "GET", "/500.php", "HTTP/1.1", "Host: monitor.nl.local", "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-US,en;q=0.5", "X-Forwarded-For: 172.16.10.136", "Accept-Encoding: gzip", "X-Varnish: 3", }, http[beresp] = { ws = 0x7f08558280e8[bo] "HTTP/1.1", "500", "Internal Server Error", "Date: Mon, 12 May 2014 14:33:40 GMT", "Server: Apache/2.2.15 (CentOS)", "X-Powered-By: PHP/5.4.27", "Content-Length: 0", "Connection: close", "Content-Type: text/html; charset=UTF-8", }, ws = 0x7f0855828270 { BAD_MAGIC(0x00000000) }, }, objcore (FETCH) = 0x7f0855866080 { refcnt = 2 flags = 0x2 objhead = 0x7f0855868080 } } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 16:01:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 16:01:34 -0000 Subject: [Varnish] #1494: panic on retry in vcl_backend_response In-Reply-To: <049.aed8fbca60dcb5815d19e9ac04e56fef@varnish-cache.org> References: <049.aed8fbca60dcb5815d19e9ac04e56fef@varnish-cache.org> Message-ID: <064.dd7e04947e361e140e2c0a6ba53f63ea@varnish-cache.org> #1494: panic on retry in vcl_backend_response -------------------------+---------------------------------------- Reporter: g.gerritsen | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | -------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: Need info => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [32d0751bc19f3725e291e46b95ff33e1882a291e]: {{{ #!CommitTicketReference repository="" revision="32d0751bc19f3725e291e46b95ff33e1882a291e" Reset the "must close" flag when we close the backend connection before a retry. Fixes #1494 Testcase by: scoof }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 17:39:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 17:39:55 -0000 Subject: [Varnish] #1501: crash on hash director with all backends down Message-ID: <049.87496517998d0b43520b4c078348d4cd@varnish-cache.org> #1501: crash on hash director with all backends down -------------------------+---------------------- Reporter: g.gerritsen | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | -------------------------+---------------------- varnish crashes when handling any requests using a hash director with all backends sick. I have included the vcl to reproduce the problem. {{{ # varnishadm panic.show Last panic at: Mon, 12 May 2014 17:36:17 GMT Assert error in vbf_stp_mkbereq(), cache/cache_fetch.c line 184: Condition((bo->director) != 0) not true. thread = (cache-worker) ident = Linux,2.6.32-431.11.2.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43a796: pan_backtrace+0x19 0x43aaa6: pan_ic+0x1e8 0x42281b: vbf_stp_mkbereq+0x1dd 0x42549c: vbf_fetch_thread+0x39c 0x43c581: Pool_Work_Thread+0x3e6 0x455081: wrk_thread_real+0x143 0x4551aa: WRK_thread+0x27 0x7feb0962e9d1: /lib64/libpthread.so.0(+0x79d1) [0x7feb0962e9d1] 0x7feb0937bb6d: /lib64/libc.so.6(clone+0x6d) [0x7feb0937bb6d] busyobj = 0x7feaf7406020 { ws = 0x7feaf74060e0 { id = "bo", {s,f,r,e} = {0x7feaf7407fe8,0x7feaf7407fe8,(nil),+57400}, }, refcnt = 2 retries = 0 failed = 0 state = 0 is_do_stream bodystatus = 0 (none), }, ws = 0x7feaf7406268 { BAD_MAGIC(0x00000000) }, }, objcore (FETCH) = 0x7feb08bfe080 { refcnt = 2 flags = 0x2 objhead = 0x7feaf7441080 } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 12 21:42:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 May 2014 21:42:01 -0000 Subject: [Varnish] #1500: Possible bug in 4.0.0 with Range+do_stream=true In-Reply-To: <049.e06f300085772a9d4aec9d7530952cf7@varnish-cache.org> References: <049.e06f300085772a9d4aec9d7530952cf7@varnish-cache.org> Message-ID: <064.6f14c64580d73a7254449728c7524b3f@varnish-cache.org> #1500: Possible bug in 4.0.0 with Range+do_stream=true -------------------------+-------------------- Reporter: moseleymark | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by moseleymark): Yup, I could see how the combo of Streaming + Ranges could be a seriously tangled issue. Though I was initially thrown by streaming being on by default. I've not seen anything in the docs that indicate that that was the case. Workaround-wise, I think the easy solution is just to set do_stream=false if the Range header is set. I've been playing around with that, but I've run into one thing that's come up a few times as I port my varnish 3 vcl to 4: the narrower scope in 4.0 of where you can use the req/bereq/resp/beresp vars makes it hard to communicate between the different vcl_* subroutines. I've typically used headers to communicate between the subs. For example, to do this workaround, I can set (in vcl_recv) a new header on 'req'. But I can't seem to set 'do_stream' until vcl_backend_response, so I can't remove the header before it gets sent to the backend. Do you have any recommendations on how to better communicate between the various vcl_* subroutines? I've been trying to avoid (for easy of packaging-sake) adding new compiled vmod modules. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 13 06:35:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 May 2014 06:35:41 -0000 Subject: [Varnish] #1502: if ( req.backend_hint == name-of-director ) { } not possible Message-ID: <041.3ed6122c1afdec9eeade64e100badd4b@varnish-cache.org> #1502: if ( req.backend_hint == name-of-director ) { } not possible --------------------------------+-------------------- Reporter: Tin | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: vmod_directors if | --------------------------------+-------------------- In 3.0 it was possible to do something like {{{ if ( req.backend == mydirector || req.backend == myotherdirector ) { # do something very specific for these directors } }}} Which is nice if you have over 100 directors and 1000's of director related URL's. In 4.0 this does not seem possible anymore as {{{ vcl 4.0; backend one { .host="127.0.0.1"; } backend two { .host="127.0.0.1"; } import directors; sub vcl_init { new apenootjes = directors.hash(); apenootjes.add_backend(one,1); apenootjes.add_backend(two,1); } sub vcl_recv { set req.backend_hint=apenootjes.backend(client.identity); if ( req.backend_hint == apenootjes.backend(client.identity) ) { return(lookup); } else { return(pass); } } }}} Will not even compile. Alternatives have been tried but won't compile either. A workaround is to define a specific X-header when addressing a director, but that is not really nice. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 13 06:56:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 May 2014 06:56:22 -0000 Subject: [Varnish] #1139: default_keep makes objects stay around too long In-Reply-To: <044.8c1a9c748ce289914d1adcd0203efe6a@varnish-cache.org> References: <044.8c1a9c748ce289914d1adcd0203efe6a@varnish-cache.org> Message-ID: <059.01f266f97d8d197062f440084996626f@varnish-cache.org> #1139: default_keep makes objects stay around too long ----------------------+--------------------- Reporter: martin | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [578366ecf3fbc1159ea5ed8543f3e81412bbe43d]: {{{ #!CommitTicketReference repository="" revision="578366ecf3fbc1159ea5ed8543f3e81412bbe43d" Also zap keep when purging. Fixes #1139 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 13 08:40:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 May 2014 08:40:13 -0000 Subject: [Varnish] #1503: return(restart) seems to be changed into return(retry) Message-ID: <041.cf2573d353ec972ade6717eda53bca06@varnish-cache.org> #1503: return(restart) seems to be changed into return(retry) ---------------------------+--------------------------- Reporter: Tin | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 4.0.0 | Severity: normal Keywords: return(retry) | ---------------------------+--------------------------- Can't find this on https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 13 08:44:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 May 2014 08:44:59 -0000 Subject: [Varnish] #1478: Panic when trying to stream a big file that is still being cached and its TTL has expired In-Reply-To: <044.80053f43190452a5895eda5daf7014f5@varnish-cache.org> References: <044.80053f43190452a5895eda5daf7014f5@varnish-cache.org> Message-ID: <059.fb43f091c1cfd1e27f6add87fd6b6cf9@varnish-cache.org> #1478: Panic when trying to stream a big file that is still being cached and its TTL has expired ---------------------------------------------+----------------------------- Reporter: citrus | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 Component: varnishd | release Severity: normal | Version: 4.0.0 Keywords: ignore_busy streaming panic ttl | Resolution: fixed ---------------------------------------------+----------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [20d3ecae26e8b9f522c04b8759e8e5b90df5789a]: {{{ #!CommitTicketReference repository="" revision="20d3ecae26e8b9f522c04b8759e8e5b90df5789a" Move a misplaced assert. Fixes #1478 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 13 11:23:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 May 2014 11:23:04 -0000 Subject: [Varnish] #1504: With vcc_err_unref=off, CC still fails on unused acls Message-ID: <043.e660f41725bfdf3814951a9aefa6f303@varnish-cache.org> #1504: With vcc_err_unref=off, CC still fails on unused acls ----------------------+--------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: unknown Severity: normal | Keywords: ----------------------+--------------------------------- {{{ Message from VCC-compiler: Unused acl fdsafdsa, defined: ('input' Line 10 Pos 5) acl fdsafdsa { ----########-- (That was just a warning) Message from C-compiler: ./vcl.sW4evF1T.c:581:1: error: ?match_acl_named_fdsafdsa? defined but not used [-Werror=unused-function] match_acl_named_fdsafdsa(const struct vrt_ctx *ctx, const VCL_IP p) ^ cc1: all warnings being treated as errors Running C-compiler failed, exit 1 VCL compilation failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 14 15:22:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 May 2014 15:22:07 -0000 Subject: [Varnish] #1505: 4.0 and banning Message-ID: <041.9a6afd960fdc353a64e3283042224560@varnish-cache.org> #1505: 4.0 and banning -------------------+--------------------------- Reporter: dbu | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: ban | -------------------+--------------------------- https://www.varnish-cache.org/docs/4.0/users-guide/purging.html#bans says to do sub vcl_backend_response { set beresp.http.x-url = req.url; } but https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html#req- not-available-in-vcl-backend-response says that req. is not available when handling the backend response. how to set the url for the ban lurker? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 14 19:48:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 May 2014 19:48:25 -0000 Subject: [Varnish] #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' Message-ID: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' ---------------------------------+---------------------- Reporter: DonMacAskill | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: build Version: 4.0.0 | Severity: critical Keywords: | ---------------------------------+---------------------- Nils Goroll suggested I open this ticket, so here goes. Using Varnish 4, I have a set of backends that're responding with a valid ''Content- Length'' header and no ''Transfer-Encoding'' header. On the first hit from a client, rather than responding to the client with those headers, Varnish is dropping the ''Content-Length'' header and adding ''Transfer-Encoding: chunked'' to the response. (Interestingly, the payload doesn't appear to have any chunks in it - it's one contiguous payload). This causes serious problems for clients like Flash video players that are trying to do segment-size, bandwidth, etc analysis based on the ''Content- Length'' header. Their analysis fails, and they can't do things like multi-bitrate streaming, etc. I've tried a number of semi-obvious things like: * beresp.do_stream = true/false * beresp.do_gzip = false * beresp.do_esi = false * unset req.http.Accept-Encoding Sample backend response: {{{ HTTP/1.1 200 OK Cache-Control: public, max-age=600 Content-Type: video/mp4 Date: Tue, 13 May 2014 19:44:35 GMT Server: Apache Content-Length: 796618 Connection: keep-alive }}} Sample varnish response: {{{ HTTP/1.1 200 OK Server: Apache Cache-Control: public, max-age=600 Content-Type: video/mp4 Date: Tue, 13 May 2014 23:10:06 GMT X-Varnish: 2 Age: 0 Transfer-Encoding: chunked Accept-Ranges: bytes }}} Subsequent loads of the object do including the Content-Length header, just not the first load into cache. VCL: https://gist.github.com/onethumb/e64a405cc579909cace1 varnishlog output: https://gist.github.com/onethumb/e66a2bc4727a3a5340b6 Stackoverflow discussion: http://stackoverflow.com/questions/23643233 /how-do-i-disable-transfer-encoding-chunked-encoding-in-varnish -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 15 07:30:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 May 2014 07:30:58 -0000 Subject: [Varnish] #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> Message-ID: <065.1c388bb1ea5e0fd2a16b1f9e3a5e00a8@varnish-cache.org> #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' --------------------------+---------------------------------- Reporter: DonMacAskill | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: critical | Resolution: Keywords: | --------------------------+---------------------------------- Changes (by slink): * owner: => slink * status: new => assigned Comment: This bug is in the gray area between bug and improvement as http/1.1 clients MUST support chunked encoding: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 The workaround for this issue is to disable streaming, see http://stackoverflow.com/questions/23643233/how-do-i-disable-transfer- encoding-chunked-encoding-in-varnish I think we might be able to use C-L also with streaming. I am working on this and got a poc patch, which needs more work still before I'd like to discuss it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 15 07:31:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 May 2014 07:31:23 -0000 Subject: [Varnish] #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> Message-ID: <065.57dde48fe51d6eec22ebb1ca77b1e004@varnish-cache.org> #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' --------------------------+---------------------------------- Reporter: DonMacAskill | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: critical | Resolution: Keywords: | --------------------------+---------------------------------- Changes (by slink): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 15 10:40:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 May 2014 10:40:14 -0000 Subject: [Varnish] #1505: 4.0 and banning In-Reply-To: <041.9a6afd960fdc353a64e3283042224560@varnish-cache.org> References: <041.9a6afd960fdc353a64e3283042224560@varnish-cache.org> Message-ID: <056.8631a02ad154a036246595a20a9abdb8@varnish-cache.org> #1505: 4.0 and banning ---------------------------+--------------------- Reporter: dbu | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: ban | ---------------------------+--------------------- Changes (by daghf): * status: new => closed * resolution: => fixed Comment: The 'req.url' part was supposed to be 'bereq.url'. This has since been fixed in commit ec13b93699041fbf721cc0a0b4d0c4a5fe62a635 The master branch version of that document can be seen here, https://www .varnish-cache.org/docs/master/users-guide/purging.html#bans -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 16 12:55:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 May 2014 12:55:33 -0000 Subject: [Varnish] #1297: Negative times and nan in varnishlog tag ReqEnd In-Reply-To: <044.01c9f35fdc4f956b688fa5b86e2251dd@varnish-cache.org> References: <044.01c9f35fdc4f956b688fa5b86e2251dd@varnish-cache.org> Message-ID: <059.618cf82596856c7c83368ecf9f9cc047@varnish-cache.org> #1297: Negative times and nan in varnishlog tag ReqEnd -----------------------------------+--------------------- Reporter: sthing | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: varnishlog ReqEnd nan | -----------------------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [8213a0b3c7a779ee505db7467ed7f2dadfd70012]: {{{ #!CommitTicketReference repository="" revision="8213a0b3c7a779ee505db7467ed7f2dadfd70012" Don't medd up the t_open and t_resp when handling ESI subrequests. ESI subrequests would mangle the t_open and t_resp timestamps of the original requests, causing negative time and NAN being logged in ReqEnd. Fixes: #1297 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 16 12:59:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 May 2014 12:59:22 -0000 Subject: [Varnish] #1444: varnishncsa with %D format not working properly In-Reply-To: <049.3ea4c3048adb96b45082c7435628b21e@varnish-cache.org> References: <049.3ea4c3048adb96b45082c7435628b21e@varnish-cache.org> Message-ID: <064.7728e10fcb4a0878dc2f4412faf2c010@varnish-cache.org> #1444: varnishncsa with %D format not working properly -------------------------+--------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.5 Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: The documentation has been updated to add the '%D' format specifier that was previously undocumented. This will be included in the next release of Varnish 3.0. Note that the format of '%D' has been fixed to now be microseconds as an integer instead of a float formatted seconds. This is now in line with how Apache logs. I have been unable to reproduce the negative timings that you report. This could possibly be the result of setting the clock while the request is being processed. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 06:47:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 06:47:01 -0000 Subject: [Varnish] #1504: With vcc_err_unref=off, CC still fails on unused acls In-Reply-To: <043.e660f41725bfdf3814951a9aefa6f303@varnish-cache.org> References: <043.e660f41725bfdf3814951a9aefa6f303@varnish-cache.org> Message-ID: <058.1b26e5912b98af7d6b82279c1cc5182e@varnish-cache.org> #1504: With vcc_err_unref=off, CC still fails on unused acls ----------------------+---------------------------------------- Reporter: scoof | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [a1b74f7b57d8a95abbbc0fa74217a09f8f06a39f]: {{{ #!CommitTicketReference repository="" revision="a1b74f7b57d8a95abbbc0fa74217a09f8f06a39f" Allow ACLs to be unreferenced when vcc_err_unref=off. Add a reference from the init function to any non-anonymous match_acl_*() functions to ensure the compiler does not barf. Fixes #1504 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 06:49:26 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 06:49:26 -0000 Subject: [Varnish] #1502: if ( req.backend_hint == name-of-director ) { } not possible In-Reply-To: <041.3ed6122c1afdec9eeade64e100badd4b@varnish-cache.org> References: <041.3ed6122c1afdec9eeade64e100badd4b@varnish-cache.org> Message-ID: <056.acabe315a1636910f482c689e64426e3@varnish-cache.org> #1502: if ( req.backend_hint == name-of-director ) { } not possible --------------------------------+---------------------- Reporter: Tin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: wontfix Keywords: vmod_directors if | --------------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: You will have to go the X-header route. This changed behaviour is a consequence of moving the directors to vmods and there is no way to bring the old behaviour back which isn't far more "not really nice" than using an X-header. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 07:19:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 07:19:44 -0000 Subject: [Varnish] #1501: crash on hash director with all backends down In-Reply-To: <049.87496517998d0b43520b4c078348d4cd@varnish-cache.org> References: <049.87496517998d0b43520b4c078348d4cd@varnish-cache.org> Message-ID: <064.aeac0b641a29a1b89fee034a11a9eb22@varnish-cache.org> #1501: crash on hash director with all backends down -------------------------+---------------------------------------- Reporter: g.gerritsen | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | -------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [01f0e719f90bba1219426fa25abcd6cf3b68eebd]: {{{ #!CommitTicketReference repository="" revision="01f0e719f90bba1219426fa25abcd6cf3b68eebd" Directors are allowed to fail to pick a backend. Fixes #1501 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 10:16:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 10:16:27 -0000 Subject: [Varnish] #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> Message-ID: <065.7ca00c28aa8372b40ec5d15533f23fa3@varnish-cache.org> #1506: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked' --------------------------+---------------------------------- Reporter: DonMacAskill | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: critical | Resolution: Keywords: | --------------------------+---------------------------------- Comment (by slink): Don, can you provide more information on the clients which can't handle chunked? Can we identify these (e.g. by inspecting `User-Agent`) ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 10:22:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 10:22:27 -0000 Subject: [Varnish] #1503: return(restart) seems to be changed into return(retry) In-Reply-To: <041.cf2573d353ec972ade6717eda53bca06@varnish-cache.org> References: <041.cf2573d353ec972ade6717eda53bca06@varnish-cache.org> Message-ID: <056.26949aca8c82c5b71bdc2bf3cd0c3f9d@varnish-cache.org> #1503: return(restart) seems to be changed into return(retry) ---------------------------+-------------------- Reporter: Tin | Owner: scoof Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 4.0.0 Severity: normal | Resolution: Keywords: return(retry) | ---------------------------+-------------------- Changes (by scoof): * owner: => scoof -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 10:40:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 10:40:23 -0000 Subject: [Varnish] #1500: Possible bug in 4.0.0 with Range+do_stream=true In-Reply-To: <049.e06f300085772a9d4aec9d7530952cf7@varnish-cache.org> References: <049.e06f300085772a9d4aec9d7530952cf7@varnish-cache.org> Message-ID: <064.fa0d7cedbbe5689b44535c2114d392ac@varnish-cache.org> #1500: Possible bug in 4.0.0 with Range+do_stream=true -------------------------+------------------------ Reporter: moseleymark | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: duplicate Keywords: | -------------------------+------------------------ Changes (by slink): * status: new => closed * resolution: => duplicate Comment: We've discussed this issue and have come to the conclusion that this issue and #1506 should be solved in one go. I will add a summary of the discussion to #1506 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 10:53:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 10:53:49 -0000 Subject: [Varnish] #1506: Make better use of Content-Length information: Avoid chunked responses, more control over Range handling (was: Backend replies with 'Content-Length' but varnish 4.0 discards and replies with 'Transfer-Encoding: chunked') In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> Message-ID: <065.73615798e12473b6dc8e7c549190f082@varnish-cache.org> #1506: Make better use of Content-Length information: Avoid chunked responses, more control over Range handling --------------------------+---------------------------------- Reporter: DonMacAskill | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: critical | Resolution: Keywords: | --------------------------+---------------------------------- Comment (by slink): Summary of a discussion on varnish-hacking (mostly phk, martin, slink): * We want to make use of the backend C-L in deliver wherever we can * if it turns out that the announced C-L was bad, fallback to close * We might be able to motivate the backend to not send chunked for more cases, so we get a C-L * `Range: bytes 1-` is an idea, but unclear if it will work * VCL should have control over preferred delivery methods * like with `std.deliver_option(no_chunked)` * should disable other processing which is incompatible, if possible * can always fall back to EOF mode, but that doesn't send C-L either * On `Range` - from #1500: * trust C-L whenever we know it * add `std.wait_body` for use in `vcl_response` to prefer to wait until we know a C-L for the cases where we don't have one before reading the response (read: response sent chunked) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 19 16:14:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 May 2014 16:14:28 -0000 Subject: [Varnish] #1506: Make better use of Content-Length information: Avoid chunked responses, more control over Range handling In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> Message-ID: <065.0e145033d67a0562c4f827fde12ac202@varnish-cache.org> #1506: Make better use of Content-Length information: Avoid chunked responses, more control over Range handling --------------------------+---------------------------------- Reporter: DonMacAskill | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: critical | Resolution: Keywords: | --------------------------+---------------------------------- Comment (by DonMacAskill): So all of the cases I've encountered so far are Flash video players attempting to do multi-bitrate adaptive streaming. In those cases, the UA typically appears as if it's the browser, so I don't think there's any obvious way to detect and react. Some example players which I've confirmed exhibit this problem: Akamai HDS test player: http://mediapm.edgesuite.net/edgeflash/public/zeri/debug/Main.html Akamai OSMF test player: http://mediapm.edgesuite.net/akamai-osmf- plugins/samples/flash-builder-4/AASPlugin-sample-flex/bin-debug/Main.html Flowplayer: https://flowplayer.org/ There are probably more, but so far these are the only ones we've confirmed. All three of these players have large amounts of sites deployed at scale (all Flash video streaming on Akamai's network uses one of those two, for example, and I believe Flowplayer is the most popular 3rd party video player). Here's an F4M manifest link that doesn't pass through varnish: http ://photos-origin.smugmug.net/1234/Video-Tests- Dec-2013/Exploratorium-2012/i-gSNfWFW/0/SMIL/gSNfWFW.smil/manifest.f4m If you drop that into any of the above players, you'll see adaptive bitrate streaming. If you front it with varnish, you'll see that it never adapts. (Content-Length vs Transfer-Encoding being the thing that switches it on/off, presumably since these libraries are using the segment transfer time compared against Content-Length to generate bitrate guesses) I'll see if I can get a publicly available Flowplayer URL up as well, currently our only Flowplayer testbed isn't publicly accessible. But the Akamai test players should work well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 20 10:34:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 May 2014 10:34:49 -0000 Subject: [Varnish] #1495: WRK_SumStat lock contention with high number of thread pools In-Reply-To: <046.4488ac6b747ee86e9e256ea0d96628aa@varnish-cache.org> References: <046.4488ac6b747ee86e9e256ea0d96628aa@varnish-cache.org> Message-ID: <061.168a6758107504ea84680e367e1204d1@varnish-cache.org> #1495: WRK_SumStat lock contention with high number of thread pools ----------------------+---------------------------------------- Reporter: dormando | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [38ee7837bb5129276e4c75d45a554fb56ddbeb37]: {{{ #!CommitTicketReference repository="" revision="38ee7837bb5129276e4c75d45a554fb56ddbeb37" The mutex protecting summing of stats into the global VSC counters is a contention point and scales negatively with number of thread-pools. Sum into a per-pool dstat structure instead, and have the first idle thread summ that into the global counters without blocking the pool mutex. Fixes #1495 (I hope) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 21 12:38:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 May 2014 12:38:30 -0000 Subject: [Varnish] #1507: varnishstat is missing cache hit ratio Message-ID: <041.dd00f17339d5a9cb13ffc84055c90494@varnish-cache.org> #1507: varnishstat is missing cache hit ratio -------------------------+-------------------- Reporter: Tin | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: varnishstat | -------------------------+-------------------- Varnish stat in 4.0 seems to miss the cache-hit ratio. According to Martin is should be easy to fix. Cheers, Martin Boer -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 21 18:11:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 May 2014 18:11:31 -0000 Subject: [Varnish] #1508: 301 Redirects in VCL not working properly Message-ID: <052.11bccb536670c616d235bc0bdc10846e@varnish-cache.org> #1508: 301 Redirects in VCL not working properly ----------------------------+-------------------- Reporter: mightymongoose | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: 301 redirect | ----------------------------+-------------------- {{{ if (req.url == "/something") { set req.url = "/something/"; return (synth(301, "Response")); } }}} So maybe I am mistaken, but the above code, while returning a 301 response, does not redirect to the new URL. Yet it compiles and all. Documentation seems sparse on this subject, but I think this is a bug? Fiddler/chrome both just show a 301 error response with no redirect. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 21 20:07:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 May 2014 20:07:33 -0000 Subject: [Varnish] #1508: 301 Redirects in VCL not working properly In-Reply-To: <052.11bccb536670c616d235bc0bdc10846e@varnish-cache.org> References: <052.11bccb536670c616d235bc0bdc10846e@varnish-cache.org> Message-ID: <067.52be242f022e013796a0f85be6465ba4@varnish-cache.org> #1508: 301 Redirects in VCL not working properly ----------------------------+---------------------- Reporter: mightymongoose | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: invalid Keywords: 301 redirect | ----------------------------+---------------------- Changes (by daghf): * status: new => closed * resolution: => invalid Comment: The target of a 3xx redirect is indicated in the 'Location' response header. You need to explicitly set that in vcl_synth{}. Please use the varnish-misc mailing list or our irc help channel for further followup. https://www.varnish-cache.org/support -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 21 21:38:36 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 May 2014 21:38:36 -0000 Subject: [Varnish] #1509: libedit dependency missing on EL6 Message-ID: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> #1509: libedit dependency missing on EL6 -----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: major | Keywords: -----------------------+------------------- In Centos 6.5: # rpm -i ./varnish-4.0.0-1.el6.x86_64.rpm # varnishadm varnishadm: error while loading shared libraries: libedit.so.0: cannot open shared object file: No such file or directory After installing libedit works as expected. This also works fine in 3.0.5. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 21 21:39:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 May 2014 21:39:04 -0000 Subject: [Varnish] #1509: libedit dependency missing on EL6 In-Reply-To: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> References: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> Message-ID: <058.1d9403f2c1741dcda57f6e4ee090b969@varnish-cache.org> #1509: libedit dependency missing on EL6 -----------------------+-------------------- Reporter: fgsch | Owner: scn Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: major | Resolution: Keywords: | -----------------------+-------------------- Changes (by fgsch): * owner: => scn -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 21 21:40:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 May 2014 21:40:12 -0000 Subject: [Varnish] #1509: libedit dependency missing on EL6 In-Reply-To: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> References: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> Message-ID: <058.2d9e8ddd8e8b71acad82a9e2f6d47f64@varnish-cache.org> #1509: libedit dependency missing on EL6 -----------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: major | Resolution: Keywords: | -----------------------+----------------------- Changes (by fgsch): * owner: scn => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 21 21:42:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 May 2014 21:42:14 -0000 Subject: [Varnish] #1509: libedit dependency missing on EL6 In-Reply-To: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> References: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> Message-ID: <058.03e30ed1fd991cf0024c181547503508@varnish-cache.org> #1509: libedit dependency missing on EL6 -----------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: major | Resolution: Keywords: | -----------------------+----------------------- Description changed by fgsch: Old description: > In Centos 6.5: > > # rpm -i ./varnish-4.0.0-1.el6.x86_64.rpm > # varnishadm > varnishadm: error while loading shared libraries: libedit.so.0: cannot > open shared object file: No such file or directory > > After installing libedit works as expected. This also works fine in > 3.0.5. New description: In Centos 6.5: {{{ # rpm -i ./varnish-4.0.0-1.el6.x86_64.rpm # varnishadm varnishadm: error while loading shared libraries: libedit.so.0: cannot open shared object file: No such file or directory }}} After installing libedit works as expected. This also works fine in 3.0.5. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 22 07:38:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 May 2014 07:38:44 -0000 Subject: [Varnish] #1510: using "first" as the name of a director in V4.0 Message-ID: <043.357f9f432ad670254a3b404ad3330750@varnish-cache.org> #1510: using "first" as the name of a director in V4.0 ---------------------+---------------------- Reporter: alanj | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: unknown | Severity: normal Keywords: | ---------------------+---------------------- In converting a file form V3 to v4 I my testing resulted in the error: /usr/local/sbin/varnishd -C -f default.vcl.410b Message from VCC-compiler: Missing errorhandling code in parse_new(), vcc_action.c line 167: Condition((sy1) == 0) not true. Running VCC-compiler failed, signal 6 VCL compilation failed when compiling this was caused by a backend being called first and a director being called first. Changing this to a backend called first1 and a director called start_first solved this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 22 09:34:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 May 2014 09:34:07 -0000 Subject: [Varnish] #1510: using "first" as the name of a director in V4.0 In-Reply-To: <043.357f9f432ad670254a3b404ad3330750@varnish-cache.org> References: <043.357f9f432ad670254a3b404ad3330750@varnish-cache.org> Message-ID: <058.b749967bd318b55b06f6655e11b195ff@varnish-cache.org> #1510: using "first" as the name of a director in V4.0 ----------------------+---------------------- Reporter: alanj | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------- Comment (by alanj): As an adjunct to this also discovered that a "director" of "default" causes an issue at compilation: }; Message from C-compiler: ./vcl.pVnQ7Rk_.c:918:43: error: expected identifier or ?(? before ?default? static struct vmod_directors_round_robin *default; ^ ./vcl.pVnQ7Rk_.c: In function ?VGC_function_vcl_recv?: ./vcl.pVnQ7Rk_.c:1119:54: error: expected expression before ?default? Vmod_directors_Func.round_robin_backend(ctx, default) ^ ./vcl.pVnQ7Rk_.c: In function ?VGC_function_vcl_init?: ./vcl.pVnQ7Rk_.c:4701:51: error: expected expression before ?default? Vmod_directors_Func.round_robin__init(ctx, &default, "default"); [24 lines truncated] Running C-compiler failed, exit 1 VCL compilation failed Changing this to www_default allowed for completion of the compilation of the VCL. This relates the V4. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 23 22:38:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 23 May 2014 22:38:49 -0000 Subject: [Varnish] #1511: panic when attempt to retry after backend returns 500 Message-ID: <046.9c69475781ac6e120fadf12b78e4dec2@varnish-cache.org> #1511: panic when attempt to retry after backend returns 500 ---------------------------------+---------------------- Reporter: bytemask | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: panic | ---------------------------------+---------------------- varnishd child panics when I put logic in my vcl to retry when my backend returns an error 500. the vcl logic i'm using to trigger this is roughly: {{{ sub vcl_backend_response { <...> if ( beresp.status >= 500 && bereq.retries < 5 ) { return(retry); } <...> } }}} After hitting any route that returns a 500 error, the child crashes. panic.show output is: {{{ 200 Last panic at: Fri, 23 May 2014 22:34:08 GMT Assert error in vbf_stp_startfetch(), cache/cache_fetch.c line 258: Condition((bo->should_close) == 0) not true. thread = (cache-worker) ident = Linux,3.2.0-57-virtual,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4325b5: /usr/sbin/varnishd() [0x4325b5] 0x421596: /usr/sbin/varnishd() [0x421596] 0x434ab4: /usr/sbin/varnishd(Pool_Work_Thread+0xb4) [0x434ab4] 0x4477e8: /usr/sbin/varnishd() [0x4477e8] 0x7f9458b0fe9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f9458b0fe9a] 0x7f945883c3fd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f945883c3fd] busyobj = 0x7f9418030970 { ws = 0x7f9418030a38 { id = "bo", {s,f,r,e} = {0x7f9418032940,+1016,(nil),+57392}, }, refcnt = 2 retries = 1 failed = 0 state = 1 is_do_stream is_should_close bodystatus = 3 (length), }, http[bereq] = { ws = 0x7f9418030a38[bo] "GET", "/topics.mobile.html", "HTTP/1.1", "Host: qa05.ourwebsite.com", "Referer: http://www.google.com", "User-Agent: scrapy", "X-Forwarded-For: 216.112.253.12", "X-UA-Device: pc", "Accept-Encoding: gzip", "X-Varnish: 196611", }, http[beresp] = { ws = 0x7f9418030a38[bo] "HTTP/1.1", "500", "Internal Server Error", "Date: Fri, 23 May 2014 22:34:06 GMT", "Content-Length: 538", "Connection: close", "Content-Type: text/html; charset=iso-8859-1", "Server: Apache", }, ws = 0x7f9418030bc0 { BAD_MAGIC(0x00000000) }, }, objcore (FETCH) = 0x7f93f4000930 { refcnt = 2 flags = 0x2 objhead = 0x7f93f40009c0 } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 07:44:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 07:44:55 -0000 Subject: [Varnish] #1511: panic when attempt to retry after backend returns 500 In-Reply-To: <046.9c69475781ac6e120fadf12b78e4dec2@varnish-cache.org> References: <046.9c69475781ac6e120fadf12b78e4dec2@varnish-cache.org> Message-ID: <061.42c3b31869f333c6453c83671a12d6e7@varnish-cache.org> #1511: panic when attempt to retry after backend returns 500 ----------------------+---------------------------------- Reporter: bytemask | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: duplicate Keywords: panic | ----------------------+---------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #1494 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 08:40:17 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 08:40:17 -0000 Subject: [Varnish] #1510: using "first" as the name of a director in V4.0 In-Reply-To: <043.357f9f432ad670254a3b404ad3330750@varnish-cache.org> References: <043.357f9f432ad670254a3b404ad3330750@varnish-cache.org> Message-ID: <058.c4e4011bc593f1f58afbbab9e095ad45@varnish-cache.org> #1510: using "first" as the name of a director in V4.0 ----------------------+---------------------------------------- Reporter: alanj | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [60b5e71e8a59a53f2575802c30a2f6eb2b7d2336]: {{{ #!CommitTicketReference repository="" revision="60b5e71e8a59a53f2575802c30a2f6eb2b7d2336" Properly complain if people try to reuse symbols. Fixes #1510 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:07:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:07:08 -0000 Subject: [Varnish] #1187: Document restrictions on range requests In-Reply-To: <043.3a5b79d566e4d093cdee9d9c0342bc65@varnish-cache.org> References: <043.3a5b79d566e4d093cdee9d9c0342bc65@varnish-cache.org> Message-ID: <058.2e8045e37a80720f061509461654cd74@varnish-cache.org> #1187: Document restrictions on range requests ---------------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Changes (by lkarsten): * owner: scoof => lkarsten Comment: This is more of a feature request than a bug, so I'm moving it to the Future_Feature wiki page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:09:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:09:35 -0000 Subject: [Varnish] #1214: s_bodybytes and range: header issue In-Reply-To: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> References: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> Message-ID: <059.ca67cc164d16db00d61d0a018a88175e@varnish-cache.org> #1214: s_bodybytes and range: header issue ------------------------------------+-------------------- Reporter: emilio | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: s_bodybytes range: 206 | ------------------------------------+-------------------- Changes (by daghf): * owner: tfheen => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:16:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:16:59 -0000 Subject: [Varnish] #1269: varnishncsa does not show pipe'ed requests In-Reply-To: <047.74c03b61e1ee686de1e8904dfd87ef9a@varnish-cache.org> References: <047.74c03b61e1ee686de1e8904dfd87ef9a@varnish-cache.org> Message-ID: <062.75cd02872f6293bb29aea1984fe2442b@varnish-cache.org> #1269: varnishncsa does not show pipe'ed requests -------------------------+----------------------- Reporter: prymitive | Owner: lkarsten Type: defect | Status: new Priority: low | Milestone: Component: varnishncsa | Version: 3.0.3 Severity: minor | Resolution: Keywords: | -------------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten Comment: I'll review the documentation on this, so we don't lie about what we log. Dag says that in master we're logging the first piped request, but it should be clear. Need to look this up. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:19:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:19:12 -0000 Subject: [Varnish] #1315: Varnish doesn't respect req.ttl = 0s In-Reply-To: <043.51e28a4bf824b5282ca32638aed81d0a@varnish-cache.org> References: <043.51e28a4bf824b5282ca32638aed81d0a@varnish-cache.org> Message-ID: <058.7f0304f5ced7d2faf0542cd1a06e305a@varnish-cache.org> #1315: Varnish doesn't respect req.ttl = 0s --------------------+------------------------- Reporter: daghf | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Req.{ttl,grace,keep} are gone in 4.0, so this is overtaken by events. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:21:19 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:21:19 -0000 Subject: [Varnish] #1343: Storage file handling is confused if file exists In-Reply-To: <046.7e806953bab79cec3b63fad3eb7638f4@varnish-cache.org> References: <046.7e806953bab79cec3b63fad3eb7638f4@varnish-cache.org> Message-ID: <061.fee9fccd1015b22a4d2995b094b3859c@varnish-cache.org> #1343: Storage file handling is confused if file exists ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Discussed during bugwash today. We keep this and try to get it fixed. What Tollef wrote up is still our preferred way to handle this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:23:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:23:23 -0000 Subject: [Varnish] #1354: Segfault in libvgz.so In-Reply-To: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> References: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> Message-ID: <057.3ff3076199b9a1b2181148b53c06a4d7@varnish-cache.org> #1354: Segfault in libvgz.so --------------------+-------------------- Reporter: ixos | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 3.0.4 Severity: major | Resolution: Keywords: | --------------------+-------------------- Comment (by lkarsten): Hi. This was discussed during bugwash today. We haven't been able to reproduce this, or seen it in any other setups. Is this still an issue for you? (timeout/close this in two weeks if nothing heard) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:34:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:34:13 -0000 Subject: [Varnish] #1349: No exact match on varnishadm backend.set_health In-Reply-To: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org> References: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org> Message-ID: <061.4a03e039598cf59278ade584a5906f73@varnish-cache.org> #1349: No exact match on varnishadm backend.set_health --------------------------------------------+-------------------- Reporter: tmagnien | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: exact match backend.set_health | --------------------------------------------+-------------------- Changes (by daghf): * owner: => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:37:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:37:02 -0000 Subject: [Varnish] #1402: Failed dependencies: libvarnishapi.so.1 In-Reply-To: <046.8f382fc03c0717150d85139dbc82a371@varnish-cache.org> References: <046.8f382fc03c0717150d85139dbc82a371@varnish-cache.org> Message-ID: <061.862d03521f632d6ad8a628a7a973c86f@varnish-cache.org> #1402: Failed dependencies: libvarnishapi.so.1 -----------------------+------------------------------ Reporter: dmalinow | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: packaging | Version: trunk Severity: major | Resolution: Keywords: | -----------------------+------------------------------ Changes (by lkarsten): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:38:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:38:08 -0000 Subject: [Varnish] #1402: Failed dependencies: libvarnishapi.so.1 In-Reply-To: <046.8f382fc03c0717150d85139dbc82a371@varnish-cache.org> References: <046.8f382fc03c0717150d85139dbc82a371@varnish-cache.org> Message-ID: <061.5f6e79e272d6d3b77452581860f37de7@varnish-cache.org> #1402: Failed dependencies: libvarnishapi.so.1 -----------------------+------------------------------ Reporter: dmalinow | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: packaging | Version: trunk Severity: major | Resolution: Keywords: | -----------------------+------------------------------ Comment (by lkarsten): I'll fix and make sure this is gone when I do the 4.0.1 release. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 10:57:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 10:57:56 -0000 Subject: [Varnish] #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. In-Reply-To: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> References: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> Message-ID: <058.73a327a90290f9037d3a09ccd574ddaa@varnish-cache.org> #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. ----------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: Keywords: gzip | ----------------------+-------------------- Comment (by geoff): Will check if this can still happen in V4. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 13:09:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 13:09:21 -0000 Subject: [Varnish] #1214: s_bodybytes and range: header issue In-Reply-To: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> References: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> Message-ID: <059.9f16991da8f25ea0356fa8373b1df789@varnish-cache.org> #1214: s_bodybytes and range: header issue ------------------------------------+--------------------- Reporter: emilio | Owner: daghf Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: s_bodybytes range: 206 | ------------------------------------+--------------------- Changes (by daghf): * status: new => closed * resolution: => fixed Comment: I amended test case c00034.vtc to verify that this has since been fixed - see commit 2e48fba. Please let us know if you are able to reproduce this again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 13:24:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 13:24:35 -0000 Subject: [Varnish] #1142: nuke_limit documentation needs expanding to explain 'random' 503's In-Reply-To: <046.29494e99aa56b9276a3039740969a02d@varnish-cache.org> References: <046.29494e99aa56b9276a3039740969a02d@varnish-cache.org> Message-ID: <061.5abd9208ed4ce6a57c8aeda7c72c4fc2@varnish-cache.org> #1142: nuke_limit documentation needs expanding to explain 'random' 503's ---------------------------+---------------------- Reporter: timbunce | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 3.0.0 Severity: normal | Resolution: invalid Keywords: | ---------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: This is asking for feature development, which is tracked in _Future wiki pages. See https://www.varnish-cache.org/trac/wiki/Future_Feature Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 13:32:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 13:32:15 -0000 Subject: [Varnish] #1130: varnishncsa -d makes it exit(0) after processing old entries In-Reply-To: <040.07815af94e0e42afed90f4fadb228259@varnish-cache.org> References: <040.07815af94e0e42afed90f4fadb228259@varnish-cache.org> Message-ID: <055.c8d6eb7f8fc181f257d282ac987c20b1@varnish-cache.org> #1130: varnishncsa -d makes it exit(0) after processing old entries -------------------------+---------------------- Reporter: bz | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.2 Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: This feature request has been moved to https://www.varnish- cache.org/trac/wiki/Future_Tools#varnishlog-dbehavior Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 13:37:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 13:37:07 -0000 Subject: [Varnish] #1365: AIX, configure, readline, libedit, python, C99 compatible build questions/issues In-Reply-To: <049.41434828da49a3ac122c1c8c7d6f60fe@varnish-cache.org> References: <049.41434828da49a3ac122c1c8c7d6f60fe@varnish-cache.org> Message-ID: <064.03a58c35b618a0224074c220509b97ab@varnish-cache.org> #1365: AIX, configure, readline, libedit, python, C99 compatible build questions/issues -------------------------+---------------------- Reporter: MichaelFelt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: wontfix Keywords: | -------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => wontfix Comment: A lot of changes to the build system has happened in Varnish 4, which would at the very least give a new set of build problems on AIX making this ticket past it's best before date. And AIX isn't among the prioritized platforms for Varnish. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 13:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 13:38:28 -0000 Subject: [Varnish] #1392: no logging when saintmode denies a backend connection In-Reply-To: <045.0281c891683c52d234a42d7ec416ce90@varnish-cache.org> References: <045.0281c891683c52d234a42d7ec416ce90@varnish-cache.org> Message-ID: <060.562bae58b10971e1664455b5aa2fb456@varnish-cache.org> #1392: no logging when saintmode denies a backend connection -------------------------+---------------------- Reporter: odoucet | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: OBE as saintmode was removed during the Varnish 4 development cycle. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 13:58:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 13:58:13 -0000 Subject: [Varnish] #1349: No exact match on varnishadm backend.set_health In-Reply-To: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org> References: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org> Message-ID: <061.f635109e9059a17ce0eea898283fce91@varnish-cache.org> #1349: No exact match on varnishadm backend.set_health --------------------------------------------+-------------------- Reporter: tmagnien | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: exact match backend.set_health | --------------------------------------------+-------------------- Changes (by daghf): * version: 3.0.3 => trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 14:24:20 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 14:24:20 -0000 Subject: [Varnish] #1311: Probe with chunked encoding results in abnormal varnishlog output In-Reply-To: <050.b0bdd4cc49a4d1d460793944567caa10@varnish-cache.org> References: <050.b0bdd4cc49a4d1d460793944567caa10@varnish-cache.org> Message-ID: <065.0752aea302a3a6efdad79cbb8ea50ff0@varnish-cache.org> #1311: Probe with chunked encoding results in abnormal varnishlog output --------------------------+--------------------- Reporter: philipseidel | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: varnishlog | --------------------------+--------------------- Comment (by martin): This has been fixed in Varnish 4 (varnishlog no longer prints anything past the first \r\n). Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 14:24:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 14:24:31 -0000 Subject: [Varnish] #1311: Probe with chunked encoding results in abnormal varnishlog output In-Reply-To: <050.b0bdd4cc49a4d1d460793944567caa10@varnish-cache.org> References: <050.b0bdd4cc49a4d1d460793944567caa10@varnish-cache.org> Message-ID: <065.44344eca9b4694cee36946ccdf973004@varnish-cache.org> #1311: Probe with chunked encoding results in abnormal varnishlog output --------------------------+--------------------- Reporter: philipseidel | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishlog | --------------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 22:30:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 22:30:24 -0000 Subject: [Varnish] #1375: Varnish performance appears to be impacted by the presence of many vary headers In-Reply-To: <046.e6aab9a8880d23ef3a990bd54017648f@varnish-cache.org> References: <046.e6aab9a8880d23ef3a990bd54017648f@varnish-cache.org> Message-ID: <061.cb570f4ebaa8a123af07021345bd1149@varnish-cache.org> #1375: Varnish performance appears to be impacted by the presence of many vary headers ----------------------+------------------------- Reporter: closer01 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Sorry about the long delay in answering, for some reason we had all overlooked this ticket. The scenarios you report on are not typical and varnish is not aimed at them. However, Varnish will handle them incredibly efficient, but you have to force the Vary'ants into the hash-key, rather than rely on the built in vary mechanism. The sort explanation is that we keep the Vary-ants on a linked list under the hash-key, so many vary-ants, either through man vary headers or through many variants, causes this link to become longer than good is. If instead you add the vary criteria to the hash-key (in vcl_hash{}) you get more hash-keys, but each with a shorter linked list, and the performance should not suffer at all, quite the contrary: It will be faster than doing Vary processing. The downside is that you need to tell your VCL about the structure of your objects vary-ances, which is less general. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 22:31:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 22:31:14 -0000 Subject: [Varnish] #1451: p00009.vtc is fragile In-Reply-To: <046.a43cd06901bb6cec45f2384dcd13c80d@varnish-cache.org> References: <046.a43cd06901bb6cec45f2384dcd13c80d@varnish-cache.org> Message-ID: <061.4737253de7b7f392c4e12494fdc8fd95@varnish-cache.org> #1451: p00009.vtc is fragile -------------------------+---------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: minor | Resolution: wontfix Keywords: | -------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: We have decided to deprecate -spersistent. See: https://www.varnish-cache.org/docs/trunk/phk/persistent.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 22:31:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 22:31:47 -0000 Subject: [Varnish] #1471: Assert error with persistent storage In-Reply-To: <046.385d53525338dce61ea8f1e5b97f7250@varnish-cache.org> References: <046.385d53525338dce61ea8f1e5b97f7250@varnish-cache.org> Message-ID: <061.260709f744cff5dd2de895ae72f44d7d@varnish-cache.org> #1471: Assert error with persistent storage ---------------------------------------------+-------------------------- Reporter: tmagnien | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0-beta1 Severity: normal | Resolution: wontfix Keywords: assert persistent smp_oc_getobj | ---------------------------------------------+-------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: We have decided to deprecate -spersistent. See: https://www.varnish-cache.org/docs/trunk/phk/persistent.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 26 22:32:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 May 2014 22:32:15 -0000 Subject: [Varnish] #1053: Persistent storage: Catch-all ticket In-Reply-To: <046.15b4aca0756757e34fe8cc21c10552fc@varnish-cache.org> References: <046.15b4aca0756757e34fe8cc21c10552fc@varnish-cache.org> Message-ID: <061.dbcf42fa26f17d1e45b7cbeb358735a6@varnish-cache.org> #1053: Persistent storage: Catch-all ticket ----------------------+---------------------- Reporter: dumbbell | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: wontfix Keywords: | ----------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: We have decided to deprecate -spersistent. See: https://www.varnish-cache.org/docs/trunk/phk/persistent.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 27 08:53:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 May 2014 08:53:44 -0000 Subject: [Varnish] #1366: persistence panic: vca_tcp_opt_set(), cache/cache_acceptor.c line 222: In-Reply-To: <046.4f5b81be0598ee1826ee59e3c9b23187@varnish-cache.org> References: <046.4f5b81be0598ee1826ee59e3c9b23187@varnish-cache.org> Message-ID: <061.1bbf808a6cf8f90befc0a957a483ef0e@varnish-cache.org> #1366: persistence panic: vca_tcp_opt_set(), cache/cache_acceptor.c line 222: ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): To clarify; the use of "persistence" here is because of the test suite in Fryer that failed. In essence it just means that varnishd is running with -spersistent. I haven't seen any similar crashes lately, so I'd be ok with closing this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 27 11:24:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 May 2014 11:24:21 -0000 Subject: [Varnish] #1512: Changes to bereq are lost between v_b_r and v_b_f Message-ID: <043.04a15d59ba73f8274523e0e9150e84a7@varnish-cache.org> #1512: Changes to bereq are lost between v_b_r and v_b_f --------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- See attached testcase. If a header is added to bereq and v_b_r returns retry the header is lost in v_b_f. It should maintain keep the header between restarts. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 27 11:31:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 May 2014 11:31:56 -0000 Subject: [Varnish] #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon Message-ID: <043.db2ab567f1ed05ba57f00e57b891cb67@varnish-cache.org> #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon --------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- See attached testcase. If a header is added to beresp and v_b_r or v_b_e returns abandon the header is lost in v_s. Abandon is treated as fail and a 503 response is generated, discarding any changes to beresp. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 27 13:23:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 May 2014 13:23:33 -0000 Subject: [Varnish] #1514: Documentation update Message-ID: <049.ba7f49e64c3a6f17f160c2febdc52f39@varnish-cache.org> #1514: Documentation update -------------------------+--------------------------- Reporter: neverexists | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | -------------------------+--------------------------- Hi, i find this variables (storage.$name.free_space , storage.$name.used_space and storage.$name.happy and ) defined in changes.rst and .html by version 3.0 but these vars are not mentioned in the documentation. Maybe are interesting for someone . Can you update ? thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 27 14:39:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 May 2014 14:39:28 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write Message-ID: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+---------------------- Reporter: g.gerritsen | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------------+---------------------- Assert error in HTTP1_Write(), cache/cache_http1_proto.c line 518: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache-worker) ident = Linux,2.6.32-431.17.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43a756: pan_backtrace+0x19 0x43aa66: pan_ic+0x1e8 0x435dd3: HTTP1_Write+0xa6 0x44275e: V1D_Deliver+0x630 0x43dad2: cnt_deliver+0x75d 0x440e0a: CNT_Request+0x529 0x433915: HTTP1_Session+0x429 0x443d5f: ses_req_pool_task+0x166 0x44402a: ses_sess_pool_task+0x23b 0x4445d6: SES_pool_accept_task+0x1f9 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 28 09:04:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 May 2014 09:04:30 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write In-Reply-To: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> References: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> Message-ID: <064.84259b326ca287b989079c8446183c0a@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+-------------------- Reporter: g.gerritsen | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by g.gerritsen): probleem is caused by big cookies, once I removed the cookies from these requests the panics did not occur anymore. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 28 18:18:32 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 May 2014 18:18:32 -0000 Subject: [Varnish] #1516: vcl example fixup vary Message-ID: <041.7fb26af8baff66cc8070b6fcf8c5b93f@varnish-cache.org> #1516: vcl example fixup vary ---------------------+--------------------------- Reporter: dbu | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ---------------------+--------------------------- i am reading https://www.varnish-cache.org/trac/wiki/VCLExampleFixupVary and am confused why the right hand side of the operations are talking about req.http.Vary ? i guess this should be beresp as well, no? and it is meant to be in vcl_recv i guess? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 29 00:34:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 29 May 2014 00:34:55 -0000 Subject: [Varnish] #1517: HTTPS Redirects Message-ID: <051.0f52524c4a4d7a95edfd419cba0e2b07@varnish-cache.org> #1517: HTTPS Redirects ---------------------------------+--------------------------- Reporter: shredtechular | Type: documentation Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: documentation Version: 4.0.0 | Severity: normal Keywords: | ---------------------------------+--------------------------- I've been trying to use the documented example () to setup a redirect for our website from http to https. This documented example appears to only work in version 3.x and not 4.0 however. I've modified the example from: {{{ sub vcl_recv { if ( (req.http.host ~ "^(?i)somesite.org" || req.http.host ~ "^(?i)www.somesite.org") && req.http.X-Forwarded-Proto !~ "(?i)https") { set req.http.x-Redir-Url = "https://www.somesite.org" + req.url; error 750 req.http.x-Redir-Url; } } sub vcl_error { if (obj.status == 750) { set obj.http.Location = obj.response; set obj.status = 302; return (deliver); } }}} to: {{{ sub vcl_recv { if ( (req.http.host ~ "^(?i)mysite.com") && req.http.X-Forwarded-Proto !~ "(?i)https") { set req.http.x-redir-url = "https://" + req.http.host + req.url; #error 750 req.http.x-redir-url; } } sub vcl_backend_error { if (beresp.status == 750) { # set beresp.http.Location = beresp.response; set beresp.status = 302; return (deliver); } } }}} However, I'm struggling to figure out how to throw the custom error code to tell Varnish to go to the vcl_backend_error subroutine. In reading through the documentation it seems like maybe I should use "synth" instead of "error" but this doesn't seem to be working for me either. If I uncomment the commented out lines, I'm unable to restart Varnish. Any ideas or help to do this? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 29 01:36:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 29 May 2014 01:36:41 -0000 Subject: [Varnish] #1517: HTTPS Redirects In-Reply-To: <051.0f52524c4a4d7a95edfd419cba0e2b07@varnish-cache.org> References: <051.0f52524c4a4d7a95edfd419cba0e2b07@varnish-cache.org> Message-ID: <066.f78a37825545b54ea063f3c2efb5322d@varnish-cache.org> #1517: HTTPS Redirects ---------------------------+---------------------------------- Reporter: shredtechular | Owner: Type: documentation | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: documentation | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ---------------------------+---------------------------------- Comment (by shredtechular): Nevermind, I figured it out... Please feel free to close the ticket out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 30 17:52:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 May 2014 17:52:11 -0000 Subject: [Varnish] #1484: Extra provides in 4.0.0 RPM packages In-Reply-To: <046.737980f5728501ca8500dd42baa96c66@varnish-cache.org> References: <046.737980f5728501ca8500dd42baa96c66@varnish-cache.org> Message-ID: <061.9440e93c1350cfc3bf5f08abf50f8211@varnish-cache.org> #1484: Extra provides in 4.0.0 RPM packages -----------------------+----------------------- Reporter: lkarsten | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | -----------------------+----------------------- Comment (by smerrill): When will new RHEL 6 RPMs be available that fix this defect? -- Ticket URL: Varnish The Varnish HTTP Accelerator