From varnish-bugs at varnish-cache.org Mon Jul 2 09:09:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 09:09:29 -0000 Subject: [Varnish] #1161: beresp.http.set-cookie cann't contain all the cookie Message-ID: <045.4b304f21a04cca34a4193ce04fe7564b@varnish-cache.org> #1161: beresp.http.set-cookie cann't contain all the cookie ------------------------------------+--------------------------------------- Reporter: bitwind | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.4 | Severity: normal Keywords: beresp.http.set-cookie | ------------------------------------+--------------------------------------- I want to get a variable from cookie, but in varnish beresp.http.set- cookie cann't contain all the cookie and I cann't get the variable from the cookie[[BR]] for eg[[BR]] in browser the value of set cookie is[[BR]] Set-Cookie:JSESSIONID=0000RGgc9kpgTUnLzLdxZYTOop2:871ab6ad-7832-4ade-8c0b- 6d185d3b6dde; Path=/; HttpOnly, IBMSessionHandle_SessGrid-7321712278580331224=6; Path=/, IBMID=RGgc9kpgTUnLzLdxZYTOop2:1; Path=/, XStickySessionID=SDE12345678[[BR]] set beresp.http.X-Cookie-Debug-stickysession = beresp.http.set-cookie; // I get the cookie with this statement in vcl[[BR]] but in the browser [[BR]] X-Cookie-Debug-beresp- cookie:JSESSIONID=0000RGgc9kpgTUnLzLdxZYTOop2:871ab6ad-7832-4ade-8c0b- 6d185d3b6dde; Path=/; HttpOnly[[BR]] it cann't get all the content of the cookie -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 09:14:24 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 09:14:24 -0000 Subject: [Varnish] #849: Session timeout while receiving POST data from client causes multiple broken backend requests In-Reply-To: <041.0e6f1a912317111f89bfe1014049adca@varnish-cache.org> References: <041.0e6f1a912317111f89bfe1014049adca@varnish-cache.org> Message-ID: <050.757a2ee874ea4ed36565b702f93e1c88@varnish-cache.org> #849: Session timeout while receiving POST data from client causes multiple broken backend requests ----------------------+----------------------------------------------------- Reporter: lew | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: 503, post, backend write error: 11 (Resource temporarily unavailable) ----------------------+----------------------------------------------------- Comment(by vrobert): Hello, we had this issue too. I've done some tests: disabling keepalive or increasing the keepalive on apache does nothing. The thing is bizzare because some of our customers seem to be more affected than others. (Slow connection, perhaps but not sure) I don't want to use pipe. Increasing of sess_timeout have extended the waiting time before the error arrives, but the number of errors is always the same. Statistics on 06/26/2012: 1571434 POST - 3336 POST with 503 (0.21%) - sess_timeout = 5 Statistics on 06/27/2012: 1391161 POST - 3011 POST with 503 (0.19%) - sess_timeout = 5 Statistics on 06/28/2012: 1322403 POST - 2493 POST with 503 (0.20%) - sess_timeout = 5 Statistics on 06/29/2012: 1328187 POST - 2645 POST with 503 (0.21%) - sess_timeout = 5 & 10 Statistics on 06/30/2012: 1201337 POST - 2593 POST with 503 (0.22%) - sess_timeout = 10 Statistics on 07/01/2012: 1270146 POST - 2841 POST with 503 (0.21%) - sess_timeout = 10 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 09:21:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 09:21:59 -0000 Subject: [Varnish] #849: Session timeout while receiving POST data from client causes multiple broken backend requests In-Reply-To: <041.0e6f1a912317111f89bfe1014049adca@varnish-cache.org> References: <041.0e6f1a912317111f89bfe1014049adca@varnish-cache.org> Message-ID: <050.e48a2e7588d54597792633ba581ce936@varnish-cache.org> #849: Session timeout while receiving POST data from client causes multiple broken backend requests ----------------------+----------------------------------------------------- Reporter: lew | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: 503, post, backend write error: 11 (Resource temporarily unavailable) ----------------------+----------------------------------------------------- Comment(by vrobert): I forgot to write that we use Varnish 2.1.5. Replying to [comment:7 vrobert]: > Hello, > > we had this issue too. > I've done some tests: disabling keepalive or increasing the keepalive on apache does nothing. > > The thing is bizzare because some of our customers seem to be more affected than others. (Slow connection, perhaps but not sure) > > I don't want to use pipe. > Increasing of sess_timeout have extended the waiting time before the error arrives, but the number of errors is always the same. > > Statistics on 06/26/2012: 1571434 POST - 3336 POST with 503 (0.21%) - sess_timeout = 5 > Statistics on 06/27/2012: 1391161 POST - 3011 POST with 503 (0.19%) - sess_timeout = 5 > Statistics on 06/28/2012: 1322403 POST - 2493 POST with 503 (0.20%) - sess_timeout = 5 > Statistics on 06/29/2012: 1328187 POST - 2645 POST with 503 (0.21%) - sess_timeout = 5 & 10 > Statistics on 06/30/2012: 1201337 POST - 2593 POST with 503 (0.22%) - sess_timeout = 10 > Statistics on 07/01/2012: 1270146 POST - 2841 POST with 503 (0.21%) - sess_timeout = 10 > -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 10:10:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 10:10:04 -0000 Subject: [Varnish] #1161: beresp.http.set-cookie cann't contain all the cookie In-Reply-To: <045.4b304f21a04cca34a4193ce04fe7564b@varnish-cache.org> References: <045.4b304f21a04cca34a4193ce04fe7564b@varnish-cache.org> Message-ID: <054.e741130e73fa0016f9c5fea74263bcc2@varnish-cache.org> #1161: beresp.http.set-cookie cann't contain all the cookie ----------------------+----------------------------------------------------- Reporter: bitwind | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.4 | Severity: normal Resolution: invalid | Keywords: beresp.http.set-cookie ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: I believe you want to use the vmod named header to manipulate Set-Cookie headers: https://github.com/varnish/libvmod-header -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 10:11:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 10:11:43 -0000 Subject: [Varnish] #1160: [PATCH] varnishadm crashes when run with -n and server without -T and -S In-Reply-To: <046.06913db15d2f5e7306db8049b18783f7@varnish-cache.org> References: <046.06913db15d2f5e7306db8049b18783f7@varnish-cache.org> Message-ID: <055.e3b75767ad904e4b6746b88c1094394d@varnish-cache.org> #1160: [PATCH] varnishadm crashes when run with -n and server without -T and -S ----------------------+----------------------------------------------------- Reporter: lkundrak | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 10:11:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 10:11:43 -0000 Subject: [Varnish] #849: Session timeout while receiving POST data from client causes multiple broken backend requests In-Reply-To: <041.0e6f1a912317111f89bfe1014049adca@varnish-cache.org> References: <041.0e6f1a912317111f89bfe1014049adca@varnish-cache.org> Message-ID: <050.1f7d6cd79701df6303e11301e5adfae8@varnish-cache.org> #849: Session timeout while receiving POST data from client causes multiple broken backend requests -----------------------------------------------------------------------------------+ Reporter: lew | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.4 Severity: normal | Resolution: invalid Keywords: 503, post, backend write error: 11 (Resource temporarily unavailable) | -----------------------------------------------------------------------------------+ Changes (by phk): * status: new => closed * resolution: => invalid Comment: The problem is that we don't buffer the request-body (if there is one). This is really a feature-request, so I'm closing this ticket. We have an item about this in [wiki:Future_Feature]. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 10:16:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 10:16:45 -0000 Subject: [Varnish] #1159: bad IP address in test In-Reply-To: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> References: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> Message-ID: <054.d835190bb083b5301e514be21a65e57e@varnish-cache.org> #1159: bad IP address in test -------------------------+-------------------------------------------------- Reporter: jdrusch | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.2 Severity: minor | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen Comment: Can you please tell me what the contents of /proc/sys/net/ipv4/ip_nonlocal_bind is on your systemd? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 11:12:22 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 11:12:22 -0000 Subject: [Varnish] #1156: first_byte_timeout is "doubled" on the client side when keep-alive is used In-Reply-To: <041.241bf6dcc23aa9f0c29f48821fcf593f@varnish-cache.org> References: <041.241bf6dcc23aa9f0c29f48821fcf593f@varnish-cache.org> Message-ID: <050.1ee90114e8ad9711a9de81a31a837e12@varnish-cache.org> #1156: first_byte_timeout is "doubled" on the client side when keep-alive is used -------------------+-------------------------------------------------------- Reporter: tnt | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by tnt): Any progress on this ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 2 17:27:39 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jul 2012 17:27:39 -0000 Subject: [Varnish] #1159: bad IP address in test In-Reply-To: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> References: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> Message-ID: <054.ded2b8e0cb1678a282abe05116b3ce36@varnish-cache.org> #1159: bad IP address in test -------------------------+-------------------------------------------------- Reporter: jdrusch | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.2 Severity: minor | Keywords: -------------------------+-------------------------------------------------- Comment(by jdrusch): Sure, I forgot to mention that I already checked this [root at gossip network-scripts]# cat /proc/sys/net/ipv4/ip_nonlocal_bind 0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 3 08:04:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Jul 2012 08:04:37 -0000 Subject: [Varnish] #897: sess_mem "leak" on hyper-threaded cpu In-Reply-To: <046.214e041eae3c0d463d92b586ac7bbd29@varnish-cache.org> References: <046.214e041eae3c0d463d92b586ac7bbd29@varnish-cache.org> Message-ID: <055.bea6091490706c46f8caab7cf55009a6@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu -------------------------------------------------+-------------------------- Reporter: askalski | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: Keywords: sess_mem leak n_sess race condition | -------------------------------------------------+-------------------------- Changes (by martin): * status: closed => reopened * version: trunk => 3.0.2 * resolution: fixed => Comment: Have found a setup now where they managed to hit session_max twice a day because of this issue, so I guess this warrants reopening this bug. Specific for this case is a very high connection rate, without http keep- alives. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 3 13:57:08 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Jul 2012 13:57:08 -0000 Subject: [Varnish] #1160: [PATCH] varnishadm crashes when run with -n and server without -T and -S In-Reply-To: <046.06913db15d2f5e7306db8049b18783f7@varnish-cache.org> References: <046.06913db15d2f5e7306db8049b18783f7@varnish-cache.org> Message-ID: <055.d968c1da5e1c5fb2b55254b7d7a82418@varnish-cache.org> #1160: [PATCH] varnishadm crashes when run with -n and server without -T and -S ----------------------+----------------------------------------------------- Reporter: lkundrak | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: Commit 673c50deaa447eb80c7830f2adef0749347f44bc fixes this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 4 10:53:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 04 Jul 2012 10:53:13 -0000 Subject: [Varnish] #1162: ban lurker races against HSH_Unbusy() Message-ID: <044.7d2de4cece00d3c52218fd1a37795ded@varnish-cache.org> #1162: ban lurker races against HSH_Unbusy() ----------------------+----------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- The ban lurker can raise against HSH_Unbusy(), and try to get the object of an objcore that is still flagged as busy causing assertion. This is particularly visible in 3.0, when using 'do_stream = true;', as the object will be inserted in the ban list on creation, but not unbusyied until after the fetch has finished. It applies to current trunk as well, and also when do_stream isn't set, but the window of race is much smaller. {{{ *** v1 2.5 debug| Child (30452) Panic message: Assert error in oc_getobj(), cache/cache.h line 436:\n *** v1 2.5 debug| Condition((oc->flags & (1<<1)) == 0) not true.\n *** v1 2.5 debug| thread = (ban-lurker)\n *** v1 2.5 debug| ident = Linux,3.2.0-26-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll\n *** v1 2.5 debug| Backtrace:\n *** v1 2.5 debug| 0x43cce7: pan_backtrace+28\n *** v1 2.5 debug| 0x43cfe0: pan_ic+1bd\n *** v1 2.5 debug| 0x413981: oc_getobj+c9\n *** v1 2.5 debug| 0x4168f6: ban_lurker_work+528\n *** v1 2.5 debug| 0x416cbd: ban_lurker+dd\n *** v1 2.5 debug| 0x4524ec: wrk_bgthread+103\n *** v1 2.5 debug| 0x7fd6d1162e9a: _end+7fd6d0ab7662\n *** v1 2.5 debug| 0x7fd6d0e904bd: _end+7fd6d07e4c85\n }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 5 14:04:30 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 05 Jul 2012 14:04:30 -0000 Subject: [Varnish] #1163: .saintmode_threshold with ESI Message-ID: <045.5eb39dca6fe96b66a032aa3d10aa6903@varnish-cache.org> #1163: .saintmode_threshold with ESI ----------------------------+----------------------------------------------- Reporter: fenidik | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: esi, saintmode | ----------------------------+----------------------------------------------- .saintmode_threshold don't work properly with ESI. I have one 500 response from backend and varnish mark him sick. {{{ 9 BackendOpen b default 10.10.101.149 34973 10.10.101.193 80 9 TxRequest b GET 9 TxURL b /ru/analytics/ 9 TxProtocol b HTTP/1.1 9 TxHeader b X-Real-IP: 192.168.73.52 9 TxHeader b Host: ************ 9 TxHeader b Ext-Host: ******** 9 TxHeader b X-Forwarded-For: 192.168.73.52 9 TxHeader b Authorization: Basic cHNkOmRzcA== 9 TxHeader b User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.41 Safari/536.11 9 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 TxHeader b Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,ru;q=0.4 9 TxHeader b Accept-Charset: UTF-8,*;q=0.5 9 TxHeader b X-Cookie: sid=k6m4686butvgeetf6kec2oda66 9 TxHeader b Surrogate-Capability: Varnish=ESI/1.0 9 TxHeader b X-Varnish: 1401023776 9 TxHeader b Accept-Encoding: gzip 9 RxProtocol b HTTP/1.0 9 RxStatus b 200 9 RxResponse b OK 9 RxHeader b Date: Thu, 05 Jul 2012 13:39:16 GMT 9 RxHeader b Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.8 with Suhosin-Patch 9 RxHeader b X-Powered-By: PHP/5.3.8 9 RxHeader b cache-control: public, s-maxage=1200 9 RxHeader b surrogate-control: content="ESI/1.0" 9 RxHeader b Content-Length: 98992 9 RxHeader b Connection: close 9 RxHeader b Content-Type: text/html; charset=UTF-8 9 Fetch_Body b 4(length) cls 0 mklen 1 9 Length b 98992 9 BackendClose b default 9 BackendOpen b default 10.10.101.149 34974 10.10.101.193 80 9 TxRequest b GET 9 TxURL b /_internal/gtt.company_news.controller.news%3AlistAction/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop- panel__company.html.twig%26pageSize%3D3%26_locale%3Dru%26stateless%3D1%26section%3Dmain.html 9 TxProtocol b HTTP/1.1 9 TxHeader b X-Real-IP: 192.168.73.52 9 TxHeader b Host: ****** 9 TxHeader b Ext-Host: ******** 9 TxHeader b X-Forwarded-For: 192.168.73.52 9 TxHeader b Authorization: Basic cHNkOmRzcA== 9 TxHeader b User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.41 Safari/536.11 9 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 TxHeader b Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,ru;q=0.4 9 TxHeader b Accept-Charset: UTF-8,*;q=0.5 9 TxHeader b X-Cookie: sid=k6m4686butvgeetf6kec2oda66 9 TxHeader b Surrogate-Capability: Varnish=ESI/1.0 9 TxHeader b X-Varnish: 1401023776 9 TxHeader b Accept-Encoding: gzip 9 RxProtocol b HTTP/1.0 9 RxStatus b 200 9 RxResponse b OK 9 RxHeader b Date: Thu, 05 Jul 2012 13:39:16 GMT 9 RxHeader b Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.8 with Suhosin-Patch 9 RxHeader b X-Powered-By: PHP/5.3.8 9 RxHeader b cache-control: public, s-maxage=3600 9 RxHeader b Content-Length: 950 9 RxHeader b Connection: close 9 RxHeader b Content-Type: text/html; charset=UTF-8 9 Fetch_Body b 4(length) cls 0 mklen 1 9 Length b 950 9 BackendClose b default 9 BackendOpen b default 10.10.101.149 34978 10.10.101.193 80 9 TxRequest b GET 9 TxURL b /_internal/gtt.company_news.controller.news%3AlistAction/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop- panel__regions.html.twig%26pageSize%3D3%26_locale%3Dru%26stateless%3D1%26section%3Dpartners%26withSections%3D1.html 9 TxProtocol b HTTP/1.1 9 TxHeader b X-Real-IP: 192.168.73.52 9 TxHeader b Host: **** 9 TxHeader b Ext-Host: ***** 9 TxHeader b X-Forwarded-For: 192.168.73.52 9 TxHeader b Authorization: Basic cHNkOmRzcA== 9 TxHeader b User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.41 Safari/536.11 9 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 TxHeader b Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,ru;q=0.4 9 TxHeader b Accept-Charset: UTF-8,*;q=0.5 9 TxHeader b X-Cookie: sid=k6m4686butvgeetf6kec2oda66 9 TxHeader b Surrogate-Capability: Varnish=ESI/1.0 9 TxHeader b X-Varnish: 1401023776 9 TxHeader b Accept-Encoding: gzip 9 RxProtocol b HTTP/1.0 9 RxStatus b 200 9 RxResponse b OK 9 RxHeader b Date: Thu, 05 Jul 2012 13:39:17 GMT 9 RxHeader b Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.8 with Suhosin-Patch 9 RxHeader b X-Powered-By: PHP/5.3.8 9 RxHeader b cache-control: public, s-maxage=3600 9 RxHeader b Content-Length: 1884 9 RxHeader b Connection: close 9 RxHeader b Content-Type: text/html; charset=UTF-8 9 Fetch_Body b 4(length) cls 0 mklen 1 9 Length b 1884 9 BackendClose b default 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1341495559 1.0 0 Debug - "VCL_error(500, Internal Server Error)" 9 BackendOpen b default 10.10.101.149 34981 10.10.101.193 80 9 TxRequest b GET 9 TxURL b /_internal/gtt.partnership.controller.main%3AbranchListAction/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop- panel__branches.html.twig%26_locale%3Dru%26stateless%3D1.html 9 TxProtocol b HTTP/1.1 9 TxHeader b X-Real-IP: 192.168.73.52 9 TxHeader b Host: **** 9 TxHeader b Ext-Host: ******* 9 TxHeader b X-Forwarded-For: 192.168.73.52 9 TxHeader b Authorization: Basic cHNkOmRzcA== 9 TxHeader b User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.41 Safari/536.11 9 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 TxHeader b Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,ru;q=0.4 9 TxHeader b Accept-Charset: UTF-8,*;q=0.5 9 TxHeader b X-Cookie: sid=k6m4686butvgeetf6kec2oda66 9 TxHeader b Surrogate-Capability: Varnish=ESI/1.0 9 TxHeader b X-Varnish: 1401023776 9 TxHeader b Accept-Encoding: gzip 9 RxProtocol b HTTP/1.0 9 RxStatus b 500 9 RxResponse b Internal Server Error 9 RxHeader b Date: Thu, 05 Jul 2012 13:39:18 GMT 9 RxHeader b Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.8 with Suhosin-Patch 9 RxHeader b X-Powered-By: PHP/5.3.8 9 RxHeader b cache-control: no-cache 9 RxHeader b Content-Length: 577 9 RxHeader b Connection: close 9 RxHeader b Content-Type: text/html; charset=UTF-8 9 BackendClose b default 3 SessionOpen c 10.10.101.149 34972 :8080 3 ReqStart c 10.10.101.149 34972 1401023776 3 RxRequest c GET 3 RxURL c /ru/analytics/ 3 RxProtocol c HTTP/1.0 3 RxHeader c X-Real-IP: 192.168.73.52 3 RxHeader c Host: *** 3 RxHeader c Ext-Host: ****** 3 RxHeader c X-Forwarded-For: 192.168.73.52 3 RxHeader c Connection: close 3 RxHeader c Authorization: Basic cHNkOmRzcA== 3 RxHeader c User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.41 Safari/536.11 3 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 3 RxHeader c Accept-Encoding: gzip,deflate,sdch 3 RxHeader c Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,ru;q=0.4 3 RxHeader c Accept-Charset: UTF-8,*;q=0.5 3 RxHeader c Cookie: __atuvc=2|20; ow-autologin=0; ow- sessionkey**-test=OWAxVDVOp%2Fxkw; ow-ssl=0; ow-loginname=test; ow- default_logindomain=**; ow-httpcompress=1; sid=k6m4686butvgeetf6kec2oda66; **_cookie_prolongate_time=134 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c /ru/analytics/ 3 Hash c *** 3 VCL_return c hash 3 VCL_call c miss fetch 3 Backend c 9 default default 3 TTL c 1401023776 RFC 1200 -1 -1 1341495557 0 1341495556 0 1200 3 VCL_call c fetch 3 TTL c 1401023776 VCL 1200 86400 -1 1341495556 -0 3 VCL_return c deliver 3 ObjProtocol c HTTP/1.1 3 ObjResponse c OK 3 ObjHeader c Date: Thu, 05 Jul 2012 13:39:16 GMT 3 ObjHeader c Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.8 with Suhosin-Patch 3 ObjHeader c X-Powered-By: PHP/5.3.8 3 ObjHeader c cache-control: public, s-maxage=1200 3 ObjHeader c Content-Type: text/html; charset=UTF-8 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 TxProtocol c HTTP/1.1 3 TxStatus c 200 3 TxResponse c OK 3 TxHeader c cache-control: public, s-maxage=1200 3 TxHeader c Content-Type: text/html; charset=UTF-8 3 TxHeader c Date: Thu, 05 Jul 2012 13:39:16 GMT 3 TxHeader c Connection: close 3 TxHeader c Vary: Cookie 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c /_internal/gtt.company_news.controller.news%3AlistAction/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop- panel__company.html.twig%26pageSize%3D3%26_locale%3Dru%26stateless%3D1%26section%3Dmain.html 3 Hash c * 3 VCL_return c hash 3 VCL_call c miss fetch 3 Backend c 9 default default 3 TTL c 1401023776 RFC 3600 -1 -1 1341495558 0 1341495556 0 3600 3 VCL_call c fetch 3 TTL c 1401023776 VCL 3601 86400 -1 1341495556 -1 3 VCL_return c deliver 3 ObjProtocol c HTTP/1.1 3 ObjResponse c OK 3 ObjHeader c Date: Thu, 05 Jul 2012 13:39:16 GMT 3 ObjHeader c Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.8 with Suhosin-Patch 3 ObjHeader c X-Powered-By: PHP/5.3.8 3 ObjHeader c cache-control: public, s-maxage=3600 3 ObjHeader c Content-Type: text/html; charset=UTF-8 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c /_internal/gtt.company_news.controller.news%3AlistAction/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop- panel__regions.html.twig%26pageSize%3D3%26_locale%3Dru%26stateless%3D1%26section%3Dpartners%26withSections%3D1.html 3 Hash c ** 3 VCL_return c hash 3 VCL_call c miss fetch 3 Backend c 9 default default 3 TTL c 1401023776 RFC 3600 -1 -1 1341495559 0 1341495557 0 3600 3 VCL_call c fetch 3 TTL c 1401023776 VCL 3602 86400 -1 1341495556 -2 3 VCL_return c deliver 3 ObjProtocol c HTTP/1.1 3 ObjResponse c OK 3 ObjHeader c Date: Thu, 05 Jul 2012 13:39:17 GMT 3 ObjHeader c Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.8 with Suhosin-Patch 3 ObjHeader c X-Powered-By: PHP/5.3.8 3 ObjHeader c cache-control: public, s-maxage=3600 3 ObjHeader c Content-Type: text/html; charset=UTF-8 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c /_internal/gtt.partnership.controller.main%3AbranchListAction/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop- panel__branches.html.twig%26_locale%3Dru%26stateless%3D1.html 3 Hash c *** 3 VCL_return c hash 3 VCL_call c miss fetch 3 Backend c 9 default default 3 TTL c 1401023776 RFC -1 -1 -1 1341495559 0 1341495558 0 0 3 VCL_call c fetch error 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c /_internal/gtt.partnership.controller.main%3AbranchListAction/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop- panel__branches.html.twig%26_locale%3Dru%26stateless%3D1.html 3 Hash c *** 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop-panel__lk.html.twig%26_locale%3Dru.html 3 Hash c *** 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Ablocks %252Ftop-panel%252Ftop-panel__lk.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics%252Findex__button_become-a-client.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics%252Findex__button_become-a-client.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_dow-jones-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_dow-jones-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c /_internal/gtt.informer.controller.news%3AgetDataAction/_template%3D%253A%253Apages%252Fanalytics %252Findex__next-news.html.twig%26lang%3Dru%26stateless%3D1.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c /_internal/gtt.informer.controller.news%3AgetDataAction/_template%3D%253A%253Apages%252Fanalytics %252Findex__next-news.html.twig%26lang%3Dru%26stateless%3D1.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/gtt.trading_central.controller.main%3AredirectAction/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_trading-central-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/gtt.trading_central.controller.main%3AredirectAction/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_trading-central-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_autochartist-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_autochartist-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_squawk-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c sid=k6m4686butvgeetf6kec2oda66 3 Hash c /_internal/GttCoreBundle%3ATemplate%3Arender/_template%3D%253A%253Apages%252Fanalytics %252Findex__button_squawk-auth.html.twig%26_locale%3Dru.html 3 Hash c 3 VCL_return c hash 3 VCL_call c miss fetch 3 FetchError c no backend connection 3 VCL_call c error 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 VCL_call c deliver 3 VCL_acl c NO_MATCH developers 3 VCL_return c deliver 3 Length c 3522 }}} Config: {{{ ################## PROBES CONFIGURATION ################## probe heartbeat { .url = "/_health/"; .interval = 5s; .timeout = 5s; .window = 8; .threshold = 3; } ################## BACKENDS CONFIGURATION ################# # backend default { .host = "***"; .port = "80"; .probe = heartbeat; .saintmode_threshold = 50; } if (beresp.status == 500 || beresp.status == 503) { set beresp.saintmode = 10s; } if (beresp.http.Surrogate-Control ~ "ESI/1.0") { unset beresp.http.Surrogate-Control; // for Varnish >= 3.0 set beresp.do_esi = true; // for Varnish < 3.0 // esi; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 6 07:32:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 Jul 2012 07:32:52 -0000 Subject: [Varnish] #1163: .saintmode_threshold with ESI In-Reply-To: <045.5eb39dca6fe96b66a032aa3d10aa6903@varnish-cache.org> References: <045.5eb39dca6fe96b66a032aa3d10aa6903@varnish-cache.org> Message-ID: <054.6ed854aefb1e37477b0fc515aa06f177@varnish-cache.org> #1163: .saintmode_threshold with ESI ----------------------------+----------------------------------------------- Reporter: fenidik | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: esi, saintmode | ----------------------------+----------------------------------------------- Comment(by fenidik): Saint mode isn't useful with one backend? Probably its misunderstanding. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 6 14:52:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 Jul 2012 14:52:29 -0000 Subject: [Varnish] #1164: Naming a backend storage_something cause VCL compilation error Message-ID: <049.29c206ec5c86a0973f969254e27f4790@varnish-cache.org> #1164: Naming a backend storage_something cause VCL compilation error -------------------------+-------------------------------------------------- Reporter: kimjohansen | Type: defect Status: new | Priority: normal Milestone: Later | Component: build Version: 3.0.2 | Severity: normal Keywords: vcl backend | -------------------------+-------------------------------------------------- Creating a backend named storage_ cause VCL compilation error. Example: backend storage_test{ .host ="127.0.0.1"; .port ="80"; } Result: Message from VCC-compiler: Assert error in vcc_Stv_Wildcard(), vcc_storage.c line 116: Condition(!memcmp(t->b, PFX, strlen(PFX))) not true. Running VCC-compiler failed, signal 6 VCL compilation failed Suggestion: Give a more describing error message or allow storage_ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 9 09:19:23 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jul 2012 09:19:23 -0000 Subject: [Varnish] #1158: graced objects serve very old objects In-Reply-To: <046.2c701f0eda5d50250b65a0c0701b2378@varnish-cache.org> References: <046.2c701f0eda5d50250b65a0c0701b2378@varnish-cache.org> Message-ID: <055.b579a2bb5a65180d60ab4069a6890105@varnish-cache.org> #1158: graced objects serve very old objects -----------------------+---------------------------------------------------- Reporter: nicholas | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: invalid | Keywords: grace -----------------------+---------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: This has turned into a feature request, so I will close the bug report. Some ideas of functionality that will cover this has been added here: https://www.varnish-cache.org/trac/wiki/Future_Feature#Soft-BANs. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 10 02:39:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jul 2012 02:39:21 -0000 Subject: [Varnish] #1165: the authentication problem with varnish healthy check probe Message-ID: <045.3f0c88cd78575668f553af8337842aec@varnish-cache.org> #1165: the authentication problem with varnish healthy check probe -----------------------------------+---------------------------------------- Reporter: bitwind | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 2.1.4 | Severity: normal Keywords: authentication probe | -----------------------------------+---------------------------------------- we use probe to do healthy check with the backend for example[[BR]] probe = {[[BR]] .url = "/iCAP/apis/";[[BR]] .timeout = 30s;[[BR]] .interval = 5s;[[BR]] .window = 5;[[BR]] .threshold = 3;[[BR]] }[[BR]] It need security authentication to access, I don't know whether there is an approach to do it in the VCL, or we must set other pingURL which doesn't need auhtentication? thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 11 09:03:44 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jul 2012 09:03:44 -0000 Subject: [Varnish] #1166: Varnishadm throws an assert Message-ID: <051.5814c781387d31eb173c4ed622e0ca4c@varnish-cache.org> #1166: Varnishadm throws an assert ---------------------------+------------------------------------------------ Reporter: rj@? | Type: defect Status: new | Priority: normal Milestone: | Component: varnishadm Version: 3.0.2 | Severity: normal Keywords: varnishadm | ---------------------------+------------------------------------------------ Hey guys. I was doing some ban.url through varnishadm today and when leaving it idling after 2 minutes of time I got this message: {{{ varnish> Assert error in pass(), varnishadm.c line 219: Condition(i > 0) not true. errno = 4 (Interrupted system call) Aborted }}} The error didn't get thrown when I executed any command. It merely appeared after some time had past.. I have the varnish cache cloned on another server(with same setup and everything) and was doing exactly the same thing on that one. The other server didn't throw any error. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 11 09:21:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jul 2012 09:21:45 -0000 Subject: [Varnish] #1167: 3.0.3rc1 Compile Error on Solaris 10 with gcc 4.3.3 Message-ID: <044.677261b72c12472e07a7cff6c933fe66@varnish-cache.org> #1167: 3.0.3rc1 Compile Error on Solaris 10 with gcc 4.3.3 --------------------------+------------------------------------------------- Reporter: Dommas | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: port:solaris | Version: trunk Severity: normal | Keywords: --------------------------+------------------------------------------------- Hi, I get a compile error while trying to build 3.0.3-rc1 for Solaris 10 using gcc 4.3.3 from OpenCSW. Building 3.0.2 and earlier using the same method always worked. # CC="/opt/csw/gcc4/bin/gcc" CFLAGS="-O3 -fPIC -pthreads -fomit-frame- pointer -m64 -L/opt/csw/lib/amd64 -I/opt/csw/include " LDFLAGS="-lumem -pthreads" ./configure --prefix=$PREFIX --with-gnu-ld=yes # make ... cache_waiter_ports.c: In function 'vca_main': cache_waiter_ports.c:228: error: 'cache_param' undeclared (first use in this function) cache_waiter_ports.c:228: error: (Each undeclared identifier is reported only once cache_waiter_ports.c:228: error: for each function it appears in.) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 12 07:46:27 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Jul 2012 07:46:27 -0000 Subject: [Varnish] #897: sess_mem "leak" on hyper-threaded cpu In-Reply-To: <046.214e041eae3c0d463d92b586ac7bbd29@varnish-cache.org> References: <046.214e041eae3c0d463d92b586ac7bbd29@varnish-cache.org> Message-ID: <055.1cc57abf715ce0445e2966032755dfcb@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu -------------------------------------------------+-------------------------- Reporter: askalski | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: fixed Keywords: sess_mem leak n_sess race condition | -------------------------------------------------+-------------------------- Changes (by Martin Blix Grydeland ): * status: reopened => closed * resolution: => fixed Comment: (In [596246ea3fc36847dc27d1672dd37a8fef817ac5]) Make n_sess be the difference between in use and released session objects. This avoids a memory race on the n_sess counter, which can lead to excessive session object allocation. Keeping the counters of in use and released separate allows the acceptor to continue to run lockless. Fixes: #897 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 12 18:36:38 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Jul 2012 18:36:38 -0000 Subject: [Varnish] #1168: rollback breaks ESI Message-ID: <043.c4c3c5288e64565202f3ef2286a684c8@varnish-cache.org> #1168: rollback breaks ESI ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- When issuing a rollback on an ESI sub-request, req is rolled back to the initial request, thus making rollback unusable for ESI. vtc attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 13 07:23:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Jul 2012 07:23:56 -0000 Subject: [Varnish] #1169: Varnishadmin trnucates the output of param.show -l Message-ID: <052.3052098d8261daec89ce9318fee50f89@varnish-cache.org> #1169: Varnishadmin trnucates the output of param.show -l --------------------------------------------+------------------------------- Reporter: desperate_john | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: varnish-trunk revision 7d9ca7d | --------------------------------------------+------------------------------- Since introduction of cli_limit, the 'param.show -l' output is truncated in varnish shell because the output if larger than the default of cli_limit. varnish-trunk revision 7d9ca7d -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 13 07:29:55 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Jul 2012 07:29:55 -0000 Subject: [Varnish] #1170: varnishlog processes old entries on startup Message-ID: <052.c67882da1b5fc7914959e9ebd3d551c4@varnish-cache.org> #1170: varnishlog processes old entries on startup ------------------------------+--------------------------------------------- Reporter: desperate_john | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: revision 7d9ca7d | ------------------------------+--------------------------------------------- At least with varnish-trunk revision 7d9ca7d the varnishlog process old log entries on startup (like the -d option). It's annyoing to use varnshlog because it's awfully slow. Please make -d optional again, not default. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 07:40:28 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 07:40:28 -0000 Subject: [Varnish] Password reset for user: derjohn Message-ID: Password reset for user for user derjohn -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 07:49:28 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 07:49:28 -0000 Subject: [Varnish] Password reset for user: tfheen Message-ID: Password reset for user for user tfheen -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 07:50:08 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 07:50:08 -0000 Subject: [Varnish] Password reset for user: tfheen Message-ID: Password reset for user for user tfheen -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 10:11:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 10:11:43 -0000 Subject: [Varnish] #1169: Varnishadmin trnucates the output of param.show -l In-Reply-To: <052.3052098d8261daec89ce9318fee50f89@varnish-cache.org> References: <052.3052098d8261daec89ce9318fee50f89@varnish-cache.org> Message-ID: <067.88ca2cde092063f46f09da4bea694f8d@varnish-cache.org> #1169: Varnishadmin trnucates the output of param.show -l --------------------------------------------+--------------------- Reporter: desperate_john | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: varnish-trunk revision 7d9ca7d | --------------------------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 10:19:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 10:19:33 -0000 Subject: [Varnish] #1165: the authentication problem with varnish healthy check probe In-Reply-To: <045.3f0c88cd78575668f553af8337842aec@varnish-cache.org> References: <045.3f0c88cd78575668f553af8337842aec@varnish-cache.org> Message-ID: <060.6412f62ccc76c3bfd73eed40c1530618@varnish-cache.org> #1165: the authentication problem with varnish healthy check probe -----------------------------------+--------------------- Reporter: bitwind | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 2.1.4 Severity: normal | Resolution: Keywords: authentication probe | -----------------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 10:20:14 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 10:20:14 -0000 Subject: [Varnish] #1168: rollback breaks ESI In-Reply-To: <043.c4c3c5288e64565202f3ef2286a684c8@varnish-cache.org> References: <043.c4c3c5288e64565202f3ef2286a684c8@varnish-cache.org> Message-ID: <058.c62e4f15029a76b4caeae1b2cfbdd7c6@varnish-cache.org> #1168: rollback breaks ESI ----------------------+-------------------- Reporter: scoof | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 10:20:23 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 10:20:23 -0000 Subject: [Varnish] #1164: Naming a backend storage_something cause VCL compilation error In-Reply-To: <049.29c206ec5c86a0973f969254e27f4790@varnish-cache.org> References: <049.29c206ec5c86a0973f969254e27f4790@varnish-cache.org> Message-ID: <064.602bfd5f3a7683c9fbe6508631cce862@varnish-cache.org> #1164: Naming a backend storage_something cause VCL compilation error -------------------------+-------------------- Reporter: kimjohansen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Later Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: vcl backend | -------------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 10:31:18 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 10:31:18 -0000 Subject: [Varnish] #1163: .saintmode_threshold with ESI In-Reply-To: <045.5eb39dca6fe96b66a032aa3d10aa6903@varnish-cache.org> References: <045.5eb39dca6fe96b66a032aa3d10aa6903@varnish-cache.org> Message-ID: <060.cb87d58cf60e23e88dc73ddfd87a8b3b@varnish-cache.org> #1163: .saintmode_threshold with ESI ----------------------------+----------------------- Reporter: fenidik | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: esi, saintmode | ----------------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 17 12:39:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jul 2012 12:39:32 -0000 Subject: [Varnish] #1171: Timing information for each backend request / ESI Message-ID: <045.16d0c099d0dcd079914c1157d1344194@varnish-cache.org> #1171: Timing information for each backend request / ESI --------------------------------+------------------------- Reporter: derjohn | Type: enhancement Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: normal Keywords: esi derjohn timing | --------------------------------+------------------------- For performance analysis I'll like to get timing information for each ESI backend request. Currently there is only a timing info in the shared memory log: It's is logged with "ReqEnd" for a _client_ request, but not for a bereq! At least I want to see start and end timestamps per ESI backend request. It would be a nice to have to see also the first byte received as a timestamp in order to tune the first byte timeout. Timing info in ms (instead of ns) would be sufficient for me needs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 21:20:09 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 21:20:09 -0000 Subject: [Varnish] New user registration: RuddO Message-ID: New user registration for user RuddO -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 21:24:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 21:24:53 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches Message-ID: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches -------------------+-------------------- Reporter: RuddO | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | -------------------+-------------------- http://redbot.org/?uri=http://declinefm.com/search_form When Varnish 3.0.2 gets a request with gzip compression in the Accept- Encoding header, it sends a different Vary: header than when it gets a request without gzip compression. The VCL is not doing anything special there. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 21:53:17 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 21:53:17 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches In-Reply-To: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> References: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> Message-ID: <058.500702dfadb9cef2c7f64ef32b021415@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches --------------------+-------------------- Reporter: RuddO | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by scoof): Can't reproduce here, please attach varnishlog (and preferably vcl too) showing the issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 21:56:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 21:56:33 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches In-Reply-To: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> References: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> Message-ID: <058.dd2ce313a99e05eaabc52d2ab23543ca@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches --------------------+-------------------- Reporter: RuddO | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by RuddO): I have discovered this is related to the hit for pass feature. This is an example of a request that gets routed to miss after hash: /etc/varnish@? ??: echo "GET /search_form HTTP/1.1 Host: declinefm.com " | nc localhost 80 | head -20 HTTP/1.1 200 OK Server: Zope/(2.13.13, python 2.6.7, linux2) ZServer/1.1 Content-Language: en Expires: Sat, 1 Jan 2000 00:00:00 GMT Vary: Accept- Encoding Content-Type: text/html;charset=utf-8 Transfer-Encoding: chunked Date: Wed, 18 Jul 2012 21:50:06 GMT X-Varnish: 13272803 Age: 0 Via: 1.1 varnish Connection: keep-alive Note the Vary header there. Almost immediately after that, I produce another request. This, of course, goes straight to pass since the TTL of the previous fetch was 0 seconds, and so varnish registered a hit for pass for this object. 0 <- echo "GET /search_form HTTP/1.1 Host: declinefm.com " | nc localhost 80 | head -20 /etc/varnish@? ??: echo "GET /search_form HTTP/1.1 Host: declinefm.com " | nc localhost 80 | head -20 HTTP/1.1 200 OK Server: Zope/(2.13.13, python 2.6.7, linux2) ZServer/1.1 Expires: Sat, 1 Jan 2000 00:00:00 GMT Content-Type: text/html;charset=utf-8 Content-Language: en Transfer-Encoding: chunked Date: Wed, 18 Jul 2012 21:50:37 GMT X-Varnish: 13272824 Age: 0 Via: 1.1 varnish Connection: keep-alive Note the absence of the Vary header here. I verified my backend and it has correct, consistent behavior. This appears to be a legitimate varnish bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 22:00:07 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 22:00:07 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches In-Reply-To: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> References: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> Message-ID: <058.e1a14c6be59e67b0244750c7a64cd152@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches --------------------+-------------------- Reporter: RuddO | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by RuddO): Output from CURL -v: {{{ ~@karen.dragonfear ?: headers http://declinefm.com/search_form * About to connect() to declinefm.com port 80 (#0) * Trying 117.121.243.202... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* connected * Connected to declinefm.com (117.121.243.202) port 80 (#0) > GET /search_form HTTP/1.1 > User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.4.0 zlib/1.2.5 libidn/1.24 libssh2/1.4.1 > Host: declinefm.com > Accept: */* > < HTTP/1.1 200 OK < Server: Zope/(2.13.13, python 2.6.7, linux2) ZServer/1.1 < Content-Language: en < Expires: Sat, 1 Jan 2000 00:00:00 GMT < Vary: Accept-Encoding < Content-Type: text/html;charset=utf-8 < Transfer-Encoding: chunked < Date: Wed, 18 Jul 2012 21:59:24 GMT < X-Varnish: 13273159 < Age: 0 < Via: 1.1 varnish < Connection: keep-alive < { [data not shown] 100 15076 0 15076 0 0 84449 0 --:--:-- --:--:-- --:--:-- 101k * Connection #0 to host declinefm.com left intact * Closing connection #0 0 <- headers http://declinefm.com/search_form ~@karen.dragonfear ?: headers http://declinefm.com/search_form * About to connect() to declinefm.com port 80 (#0) * Trying 117.121.243.202... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* connected * Connected to declinefm.com (117.121.243.202) port 80 (#0) > GET /search_form HTTP/1.1 > User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.4.0 zlib/1.2.5 libidn/1.24 libssh2/1.4.1 > Host: declinefm.com > Accept: */* > < HTTP/1.1 200 OK < Server: Zope/(2.13.13, python 2.6.7, linux2) ZServer/1.1 < Expires: Sat, 1 Jan 2000 00:00:00 GMT < Content-Type: text/html;charset=utf-8 < Content-Language: en < Transfer-Encoding: chunked < Date: Wed, 18 Jul 2012 21:59:26 GMT < X-Varnish: 13273160 < Age: 0 < Via: 1.1 varnish < Connection: keep-alive < { [data not shown] 100 15076 0 15076 0 0 86378 0 --:--:-- --:--:-- --:--:-- 103k * Connection #0 to host declinefm.com left intact * Closing connection #0 }}} As I said, my VCL is for all purposes and intents, the default VCL. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 22:03:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 22:03:00 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches In-Reply-To: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> References: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> Message-ID: <058.de3e25d7123b8d791bcf7bf0692dca8d@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches --------------------+-------------------- Reporter: RuddO | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by RuddO): Varnishlog of the relevant things: --------------------------- {{{ /etc/varnish at tobey.rudd-o.com ??: varnishlog -c -u | egrep "(RxURL|Host:|TxStatus|VCL_|Location:|Referer:|Vary:|TTL|HitPass|Cache)" 12 RxURL c /search_form 12 RxHeader c Host: declinefm.com 12 VCL_call c recv lookup 12 VCL_call c hash 12 VCL_return c hash 12 VCL_call c miss fetch 12 TTL c 13273340 RFC 0 -1 -1 1342648951 0 1342648950 946684800 0 12 VCL_call c fetch 12 VCL_Log c Search form accessed 12 TTL c 13273340 VCL 120 -1 -1 1342648951 -0 12 VCL_return c hit_for_pass 12 ObjHeader c Vary: Accept-Encoding 12 VCL_call c deliver deliver 12 TxStatus c 200 12 TxHeader c Vary: Accept-Encoding 12 RxURL c /search_form 12 RxHeader c Host: declinefm.com 12 VCL_call c recv lookup 12 VCL_call c hash 12 VCL_return c hash 12 HitPass c 13273340 12 VCL_call c pass pass 12 TTL c 13273341 RFC 0 -1 -1 1342648952 0 1342648952 946684800 0 12 VCL_call c fetch 12 VCL_Log c Search form accessed 12 TTL c 13273341 VCL 120 -1 -1 1342648952 -0 12 VCL_return c hit_for_pass 12 VCL_call c deliver deliver 12 TxStatus c 200 ^C }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 22:05:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 22:05:13 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches In-Reply-To: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> References: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> Message-ID: <058.fc78b0badae69450df6287629a613dc4@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches --------------------+-------------------- Reporter: RuddO | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by scoof): Please give us something to work with here, and include the full varnishlog of the backend and client transaction. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 18 23:27:08 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Jul 2012 23:27:08 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches In-Reply-To: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> References: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> Message-ID: <058.83c08f4b9404979f4b8d4b9a9848be00@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches --------------------+-------------------- Reporter: RuddO | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by RuddO): ok. i will. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 19 09:16:28 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Jul 2012 09:16:28 -0000 Subject: [Varnish] Password reset for user: geoff Message-ID: Password reset for user for user geoff -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 19 09:17:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Jul 2012 09:17:33 -0000 Subject: [Varnish] Password reset for user: geoff Message-ID: Password reset for user for user geoff -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 19 09:20:27 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Jul 2012 09:20:27 -0000 Subject: [Varnish] #1167: 3.0.3rc1 Compile Error on Solaris 10 with gcc 4.3.3 In-Reply-To: <044.677261b72c12472e07a7cff6c933fe66@varnish-cache.org> References: <044.677261b72c12472e07a7cff6c933fe66@varnish-cache.org> Message-ID: <059.f1d7b6caf022b501c11176db01e4370b@varnish-cache.org> #1167: 3.0.3rc1 Compile Error on Solaris 10 with gcc 4.3.3 --------------------------+-------------------- Reporter: Dommas | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: port:solaris | Version: trunk Severity: normal | Resolution: Keywords: | --------------------------+-------------------- Comment (by geoff): Please attempt to verify the attached patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 19 10:30:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Jul 2012 10:30:53 -0000 Subject: [Varnish] New user registration: daghf Message-ID: New user registration for user daghf -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 19 12:37:10 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Jul 2012 12:37:10 -0000 Subject: [Varnish] #1150: Fast expiry_sleep causing panics In-Reply-To: <045.8334b39d0642817ed08d71ad9c27d0d6@varnish-cache.org> References: <045.8334b39d0642817ed08d71ad9c27d0d6@varnish-cache.org> Message-ID: <060.d6f1d77ad24b0c9491c97aa13a79d43f@varnish-cache.org> #1150: Fast expiry_sleep causing panics --------------------------------+--------------------- Reporter: jjordan | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Resolution: fixed Keywords: expiry_sleep panic | --------------------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: Commit 116393f289258b2bb9b49d518b0206cec6550a75 fixes this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 19 12:37:58 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Jul 2012 12:37:58 -0000 Subject: [Varnish] #1162: ban lurker races against HSH_Unbusy() In-Reply-To: <044.7d2de4cece00d3c52218fd1a37795ded@varnish-cache.org> References: <044.7d2de4cece00d3c52218fd1a37795ded@varnish-cache.org> Message-ID: <059.31158ffea32e4b6cf557d3aeaf1623d2@varnish-cache.org> #1162: ban lurker races against HSH_Unbusy() ----------------------+--------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: Commit 0c9975c1be926799c368d904dd65204eca25ed50 fixes this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 20 05:43:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Jul 2012 05:43:00 -0000 Subject: [Varnish] New user registration: cche5425 Message-ID: New user registration for user cche5425 -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 20 05:54:55 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Jul 2012 05:54:55 -0000 Subject: [Varnish] #1173: Help, varnish makes my session lose Message-ID: <046.8a493d50735d23909f96f79d8983c9d0@varnish-cache.org> #1173: Help, varnish makes my session lose ----------------------------------+---------------------- Reporter: cche5425 | Type: defect Status: new | Priority: highest Milestone: | Component: website Version: 3.0.0 | Severity: critical Keywords: varnish session lost | ----------------------------------+---------------------- Hi guys, i am new to varnish and i recently searched heavily on google and tried to install varnish on my company's website (which is an e-commerce website). The problem is when i start varnish, i found when people put thing into cart, then go to the checkout page, the cart session lost, which means the things that customers just added are lost. As soon as i turn off the varnish, everything works fine again. Some one please help me since i do not know where my problem is[[BR]] Here is my configuration file:[[BR]] sub vcl_recv { if (req.url ~ "\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$") { unset req.http.cookie; return(lookup); } if(req.url ~ "^/GenerateProductList"){ return (lookup); } if(req.http.Cookie !~ "pflcustomerId" && req.url ~ "^/(dog|cat|flea)"){ return (lookup); } return(pass); } [[BR]] sub vcl_pipe { return (pipe); } sub vcl_pass { return (pass); } # sub vcl_hash { hash_data(req.url); if (req.http.host) { hash_data(req.http.host); } else { hash_data(server.ip); } return (hash); } # sub vcl_hit { # after lookup, if find the request content, then use it return (deliver); } # sub vcl_miss { # after lookup, cant find the request, then here we can see if we need to # get the content from the backend. return (fetch); } # sub vcl_fetch { return(deliver); } sub vcl_deliver { # send contents in the cache to the client. return (deliver); } sub vcl_error { set obj.http.Content-Type = "text/html; charset=utf-8"; set obj.http.Retry-After = "5"; synthetic {" "} + obj.status + " " + obj.response + {"

Error "} + obj.status + " " + obj.response + {"

"} + obj.response + {"

Guru Meditation:

XID: "} + req.xid + {"

Varnish cache server

"}; return (deliver); } sub vcl_init { return (ok); } sub vcl_fini { return (ok); } Thanks in advance and any suggestions will be appreciated -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 20 09:25:14 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Jul 2012 09:25:14 -0000 Subject: [Varnish] #1165: the authentication problem with varnish healthy check probe In-Reply-To: <045.3f0c88cd78575668f553af8337842aec@varnish-cache.org> References: <045.3f0c88cd78575668f553af8337842aec@varnish-cache.org> Message-ID: <060.56f9037bfbd925e3e592cc43c99ab588@varnish-cache.org> #1165: the authentication problem with varnish healthy check probe -----------------------------------+---------------------- Reporter: bitwind | Owner: martin Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 2.1.4 Severity: normal | Resolution: invalid Keywords: authentication probe | -----------------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: This can be achieved by giving the complete HTTP request to the probe. Look at the .request attribute on the page https://www.varnish- cache.org/docs/3.0/reference/vcl.html#backend-probes and more thoroughly explained here https://www.varnish-cache.org/trac/wiki/BackendPolling You will then add a Auth-header with the prepared combined username and password Base64 -encoded. Look up HTTP basic auth. Note that this is not a bug in Varnish, and the varnish-misc mailing list or the #varnish IRC channel is the place to get help configuring your setup. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 20 10:41:20 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Jul 2012 10:41:20 -0000 Subject: [Varnish] #1169: Varnishadmin trnucates the output of param.show -l In-Reply-To: <052.3052098d8261daec89ce9318fee50f89@varnish-cache.org> References: <052.3052098d8261daec89ce9318fee50f89@varnish-cache.org> Message-ID: <067.f064a10c68040121618f18e9568abaa3@varnish-cache.org> #1169: Varnishadmin trnucates the output of param.show -l --------------------------------------------+--------------------- Reporter: desperate_john | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: varnish-trunk revision 7d9ca7d | --------------------------------------------+--------------------- Comment (by Martin Blix Grydeland ): In [f9c42ca8306792ceb1d52cb78c4af23b7ee474af]: {{{ #!CommitTicketReference repository="" revision="f9c42ca8306792ceb1d52cb78c4af23b7ee474af" Extend cli_limit to 48k to make room for the full output of 'param.show -l'. Fixes: #1169 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 20 10:46:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Jul 2012 10:46:02 -0000 Subject: [Varnish] #1164: Naming a backend storage_something cause VCL compilation error In-Reply-To: <049.29c206ec5c86a0973f969254e27f4790@varnish-cache.org> References: <049.29c206ec5c86a0973f969254e27f4790@varnish-cache.org> Message-ID: <064.fffeb2d39b9e0a5eae6c7d20184d053b@varnish-cache.org> #1164: Naming a backend storage_something cause VCL compilation error -------------------------+--------------------- Reporter: kimjohansen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Later Component: build | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: vcl backend | -------------------------+--------------------- Changes (by daghf): * status: new => closed * resolution: => fixed Comment: Fixed in b33efe4cbe2ee8b69222d7f53bd3833938542390 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 23 07:16:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jul 2012 07:16:32 -0000 Subject: [Varnish] #1167: 3.0.3rc1 Compile Error on Solaris 10 with gcc 4.3.3 In-Reply-To: <044.677261b72c12472e07a7cff6c933fe66@varnish-cache.org> References: <044.677261b72c12472e07a7cff6c933fe66@varnish-cache.org> Message-ID: <059.22b0a860bb8ed3cd8b6e698ddaff0d4b@varnish-cache.org> #1167: 3.0.3rc1 Compile Error on Solaris 10 with gcc 4.3.3 --------------------------+-------------------- Reporter: Dommas | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: port:solaris | Version: trunk Severity: normal | Resolution: Keywords: | --------------------------+-------------------- Comment (by Dommas): The patch solves the problem, build succeeds. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 23 12:33:06 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jul 2012 12:33:06 -0000 Subject: [Varnish] #1174: Varnish should warn about timeouts exceeded in varnishlog Message-ID: <045.4cb88af9abb92ce981897a441af11508@varnish-cache.org> #1174: Varnish should warn about timeouts exceeded in varnishlog -----------------------------+------------------------- Reporter: derjohn | Type: enhancement Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: 3.0.0 | Severity: normal Keywords: | -----------------------------+------------------------- Heya, if a timeout triggers a connectiom close, e.g. idle_timeout, send_timeout or first_byte_timeout, in varnishlog there is no explicit warning about the timeout being the reason for the close.. I would like to see such a log line in order being able to ajdust my timeouts better. rgds, j -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 24 05:05:22 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jul 2012 05:05:22 -0000 Subject: [Varnish] New user registration: kazuki1226 Message-ID: New user registration for user kazuki1226 -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 24 12:26:14 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jul 2012 12:26:14 -0000 Subject: [Varnish] #1175: -smalloc size limit failures does not increment the c_fail counter, but adds failed bytes to it Message-ID: <044.58f144b9b4eb28dfdaa21e6af9077a7e@varnish-cache.org> #1175: -smalloc size limit failures does not increment the c_fail counter, but adds failed bytes to it ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Keywords: ----------------------+------------------- When -smalloc fails to allocate memory due to max size limit, it will add the number of bytes that failed to the c_fail counter for this storage backend. This is inconsistent with how -sfile works, and also how -smalloc behaves when the malloc() call fails. These other places all increment c_fail by one on errors. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 24 12:40:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jul 2012 12:40:02 -0000 Subject: [Varnish] #1176: varnishd segfaults if no storage backend has been defined Message-ID: <044.359689bc726e4977b127817ced20225c@varnish-cache.org> #1176: varnishd segfaults if no storage backend has been defined ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Keywords: ----------------------+------------------- If you start varnishd by e.g. '-s Transient=malloc' as the only storage declaration, it will start without any storage backends defined. When it tries to allocate storage, it will segfault. This is because the -s option correctly makes varnishd skip the default storage backend declaration. When that -s option only redefines the transient storage, there still aren't any non-transient storage backends defined. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 25 18:34:18 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 Jul 2012 18:34:18 -0000 Subject: [Varnish] New user registration: ikemia971 Message-ID: New user registration for user ikemia971 -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 27 08:55:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Jul 2012 08:55:49 -0000 Subject: [Varnish] New user registration: jpastsuzek Message-ID: New user registration for user jpastsuzek -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 27 19:55:10 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Jul 2012 19:55:10 -0000 Subject: [Varnish] New user registration: karnak Message-ID: New user registration for user karnak -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 27 20:03:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Jul 2012 20:03:45 -0000 Subject: [Varnish] #1177: Child will not start on Solaris died signal=10 (core dumped) Message-ID: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> #1177: Child will not start on Solaris died signal=10 (core dumped) ---------------------+-------------------- Reporter: karnak | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: Solaris | ---------------------+-------------------- varnishd starts - the children core dump {{{ child (4490) Started Pushing vcls failed: CLI communication error (hdr) Stopping Child 200 0 Child (4490) died signal=10 (core dumped) Child (-1) said Child starts Child cleanup complete }}} {{{ core 'core_cahaba_varnishd_6171_512_1343418676_4490' of 4490: /opt/varnish/sbin/varnishd -d -f /opt/varnish/etc/varnish/default.vcl 0000000100077abc vsl_wrap (ffffffff77c105b0, 1001fe, ffffffff77c105ac, 1001fe, 1001fe000, 1001fe000) + 178 00000001000790a8 VSL_Init (100200, 1001fe000, ffffffff77c105ac, ffffffff7cc105ac, ffffffff77c105b0, 1001fe000) + 360 00000001000683b8 child_main (1000e9e28, 1000e9000, 1000e9, 1001fe, 1001fe, 100000) + 160 0000000100096c28 start_child (3, 100343e20, 2, 1, b, 1001fffa0) + 8b4 ffffffff7f00ac94 cls_vlu2 (1003e7ec0, 100343ba0, 100341ef8, 73, 1, 1003e7ef0) + 4ac ffffffff7f00b128 cls_vlu (1003e7ec0, 0, 10dbd1e, 10dbd1e, ffffffff7f11c638, ffffffff7f01b8a0) + 3d0 ffffffff7f011dfc LineUpProcess (1003238d0, 0, ffffffff, 1003f7c10, ffffffff7f01c0e0, 1001ffbc0) + 5cc ffffffff7f00bdac VCLS_PollFd (1003e5f40, 1003e7ef0, 0, 1001fe000, 1003e7ec0, ffffffff7f11c638) + 264 ffffffff7f010ab8 vev_schedule_one (10033fec0, 0, 1, ffffffff7f11c638, ffffffff7f01bf38, 1003fbe50) + 7f0 ffffffff7f00ff88 vev_schedule (10033fec0, ffffffffffeff748, 100800, ffffffff7db4a4c0, 10033fec0, ffffffff7f01bd80) + 108 00000001000977f4 MGT_Run (1, 1001fe000, 1, 1000efa88, 2, 1001ff000) + 430 00000001000b8e00 main (1, 10035f010, 0, 1000fa7b8, 1001ff000, 1001fe000) + f20 000000010001f0ec _start (0, 0, 0, 0, 0, 0) + 12c }}} {{{ core 'core_cahaba_varnishd_6171_512_1343418676_4490' of 4490: /opt/varnish/sbin/varnishd -d -f /opt/varnish/etc/varnish/default.vcl 0000000100000000 960K r-x-- /opt/varnish/sbin/varnishd 00000001000F0000 48K r-x-- /opt/varnish/sbin/varnishd 00000001001FA000 24K rwx-- /opt/varnish/sbin/varnishd 0000000100200000 2112K rwx-- [ heap ] FFFFFFFF77C00000 82944K rw---* FFFFFFFF7D000000 64K rwx-- FFFFFFFF7D100000 40K r-x-- /lib/sparcv9/nss_files.so.1 FFFFFFFF7D20A000 8K rwx-- /lib/sparcv9/nss_files.so.1 FFFFFFFF7D300000 64K rwx-- FFFFFFFF7D400000 64K rwx-- FFFFFFFF7D500000 56K r-x-- /lib/sparcv9/libmd.so.1 FFFFFFFF7D60E000 8K rwx-- /lib/sparcv9/libmd.so.1 FFFFFFFF7D700000 32K r-x-- /lib/sparcv9/libaio.so.1 FFFFFFFF7D800000 8K r----* FFFFFFFF7D808000 8K rwx-- /lib/sparcv9/libaio.so.1 FFFFFFFF7D80A000 8K rwx-- /lib/sparcv9/libaio.so.1 FFFFFFFF7D900000 1216K r-x-- /lib/sparcv9/libc.so.1 FFFFFFFF7DA30000 56K r-x-- /lib/sparcv9/libc.so.1 FFFFFFFF7DB00000 8K r-x-- /platform/sun4v/lib/sparcv9/libc_psr.so.1 FFFFFFFF7DB3E000 8K rwx-- /lib/sparcv9/libc.so.1 FFFFFFFF7DB40000 64K rwx-- /lib/sparcv9/libc.so.1 FFFFFFFF7DB50000 8K rwx-- /lib/sparcv9/libc.so.1 FFFFFFFF7DC00000 576K r-x-- /lib/sparcv9/libm.so.2 FFFFFFFF7DC90000 8K r-x-- /lib/sparcv9/libm.so.2 FFFFFFFF7DD00000 64K rwx-- FFFFFFFF7DD90000 32K rwx-- /lib/sparcv9/libm.so.2 FFFFFFFF7DE00000 56K r-x-- /lib/sparcv9/libsocket.so.1 FFFFFFFF7DF00000 8K rwx-- FFFFFFFF7DF0E000 16K rwx-- /lib/sparcv9/libsocket.so.1 FFFFFFFF7E000000 640K r-x-- /lib/sparcv9/libnsl.so.1 FFFFFFFF7E0A0000 48K r-x-- /lib/sparcv9/libnsl.so.1 FFFFFFFF7E100000 24K rwx-- FFFFFFFF7E1AC000 64K rwx-- /lib/sparcv9/libnsl.so.1 FFFFFFFF7E1BC000 32K rwx-- /lib/sparcv9/libnsl.so.1 FFFFFFFF7E200000 8K r-x-- /lib/sparcv9/libdl.so.1 FFFFFFFF7E302000 8K rwx-- /lib/sparcv9/libdl.so.1 FFFFFFFF7E400000 128K r-x-- /opt/local/lib/libpcre.so.1.0.1 FFFFFFFF7E420000 40K r-x-- /opt/local/lib/libpcre.so.1.0.1 FFFFFFFF7E500000 8K rwx-- FFFFFFFF7E528000 8K rwx-- /opt/local/lib/libpcre.so.1.0.1 FFFFFFFF7E600000 128K r-x-- /lib/sparcv9/libumem.so.1 FFFFFFFF7E620000 16K r-x-- /lib/sparcv9/libumem.so.1 FFFFFFFF7E700000 8K rwx-- FFFFFFFF7E724000 40K rwx-- /lib/sparcv9/libumem.so.1 FFFFFFFF7E72E000 40K rwx-- /lib/sparcv9/libumem.so.1 FFFFFFFF7E800000 64K r-x-- /opt/varnish/lib/varnish/libvgz.so FFFFFFFF7E810000 56K r-x-- /opt/varnish/lib/varnish/libvgz.so FFFFFFFF7E900000 24K r-x-- /lib/sparcv9/libthread.so.1 FFFFFFFF7E91C000 8K rwx-- /opt/varnish/lib/varnish/libvgz.so FFFFFFFF7EA00000 128K r-x-- /opt/varnish/lib/varnish/libvcl.so FFFFFFFF7EA20000 32K r-x-- /opt/varnish/lib/varnish/libvcl.so FFFFFFFF7EB00000 16K r-x-- /lib/sparcv9/libpthread.so.1 FFFFFFFF7EB26000 16K rwx-- /opt/varnish/lib/varnish/libvcl.so FFFFFFFF7EC00000 8K r-x-- /opt/varnish/lib/varnish/libvarnishcompat.so FFFFFFFF7ED00000 8K rwx-- /opt/varnish/lib/varnish/libvarnishcompat.so FFFFFFFF7EE00000 32K r-x-- /lib/sparcv9/librt.so.1 FFFFFFFF7EF00000 8K rwx-- FFFFFFFF7EF08000 8K rwx-- /lib/sparcv9/librt.so.1 FFFFFFFF7F000000 64K r-x-- /opt/varnish/lib/varnish/libvarnish.so FFFFFFFF7F010000 56K r-x-- /opt/varnish/lib/varnish/libvarnish.so FFFFFFFF7F100000 8K rwx-- FFFFFFFF7F11C000 8K rwx-- /opt/varnish/lib/varnish/libvarnish.so FFFFFFFF7F200000 8K rwx-- FFFFFFFF7F300000 8K rwx-- FFFFFFFF7F400000 8K rw--- FFFFFFFF7F500000 8K rw--- FFFFFFFF7F600000 192K r-x-- /lib/sparcv9/ld.so.1 FFFFFFFF7F630000 48K r-x-- /lib/sparcv9/ld.so.1 FFFFFFFF7F700000 8K rwx-- FFFFFFFF7F70C000 8K rwx-- FFFFFFFF7F73C000 24K rwx-- /lib/sparcv9/ld.so.1 FFFFFFFF7FFC0000 256K rw--- [ stack ] total 90920K }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 10:08:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 10:08:26 -0000 Subject: [Varnish] Password reset for user: tfheen Message-ID: Password reset for user for user tfheen -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 10:09:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 10:09:45 -0000 Subject: [Varnish] #1177: Child will not start on Solaris died signal=10 (core dumped) In-Reply-To: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> References: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> Message-ID: <059.1a4398656fadf9a1a5e801b340472f12@varnish-cache.org> #1177: Child will not start on Solaris died signal=10 (core dumped) --------------------------+-------------------- Reporter: karnak | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: port:solaris | Version: 3.0.2 Severity: normal | Resolution: Keywords: Solaris | --------------------------+-------------------- Changes (by phk): * owner: => slink * component: build => port:solaris -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 10:28:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 10:28:16 -0000 Subject: [Varnish] #1169: Varnishadmin trnucates the output of param.show -l In-Reply-To: <052.3052098d8261daec89ce9318fee50f89@varnish-cache.org> References: <052.3052098d8261daec89ce9318fee50f89@varnish-cache.org> Message-ID: <067.d193e8db1a18d54c5681902600a73ec2@varnish-cache.org> #1169: Varnishadmin trnucates the output of param.show -l --------------------------------------------+--------------------- Reporter: desperate_john | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: varnish-trunk revision 7d9ca7d | --------------------------------------------+--------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 10:34:44 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 10:34:44 -0000 Subject: [Varnish] #1173: Help, varnish makes my session lose In-Reply-To: <046.8a493d50735d23909f96f79d8983c9d0@varnish-cache.org> References: <046.8a493d50735d23909f96f79d8983c9d0@varnish-cache.org> Message-ID: <061.165662d9833e59e49b7e477baf2202d1@varnish-cache.org> #1173: Help, varnish makes my session lose ----------------------------------+------------------------- Reporter: cche5425 | Owner: Type: defect | Status: closed Priority: highest | Milestone: Component: website | Version: 3.0.0 Severity: critical | Resolution: worksforme Keywords: varnish session lost | ----------------------------------+------------------------- Changes (by scoof): * status: new => closed * resolution: => worksforme Comment: This does not look like a bug, but a misconfiguration. Please use the varnish-misc mailing list for such issues: https://www.varnish- cache.org/community/mailing-lists You should also review the wiki and documentation, in particular https://www.varnish-cache.org/docs/3.0/tutorial/cookies.html https://www.varnish-cache.org/trac/wiki/VCLExampleCacheCookies https://www.varnish-cache.org/trac/wiki/VCLExampleCachingLoggedInUsers -- Ticket URL: Varnish The Varnish HTTP Accelerator From jinjian.1 at gmail.com Thu Jul 19 02:18:00 2012 From: jinjian.1 at gmail.com (=?UTF-8?B?6YeR5YmR?=) Date: Thu, 19 Jul 2012 10:18:00 +0800 Subject: Varnish Streaming Bug? Message-ID: Hi, Varnish version is: 3.0.2. When Varnish received a large(>50k) chunked & gziped response, sometimes it will report 20 FetchError c Invalid Gzip data: invalid code lengths set And 23 FetchError c Invalid Gzip data: invalid block type Does any others encounter this issue? Best Regards! Jian Jin -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Mon Jul 30 12:54:09 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 12:54:09 -0000 Subject: [Varnish] #1178: Varnish should add Vary: Accept-Encoding when compressing content Message-ID: <043.f8e3add5fe2d9de34f59397c4cedbe58@varnish-cache.org> #1178: Varnish should add Vary: Accept-Encoding when compressing content --------------------+------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- When gzipping content on fetch, varnish should add a Accept-Encoding to the Vary header. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 13:02:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 13:02:33 -0000 Subject: [Varnish] #1172: Varnish sends inconsistent Vary to downstream caches In-Reply-To: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> References: <043.118f02d3c76ba2b879c0e99bd34a5ff8@varnish-cache.org> Message-ID: <058.7285ad1243a64b2d4e5aea81042eb159@varnish-cache.org> #1172: Varnish sends inconsistent Vary to downstream caches --------------------+------------------------- Reporter: RuddO | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------- Changes (by scoof): * status: new => closed * resolution: => worksforme Comment: In this particular instance, it looks like a backend problem. If you look at the second request without an Accept-Encoding header, the backend does not return a proper Vary. There is, however an issue where varnish does not produce a proper Vary header when compressing the response from an uncompressed backend response. I've opened #1178 for this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 14:33:36 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 14:33:36 -0000 Subject: [Varnish] New user registration: turok Message-ID: New user registration for user turok -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 14:35:19 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 14:35:19 -0000 Subject: [Varnish] #1179: Defend Your System Message-ID: <043.b1d416d173eda352a06f873aaee40ad4@varnish-cache.org> #1179: Defend Your System -------------------------------+-------------------- Reporter: turok | Type: defect Status: new | Priority: low Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: system, soft, web | -------------------------------+-------------------- Quite a few computer system operators aren't fully mindful about what is [http://www.malwarewiki.org/Main_Page malware]. Malware is an especially programmed type of code which has the potential of making its way into the computer. It may destabilize computer's performance or maybe steal important info from computer. Different kinds of malicious software may include things like a computer virus, spyware, adware, Trojan horse and so forth. You will find a large number of powerful methods of combating malevolent software well before a lot of damage is done. The web based environment is packed with lots of malware scan and antimalware resources that help you get rid of all of issues and make your computer system infections free. In most situations, malicious software intrude your computer while you get data from the internet. This is also true if you use file sharing clients such as Kaaza, LimeWire,, Azures as well as Utorrent client etc. Most of the times, the origin of downloaded information is not trustworthy and the end user won't have simple ways of finding this out. The end result is that the person eventually ends up inviting lots of problems on computer by means of malevolent software. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 14:43:38 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 14:43:38 -0000 Subject: [Varnish] Deleted User: turok Message-ID: Deleted User for user turok -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 14:44:48 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 14:44:48 -0000 Subject: [Varnish] #1179: Defend Your System In-Reply-To: <043.b1d416d173eda352a06f873aaee40ad4@varnish-cache.org> References: <043.b1d416d173eda352a06f873aaee40ad4@varnish-cache.org> Message-ID: <058.6f10c49732f1cdd16be3b9926bcd0760@varnish-cache.org> #1179: Defend Your System -------------------------------+---------------------- Reporter: turok | Owner: Type: defect | Status: closed Priority: low | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: invalid Keywords: system, soft, web | -------------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Old description: > Quite a few computer system operators aren't fully mindful about what is > [http://www.malwarewiki.org/Main_Page malware]. Malware is an especially > programmed type of code which has the potential of making its way into > the computer. It may destabilize computer's performance or maybe steal > important info from computer. Different kinds of malicious software may > include things like a computer virus, spyware, adware, Trojan horse and > so forth. > You will find a large number of powerful methods of combating malevolent > software well before a lot of damage is done. The web based environment > is packed with lots of malware scan and antimalware resources that help > you get rid of all of issues and make your computer system infections > free. > In most situations, malicious software intrude your computer while you > get data from the internet. This is also true if you use file sharing > clients such as Kaaza, LimeWire,, Azures as well as Utorrent client etc. > Most of the times, the origin of downloaded information is not > trustworthy and the end user won't have simple ways of finding this out. > The end result is that the person eventually ends up inviting lots of > problems on computer by means of malevolent software. New description: Spam, spam, spam, egg and spam. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 15:24:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 15:24:52 -0000 Subject: [Varnish] #1131: Strange bug with if/lookup - else/pass in vcl_recv In-Reply-To: <049.eecbfc45a96523cf173c9f229a4e2cac@varnish-cache.org> References: <049.eecbfc45a96523cf173c9f229a4e2cac@varnish-cache.org> Message-ID: <064.e0c316744b900bc73562e933016a3a3e@varnish-cache.org> #1131: Strange bug with if/lookup - else/pass in vcl_recv -------------------------+------------------------- Reporter: Guillaume.S | Owner: 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: Hi ! It's done, we found how fix it. Our infrastructure : VH : Varnish ACE : Cisco ACE WEBS : Thousand web servers (Apache) WEBX : web server Step by step : 1?? VH <-> ACE <-> WEBS 2?? VH --> ACE (Cookie? Yes:Set-Cookie=$cookie, No:Set-Cookie=newcookie()) --> WEBX 3?? VH --- ACE Transparent mode --> WEBX 4?? VH <-- ACE Transparent mode --- WEBX Some responses were back from backend to VH without "Set-Cookie" field. Web servers had keep-alive enable, so when VH reuse connections, step2 was ignored. We had disable keep-alive connections on web servers, and all is fine :) Guile. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 15:53:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 15:53:51 -0000 Subject: [Varnish] #1175: -smalloc size limit failures does not increment the c_fail counter, but adds failed bytes to it In-Reply-To: <044.58f144b9b4eb28dfdaa21e6af9077a7e@varnish-cache.org> References: <044.58f144b9b4eb28dfdaa21e6af9077a7e@varnish-cache.org> Message-ID: <059.c1d5419308e8f41035be678d49a4fd0e@varnish-cache.org> #1175: -smalloc size limit failures does not increment the c_fail counter, but adds failed bytes to it ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [610d3cbee4fd6b1e2ca6c84ef385beae07f56144]: {{{ #!CommitTicketReference repository="" revision="610d3cbee4fd6b1e2ca6c84ef385beae07f56144" I have no idea how I ended up incrementting the fail counter by the size of the request, probably sleep copy&paste ? Fixed #1175 Submitted by: martin }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 15:58:08 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 15:58:08 -0000 Subject: [Varnish] #1176: varnishd segfaults if no storage backend has been defined In-Reply-To: <044.359689bc726e4977b127817ced20225c@varnish-cache.org> References: <044.359689bc726e4977b127817ced20225c@varnish-cache.org> Message-ID: <059.d9571ba1dce09c0883bedc1d8d2e048b@varnish-cache.org> #1176: varnishd segfaults if no storage backend has been defined ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): I cannot reproduce this on -trunk, is this a 3.0.x only issue ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 15:59:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 15:59:02 -0000 Subject: [Varnish] #1175: -smalloc size limit failures does not increment the c_fail counter, but adds failed bytes to it In-Reply-To: <044.58f144b9b4eb28dfdaa21e6af9077a7e@varnish-cache.org> References: <044.58f144b9b4eb28dfdaa21e6af9077a7e@varnish-cache.org> Message-ID: <059.2a1172985c044d4f63b26a26d7a612be@varnish-cache.org> #1175: -smalloc size limit failures does not increment the c_fail counter, but adds failed bytes to it ----------------------+--------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 16:35:54 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 16:35:54 -0000 Subject: [Varnish] #1159: bad IP address in test In-Reply-To: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> References: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> Message-ID: <060.dd12eb7ee37f6ee71d684f8bbfb604b0@varnish-cache.org> #1159: bad IP address in test -------------------------+--------------------- Reporter: jdrusch | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.2 Severity: minor | Resolution: Keywords: | -------------------------+--------------------- Comment (by Poul-Henning Kamp ): In [ffa30f0490d6e2b59204757ddbdc7f032d64ce3a]: {{{ #!CommitTicketReference repository="" revision="ffa30f0490d6e2b59204757ddbdc7f032d64ce3a" Change our chosen "bad_ip" to 192.0.2.255 which is a broadcast address from RFC5737's TEST-NET-1 and put a comment there to explain. I fear this is a loosing battle, but at least this is more "official" than the previous "10.255.255.255" choice. Fixes #1159 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 16:36:22 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 16:36:22 -0000 Subject: [Varnish] #1159: bad IP address in test In-Reply-To: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> References: <045.3364ad2809a6f81e737fc49a2174112a@varnish-cache.org> Message-ID: <060.6807bbd01833e313610e62c398a21eff@varnish-cache.org> #1159: bad IP address in test -------------------------+--------------------- Reporter: jdrusch | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 3.0.2 Severity: minor | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 16:46:09 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 16:46:09 -0000 Subject: [Varnish] #1171: Timing information for each backend request / ESI In-Reply-To: <045.16d0c099d0dcd079914c1157d1344194@varnish-cache.org> References: <045.16d0c099d0dcd079914c1157d1344194@varnish-cache.org> Message-ID: <060.8dd835c803643ea5f2c10132af7e6cf4@varnish-cache.org> #1171: Timing information for each backend request / ESI --------------------------------+------------------------------ Reporter: derjohn | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: esi derjohn timing | --------------------------------+------------------------------ Changes (by phk): * status: new => closed * resolution: => invalid Comment: I'm closing this ticket as "invalid" because we only use tickets for genuine bugs and track feature-requests in the Future_* wiki pages. But in this case, you don't need to put it in the Wiki pages, since this is already in the works in -trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 30 20:05:22 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jul 2012 20:05:22 -0000 Subject: [Varnish] New user registration: eltlhnsc Message-ID: New user registration for user eltlhnsc -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 06:29:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 06:29:21 -0000 Subject: [Varnish] New user registration: test Message-ID: New user registration for user test -- Varnish The Varnish HTTP Accelerator From phk at phk.freebsd.dk Mon Jul 30 15:28:18 2012 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 30 Jul 2012 15:28:18 +0000 Subject: inconsistent output from debug.backend / debug.health In-Reply-To: Your message of "Tue, 03 Apr 2012 10:48:06 MST." Message-ID: <23179.1343662098@critter.freebsd.dk> In message , Nathan Mehl writes: >Context: we have varnish fronting for a pool of servers that >(semi-)automatically scale based on load criteria. A puppet job updates a >vcl file defining all of the directors any time a server is added or >removed from the pool, and then reloads the VCL. We have recently added an "administrative health" setting to Varnish and I think you should use that instead to selectively enable and disable backends. >debug.backend: > >0x7f83618dfc00 cms_director[0](10.251.39.31,(null),:8080) 3 0 >0x7f51686f8840 cms_director[1](10.62.87.78,(null),:8080) 2 2 >0x7f516848f480 cms_director[0](10.62.87.78,(null),:8080) 5 1 We try to recognize when a new VCL has the _exact_ same backend definition as another loaded VCL, so that we can reuse that instance of the backend (and any cached open connections etc) For that to work, the backend definition must be _exactly_ the same, token for token. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Mon Jul 30 15:31:21 2012 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 30 Jul 2012 15:31:21 +0000 Subject: req.backend.healthy in VCL deliver is not always available and causes crash In-Reply-To: Your message of "Wed, 14 Mar 2012 10:04:47 +0100." <64EE172A-8FF6-43A7-9617-763CACDB56ED@digmia.com> Message-ID: <24024.1343662281@critter.freebsd.dk> In message <64EE172A-8FF6-43A7-9617-763CACDB56ED at digmia.com>, Michal Paal write s: >We have found a problem with req.backend.healthy information. Yes, that looks like a bug, please open a ticket for it. Can you give us a recipe for reproducing it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From varnish-bugs at varnish-cache.org Tue Jul 31 06:30:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 06:30:51 -0000 Subject: [Varnish] Deleted User: test Message-ID: Deleted User for user test -- Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 08:06:10 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 08:06:10 -0000 Subject: [Varnish] #1156: first_byte_timeout is "doubled" on the client side when keep-alive is used In-Reply-To: <041.241bf6dcc23aa9f0c29f48821fcf593f@varnish-cache.org> References: <041.241bf6dcc23aa9f0c29f48821fcf593f@varnish-cache.org> Message-ID: <056.a37b6854e9ab36951170e043c1e7d92d@varnish-cache.org> #1156: first_byte_timeout is "doubled" on the client side when keep-alive is used ----------------------+-------------------- Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [feac37150e5820cb36b0181811a47b957cd9b51c]: {{{ #!CommitTicketReference repository="" revision="feac37150e5820cb36b0181811a47b957cd9b51c" Don't do automatic backend retry if we have received anything from the backend at all. The retry is only (pseudo-)valid when we have not received anything at all, indicating that the backend closed before it got our request. Also don't retry if we sent the request body (not part of test-case). Fixes #1156 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 08:06:11 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 08:06:11 -0000 Subject: [Varnish] #1156: first_byte_timeout is "doubled" on the client side when keep-alive is used In-Reply-To: <041.241bf6dcc23aa9f0c29f48821fcf593f@varnish-cache.org> References: <041.241bf6dcc23aa9f0c29f48821fcf593f@varnish-cache.org> Message-ID: <056.a069f2dfb09d4204ac2617a309188b1f@varnish-cache.org> #1156: first_byte_timeout is "doubled" on the client side when keep-alive is used ----------------------+--------------------- Reporter: tnt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [feac37150e5820cb36b0181811a47b957cd9b51c]) Don't do automatic backend retry if we have received anything from the backend at all. The retry is only (pseudo-)valid when we have not received anything at all, indicating that the backend closed before it got our request. Also don't retry if we sent the request body (not part of test-case). Fixes #1156 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 08:51:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 08:51:00 -0000 Subject: [Varnish] #1054: Child not responding to CLI, killing it In-Reply-To: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> References: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> Message-ID: <061.97018fc4e4c885f49d273b07a07851fc@varnish-cache.org> #1054: Child not responding to CLI, killing it ---------------------------+----------------------- Reporter: scorillo | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Changes (by phk): * component: varnishd => documentation Comment: This needs to go into docs somewhere. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 08:53:31 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 08:53:31 -0000 Subject: [Varnish] #906: Varnish 2.1.x packages for el5 are not signed In-Reply-To: <042.81612be9473485b62d21cc39a5a1ac73@varnish-cache.org> References: <042.81612be9473485b62d21cc39a5a1ac73@varnish-cache.org> Message-ID: <057.ad5a6a50dab59384b48b61416cd6c8e2@varnish-cache.org> #906: Varnish 2.1.x packages for el5 are not signed ------------------------------+---------------------- Reporter: maxp | Owner: tfheen Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: wontfix Keywords: gpg rpm security | ------------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: This seems a settled issue to me, and there is no value in keeping this non-actionable ticket open. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 21:58:22 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 21:58:22 -0000 Subject: [Varnish] #1180: Restart in vcl_miss increases miss count even for hits and passes. Message-ID: <043.71c1a3fa3d2e6ef741b0d3c2e99e38f1@varnish-cache.org> #1180: Restart in vcl_miss increases miss count even for hits and passes. -------------------+-------------------- Reporter: david | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | -------------------+-------------------- Hello, I believe I have located another bug in Varnish Cache. This is similar to and follows Trac # 965. My code hashes all requests based on client.ip to see if the user has a cached ban on their IP. If they do not, we restart the request and hash normally. The problem with this is that I end up with far more cache_misses than I had requests: client_conn 749 6.35 Client connections accepted client_req 749 6.35 Client requests received cache_hit 75 0.64 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 1365 11.57 Cache misses s_pass 52 0.44 Total pass This is the VCL that reproduces the problem: sub vcl_recv { if (req.http.X-LJ-Banned ~ "sysban-ip") { return (lookup); } elseif (req.restarts == 0) { set req.http.X-LJ-Banned = "check"; return (lookup); } } sub vcl_hash { if (req.http.X-LJ-Banned && req.restarts > 0) { hash_data(client.ip); return (hash); } } sub vcl_miss { if (req.http.X-LJ-Banned == "check") { remove req.http.X-LJ-Banned; error 988; } } sub vcl_error { if (obj.status == 988) { return (restart); } } I left out the vcl_fetch code since it is not required to reproduce this problem. I assume showing more cache misses than the total number of requests is not intentional and is something that should be fixed. Warm Regards, David Newhall -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 21:59:11 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 21:59:11 -0000 Subject: [Varnish] #1180: Restart in vcl_miss increases miss count even for hits and passes. In-Reply-To: <043.71c1a3fa3d2e6ef741b0d3c2e99e38f1@varnish-cache.org> References: <043.71c1a3fa3d2e6ef741b0d3c2e99e38f1@varnish-cache.org> Message-ID: <058.7877ac6a713df1cf61044af85ef57f62@varnish-cache.org> #1180: Restart in vcl_miss increases miss count even for hits and passes. --------------------+-------------------- Reporter: david | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by david): Apparently all my copy/pastes were formatted how trac wanted and not how I expected. Sorry for that. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 31 22:19:17 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 Jul 2012 22:19:17 -0000 Subject: [Varnish] #1180: Restart in vcl_miss increases miss count even for hits and passes. In-Reply-To: <043.71c1a3fa3d2e6ef741b0d3c2e99e38f1@varnish-cache.org> References: <043.71c1a3fa3d2e6ef741b0d3c2e99e38f1@varnish-cache.org> Message-ID: <058.028fa25cc4edf55b879c1204c10b3950@varnish-cache.org> #1180: Restart in vcl_miss increases miss count even for hits and passes. --------------------+---------------------- Reporter: david | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: invalid Keywords: | --------------------+---------------------- Changes (by scoof): * status: new => closed * resolution: => invalid Comment: Not a bug. A cache miss means that the lookup in the cache missed, it does not indicate whether or not a cached object was served to the requestor in the end. -- Ticket URL: Varnish The Varnish HTTP Accelerator