From varnish-bugs at varnish-cache.org Wed Apr 1 11:13:52 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 01 Apr 2015 11:13:52 -0000 Subject: [Varnish] #1696: Varnish leaves connections in CLOSE_WAIT In-Reply-To: <045.9d3cd635ef30cb25d4bc2d87bd479cf7@varnish-cache.org> References: <045.9d3cd635ef30cb25d4bc2d87bd479cf7@varnish-cache.org> Message-ID: <060.69ee89134260808e4a562dee4df64580@varnish-cache.org> #1696: Varnish leaves connections in CLOSE_WAIT ----------------------+---------------------- Reporter: rwimmer | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 3.0.5 Severity: critical | Resolution: invalid Keywords: | ----------------------+---------------------- Changes (by daghf): * status: new => closed * resolution: => invalid Comment: Hi What happens here is sessions piling up in the waitinglists, due to backend request serialization caused by a vcl_fetch misconfiguration. On a cache miss, Varnish will kick off a backend request, and any subsequent request for that object while it is being fetched will be waitlisted, on the premise that the response from the request that was first kicked off is indeed cacheable and can thus also be delivered to the waiting clients. To avoid waitlisting for non-cacheable resources, Varnish has the concept of hit_for_pass, which basically means that we cache the decision not to cache this object - and thus don't do any waitlisting/request coalescing. However, a hit_for_pass object also carries a TTL, and if that TTL was set to 0s, it is immediately timed out and we're back to queueing up requests (for a resources that is not cacheable), and thus they will be dispatched in a serialized manner, one at the time. In a situation where the incoming request rate is higher than the rate that they are dispatched to the backend, you will then see a pileup of sessions stuck in the waiting lists. The built-in VCL has safeguards to prevent this (if the ttl was set to 0s it will create a 120s hit_for_pass object), but when an explicit return is done that prevents the built-in VCL from executing. Summary: If you do an explicit return from vcl_fetch, make sure beresp.ttl is different from 0s. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 1 13:25:53 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 01 Apr 2015 13:25:53 -0000 Subject: [Varnish] #1697: Discard a configuration with bad character is impossible In-Reply-To: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> References: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> Message-ID: <060.b95c0dc30a27895bf1f3773ecc08ab6b@varnish-cache.org> #1697: Discard a configuration with bad character is impossible ------------------------+---------------------------------- Reporter: vrobert | Owner: Type: defect | Status: new Priority: low | Milestone: Varnish 4.0 release Component: varnishadm | Version: 4.0.3 Severity: normal | Resolution: Keywords: discard | ------------------------+---------------------------------- Comment (by fgsch): Try: varnishadm .. vcl.list | hexdump To find the weird char. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 6 21:30:35 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 06 Apr 2015 21:30:35 -0000 Subject: [Varnish] #1698: compressed objects over allocate when content-length is specified Message-ID: <045.02fe9abcb486afe8f5807f4d21b45896@varnish-cache.org> #1698: compressed objects over allocate when content-length is specified ---------------------+---------------------- Reporter: dward84 | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.3 | Severity: normal Keywords: | ---------------------+---------------------- Varnish appears to be allocating the uncompressed object size when 1. Declaring beresp.do_gzip (so that the server compresses content when it stores it in cache) 2. The server returns content-length This results in excessive memory consumption. As an attempted work-around, I tried removing the content-length header in vcl_backend_response, which doesn't work. The following test shows that more than 40K is allocated for what compresses down to several hundred bytes. {{{ varnishtest "bloated object size" server s1 { rxreq # add -nolen here to remove Content-Length. it will just allocate the fetch_chunksize, passing the test. txresp -bodylen 40000 } -start varnish v1 -arg "-s malloc,1M" \ -arg "-pgzip_level=8" \ -arg "-phttp_gzip_support=true" \ -arg "-pfetch_chunksize=4k" \ -vcl+backend { sub vcl_backend_response { set beresp.do_gzip = true; set beresp.ttl = 1m; # This doesn't work... but should it? unset beresp.http.Content-Length; } } -start client c1 { txreq -url "/foo" rxresp expect resp.bodylen == 40000 } -run varnish v1 -expect SMA.s0.g_bytes <= 40000 }}} Is this expected behavior? If so, is there a workaround? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 7 10:46:23 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Apr 2015 10:46:23 -0000 Subject: [Varnish] #1699: Binding to port 80 fail. (privs dropped by then) Message-ID: <046.747e3a85f69108edabb6e39a9c1ffc98@varnish-cache.org> #1699: Binding to port 80 fail. (privs dropped by then) ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- git master 6044905 drops privileges before it tries to bind to port 80, which leads to permission denied and a non-starting varnishd. Expected behaviour: bind to privileged ports before setresuid() and setresgid(). {{{ 6526 execve("/opt/varnish/sbin/varnishd", ["/opt/varnish/sbin/varnishd", "-P", "/var/run/varnish/varnishd.pid", "-a", ":80", "-T", "localhost:6082", "-f", "/etc/varnish/default4.vcl", "-S", "/etc/varnish/secret", "-p", "nuke_limit=50000", "-p", "fetch_chunksize=8k", "-p", ...], [/* 27 vars */]) = 0 [..] 6526 setresgid(-1, 125, -1) = 0 6526 setresuid(-1, 118, -1) = 0 [..] 6526 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 6526 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 6526 bind(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EACCES (Permission denied) 6526 close(3) = 0 6526 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3 6526 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 6526 setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 6526 bind(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EACCES (Permission denied) 6526 close(3) = 0 6526 write(2, "Error: Could not bind to address"..., 56) = 56 6526 exit_group(2) = ? 6526 +++ exited with 2 +++ }}} (uid 118 == varnish user, gid 125 == varnish group) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 7 19:01:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Apr 2015 19:01:36 -0000 Subject: [Varnish] #1698: compressed objects over allocate when content-length is specified In-Reply-To: <045.02fe9abcb486afe8f5807f4d21b45896@varnish-cache.org> References: <045.02fe9abcb486afe8f5807f4d21b45896@varnish-cache.org> Message-ID: <060.85be365f859f9d961bc2bb21b96f5f03@varnish-cache.org> #1698: compressed objects over allocate when content-length is specified ----------------------+-------------------- Reporter: dward84 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by dward84): After looking at ticket #1617, it appears setting set beresp.do_stream = false in vcl_backend_response fixes the over allocation due to the trimming of the object. This ticket can be close or marked as a duplicate of #1617 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 7 20:59:07 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Apr 2015 20:59:07 -0000 Subject: [Varnish] #1700: objecthead counter incorrect or leaking on purge Message-ID: <045.948fd83162ebc4b65370db7c7d8df835@varnish-cache.org> #1700: objecthead counter incorrect or leaking on purge ---------------------+---------------------- Reporter: dward84 | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.3 | Severity: normal Keywords: | ---------------------+---------------------- When purging an item in varnish, I would expect the objecthead counter to be 0 (or 1?). But in practice, varnish appears to be creating a new objecthead for each replacement of the cache item. I suspect that this is an accounting error and not an actual leak as the memory usage does not appear to be increasing. See the following test: {{{ varnishtest "objecthead leak on purge" server s1 { rxreq txresp -body "this is a test" rxreq txresp -body "this is a test" rxreq txresp -body "this is a test" rxreq txresp -body "this is a test" rxreq txresp -body "this is a test" rxreq txresp -body "this is a test" rxreq txresp -body "this is a test" rxreq txresp -body "this is a test" } -start varnish v1 -arg "-s malloc,1M" \ -vcl+backend { sub vcl_recv { if (req.method == "PURGE") { return(purge); } } sub vcl_purge { return(synth(200, "Purged.")); } sub vcl_backend_response { set beresp.ttl = 1m; set beresp.grace = 0s; set beresp.keep = 0s; } } -start client c1 { txreq -url "/" rxresp txreq -req PURGE -url "/" rxresp expect resp.body ~ "Purged" txreq -url "/" rxresp txreq -req PURGE -url "/" rxresp expect resp.body ~ "Purged" txreq -url "/" rxresp txreq -req PURGE -url "/" rxresp expect resp.body ~ "Purged" txreq -url "/" rxresp txreq -req PURGE -url "/" rxresp expect resp.body ~ "Purged" } -run varnish v1 -expect MAIN.n_objecthead == 1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 8 06:14:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 08 Apr 2015 06:14:26 -0000 Subject: [Varnish] #1635: Completed bans keep accumulating In-Reply-To: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> References: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> Message-ID: <058.daa0aa22ea19e600e5a95a080f2276fb@varnish-cache.org> #1635: Completed bans keep accumulating ----------------------+-------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: lurker | ----------------------+-------------------- Comment (by RyanS): Our Varnish 4.0.3 installation probably suffers from the same problem. We use Varnish 4.0.3 for out website and serve a lot of pages with semi- unlimited (i.e. 1 year) TTL. When content gets changed, we ban te cache object through special http headers. Please note that there can be 250.000+ new bans per day. Our problem is that page load times turn out to be slower and slower the longer Varnish runs. When checking with "varnishstat -1" it seems that band never get deleted. MAIN.bans_deleted is always 0. When i login to varnishadm and type the ban.list command I see a long list of bans with status "C" for "Completed". Varnishstat -1 shows me that there can be hundreds of thousands of them. They never get deleted. --- Here are the important part from our VCL: sub vcl_recv { if (req.method == "BAN") { if (!client.ip ~ purgers) { return (synth(405, "Not allowed")); } if (req.http.X-Cache-Tags) { ban("obj.http.X-Cache-Tags ~ " + req.http.X-Cache-Tags); return (synth(200, "Banned")); } if (req.http.X-Url) { ban("obj.http.x-origurl ~ " + req.http.X-Url); return (synth(200, "Banned")); } return (synth(405, "No cache tags provided")); } ... } sub vcl_backend_response { set beresp.http.x-origurl = bereq.url; ... } --- Here's an example of the ban.list output from varnishadm: 1428440119.975700 20 C 1428440119.875178 21 C 1428440119.775048 0 C 1428440119.675068 1 C 1428440119.575059 0 C 1428440119.474236 0 C 1428440119.374664 1 C 1428440119.275055 0 C 1428440119.173203 1 C 1428440119.070568 1 C 1428440118.968622 0 C 1428440118.867101 0 C 1428440118.767099 2 C 1428440118.665274 3 C 1428440118.565995 2 C 1428440118.463959 4 C 1428440118.360379 3 C 1428440118.259975 4 C 1428440118.157665 4 C 1428440118.054391 8 C 1428440117.953973 3 C 1428440117.851816 16 C 1428440117.749820 7 C 1428440117.647959 8 C 1428440117.546431 2 C 1428440117.446593 2 C 1428440117.345096 1 C 1428440117.245096 0 C 1428440117.143993 0 C 1428440117.! --- Here's output from varnishstat -1 a couple of hours after restart: MAIN.bans 148860 . Count of bans MAIN.bans_completed 148137 . Number of bans marked 'completed' MAIN.bans_obj 148859 . Number of bans using obj.* MAIN.bans_req 0 . Number of bans using req.* MAIN.bans_added 148860 3.93 Bans added MAIN.bans_deleted 0 0.00 Bans deleted MAIN.bans_tested 2792056 73.77 Bans tested against objects (lookup) MAIN.bans_obj_killed 168 0.00 Objects killed by bans (lookup) MAIN.bans_lurker_tested 32706072512 864097.03 Bans tested against objects (lurker) MAIN.bans_tests_tested 347445702 9179.54 Ban tests tested against objects (lookup) MAIN.bans_lurker_tests_tested 32706072533 864097.03 Ban tests tested against objects (lurker) MAIN.bans_lurker_obj_killed 132363 3.50 Objects killed by bans (lurker) MAIN.bans_dups 58 0.00 Bans superseded by other bans MAIN.bans_lurker_contention 1303 0.03 Lurker gave way for lookup MAIN.bans_persisted_bytes 24958452 . Bytes used by the persisted ban lists MAIN.bans_persisted_fragmentation 22912281 . Extra bytes in persisted ban lists due to fragmentation As you can see, MAIN.bans_deleted is 0. -- I've already increased ban_lurker_batch to 100.000 and decreased ban_lurker_sleep to 0.001 sec, with no effect. If you need more information, please let me know. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 9 07:36:42 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 09 Apr 2015 07:36:42 -0000 Subject: [Varnish] #1697: Discard a configuration with bad character is impossible In-Reply-To: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> References: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> Message-ID: <060.dc02d7a8812b2f59afa0b4d8bc523304@varnish-cache.org> #1697: Discard a configuration with bad character is impossible ------------------------+---------------------------------- Reporter: vrobert | Owner: Type: defect | Status: new Priority: low | Milestone: Varnish 4.0 release Component: varnishadm | Version: 4.0.3 Severity: normal | Resolution: Keywords: discard | ------------------------+---------------------------------- Comment (by vrobert): Hi, the weird char is a capital A with tilde (?): {{{ varnishadm -T localhost:6082 -S /etc/varnish/secret vcl.list | hexdump -C 00000000 61 76 61 69 6c 61 62 6c 65 20 20 20 20 20 20 20 |available | 00000010 30 20 32 30 31 35 30 33 31 31 5f 6f 66 61 44 72 |0 20150311_ofaDr| 00000020 75 70 61 6c c3 32 0a 61 76 61 69 6c 61 62 6c 65 |upal.2.available| 00000030 20 20 20 20 20 20 20 30 20 32 30 31 35 30 33 32 | 0 2015032| 00000040 37 c3 5f 6d 61 76 69 6c 6c 65 33 36 30 5f 33 0a |7._maville360_3.| 00000050 61 63 74 69 76 65 20 20 20 20 20 20 20 20 31 30 |active 10| 00000060 32 20 32 30 31 35 30 34 30 31 5f 6f 66 61 44 65 |2 20150401_ofaDe| 00000070 76 69 63 65 0a 0a |vice..| 00000076 varnishadm -T localhost:6082 -S /etc/varnish/secret vcl.list | hexdump -c 0000000 a v a i l a b l e 0000010 0 2 0 1 5 0 3 1 1 _ o f a D r 0000020 u p a l 303 2 \n a v a i l a b l e 0000030 0 2 0 1 5 0 3 2 0000040 7 303 _ m a v i l l e 3 6 0 _ 3 \n 0000050 a c t i v e 9 0000060 2 2 0 1 5 0 4 0 1 _ o f a D e 0000070 v i c e \n \n 0000076 }}} We tested to discard the confguration but it doesn't work: {{{ varnishadm -T localhost:6082 -S /etc/varnish/secret vcl.discard 20150311_ofaDrupal?2 No configuration named 20150311_ofaDrupal?2 known. Command failed with error code 106 varnishadm -T localhost:6082 -S /etc/varnish/secret vcl.discard 20150327?_maville360_3 No configuration named 20150327?_maville360_3 known. Command failed with error code 106 }}} Do you have an idea to do the discard ? Best regards, Vincent -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 9 11:41:42 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 09 Apr 2015 11:41:42 -0000 Subject: [Varnish] #1701: Bans keep increasing, despite ban lurker removing them Message-ID: <044.5cae992690f0e4f5183b9aae2c094e59@varnish-cache.org> #1701: Bans keep increasing, despite ban lurker removing them --------------------+-------------------- Reporter: rbartl | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.6 | Severity: normal Keywords: | --------------------+-------------------- We have a high number of bans hitting our varnish cache. After some time running varnish those bans dont get deleted anymore. n_ban is ever increasing, and n_ban_retire is not changing. But Varnish Log reports ExpBan (AFAIK this is a notice that a ban gets marked as complete) {{{ varnishlog | grep -i expban 38 ExpBan c 1971612403 was banned 61 ExpBan c 1971612483 was banned 32 ExpBan c 1971612438 was banned 35 ExpBan c 1971604741 was banned }}} Bans are increasing, and not retired -> {{{ varnishstat -1 | grep -i ban ; sleep 120 ; varnishstat -1 | grep -i ban :( n_ban 68391 . N total active bans n_ban_gone 11743 . N total gone bans n_ban_add 131903 14.37 N new bans added n_ban_retire 63512 6.92 N old bans deleted n_ban_obj_test 28425760 3097.16 N objects tested n_ban_re_test 3347374701 364717.23 N regexps tested against n_ban_dups 23818 2.60 N duplicate bans removed LCK.ban.creat 19 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 203959983 22222.70 Lock Operations LCK.ban.colls 0 0.00 Collisions n_ban 68913 . N total active bans n_ban_gone 12222 . N total gone bans n_ban_add 132425 14.24 N new bans added n_ban_retire 63512 6.83 N old bans deleted n_ban_obj_test 28466827 3061.61 N objects tested n_ban_re_test 3420460198 367870.53 N regexps tested against n_ban_dups 24041 2.59 N duplicate bans removed LCK.ban.creat 19 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 204014587 21941.77 Lock Operations LCK.ban.colls 0 0.00 Collisions }}} When i call ban.list in varnishadm varnish hangs and gets restarted by its watcher adm reports a 400 error) then the ban list is empty again of course. When does varnish "garbage"-collect the ban list ? Problem about this behaviour is that the ever increasing ban list is slowing down all requests. Regards, RB. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 9 13:16:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 09 Apr 2015 13:16:29 -0000 Subject: [Varnish] #1674: Debian: varnishncsa fails to start during boot In-Reply-To: <043.c33d34c6dbef7fb5306b98989678d5f6@varnish-cache.org> References: <043.c33d34c6dbef7fb5306b98989678d5f6@varnish-cache.org> Message-ID: <058.51cc14b407ac4d0d21f54b52b469800f@varnish-cache.org> #1674: Debian: varnishncsa fails to start during boot -----------------------+----------------------------------------------- Reporter: idl0r | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: | -----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [5f9ba61a92a03dbf502bb6dbc3eb4f1051f00780]: {{{ #!CommitTicketReference repository="" revision="5f9ba61a92a03dbf502bb6dbc3eb4f1051f00780" Enable -t option in the utilities Fixes: #1674 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 9 19:27:20 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 09 Apr 2015 19:27:20 -0000 Subject: [Varnish] #1700: objecthead counter incorrect or leaking on purge In-Reply-To: <045.948fd83162ebc4b65370db7c7d8df835@varnish-cache.org> References: <045.948fd83162ebc4b65370db7c7d8df835@varnish-cache.org> Message-ID: <060.300188e06bc3221fc62971922aa28b80@varnish-cache.org> #1700: objecthead counter incorrect or leaking on purge ----------------------+-------------------- Reporter: dward84 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by dward84): I believe I found the issue: in the file bin/varnishd/hash/hash_critbit.c at function hcb_deref(), shouldn't it be setting the return value to 0 if the reference count is 0? {{{ static int __match_proto__(hash_deref_f) hcb_deref(struct objhead *oh) { int r; r = 1; CHECK_OBJ_NOTNULL(oh, OBJHEAD_MAGIC); Lck_Lock(&oh->mtx); assert(oh->refcnt > 0); oh->refcnt--; if (oh->refcnt == 0) { Lck_Lock(&hcb_mtx); hcb_delete(&hcb_root, oh); VTAILQ_INSERT_TAIL(&cool_h, oh, hoh_list); Lck_Unlock(&hcb_mtx); assert(VTAILQ_EMPTY(&oh->objcs)); AZ(oh->waitinglist); } Lck_Unlock(&oh->mtx); #ifdef PHK fprintf(stderr, "hcb_defef %d %d <%s>\n", __LINE__, r, oh->hash); #endif return (r); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 9 19:56:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 09 Apr 2015 19:56:36 -0000 Subject: [Varnish] #1700: objecthead counter incorrect or leaking on purge In-Reply-To: <045.948fd83162ebc4b65370db7c7d8df835@varnish-cache.org> References: <045.948fd83162ebc4b65370db7c7d8df835@varnish-cache.org> Message-ID: <060.de36d8a7eae7254907faa3094125f7bb@varnish-cache.org> #1700: objecthead counter incorrect or leaking on purge ----------------------+-------------------- Reporter: dward84 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by dward84): After looking at this further, there doesn't appear to be a problem. I didn't realize that with the critbit hashing there was a background thread that cleans up these objects. Please close. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 10 09:37:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 10 Apr 2015 09:37:36 -0000 Subject: [Varnish] #1700: objecthead counter incorrect or leaking on purge In-Reply-To: <045.948fd83162ebc4b65370db7c7d8df835@varnish-cache.org> References: <045.948fd83162ebc4b65370db7c7d8df835@varnish-cache.org> Message-ID: <060.62b9255a58b96db9a1411bf324270500@varnish-cache.org> #1700: objecthead counter incorrect or leaking on purge ----------------------+---------------------- Reporter: dward84 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: invalid Keywords: | ----------------------+---------------------- Changes (by fgsch): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 10 09:38:21 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 10 Apr 2015 09:38:21 -0000 Subject: [Varnish] #1698: compressed objects over allocate when content-length is specified In-Reply-To: <045.02fe9abcb486afe8f5807f4d21b45896@varnish-cache.org> References: <045.02fe9abcb486afe8f5807f4d21b45896@varnish-cache.org> Message-ID: <060.1e0d57bc5ad7eeffbdda66735e7eb1fe@varnish-cache.org> #1698: compressed objects over allocate when content-length is specified ----------------------+------------------------ Reporter: dward84 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: duplicate Keywords: | ----------------------+------------------------ Changes (by fgsch): * status: new => closed * resolution: => duplicate -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 13 06:32:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Apr 2015 06:32:26 -0000 Subject: [Varnish] #1697: Discard a configuration with bad character is impossible In-Reply-To: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> References: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> Message-ID: <060.c8e61b06c004be964226f481b9fadd64@varnish-cache.org> #1697: Discard a configuration with bad character is impossible ------------------------+---------------------------------- Reporter: vrobert | Owner: Type: defect | Status: closed Priority: low | Milestone: Varnish 4.0 release Component: varnishadm | Version: 4.0.3 Severity: normal | Resolution: worksforme Keywords: discard | ------------------------+---------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Vincent, 0xC3 is only A+tilde in charactersets of the ISO8859 family, in UTF-8 it is 0x83 + 0xc3, and the "checkerboard" pattern indicates that your terminal is running UTF-8. That means that when you type in compose+A+tilde it does not match what varnish has stored. What you can try is something like: env LC_ALL=en_US.iso8859-1 xterm (or some other terminal program) If you run varnishadm in that xterm, the 0xc3 should be correctly shown as A+tilde, and if you type compose+A+tilde you should get 0xc3. That should allow you to vcl.discard the VCL programs. You should probably spend some time finding out how that strange character ended up there in the first place, and the explanation is very likely something along the same lines. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 13 06:59:58 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Apr 2015 06:59:58 -0000 Subject: [Varnish] #1699: Binding to port 80 fail. (privs dropped by then) In-Reply-To: <046.747e3a85f69108edabb6e39a9c1ffc98@varnish-cache.org> References: <046.747e3a85f69108edabb6e39a9c1ffc98@varnish-cache.org> Message-ID: <061.63ce235d357ec0c5143ff571f6f68cba@varnish-cache.org> #1699: Binding to port 80 fail. (privs dropped by then) ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: high | 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 [f03486b7e19ac45f60191b05f2e8562625f7a189]: {{{ #!CommitTicketReference repository="" revision="f03486b7e19ac45f60191b05f2e8562625f7a189" Raise jail privs around initial socket opening. Fixes #1699 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 13 07:39:57 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Apr 2015 07:39:57 -0000 Subject: [Varnish] #1697: Discard a configuration with bad character is impossible In-Reply-To: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> References: <045.e592b764f80a19b4c80257a8cd55750b@varnish-cache.org> Message-ID: <060.6b64c102b955b09ce55f66ef486125e8@varnish-cache.org> #1697: Discard a configuration with bad character is impossible ------------------------+---------------------------------- Reporter: vrobert | Owner: Type: defect | Status: closed Priority: low | Milestone: Varnish 4.0 release Component: varnishadm | Version: 4.0.3 Severity: normal | Resolution: worksforme Keywords: discard | ------------------------+---------------------------------- Comment (by vrobert): Hi Poul ! a big thanks for your response, I've put back my putty in ISO-8859-1 translation, then indeed the "A tilde" appears : {{{ [root at serv1]varnishadm -T localhost:6082 -S /etc/varnish/secret vcl.list available 0 20150311_ofaDrupal?2 available 0 20150327?_maville360_3 active 130 20150410_ofa }}} Then i changed the locale on the centos: {{{ [root at serv1]export LC_ALL=en_US.iso8859-1 [root at serv1]locale LANG=en_US.UTF-8 LC_CTYPE="en_US.iso8859-1" LC_NUMERIC="en_US.iso8859-1" LC_TIME="en_US.iso8859-1" LC_COLLATE="en_US.iso8859-1" LC_MONETARY="en_US.iso8859-1" LC_MESSAGES="en_US.iso8859-1" LC_PAPER="en_US.iso8859-1" LC_NAME="en_US.iso8859-1" LC_ADDRESS="en_US.iso8859-1" LC_TELEPHONE="en_US.iso8859-1" LC_MEASUREMENT="en_US.iso8859-1" LC_IDENTIFICATION="en_US.iso8859-1" LC_ALL=en_US.iso8859-1 }}} Then the discard command did the job: {{{ [root at serv1]varnishadm -T localhost:6082 -S /etc/varnish/secret vcl.discard 20150311_ofaDrupal?2 }}} The ticket can be closed. Best regards, Vincent -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 13 11:36:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Apr 2015 11:36:36 -0000 Subject: [Varnish] #1702: RHEL6 Init-script: startup errors piped to /dev/null Message-ID: <044.81cb7ae807b7e679852f34b4fe523747@varnish-cache.org> #1702: RHEL6 Init-script: startup errors piped to /dev/null ---------------------+----------------------- Reporter: denisb | Type: defect Status: new | Priority: normal Milestone: | Component: packaging Version: unknown | Severity: normal Keywords: | ---------------------+----------------------- On RHEL6 the init-script pipes stdout and stderr to /dev/null, which means that any startup-errors will be lost. It would in many cases be helpful to have these errors to a logfile. Current behaviour is easy to reproduce if you pass an invalid parameter to varnishd via DAEMON_OPTS in /etc/sysconfig/varnish -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 15 13:19:40 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Apr 2015 13:19:40 -0000 Subject: [Varnish] #1703: VLC_Log extended variables not showing in varnishncsa Message-ID: <042.579f0e373adbe340885b419265436e59@varnish-cache.org> #1703: VLC_Log extended variables not showing in varnishncsa -------------------+------------------------- Reporter: tjay | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 4.0.3 | Severity: normal Keywords: | -------------------+------------------------- I have just upgrade from varnish 3 to varnish 4.0.3 and it seems the varnishncsa daemon can no longer access the VCL_Log variables. I am running this on FreeBSD10.1-RELEASE and using the varnish4 port from pkg. '''VCL config''' {{{ std.log("backend_ip:" + beresp.backend.ip); std.log("backend_port:" + std.port(beresp.backend.ip)); }}} I can see this working in the varnishlog. '''varnishlog -i VCL_Log''' {{{ * << BeReq >> 163930 - VCL_Log backend_ip:10.2.1.23 - VCL_Log backend_port:80 }}} But this does not work when i run varnishncsa '''varnishncsa -F "%{VCL_Log:backendip}x:%{VCL_Log:backend_port}x"''' {{{ : : : : }}} '''Test case''' I have managed to replicate this on a brand new build FreeBSD and varnish4. This can be replicated with this vagrant test case. {{{ git clone https://github.com/tjayl/varnishvcllogbug.git }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 15 13:22:23 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Apr 2015 13:22:23 -0000 Subject: [Varnish] #1703: VLC_Log extended variables not showing in varnishncsa In-Reply-To: <042.579f0e373adbe340885b419265436e59@varnish-cache.org> References: <042.579f0e373adbe340885b419265436e59@varnish-cache.org> Message-ID: <057.62252039531174dbc8d50c9b87b8795d@varnish-cache.org> #1703: VLC_Log extended variables not showing in varnishncsa -------------------------+-------------------- Reporter: tjay | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 4.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by tjay): That should be: {{{ varnishncsa -F "%{VCL_Log:backend_ip}x:%{VCL_Log:backend_port}x" }}} not {{{ varnishncsa -F "%{VCL_Log:backendip}x:%{VCL_Log:backend_port}x" }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 15 23:10:07 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Apr 2015 23:10:07 -0000 Subject: [Varnish] #1704: fetch_failed not incremented Message-ID: <043.7d196a75b21578116bfbb31eaaec7a7e@varnish-cache.org> #1704: fetch_failed not incremented ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- fetch_failed description says "Fetch failed (all causes)" but the counter is not incremented for connect_timeout, first_byte_timeout or between_bytes_timeout timeouts. For connect_timeout timeout, backend_fail is increased though. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 16 13:48:14 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 16 Apr 2015 13:48:14 -0000 Subject: [Varnish] #1705: Bags under the eyes indicate Kidney system Supremia Anti Aging Formula Message-ID: <047.a0daf5b407e5286ced7522d7d29799c1@varnish-cache.org> #1705: Bags under the eyes indicate Kidney system Supremia Anti Aging Formula -----------------------------------------+-------------------- Reporter: Berryjoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: Supremia Anti Aging Formula | -----------------------------------------+-------------------- How can you fix it Fountainhead forward of all if you fuck whatsoever affective problems process through it with a professional a adviser therapist or someone within your faith. This is one move of getting to the remove spirited personality that shines through in iridescent eyes. It may hump a while to get there. Secondment you can bed Beauty Tip 2 Bags low Your Eyes Bags low the eyes represent [http://premiumpureforskolinrev.com /supremia-anti-aging-formula/ Supremia Anti Aging Formula] Kidney system base energy want blood stagnation or allergies. Respectively the solutions are to amount energy and belittle overwork get much movement and circulation; and undergo the allergy cause decimate it and strike anti- allergenic herbs and foods. The Kidney system strength is specific. If you overwork get too much sex or use more vigour than your digestive group can create youll dip into this constricted forcefulness fund. http://premiumpureforskolinrev.com/supremia-anti-aging-formula/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:33:46 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:33:46 -0000 Subject: [Varnish] #1706: Group Health Insurance Coverage Message-ID: <047.ccd139cae936997e2a4555443f19e90b@varnish-cache.org> #1706: Group Health Insurance Coverage -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- You are likely alive of the fact that there are galore choices in wellbeing contract today. The most general pick is certainly grouping wellbeing shelter reporting. Its affordable rates go a stressed way toward making this deciding the most nonclassical one disposable today. This is why galore employers engage meet eudaemonia protection coverage It is an excellent way to keep their employee radical. Meet welfare shelter amount is a real grievous goodness to employees Unit upbeat contract amount is an fantabulous mess cost wise When an employer is fit to do so it testament support fantabulous health protection sum for the employees. Because the playacting wants to keep the employees it instrument ofttimes take up a generous component of the outgo of radical health contract news. Oftentimes the activity give pay as more as eighty-five proportionality of the coverage leaving only fifteen pct as the employees responsibleness This is an excellent heap for the employee. http://www.skinphysiciantips.com/instant-wrinkle-repair/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:33:51 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:33:51 -0000 Subject: [Varnish] #1707: That there are many choices in health insurance Message-ID: <047.461e9b3661e8a18a562f0da7f0919df5@varnish-cache.org> #1707: That there are many choices in health insurance -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- The info of the reportage are paw up to the employer and the insurer. This is why two companies in the homophonic extent may individual the similar underwriter yet bed a contrastive radical eudaimonia protection amount programme. The employer chooses the benefit options it wants to ply for the employee. Commonly a wider show of coverage is useable under a foregather policy than you would see low close contract. The cerebrate for this is that the visor for group welfare contract reportage is shared among a large assort becomes hired by an employer who provides group wellbeing protection sum that employee can await to human the alternative of getting meet eudaimonia insurance amount. Of way this is certainly genuine in smaller businesses. In this soul all employees are healthy to get meet welfare protection reportage. http://www.healthsupreviews.com/dont-buy-perfect-garcinia-cambogia-until- you-read-this-review/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:33:58 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:33:58 -0000 Subject: [Varnish] #1708: Health insurance coverage is an excellent Message-ID: <047.55cb192490b854cc9cab01700f250175@varnish-cache.org> #1708: Health insurance coverage is an excellent -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Within large companies there may be departments that do not make operation to the aggroup eudaemonia contract coverage. A concern may terminate to back only duty organization for illustration. In this cover reparation people power not be ariled a pregnant period employee should be competent to get health protection reporting.Because the toll of meet welfare maintenance insurance news is rationed among all the employees of a companion it can be relied upon to remain stabilised. If one member of the unit becomes rattling ill and needs a lot of amount it may increase the rates of all the members slightly. This is in nonstop counterpoint to instances in which a human may love confidential sum and happen that his or her premiums increase speedily when earnest unhealthiness occurs. http://www.skinphysiciantips.com/perfect-garcinia-cambogia/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:34:05 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:34:05 -0000 Subject: [Varnish] #1709: The cost of group health insurance coverage Message-ID: <047.049dacc6590266a212e67312191621ae@varnish-cache.org> #1709: The cost of group health insurance coverage -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Clearly there are lots of very morality reasons for choosing to use group health contract sum. It is a sad fact notwithstanding that some fill do not someone gain to this help. There are a determine of slipway of exploit corresponding benefits though. For information fill who are consciousness working fill who learning at habitation or group who own their own businesses may be competent to get foregather health shelter coverage rates. http://www.skinphysiciantips.com/la-lumieres/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:34:19 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:34:19 -0000 Subject: [Varnish] #1710: Because the cost of group health care insurance Message-ID: <047.d617b88bff2f9817f6eb8eaff37db959@varnish-cache.org> #1710: Because the cost of group health care insurance -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- You may eff heard the constituent playacting of one. This is a fair new conception that is not distributed at this case. However it is development in popularity. In galore states if you are thoughtful a enterprise of one you may be healthy to get gather wellbeing shelter coverage rates. Other option is to restraint with various localized associations. One to which you already belong may render aggroup eudaemonia shelter news. Alternately you may determine and connect an connexion that offers this benefit. http://www.strongmenmuscle.com/revtest/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:34:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:34:26 -0000 Subject: [Varnish] #1711: Humana Health Fits Their Plan Message-ID: <047.e6fd519f03cb69ca7195f6824c24ee78@varnish-cache.org> #1711: Humana Health Fits Their Plan -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Humana Upbeat Shelter Organisation is one of the person wellbeing insurance providers in the Collective States. The present why they are one of the superfine companies around is because they visage to see what their clients rattling penury and pay it to them. Humana Waste Contract is available in virtually every utter and modify in Puerto Rico which gives fill hunt for eudaimonia contract a wide potentiality of places to appear. They act numerous divers types of health protection plans but al superficial for a upbeat contract mean that offers inexpensive rates as compartment as low-cost deductibles Humana Health may be the paw organization for you. They congratulate themselves with their salient plans for both individuals as rise as groups. http://www.strongmenmuscle.com/perfect-garcinia-cambogia/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:34:35 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:34:35 -0000 Subject: [Varnish] #1712: Health Insurance Company is one of the best Message-ID: <047.89e943850ffb7d8266e06f0cd03f56a7@varnish-cache.org> #1712: Health Insurance Company is one of the best -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Oftentimes these days group are not offered everything they require in a welfare contract design from their employer which agency that they may possess to acquire a wellbeing shelter organization in improver to the forgather contract that they find. This oftentimes happens with Humana Welfare because with this reserves you can settle just what you requirement from the most specific organisation to a intend that exceeds flat your expectations when it comes to eudaimonia fixture. It all really depends on how overmuch you are voluntary to spend on a design. If you are pretty firm and do not go to the doctor real such or rarely gets medication drug you can let power visits so that you wonot be paid money for something you do not necessity, which would give you a very low reward because you would not be paying for the staff visits. http://premiumpureforskolinrev.com/revtest/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:34:44 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:34:44 -0000 Subject: [Varnish] #1713: Another thing that Humana Health is Message-ID: <047.8d6cc91a0e145e2dbe73efef83aa48ac@varnish-cache.org> #1713: Another thing that Humana Health is -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- At the said measure if you mortal kids you would be healthier off feat a organisation that includes power visits, as we cognise kids are e'er getting sick and you would be fitter off paid for visits than remunerative out of your steal.Added abstraction that Humana Health is very nice at is their consumer run. Period after twelvemonth they feature been hierarchic in the top 10 for client care and when it comes to barren upkeep you poorness a companion that takes customer pair earnestly. Not only is there a figure you can label at nigh all hours of the day but if you go online you can conceptualize out nearly anything you requirement to undergo active your poverty there is an e-mail direction for you to ask any added questions. http://www.strongmenmuscle.com/biomuscle-xr/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:34:52 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:34:52 -0000 Subject: [Varnish] #1714: Do Not Look To Far, Great Deals Through Humana Health Message-ID: <047.115d2f426650dd1fed977b572b451ee6@varnish-cache.org> #1714: Do Not Look To Far, Great Deals Through Humana Health -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Fresh it has been tall for group to get upbeat shelter reportage that is cheap. With the recent deprivation of jobs and the worsening in the system galore group fuck recovered themselves disagreeable to piss the action between providing the virtual things for their lineage and providing their phratry with cheap wellbeing contract and normally upbeat insurance does not win. Unfortunately this can end up backfiring if a precious one gets displeased or abraded. Umteen grouping do not train into record how valuable examination bills can be without eudaimonia protection which is unremarkably the get nonindulgent repercussions that can crusade uncastrated families to person to record for insolvency mainly because something as linear car accident can fuck medical bills that can be extremely overpriced without upbeat protection. http://www.skinphysiciantips.com/rapid-repair-eye-serum/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:34:58 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:34:58 -0000 Subject: [Varnish] #1715: Recently it has been difficult for people to get health Message-ID: <047.2c3a88900f1958e8330596156db2ea7d@varnish-cache.org> #1715: Recently it has been difficult for people to get health -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- This is why you bed to reach a eudaemonia contract companionship that has an cheap plan equivalent Humana Welfare Shelter. With Humana Eudaemonia Insurance you gift be healthy to hear a idea that top fits your clan whet individualistic health shelter system or regularize a temporary eudaimonia shelter idea that leave amend you during your instance of require. Erst you terminate to purchase a wellbeing contract design you penury to advantage shopping for one that gift best fit your needs. One of the optimal slipway to do this is by perception online for a intend that module ply you during your second of pauperization. http://premiumpureforskolinrev.com/metabo-garcinia/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:35:06 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:35:06 -0000 Subject: [Varnish] #1716: Once you decide to purchase a health insurance Message-ID: <047.527807f0b7e5dbe27d67ccbb3ad7da7b@varnish-cache.org> #1716: Once you decide to purchase a health insurance -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- There are many contrasting plans through each antithetic typewrite of wellbeing contract accompany for you to looking at. Dungeon in intellect that virtuous because it is the smallest overpriced mean does not meant that unsurpassed counsel every organisation is incompatible and you should rest this in watch. When you finally get your eyes set on a upbeat shelter militia equal Humana Wellbeing Shelter meet the reserves and ask them several questions virtually the project you requirement without starring on that you want to purchase protection from them Get an design of what their consumer couple is same and form certain that they excrete you experience very prosperous conversation to them almost your eudaemonia mending. http://www.strongmenmuscle.com/pure-moringa-slim/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:35:12 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:35:12 -0000 Subject: [Varnish] #1717: The Insurance Plan You Want With Humana Health Message-ID: <047.32f768609d24d2ad36ae764b66e7c03f@varnish-cache.org> #1717: The Insurance Plan You Want With Humana Health -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- There are numerous fill in the Incorporate States today that do not read why the outgo of welfare shelter is so valuable. They do not realise why they are paid hundreds of dollars each period to get peritrichous for eudaimonia costs that they may not alter use. Often when people terminate to buy health protection they are obligated to bracing under sicken with the companionship for a definite period with the choice to employ the stop when the contract is up. One of the things that group seem to grow most preventive nigh the expenditure of upbeat protection is the piercing why most grouping are charged broad monthly reward for services they may not straight use is because welfare repair is really overpriced today. http://nitroshredadvice.com/perfect-garcinia-cambogia/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:35:21 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:35:21 -0000 Subject: [Varnish] #1718: The cost of health insurance is so expensive Message-ID: <047.43218e5a19cff38814155d13ca1d3434@varnish-cache.org> #1718: The cost of health insurance is so expensive -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- There are two important reasons why the monthly premiums can be so overpriced. The best primary reason and likely the most axiomatic is that the value of medicament today is valuable. Wellbeing insurance companies tally to make their monthly premiums treble so they are fit to pay for the expenditure of guardianship for the people who poverty it. New medicines and vaccinations are being matured every day and in graduate costs of theses medicines monthly premiums are obligatory. Companies hold to be winning in many money than they are spending and in magnitude for them to firing the doomed fill who need to compile on their welfare protection claims. http://premiumpureforskolinrev.com/t-advance/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:35:27 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:35:27 -0000 Subject: [Varnish] #1719: Another reason why health insurance premiums Message-ID: <047.7eedbf452557bac6c6e793bfd9ec625b@varnish-cache.org> #1719: Another reason why health insurance premiums -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Another sanity why eudaimonia insurance premiums are traditionally advanced is because the value of administering meliorate when capital accidents or illnesses become is also an pricy expenditure to garment. Conscionable the cost for an ambulance to mean to a set of an accident and create an soul to the hospital can outlay a brace century dollars that more fill may not be able to afford without welfare protection, which is why they acquire health insurance to guarantee these alto contract can be offered tho and employer or purchased inaccurate convert through an someone programme or a ancestry counselling. http://premiumpureforskolinrev.com/muscle-rev-xtreme/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:35:35 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:35:35 -0000 Subject: [Varnish] #1720: Health insurance can be offered though and Message-ID: <047.afc622d3316a211e6c11a9e0cd0d5153@varnish-cache.org> #1720: Health insurance can be offered though and -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- There are whatsoever companies out there equal Humana Eudaemonia that present be able to give you zealous low monthly premiums with all of the reporting that you poorness from a welfare shelter fellowship. At Humana Wellbeing there are options for both traditional plans as fortunate as non-traditional plans so whether you are sensing for a plan honorable for yourself a drawing for your full troupe or a house consumer pair information. If you individual a oppugn at any abstraction about your upbeat contract program you give be competent to song Humana Wellbeing and get your questions answered forthwith without any worries. http://www.strongmenmuscle.com/drill-pill/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:35:42 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:35:42 -0000 Subject: [Varnish] #1721: Home Health Assessment Message-ID: <047.6764b87f42e5b7d9c7930914ebf356aa@varnish-cache.org> #1721: Home Health Assessment -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Todays way of an single invariably leads to long-term modification to welfare. Safekeeping Upbeat is Wealthiness in cognition Puddle Me Rubicund offers one of the most universal obviating wellbeing anxiety programs for earliest detection of style diseases. The goal of our health categorization idea is to meliorate grouping to whippy yearner & better lives. Our welfare checks program gives you mismatched benefits as compared to opposite health classification papers in this business.Our welfare classification thought is intentional for those families who smouldering in really hectic fashion and are neglecting there eudaimonia issues or are not fit to grip their welfare needs as efficiently and in a timely demeanor as they should. http://www.musclegainhelp.com/elite- test-360/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 18 14:35:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 18 Apr 2015 14:35:48 -0000 Subject: [Varnish] #1722: Diseases cannot be cured, the only way to live a healthy Message-ID: <047.c61cbf2483f4b40dc527064d0233af14@varnish-cache.org> #1722: Diseases cannot be cured, the only way to live a healthy -----------------------+-------------------- Reporter: Mariajoy1 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -----------------------+-------------------- Our wellbeing categorization info takes attention of varied health management needs for those families or individuals or corporate customers.We pair you are gushing against moment & inactivity in queues at the doctor's clinic labs are rattling torturesome have But what if theologist and labs came to you in the ministration of your accommodation at a quantify of your suitability? Represent Me Levelheaded with its USP health at home or @workplace motion the accord at their richness place at location with elated school characteristic equipment enabled with wear means GPRS engineering and thusly conducts the living call diseases such as diabetes nerve disease and respiratory diseases etc. http://www.musclegainhelp.com/testostorm/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 22 14:50:11 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 22 Apr 2015 14:50:11 -0000 Subject: [Varnish] #1703: VLC_Log extended variables not showing in varnishncsa In-Reply-To: <042.579f0e373adbe340885b419265436e59@varnish-cache.org> References: <042.579f0e373adbe340885b419265436e59@varnish-cache.org> Message-ID: <057.4364a86c7a2004a7c9eeab501f079c09@varnish-cache.org> #1703: VLC_Log extended variables not showing in varnishncsa -------------------------+-------------------- Reporter: tjay | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 4.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by aondio): Hi, each log line in varnishncsa is based on a single (client)request, this means that varnishncsa has access to the VCL_Log variables, but you'll have a visible output only if the VCL_Log variable comes from a (client)request. "Non-request transactions are ignored" from varnishncsa man page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 22 14:51:05 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 22 Apr 2015 14:51:05 -0000 Subject: [Varnish] #1703: VLC_Log extended variables not showing in varnishncsa In-Reply-To: <042.579f0e373adbe340885b419265436e59@varnish-cache.org> References: <042.579f0e373adbe340885b419265436e59@varnish-cache.org> Message-ID: <057.060a85a151b85b7dcd25fc4dd3487d5f@varnish-cache.org> #1703: VLC_Log extended variables not showing in varnishncsa -------------------------+---------------------- Reporter: tjay | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 4.0.3 Severity: normal | Resolution: wontfix Keywords: | -------------------------+---------------------- Changes (by aondio): * status: new => closed * resolution: => wontfix -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 24 15:01:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 24 Apr 2015 15:01:26 -0000 Subject: [Varnish] #1723: High CPU load and exponential peak of objects in a281a10 Message-ID: <055.a2a864aec40e58c05df529f7335d48da@varnish-cache.org> #1723: High CPU load and exponential peak of objects in a281a10 ---------------------------------+---------------------- Reporter: zaterio@? | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: trunk | Severity: major Keywords: load objects | ---------------------------------+---------------------- I am using varnishd (varnish-trunk review a281a10), with 2 storage backends: ram1: default storage (malloc, 8GB) vod1: only for mp4 files (file, 50 GB) in vcl_backend_response, whe have the following rule: set beresp.storage_hint = "ram1"; set beresp.http.x-storage = "ram1"; if (bereq.url ~ "\.mp4$") { set beresp.storage_hint = "vod1"; set beresp.http.x-storage = "vod1"; set beresp.do_stream = true; set beresp.ttl = 10h; set beresp.http.Cache-Control = "max-age=604800, public"; set beresp.do_esi = true; return (deliver); } On this machine we have traffic peaks of 1 Gbits, but yesterady we accomodate new service and trafic increased to 2 Gbps. In this situation, every 30 min, the load increases, up to 100 (5 minutes), and MAIN.n_objectcore and MAIN.n_objecthead rises to 16970000000000 (normal is 5.5k), and then uptime returns to 0, and load decreases. We have another server with identical hardware and varnish configuration (but more traffic, 5Gbps), This server does not have the above described behavior, this server is running varnish-trunk revision 7746e30. Whe downgrade the problematic machine from a281a10 to 7746e30 and after 10 hours looks normal. DAEMON_OPTS="-a XXX.XXX.XXX.XXX:80, \ -T XXX:XXX:XXX:XXX:6082 \ -f /etc/varnish/default.vcl \ -h classic,16383 \ -s ram1=malloc,8G \ -s vod1=file,/varnishcache/varnish.bin,50G \ -p thread_pools=2 \ -p thread_pool_min=500 \ -p thread_pool_max=3000 \ -p thread_pool_add_delay=2 \ -p auto_restart=on \ -p ping_interval=3 \ -p send_timeout=5000 \ -p workspace_session=1M \ -p cli_timeout=25 \ -p http_gzip_support=off \ -p tcp_keepalive_time=600 \ -p listen_depth=8192 \ -p cli_buffer=32k \ -p cli_limit=96k \ -p ban_dups=on" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 24 18:39:28 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 24 Apr 2015 18:39:28 -0000 Subject: [Varnish] #1723: High CPU load and exponential peak of objects in a281a10 In-Reply-To: <055.a2a864aec40e58c05df529f7335d48da@varnish-cache.org> References: <055.a2a864aec40e58c05df529f7335d48da@varnish-cache.org> Message-ID: <070.171c1ba4cee5ecc5ac6c6c87ff34b031@varnish-cache.org> #1723: High CPU load and exponential peak of objects in a281a10 --------------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: load objects | --------------------------+---------------------------------- Old description: > I am using varnishd (varnish-trunk review a281a10), with 2 storage > backends: > ram1: default storage (malloc, 8GB) > vod1: only for mp4 files (file, 50 GB) > > in vcl_backend_response, whe have the following rule: > > set beresp.storage_hint = "ram1"; > set beresp.http.x-storage = "ram1"; > > if (bereq.url ~ "\.mp4$") > { > set beresp.storage_hint = "vod1"; > set beresp.http.x-storage = > "vod1"; > set beresp.do_stream = true; > set beresp.ttl = 10h; > set beresp.http.Cache-Control = > "max-age=604800, public"; > set beresp.do_esi = true; > return (deliver); > } > > On this machine we have traffic peaks of 1 Gbits, but yesterady we > accomodate new service and trafic increased to 2 Gbps. > > In this situation, every 30 min, the load increases, up to 100 (5 > minutes), and MAIN.n_objectcore and > MAIN.n_objecthead rises to 16970000000000 (normal is 5.5k), and then > uptime returns to 0, and load decreases. > > We have another server with identical hardware and varnish configuration > (but more traffic, 5Gbps), This server does not have the above described > behavior, this server is running varnish-trunk revision 7746e30. > Whe downgrade the problematic machine from a281a10 to 7746e30 and after > 10 hours looks normal. > > DAEMON_OPTS="-a XXX.XXX.XXX.XXX:80, \ > -T XXX:XXX:XXX:XXX:6082 \ > -f /etc/varnish/default.vcl \ > -h classic,16383 \ > -s ram1=malloc,8G \ > -s vod1=file,/varnishcache/varnish.bin,50G \ > -p thread_pools=2 \ > -p thread_pool_min=500 \ > -p thread_pool_max=3000 \ > -p thread_pool_add_delay=2 \ > -p auto_restart=on \ > -p ping_interval=3 \ > -p send_timeout=5000 \ > -p workspace_session=1M \ > -p cli_timeout=25 \ > -p http_gzip_support=off \ > -p tcp_keepalive_time=600 \ > -p listen_depth=8192 \ > -p cli_buffer=32k \ > -p cli_limit=96k \ > -p ban_dups=on" New description: I am using varnishd (varnish-trunk review a281a10), with 2 storage backends: ram1: default storage (malloc, 8GB) vod1: only for mp4 files (file, 50 GB) in vcl_backend_response, whe have the following rule: {{{ set beresp.storage_hint = "ram1"; set beresp.http.x-storage = "ram1"; if (bereq.url ~ "\.mp4$") { set beresp.storage_hint = "vod1"; set beresp.http.x-storage = "vod1"; set beresp.do_stream = true; set beresp.ttl = 10h; set beresp.http.Cache-Control = "max-age=604800, public"; set beresp.do_esi = true; return (deliver); } }}} On this machine we have traffic peaks of 1 Gbits, but yesterady we accomodate new service and trafic increased to 2 Gbps. In this situation, every 30 min, the load increases, up to 100 (5 minutes), and MAIN.n_objectcore and MAIN.n_objecthead rises to 16970000000000 (normal is 5.5k), and then uptime returns to 0, and load decreases. We have another server with identical hardware and varnish configuration (but more traffic, 5Gbps), This server does not have the above described behavior, this server is running varnish-trunk revision 7746e30. Whe downgrade the problematic machine from a281a10 to 7746e30 and after 10 hours looks normal. {{{ DAEMON_OPTS="-a XXX.XXX.XXX.XXX:80, \ -T XXX:XXX:XXX:XXX:6082 \ -f /etc/varnish/default.vcl \ -h classic,16383 \ -s ram1=malloc,8G \ -s vod1=file,/varnishcache/varnish.bin,50G \ -p thread_pools=2 \ -p thread_pool_min=500 \ -p thread_pool_max=3000 \ -p thread_pool_add_delay=2 \ -p auto_restart=on \ -p ping_interval=3 \ -p send_timeout=5000 \ -p workspace_session=1M \ -p cli_timeout=25 \ -p http_gzip_support=off \ -p tcp_keepalive_time=600 \ -p listen_depth=8192 \ -p cli_buffer=32k \ -p cli_limit=96k \ -p ban_dups=on" }}} -- Comment (by phk): Can you try "varnishadm panic.show" and send us the output ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 07:59:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 07:59:48 -0000 Subject: [Varnish] #1704: fetch_failed not incremented In-Reply-To: <043.7d196a75b21578116bfbb31eaaec7a7e@varnish-cache.org> References: <043.7d196a75b21578116bfbb31eaaec7a7e@varnish-cache.org> Message-ID: <058.ee09302093bba13633ba02437bff9179@varnish-cache.org> #1704: fetch_failed not incremented ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): So what do we actually mean by "failed" these days ? I think the code currently implements "failed is when vcl_backend_error{} is not called" That seems useful to know at some level, but I'm not sure if this argues for having two counters (fail w/error and fail wo/error), or just changing the description of the one counter (fail wo/error) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 08:02:13 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 08:02:13 -0000 Subject: [Varnish] #1606: Assert error in VDI_Finish(), cache/cache_director.c line 120: In-Reply-To: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org> References: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org> Message-ID: <064.68dfa563d4bc34812ef6c4b3ae3f232e@varnish-cache.org> #1606: Assert error in VDI_Finish(), cache/cache_director.c line 120: -------------------------+--------------------- Reporter: cache_layer | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: timing this ticket out -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 08:03:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 08:03:55 -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.b2b02c73e2a407422eac8de1effa501e@varnish-cache.org> #1187: Document restrictions on range requests ---------------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+----------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: With the advent of VDP's range should also work in this scenario. If not, that is a new bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 08:05:39 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 08:05:39 -0000 Subject: [Varnish] #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon In-Reply-To: <043.db2ab567f1ed05ba57f00e57b891cb67@varnish-cache.org> References: <043.db2ab567f1ed05ba57f00e57b891cb67@varnish-cache.org> Message-ID: <058.d78aa460f2c59b4e2b1a986383ce4724@varnish-cache.org> #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon --------------------+------------------------- Reporter: fgsch | Owner: fgsch 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: timed out -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 08:09:50 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 08:09:50 -0000 Subject: [Varnish] #1192: RHEL6: Init-script not giving correct startup In-Reply-To: <044.184ff331e3ed28f8eba95a1c3e7eeaf7@varnish-cache.org> References: <044.184ff331e3ed28f8eba95a1c3e7eeaf7@varnish-cache.org> Message-ID: <059.3f66be0620f02aeef2f22eaead9b512a@varnish-cache.org> #1192: RHEL6: Init-script not giving correct startup ----------------------+------------------------- Reporter: Ueland | Owner: ingvar Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: timing this ticket out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 08:12:56 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 08:12:56 -0000 Subject: [Varnish] #1656: do_stream is backend request specific and not client request specific In-Reply-To: <051.4f08cd066507dd8d65e34b4c0182acc8@varnish-cache.org> References: <051.4f08cd066507dd8d65e34b4c0182acc8@varnish-cache.org> Message-ID: <066.0812a0f37ad60946efda2570cae94b50@varnish-cache.org> #1656: do_stream is backend request specific and not client request specific ---------------------------+------------------------- Reporter: imoverclocked | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: major | Resolution: worksforme Keywords: | ---------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This is a problem that should be fixed on the client side of things, and more of a feature request than a ticket anyway. I'm closing this ticket, but feel free to add this to a future_ wikipage so we don't forget. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 08:16:13 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 08:16:13 -0000 Subject: [Varnish] #1520: m00011.vtc fails on OSX x86_64 In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.d87a1aeffb42b629cd0a9b604a731552@varnish-cache.org> #1520: m00011.vtc fails on OSX x86_64 -------------------------+------------------------- Reporter: yoloseem | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 4.0.2 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Timing this ticket out -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 08:18:50 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 08:18:50 -0000 Subject: [Varnish] #1663: Both chmod 0755 and chown mgmt.uid used In-Reply-To: <048.6c04e642e3b0b687751b8da68f22ad7a@varnish-cache.org> References: <048.6c04e642e3b0b687751b8da68f22ad7a@varnish-cache.org> Message-ID: <063.0fd3b0db83608e1b919523d01f8e2489@varnish-cache.org> #1663: Both chmod 0755 and chown mgmt.uid used ------------------------+--------------------- Reporter: puiterwijk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: The entire priv-sep/jail thing has had an overhaul, and I *think* that addresses this issue as well. Please test -trunk and reopen this ticket if not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 14:51:20 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 14:51:20 -0000 Subject: [Varnish] #1675: Condition((vbc->in_waiter) != 0) not true. In-Reply-To: <055.b51225add9ab2ac387171d437c0aea93@varnish-cache.org> References: <055.b51225add9ab2ac387171d437c0aea93@varnish-cache.org> Message-ID: <070.311e1abf43d8740452454aa91902a5ee@varnish-cache.org> #1675: Condition((vbc->in_waiter) != 0) not true. ----------------------------------+---------------------------------- Reporter: zaterio@? | Owner: phk Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: in_waiter tcp_handle | ----------------------------------+---------------------------------- Comment (by lkarsten): Hit this one today, on an installation with almost no traffic. Not seeing it on any of the fryer runs. {{{ Last panic at: Mon, 27 Apr 2015 14:26:37 GMT Assert error in tcp_handle(), cache/cache_backend_tcp.c line 94: Condition((vbc->in_waiter) != 0) not true. thread = (cache-epoll) version = varnish-trunk revision 6e7c5cf ident = Linux,3.13.0-49-generic,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x439dc5: pan_backtrace+0x19 0x43a1ad: pan_ic+0x299 0x414226: tcp_handle+0x12e 0x4794d8: Wait_Handle+0x2b3 0x479c2d: vwe_eev+0xde 0x479dee: vwe_thread+0x11b 0x7f7060a9e182: libpthread.so.0(+0x8182) [0x7f7060a9e182] 0x7f70607cb47d: libc.so.6(clone+0x6d) [0x7f70607cb47d] }}} upgraded it to latest master. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 15:58:40 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 15:58:40 -0000 Subject: [Varnish] #1704: fetch_failed not incremented In-Reply-To: <043.7d196a75b21578116bfbb31eaaec7a7e@varnish-cache.org> References: <043.7d196a75b21578116bfbb31eaaec7a7e@varnish-cache.org> Message-ID: <058.f5dd5ad8ff63b4568e87da791bed8dd5@varnish-cache.org> #1704: fetch_failed not incremented ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): I guess there are two issues here: 1. the description incorrectly implying that the counter should be incremented 2. the fact the any errors other than connect_timeout are not be logged We probably need to address both in one way or another. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:16:57 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:16:57 -0000 Subject: [Varnish] #1724: no backend connection logged multiple times Message-ID: <043.9fdf3a72c0356475ff54e937934daaae@varnish-cache.org> #1724: no backend connection logged multiple times --------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- The current code will log "no backend connection" multiple times. For example see tests/c00028.vtc output. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:25:19 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:25:19 -0000 Subject: [Varnish] #1725: backend_conn is no longer incremented Message-ID: <043.78e7f027254fb82cf2802850327b40a2@varnish-cache.org> #1725: backend_conn is no longer incremented --------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- backend_conn was lost during the backend code rewrite. We should bring the counter back. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:27:02 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:27:02 -0000 Subject: [Varnish] #1724: no backend connection logged multiple times In-Reply-To: <043.9fdf3a72c0356475ff54e937934daaae@varnish-cache.org> References: <043.9fdf3a72c0356475ff54e937934daaae@varnish-cache.org> Message-ID: <058.b1af502a44e815a709b622e3874e4f05@varnish-cache.org> #1724: no backend connection logged multiple times ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by fgsch): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:27:15 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:27:15 -0000 Subject: [Varnish] #1725: backend_conn is no longer incremented In-Reply-To: <043.78e7f027254fb82cf2802850327b40a2@varnish-cache.org> References: <043.78e7f027254fb82cf2802850327b40a2@varnish-cache.org> Message-ID: <058.7b4fa11745363742c8aa69d70b62067c@varnish-cache.org> #1725: backend_conn is no longer incremented ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by fgsch): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:33:00 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:33:00 -0000 Subject: [Varnish] #1726: backend_toolate no longer used Message-ID: <043.842e036ecb4f153f9d14ef128269f440@varnish-cache.org> #1726: backend_toolate no longer used --------------------+--------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- This counter was lost during the new backend rewrite. That said it might not make sense anymore in the current world. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:33:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:33:29 -0000 Subject: [Varnish] #1726: backend_toolate no longer used In-Reply-To: <043.842e036ecb4f153f9d14ef128269f440@varnish-cache.org> References: <043.842e036ecb4f153f9d14ef128269f440@varnish-cache.org> Message-ID: <058.4c0c724c104af5dff689faf27c399fb9@varnish-cache.org> #1726: backend_toolate no longer used ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by fgsch): * version: unknown => trunk * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:52:46 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:52:46 -0000 Subject: [Varnish] #1662: BereqProtocol showing twice for HTTP 1.0 requests In-Reply-To: <043.cd65aaf168b645e5087eb24ca7cc84b1@varnish-cache.org> References: <043.cd65aaf168b645e5087eb24ca7cc84b1@varnish-cache.org> Message-ID: <058.3c2081e5e9cad0c3dc97fdeb0b1965e2@varnish-cache.org> #1662: BereqProtocol showing twice for HTTP 1.0 requests --------------------+--------------------- Reporter: fgsch | Owner: aondio Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+--------------------- Comment (by fgsch): After further thinking I'm not convinced reusing xxxUnset is the right way to go. [[br]] This could be considered as something coming from VCL when it's not the case. Ideally varnish should only log things once. The current logging code however have tentacles here and there, making logging at specific places very difficult without changes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 27 16:57:43 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Apr 2015 16:57:43 -0000 Subject: [Varnish] #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f In-Reply-To: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> References: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> Message-ID: <058.9ec0972a77ab12865cc0307dfad241b0@varnish-cache.org> #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f ----------------------+-------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): Do we want to do anything about this? I think changing vcl_hit{} to go to vcl_backend_fetch{} makes sense but I appreciate this could break anyone depending on vcl_hit{} going to vcl_miss{} on `return(fetch)`. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 28 09:07:08 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Apr 2015 09:07:08 -0000 Subject: [Varnish] #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f In-Reply-To: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> References: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> Message-ID: <058.d7a3a3f451989e3c994e476c069fee31@varnish-cache.org> #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f ----------------------+---------------------------------------- Reporter: slink | 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 [a27af9f8f286f1d7a38b91928426685a1f33493f]: {{{ #!CommitTicketReference repository="" revision="a27af9f8f286f1d7a38b91928426685a1f33493f" Fix an oversight: The correct and systematic thing is for vcl_hit{} to return(miss) rather than return(fetch). For now return(fetch) is still allowed, we don't want to bump vcl version for something this trivial, but it emits a SLT_VCL_Error urging people to change their VCL. Fixes #1603 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 28 09:44:41 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Apr 2015 09:44:41 -0000 Subject: [Varnish] #1609: Reset MGT.child_panic after a panic.clear In-Reply-To: <046.f6154daa50f9ea4015af5bbbbd99f173@varnish-cache.org> References: <046.f6154daa50f9ea4015af5bbbbd99f173@varnish-cache.org> Message-ID: <061.b2c35f50507036e60dae8762178e816d@varnish-cache.org> #1609: Reset MGT.child_panic after a panic.clear -------------------------+--------------------- Reporter: coredump | Owner: fgsch Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Comment (by razvanphp): Should I create a new ticket for my request in the comment below? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 28 10:06:16 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Apr 2015 10:06:16 -0000 Subject: [Varnish] #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f In-Reply-To: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> References: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> Message-ID: <058.65fe676c9660483e015a7aceb2cc74a5@varnish-cache.org> #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f ----------------------+---------------------------------------- Reporter: slink | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Nils Goroll ): In [d454fc1a2675844fa2c5b015a5b4cf0bfdbc9730]: {{{ #!CommitTicketReference repository="" revision="d454fc1a2675844fa2c5b015a5b4cf0bfdbc9730" Typo Fixes #1603 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 28 10:14:02 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Apr 2015 10:14:02 -0000 Subject: [Varnish] #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f In-Reply-To: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> References: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org> Message-ID: <058.e88d188025c2095806ff75d75f7592c7@varnish-cache.org> #1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to backend / v_b_f ----------------------+---------------------------------------- Reporter: slink | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Nils Goroll ): In [bf5e38e60b8dbba055ccdea6a3d90b977302e1fd]: {{{ #!CommitTicketReference repository="" revision="bf5e38e60b8dbba055ccdea6a3d90b977302e1fd" Update docs: vcl_hit{} return(miss) Fixes #1603 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 28 13:49:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Apr 2015 13:49:29 -0000 Subject: [Varnish] #1727: Incorrect field ordering in PROXY1 parser Message-ID: <043.baf3e0bfc9030e6b39fd9713f239297e@varnish-cache.org> #1727: Incorrect field ordering in PROXY1 parser ----------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Ran into this issue in master while playing around with a PROXY1-capable TLS terminator. Current Varnish master expects a PROXY1 header line that doesn't quite agree with the spec: {{{ PROXY TCPx src-addr src-port dst-addr dst-port\r\n }}} whereas PROXY spec is {{{ PROXY TCPx src-addr dst-addr src-port dst-port\r\n }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 28 14:14:14 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Apr 2015 14:14:14 -0000 Subject: [Varnish] #1727: Incorrect field ordering in PROXY1 parser In-Reply-To: <043.baf3e0bfc9030e6b39fd9713f239297e@varnish-cache.org> References: <043.baf3e0bfc9030e6b39fd9713f239297e@varnish-cache.org> Message-ID: <058.6de940dbc8b3c255343850150180ba4f@varnish-cache.org> #1727: Incorrect field ordering in PROXY1 parser ----------------------+---------------------------------------- Reporter: daghf | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [22004936371ff45d3cbdb8feffdcd88994dd2090]: {{{ #!CommitTicketReference repository="" revision="22004936371ff45d3cbdb8feffdcd88994dd2090" Get the field order right for PROXYv1 Fixes #1727 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 29 09:23:21 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Apr 2015 09:23:21 -0000 Subject: [Varnish] #1728: PROXYv1: Assert error in SES_RxReq(), cache/cache_session.c line 282:\n Message-ID: <043.7930decf4da5cb68f9b317744080b783@varnish-cache.org> #1728: PROXYv1: Assert error in SES_RxReq(), cache/cache_session.c line 282:\n ----------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Ran into another issue related to PROXYv1. If the size of the received data exceeds the maximum size of a PROXYv1 header, we crash. This also happens in the case when the PROXYv1 header is correct, but a following HTTP request received in the same packet puts it over the maximum PROXYv1 size limit. {{{ *** v1 7.5 debug| Assert error in SES_RxReq(), cache/cache_session.c line 282:\n *** v1 7.5 debug| Condition(hs == HTC_S_EMPTY) not true.\n *** v1 7.5 debug| thread = (cache-worker)\n *** v1 7.5 debug| version = varnish-trunk revision ddabce6\n *** v1 7.5 debug| ident = Linux,3.16.0-4-amd64,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,epoll\n *** v1 7.5 debug| Backtrace:\n *** v1 7.5 debug| 0x44d0b9: pan_backtrace+0x19\n *** v1 7.5 debug| 0x44ced9: pan_ic+0x329\n *** v1 7.5 debug| 0x45c1b1: SES_RxReq+0x5e1\n *** v1 7.5 debug| 0x495f32: VPX_Proto_Sess+0x182\n *** v1 7.5 debug| 0x450760: Pool_Work_Thread+0x6d0\n *** v1 7.5 debug| 0x474542: WRK_Thread+0x332\n *** v1 7.5 debug| 0x452073: pool_thread+0xd3\n *** v1 7.5 debug| 0x7efc2b4770a4: libpthread.so.0(+0x80a4) [0x7efc2b4770a4]\n *** v1 7.5 debug| 0x7efc2b1ac04d: libc.so.6(clone+0x6d) [0x7efc2b1ac04d]\n }}} (the value of 'hs' is HTC_S_OVERFLOW, returned from vpx_complete()) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 29 09:44:41 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Apr 2015 09:44:41 -0000 Subject: [Varnish] #1642: Assert error in VGZ_Ibuf() In-Reply-To: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> References: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> Message-ID: <060.f2e249ca7e9afead97bb231035de0952@varnish-cache.org> #1642: Assert error in VGZ_Ibuf() --------------------------+--------------------- Reporter: llavaud | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: assert error | --------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [238705413c44c21c5ec91e890e34e1b0c1331066]: {{{ #!CommitTicketReference repository="" revision="238705413c44c21c5ec91e890e34e1b0c1331066" Latch error values returned from any VDP function, making sure that all subsequent calls to VDP_bytes() becomes noops. This allows calling code to allow calling VDP_bytes() again even if a previous call returned error. Submitted by: Martin Fixes #1642 PS: I have given up writing a test-case /phk }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 29 13:13:06 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Apr 2015 13:13:06 -0000 Subject: [Varnish] #1728: PROXYv1: Assert error in SES_RxReq(), cache/cache_session.c line 282:\n In-Reply-To: <043.7930decf4da5cb68f9b317744080b783@varnish-cache.org> References: <043.7930decf4da5cb68f9b317744080b783@varnish-cache.org> Message-ID: <058.0b5d6bbe3d899f97e17e3272f16ca117@varnish-cache.org> #1728: PROXYv1: Assert error in SES_RxReq(), cache/cache_session.c line 282:\n ----------------------+---------------------------------------- Reporter: daghf | 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 [93c62b30fb5384d7a0110f45445d6c20088023c8]: {{{ #!CommitTicketReference repository="" revision="93c62b30fb5384d7a0110f45445d6c20088023c8" Get the PROXY1 length check right, it is only the length until the first \n which is limited. Fixes #1728 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 29 17:22:49 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Apr 2015 17:22:49 -0000 Subject: [Varnish] #1729: Incorrect parsing of responses containing both chunked transfer-encoding and Content-length Message-ID: <046.49b447f81a2003545c8fc6e797d7e59c@varnish-cache.org> #1729: Incorrect parsing of responses containing both chunked transfer-encoding and Content-length ----------------------+---------------------- Reporter: regilero | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.3 | Severity: normal Keywords: | ----------------------+---------------------- RFC 7230: > A sender MUST NOT send a Content-Length header field in any message > that contains a Transfer-Encoding header field. > (...) So having a backend response with both headers is an issue on the backend side. It means this is not a security issue for varnish. But when it happens: RFC 7230: > If a message is received with both a Transfer-Encoding and a > Content-Length header field, the Transfer-Encoding overrides the > Content-Length. Such a message might indicate an attempt to > perform request smuggling (Section 9.5) or response splitting > (Section 9.4) and ought to be handled as an error. A sender MUST > remove the received Content-Length field prior to forwarding such > a message downstream. In varnish 4.0.3, maybe because of #1506 and https://www.varnish- cache.org/trac/changeset/535d44b8909ee88e8700a35bed79f9ca77e445a4 the Content-length header from the response is not rewritten, it is assumed to be exact. The transfer-encoding: chunked is removed, so sending a content-length header is right. The chunked body is de-chunked (so varnish knows the real Content-length), and added in the new de-chunked response body without altering the initial Content-Length header. If this content length is wrong, the de-chunked content could contain a second http response (http smuggling). Expected behavior: ------------------- Either: * close the connection in error in case of conflict between the observed Content-Length and the original Content-Length * or fix the Content-length header if the length is known * or reject backend responses containing both chunked Transfer-Encoding and Content-Length There may be other problems with streamed responses, where chunks are transferred as they come (not sure this is supported in varnish). * if the Content-length header is not rejected, received chunks size should not exceed the initial content-length (and then close client connection if it happens) * prevent content-length header in chunk trailers (do not forward it) -- Ticket URL: Varnish The Varnish HTTP Accelerator