From varnish-bugs at varnish-cache.org Mon Apr 2 12:22:36 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Apr 2012 12:22:36 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) Message-ID: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) ------------------------------------------------------------------------------+ Reporter: campisano | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: blocker Keywords: child died pushing vcls failed #012CLI communication error (hdr) | ------------------------------------------------------------------------------+ Hi, I have a problem with the current version of varnish: two (or three) times it became 'freezed' with this log message: Mar 30 05:16:56 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:06 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:16 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:26 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:36 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:46 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) died signal=3 Mar 30 05:17:55 macleod varnishd[4423]: Child cleanup complete Mar 30 05:17:56 macleod varnishd[4423]: child (8349) Started Mar 30 05:18:06 macleod varnishd[4423]: Pushing vcls failed:#012CLI communication error (hdr) Mar 30 05:18:06 macleod varnishd[4423]: Stopping Child Mar 30 05:18:06 macleod varnishd[4423]: Child (8349) said Child starts Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said SMF.s0 mmap'ed 5368709120 bytes of 5368709120 Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said Child dies Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) died status=1 Mar 30 05:18:18 macleod varnishd[4423]: Child cleanup complete The main process was still active, but it didn't accept connection on incoming port (simples go in timeout, wasn't refused). I only have the 'strange' varnishstat -1 log in attachment, how can I increment the 'verbosity' of varnish ? Thanks in advantage, Riccardo -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 2 12:25:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Apr 2012 12:25:03 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <056.dd2aab4e1136a2a3bb324dd5bca8c0dd@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) ------------------------------------------------------------------------------+ Reporter: campisano | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: blocker Keywords: child died pushing vcls failed #012CLI communication error (hdr) | ------------------------------------------------------------------------------+ Comment(by campisano): Sorry :\ {{{ Mar 30 05:16:56 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:06 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:16 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:26 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:36 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:46 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) died signal=3 Mar 30 05:17:55 macleod varnishd[4423]: Child cleanup complete Mar 30 05:17:56 macleod varnishd[4423]: child (8349) Started Mar 30 05:18:06 macleod varnishd[4423]: Pushing vcls failed:#012CLI communication error (hdr) Mar 30 05:18:06 macleod varnishd[4423]: Stopping Child Mar 30 05:18:06 macleod varnishd[4423]: Child (8349) said Child starts Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said SMF.s0 mmap'ed 5368709120 bytes of 5368709120 Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said Child dies Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) died status=1 Mar 30 05:18:18 macleod varnishd[4423]: Child cleanup complete }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 2 15:52:39 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Apr 2012 15:52:39 -0000 Subject: [Varnish] #1120: Too many variants will crash varnish Message-ID: <043.b453568250b2299558ca6342b681fdb3@varnish-cache.org> #1120: Too many variants will crash varnish ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Keywords: ----------------------+----------------------------------------------------- A user running with Vary: User-Agent made varnish crash with the following assert: I assume that it's due to too many variants. Could/shouldn't this be handled more gracefully? {{{ Last panic at: Mon, 02 Apr 2012 15:14:06 GMT Assert error in VRY_Match(), cache_vary.c line 216: Condition(vsp + ln + 2 < sp->vary_e) not true. thread = (cache-worker) ident = Linux,3.0.18-linode43,i686,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x8078305: /usr/sbin/varnishd [0x8078305] 0x807ea4e: /usr/sbin/varnishd(VRY_Match+0x28e) [0x807ea4e] 0x8070106: /usr/sbin/varnishd(HSH_Lookup+0x476) [0x8070106] 0x805b515: /usr/sbin/varnishd [0x805b515] 0x805f8cb: /usr/sbin/varnishd(CNT_Session+0xc3b) [0x805f8cb] 0x807b23f: /usr/sbin/varnishd [0x807b23f] 0x807a1b2: /usr/sbin/varnishd [0x807a1b2] 0x807a7e5: /usr/sbin/varnishd [0x807a7e5] 0x4361c832: /lib/libpthread.so.0 [0x4361c832] 0x4356d4de: /lib/libc.so.6(clone+0x5e) [0x4356d4de] sp = 0x6e1ae004 { fd = 49, id = 49, xid = 517674481, client = 75.67.168.122 53918, step = STP_LOOKUP, handling = hash, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 flags = bodystatus = 4 ws = 0x6e1ae054 { id = "sess", {s,f,r,e} = {0x6e1ae7b8,+16380,+16384,+16384}, }, http[req] = { ws = 0x6e1ae054[sess] "GET", "/wp-content/plugins/wp-polls/polls-css.css?ver=2.50", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0.1) Gecko/20100101 Firefox/9.0.1", "Accept: text/css,*/*;q=0.1", "Accept-Language: en-us,en;q=0.5", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Connection: keep-alive", "If-Modified-Since: Sat, 31 Mar 2012 01:13:27 GMT", "If-None-Match: "4f4be-b13-aa11bbc0"", "X-Forwarded-For: 75.67.168.122", "Accept-Encoding: gzip", }, worker = 0x6e293048 { ws = 0x6e29321c { id = "wrk", {s,f,r,e} = {0x6e28d000,0x6e28d000,(nil),+16384}, }, }, vcl = { srcname = { "input", "Default", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 3 06:40:14 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Apr 2012 06:40:14 -0000 Subject: [Varnish] #1121: Escaped double quote mark within a regex is not recognized Message-ID: <046.147b29dc39d34edc936f027d9f6f391a@varnish-cache.org> #1121: Escaped double quote mark within a regex is not recognized ----------------------+----------------------------------------------------- Reporter: gnotaras | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- I tried to use the following check (taken from the mod_security's core ruleset) to detect command injection attacks. The vcl compiler throws an error. default.vcl: {{{ if (req.url ~ "(?:(?:[\;\|\`]\W*?\bcc|\b(wget|curl))\b|\/cc(?:[\'\"\|\;\`\-\s]|$))") { error 403 "Forbidden"; } }}} vcl compiler error: {{{ # varnishd -f default.vcl -d Message from VCC-compiler: Syntax error at ('input' Line 124 Pos 72) if (req.url ~ "(?:(?:[\;\|\`]\W*?\bcc|\b(wget|curl))\b|\/cc(?:[\'\"\|\;\`\-\s]|$))") { -----------------------------------------------------------------------#------------------ Running VCC-compiler failed, exit 1 VCL compilation failed }}} If I remove the escaped double quote from within the regex, the rule becomes: {{{ req.url ~ "(?:(?:[\;\|\`]\W*?\bcc|\b(wget|curl))\b|\/cc(?:[\'\|\;\`\-\s]|$))" }}} And the vcl compiler validates it properly without errors. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 3 13:41:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Apr 2012 13:41:29 -0000 Subject: [Varnish] #1121: Escaped double quote mark within a regex is not recognized In-Reply-To: <046.147b29dc39d34edc936f027d9f6f391a@varnish-cache.org> References: <046.147b29dc39d34edc936f027d9f6f391a@varnish-cache.org> Message-ID: <055.d63dc98d88ee491e5af5292f16203bf5@varnish-cache.org> #1121: Escaped double quote mark within a regex is not recognized ----------------------+----------------------------------------------------- Reporter: gnotaras | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by ruben): @gnotaras You should try and see if Security VCL doesn't already do what you are trying to achieve: https://github.com/comotion/security.vcl Good luck! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 3 14:24:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Apr 2012 14:24:43 -0000 Subject: [Varnish] #1122: Backwards example in ESI documentation Message-ID: <051.d5180c83165975cdc200b44fb850485d@varnish-cache.org> #1122: Backwards example in ESI documentation ---------------------------+------------------------------------------------ Reporter: MatthewWilkes | Type: documentation Status: new | Priority: low Milestone: | Component: documentation Version: trunk | Severity: trivial Keywords: | ---------------------------+------------------------------------------------ From: https://www.varnish-cache.org/docs/trunk/tutorial/esi.html {{{ Example: ~~~~~~~~~~~~~~~~~~~~~~~~ This is a special construct to allow HTML marked up with ESI to render without processing. ESI Processors will remove the start ("") when the page is processed, while still processing the contents. If the page is not processed, it will remain, becoming an HTML/XML comment tag. For example:: This assures that the ESI markup will not interfere with the rendering of the final HTML if not processed. }}} The example here says ESI Disabled, but will only be rendered when ESI is enabled. It seems to be an example for instead. The text should be changed to a real world example, like hiding explanatory text: {{{ }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 3 14:32:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Apr 2012 14:32:45 -0000 Subject: [Varnish] #1121: Escaped double quote mark within a regex is not recognized In-Reply-To: <046.147b29dc39d34edc936f027d9f6f391a@varnish-cache.org> References: <046.147b29dc39d34edc936f027d9f6f391a@varnish-cache.org> Message-ID: <055.e51df9dbae2bd91773ca3e3b63ca3ef3@varnish-cache.org> #1121: Escaped double quote mark within a regex is not recognized ----------------------+----------------------------------------------------- Reporter: gnotaras | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by gnotaras): @ruben, thanks for your suggestion. It is an excellent project! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 3 16:10:31 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Apr 2012 16:10:31 -0000 Subject: [Varnish] #1123: VGZ_WrwGunzip mangles output in trunk Message-ID: <044.24c29928fd58165e12884c3c404c9c4a@varnish-cache.org> #1123: VGZ_WrwGunzip mangles output in trunk --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Current trunk mangles output when gunziping content for the client. Bug not present in 3.0.2 and before, and is caused by lack of resetting the output buffer on explicit flushed. Introduced with new gzip buffer handling. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 5 11:29:38 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 05 Apr 2012 11:29:38 -0000 Subject: [Varnish] #1124: Document Cache-Control private/no-cache behaviour Message-ID: <046.efd3b140d66579698a8653ee733c7d45@varnish-cache.org> #1124: Document Cache-Control private/no-cache behaviour ----------------------+----------------------------------------------------- Reporter: timbunce | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- I couldn't find any documentation on how beresp.ttl is calculated. (I believe it the first of ?s-maxage? in Cache-Control, ?max-age? in Cache- Control or the Expire header.) I was wondering because I also couldn't find any documentation on if/how varnish interacts with private/no-cache clauses in the Cache-Control header. I found https://www.varnish-cache.org/trac/wiki/VCLExampleHitMissHeader which is described as "add extra diagnostic headers" but actually changes the behavior to implement support for Cache-Control private. That made me worry that Cache-Control private wasn't implemented by default. Then I found https://www.varnish-cache.org/trac/ticket/477 which confirmed it. I was very surprised. After some digging I see that in https://www.varnish- cache.org/lists/pipermail/varnish-misc/2007-November/001173.html PHK says "Varnish is not a cache in the RFC2616 sense." I'm pretty sure that statement would be a surprise to many. I can understand your choice here, and I respect that. However I think it's important to document this choice, and the implications, very clearly. Especially as it makes the default behavior _unsafe_ when used by someone not aware of this issue. Ideally I'd like to see: * A clear statement in the docs about what varnish is and isn't, and why. For example, statements like "Varnish is not a cache in the RFC2616 sense, so it's unlike most traditional reverse proxies. It's more like a web server that gets it's content via HTTP" and "For example, the private and no-cache clauses in the Cache-Control: header are ignored." * An official example VCL for correct implementation of Cache-Control private/no-cache etc clauses per RFC2616 (or as near as possible). * Add details to the varnish book. Currently it doesn't mention the behavior re Cache-Control private/no-cache anywhere that I could find. E.g., it's not mentioned in https://www.varnish- software.com/static/book/HTTP.html#cache-related-headers (Though it is implied in one of the exercises https://www.varnish- software.com/static/book/VCL_Basics.html?highlight=private#exercise-vcl- avoid-caching-a-page) Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 5 12:14:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 05 Apr 2012 12:14:53 -0000 Subject: [Varnish] #477: Change defaults to respect Cache-Control: private In-Reply-To: <042.288a3b208ec24cf984b16c1aa6870aa4@varnish-cache.org> References: <042.288a3b208ec24cf984b16c1aa6870aa4@varnish-cache.org> Message-ID: <051.7408df70f1eee2c5fec6bb48499cbbab@varnish-cache.org> #477: Change defaults to respect Cache-Control: private ----------------------+----------------------------------------------------- Reporter: olau | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ----------------------+----------------------------------------------------- Comment(by timbunce): For the record, see also https://www.varnish-cache.org/trac/ticket/1124 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 5 14:08:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 05 Apr 2012 14:08:16 -0000 Subject: [Varnish] #1124: Document Cache-Control private/no-cache behaviour In-Reply-To: <046.efd3b140d66579698a8653ee733c7d45@varnish-cache.org> References: <046.efd3b140d66579698a8653ee733c7d45@varnish-cache.org> Message-ID: <055.e7eab0f8adc069cbe1804ee76a446d8a@varnish-cache.org> #1124: Document Cache-Control private/no-cache behaviour ----------------------+----------------------------------------------------- Reporter: timbunce | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by timbunce): For the record, everyone I've mentioned this to has responded with statements of surprise (ranging from "Wow" to "Oh shit!"). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 9 18:49:41 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Apr 2012 18:49:41 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <056.82110ed8c315bfda65bca481d4b7ddf2@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) ------------------------------------------------------------------------------+ Reporter: campisano | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: blocker Keywords: child died pushing vcls failed #012CLI communication error (hdr) | ------------------------------------------------------------------------------+ Comment(by arn): I'm seeing a similar issue. Varnish 3.0.2 / Centos 5. I've seen Varnish 3.0.2 freeze, not respond to requests. Also have trouble restarting it. {{{Apr 9 14:34:20 web4 varnishd[28609]: Child (28611) not responding to CLI, killing it. Apr 9 14:34:26 web4 last message repeated 2 times Apr 9 14:34:26 web4 varnishd[28609]: Child (28611) died signal=3 Apr 9 14:34:26 web4 varnishd[28609]: child (9154) Started Apr 9 14:34:26 web4 varnishd[28609]: Child (9154) said Child starts Apr 9 14:35:03 web4 varnishd[28609]: Child (9154) not responding to CLI, killing it. Apr 9 14:35:33 web4 last message repeated 3 times Apr 9 14:36:14 web4 last message repeated 5 times Apr 9 14:36:14 web4 varnishd[28609]: Child (9154) died signal=3 Apr 9 14:36:14 web4 varnishd[28609]: child (10178) Started Apr 9 14:36:15 web4 varnishd[28609]: Child (10178) said Child starts Apr 9 14:37:02 web4 varnishd[28609]: Child (10178) not responding to CLI, killing it. Apr 9 14:37:11 web4 last message repeated 2 times Apr 9 14:37:11 web4 varnishd[28609]: Child (10178) died signal=3 Apr 9 14:37:11 web4 varnishd[28609]: child (10487) Started Apr 9 14:37:12 web4 varnishd[28609]: Child (10487) said Child starts Apr 9 14:37:28 web4 varnishd[28609]: Child (10487) not responding to CLI, killing it. Apr 9 14:37:47 web4 last message repeated 3 times Apr 9 14:37:47 web4 varnishd[28609]: Child (10487) died signal=3 Apr 9 14:37:47 web4 varnishd[28609]: child (10823) Started Apr 9 14:37:47 web4 varnishd[28609]: Child (10823) said Child starts }}} @campisano : you don't happen to be using NewRelic, are you? The timing of these freezes (3 in the last month) was after we had started using newrelic on this machine. not sure if that's just coincidence. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 9 21:00:24 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Apr 2012 21:00:24 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <056.bd27fbc81c1e3e43a362212954a9649a@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) ------------------------------------------------------------------------------+ Reporter: campisano | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: blocker Keywords: child died pushing vcls failed #012CLI communication error (hdr) | ------------------------------------------------------------------------------+ Comment(by campisano): @arn : I'm not using NewRelic. Your log have not the message "Pushing vcls failed:#012CLI": the message "Child (XXXX) not responding to CLI, killing it." could be common, I read in some place that can be a timeout issue with your backend service (ex apache): if apache response time is greather then the maximum timeout of the varnish worker, the varnish controller can kill it and stop the request. You can increase the default timeout config on your varnish config file, like this example: .connect_timeout = 5s; .first_byte_timeout = 10s; I hope this can help. BTW I don't know the default values... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 10 13:12:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Apr 2012 13:12:32 -0000 Subject: [Varnish] #1003: Fix libedit (libreadline) support for FreeBSD In-Reply-To: <044.97ea0cb79c8172ef6b88dc23843a837c@varnish-cache.org> References: <044.97ea0cb79c8172ef6b88dc23843a837c@varnish-cache.org> Message-ID: <053.d3f71e507bf60a4c378992863e024851@varnish-cache.org> #1003: Fix libedit (libreadline) support for FreeBSD -------------------------+-------------------------------------------------- Reporter: anders | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [9dc28b2ce920274432da72f78419562d9365bc2b]) Fix libedit detection on *BSD OS's The following patch allows the autoconf script to detect the presence of libedit when there isn't a pkg-config file present and thus allowing Varnish to detect libedit on OpenBSD/FreeBSD/NetBSD/DragonFly. Fixes: #1003 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 10 14:39:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Apr 2012 14:39:33 -0000 Subject: [Varnish] #1109: Gzip+ESI are broken for large included objects In-Reply-To: <044.d9ed1bba65805b3b22e3040f63c29ee9@varnish-cache.org> References: <044.d9ed1bba65805b3b22e3040f63c29ee9@varnish-cache.org> Message-ID: <053.0d7a8d86107d4d6bf04991b3507aa6ca@varnish-cache.org> #1109: Gzip+ESI are broken for large included objects ----------------------+----------------------------------------------------- Reporter: nimnul | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: Fixed by commit e6d7f462483e518400c8a0ae151ed70438b3a56c -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 11 11:12:58 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Apr 2012 11:12:58 -0000 Subject: [Varnish] #1120: Too many variants will crash varnish In-Reply-To: <043.b453568250b2299558ca6342b681fdb3@varnish-cache.org> References: <043.b453568250b2299558ca6342b681fdb3@varnish-cache.org> Message-ID: <052.e728b26c23db15f74299a4afb7e7f05f@varnish-cache.org> #1120: Too many variants will crash varnish ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by chadw): After normalizing the user agent, upping limits, and switching to disk from malloc, I'm still seeing this error. Any idea what's causing this so I can attempt a workaround? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 12 08:09:20 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Apr 2012 08:09:20 -0000 Subject: [Varnish] #1113: Backend HTTP status is used when hitting max_restarts after fetch In-Reply-To: <043.af89d41c041964c89ea3c31ccbdf8526@varnish-cache.org> References: <043.af89d41c041964c89ea3c31ccbdf8526@varnish-cache.org> Message-ID: <052.7d23949231d0ea059510a1cdff8910b6@varnish-cache.org> #1113: Backend HTTP status is used when hitting max_restarts after fetch ----------------------+----------------------------------------------------- Reporter: scoof | Owner: martin 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 [480c0a5d0b7b11e8e6b66f90dd66a2d8b22d235f]) Go over the return(restart) code. This is vastly inspired by #1113 and scoof+martins testcase+patch. Add a new cnt* state "cnt_restart" to do the mandatory restart work, and to move the restart limit check out of vcl_recv{}, getting rid of a nasty XXX comment. Set the explicit 503 when over limit, reset in other cases. Expand scoof+martins test-case to cover more vcl methods, which were also affected, but not fixed in their patch. Fixes #1113 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 12 11:01:36 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Apr 2012 11:01:36 -0000 Subject: [Varnish] #1125: Unresolved string as first parameter to regsub causes VCL compiler to segfault Message-ID: <044.0f689d70f6765a49eceb5b26a57e24fe@varnish-cache.org> #1125: Unresolved string as first parameter to regsub causes VCL compiler to segfault --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Keywords: --------------------+------------------------------------------------------- A typo for the first argument to regsub (e.g. 'regsub(reg.url,...)') causes the VCL compiler to segfault. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 12 11:26:09 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Apr 2012 11:26:09 -0000 Subject: [Varnish] #1126: ACL entry with five octets causes VCL compiler to segfault Message-ID: <044.28d1b9edc5034db6f977ab7be1f57432@varnish-cache.org> #1126: ACL entry with five octets causes VCL compiler to segfault --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Keywords: --------------------+------------------------------------------------------- An ACL entry of five octets (or a trailing dot) will cause the VCL compiler to segfault. E.g. {{ acl a { "127.0.0.0.1"; } }} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 12 11:27:09 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Apr 2012 11:27:09 -0000 Subject: [Varnish] #1126: ACL entry with five octets causes VCL compiler to segfault In-Reply-To: <044.28d1b9edc5034db6f977ab7be1f57432@varnish-cache.org> References: <044.28d1b9edc5034db6f977ab7be1f57432@varnish-cache.org> Message-ID: <053.b3789b49ed5e5faa124f24757250f7e0@varnish-cache.org> #1126: ACL entry with five octets causes VCL compiler to segfault --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by martin: Old description: > An ACL entry of five octets (or a trailing dot) will cause the VCL > compiler to segfault. > > E.g. > {{ > acl a { "127.0.0.0.1"; } > }} New description: An ACL entry of five octets (or a trailing dot) will cause the VCL compiler to segfault. E.g. {{{ acl a { "127.0.0.0.1"; } }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 14 14:15:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 14 Apr 2012 14:15:49 -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.7f23411fe0f611884647908d699ad6f4@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu ----------------------+----------------------------------------------------- Reporter: askalski | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: sess_mem leak n_sess race condition ----------------------+----------------------------------------------------- Comment(by mark): I've ported the patch to 3.0.2 (attached), but it does not seem to fix a session leak we're experiencing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 14 20:18:19 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 14 Apr 2012 20:18:19 -0000 Subject: [Varnish] #1127: Documentation processing removes backref prefixes Message-ID: <049.9139b04db44b691fb0734de9e4923d2e@varnish-cache.org> #1127: Documentation processing removes backref prefixes --------------------------------------+------------------------------------- Reporter: jpluscplusm | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: minor Keywords: vcl regsub documentation | --------------------------------------+------------------------------------- Whatever turns the raw form of the VCL docs into https://www.varnish- cache.org/docs/3.0/reference/vcl.html#functions has swallowed the backslash prefix for the "\0, "\&" and "\n" backrefs in the regsub function defintion. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 07:05:39 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 07:05:39 -0000 Subject: [Varnish] #1126: ACL entry with five octets causes VCL compiler to segfault In-Reply-To: <044.28d1b9edc5034db6f977ab7be1f57432@varnish-cache.org> References: <044.28d1b9edc5034db6f977ab7be1f57432@varnish-cache.org> Message-ID: <053.70f0cf2f482bdf66abf625252afdaa71@varnish-cache.org> #1126: ACL entry with five octets causes VCL compiler to segfault --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [10f1de6232d60c8cd2d9081a7680dad857c6d5aa]) Fix #1126 by properly setting the mask token to the IP number token. Varnishtest doesn't see the difference between a VCC core dump and a VCC error, so a test-case is non-trivial. Fixes #1126 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 07:12:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 07:12:32 -0000 Subject: [Varnish] #1125: Unresolved string as first parameter to regsub causes VCL compiler to segfault In-Reply-To: <044.0f689d70f6765a49eceb5b26a57e24fe@varnish-cache.org> References: <044.0f689d70f6765a49eceb5b26a57e24fe@varnish-cache.org> Message-ID: <053.fdeba1743e20d186570cccb5624c4369@varnish-cache.org> #1125: Unresolved string as first parameter to regsub causes VCL compiler to segfault --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [35475f8c5db39fa47a0d5862f00737ccd9985575]) Missing errorchecks incompilation of regsub() Fixes #1125 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 07:14:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 07:14:33 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <056.781c1c22404e178ebc807c22c7b6a721@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) ------------------------------------------------------------------------------+ Reporter: campisano | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: blocker Keywords: child died pushing vcls failed #012CLI communication error (hdr) | ------------------------------------------------------------------------------+ Description changed by phk: Old description: > Hi, > > I have a problem with the current version of varnish: two (or three) > times it became 'freezed' with this log message: > > Mar 30 05:16:56 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:06 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:16 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:26 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:36 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:46 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to > CLI, killing it. > Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) died signal=3 > Mar 30 05:17:55 macleod varnishd[4423]: Child cleanup complete > Mar 30 05:17:56 macleod varnishd[4423]: child (8349) Started > Mar 30 05:18:06 macleod varnishd[4423]: Pushing vcls failed:#012CLI > communication error (hdr) > Mar 30 05:18:06 macleod varnishd[4423]: Stopping Child > Mar 30 05:18:06 macleod varnishd[4423]: Child (8349) said Child starts > Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said SMF.s0 mmap'ed > 5368709120 bytes of 5368709120 > Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said Child dies > Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) died status=1 > Mar 30 05:18:18 macleod varnishd[4423]: Child cleanup complete > > The main process was still active, but it didn't accept connection on > incoming port (simples go in timeout, wasn't refused). > > I only have the 'strange' varnishstat -1 log in attachment, how can I > increment the 'verbosity' of varnish ? > > Thanks in advantage, > Riccardo New description: Hi, I have a problem with the current version of varnish: two (or three) times it became 'freezed' with this log message: {{{ Mar 30 05:16:56 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:06 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:16 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:26 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:36 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:46 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) not responding to CLI, killing it. Mar 30 05:17:55 macleod varnishd[4423]: Child (17381) died signal=3 Mar 30 05:17:55 macleod varnishd[4423]: Child cleanup complete Mar 30 05:17:56 macleod varnishd[4423]: child (8349) Started Mar 30 05:18:06 macleod varnishd[4423]: Pushing vcls failed:#012CLI communication error (hdr) Mar 30 05:18:06 macleod varnishd[4423]: Stopping Child Mar 30 05:18:06 macleod varnishd[4423]: Child (8349) said Child starts Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said SMF.s0 mmap'ed 5368709120 bytes of 5368709120 Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) said Child dies Mar 30 05:18:18 macleod varnishd[4423]: Child (8349) died status=1 Mar 30 05:18:18 macleod varnishd[4423]: Child cleanup complete }}} The main process was still active, but it didn't accept connection on incoming port (simples go in timeout, wasn't refused). I only have the 'strange' varnishstat -1 log in attachment, how can I increment the 'verbosity' of varnish ? Thanks in advantage, Riccardo -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 07:22:42 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 07:22:42 -0000 Subject: [Varnish] #1095: Assert error in SMS_Finish(), storage_synth.c line 114: In-Reply-To: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> References: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> Message-ID: <061.f210a650b26f4736e34e507b2ff9dba8@varnish-cache.org> #1095: Assert error in SMS_Finish(), storage_synth.c line 114: ---------------------------------+------------------------------------------ Reporter: alex.goncharov | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: varnishd SMS_Finish | ---------------------------------+------------------------------------------ Comment(by phk): The basic problem is a malloc() failure, so check your ulimits and similar. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 07:47:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 07:47:59 -0000 Subject: [Varnish] #1055: Long values of shm_reclen is unsafe In-Reply-To: <046.5d807a3a4de8e140197e920ca285cb4b@varnish-cache.org> References: <046.5d807a3a4de8e140197e920ca285cb4b@varnish-cache.org> Message-ID: <055.f6664b0239cb6831e7b21a40d7134c8c@varnish-cache.org> #1055: Long values of shm_reclen is unsafe ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I think this has been overtaken by events with the changed memory design on -trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 10:10:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 10:10:26 -0000 Subject: [Varnish] #1112: Varnish delivers truncated files when serving from Tomcat7 Backend and ESI enabled In-Reply-To: <045.a494717a9dcd83966ef7bb1fb1473262@varnish-cache.org> References: <045.a494717a9dcd83966ef7bb1fb1473262@varnish-cache.org> Message-ID: <054.486d24f2cad567190fe7457ca78aceb6@varnish-cache.org> #1112: Varnish delivers truncated files when serving from Tomcat7 Backend and ESI enabled ---------------------+------------------------------------------------------ Reporter: derjohn | Owner: scoof Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Keywords: ---------------------+------------------------------------------------------ Changes (by scoof): * owner: => scoof Comment: From discussions, it would seem that tomcat7 does not deliver chunked, and there are no indications that this is anything other than a timeout issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 12:18:20 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 12:18:20 -0000 Subject: [Varnish] #1127: Documentation processing removes backref prefixes In-Reply-To: <049.9139b04db44b691fb0734de9e4923d2e@varnish-cache.org> References: <049.9139b04db44b691fb0734de9e4923d2e@varnish-cache.org> Message-ID: <058.17d52a05ed57a9a407bdf3aa8c894c69@varnish-cache.org> #1127: Documentation processing removes backref prefixes --------------------------+------------------------------------------------- Reporter: jpluscplusm | Type: defect Status: closed | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: minor Resolution: fixed | Keywords: vcl regsub documentation --------------------------+------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Thanks, just fixed it now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 12:27:54 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 12:27:54 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <056.679c17398b55d01f7f2b51ad05ce1416@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) ------------------------------------------------------------------------------+ Reporter: campisano | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: blocker Keywords: child died pushing vcls failed #012CLI communication error (hdr) | ------------------------------------------------------------------------------+ Comment(by phk): The underlying cause is very likely disk-activity pileup, but the exact cause can be many different things. You can try making the cli_timeout longer, maybe a minute, and see if that changes the picture. Making it longer than a minute is probably not sensible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 12:28:54 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 12:28:54 -0000 Subject: [Varnish] #1112: Varnish delivers truncated files when serving from Tomcat7 Backend and ESI enabled In-Reply-To: <045.a494717a9dcd83966ef7bb1fb1473262@varnish-cache.org> References: <045.a494717a9dcd83966ef7bb1fb1473262@varnish-cache.org> Message-ID: <054.2f888aed558cdc7925b042ad9c955768@varnish-cache.org> #1112: Varnish delivers truncated files when serving from Tomcat7 Backend and ESI enabled ---------------------+------------------------------------------------------ Reporter: derjohn | Owner: scoof Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Keywords: ---------------------+------------------------------------------------------ Description changed by phk: Old description: > Hello, > in our setup we have a varnish in front of several Tomcat7. When Tomcat7 > delivers static content, it uses chunked tranfers. > > We'hit by a bug in that combination. The user gets the static content > (e.g. jquery.js) and receives a 200 status, but the content sometimes (!) > is not transferred completely. E.G. there jquery.js get truncated after > some kilobytes. My observation was, that this happens mostly (only?) if > the backend is reused. > > In the logs I see such error msgs, which correlate to the error: > > 19 Debug c Hit send timeout, wrote = 11680/21115; retrying > 19 Debug c Write error, retval = -1, len = 9435, errno = > Resource temporarily unavailable > > To test I use a simple script like that and look if the outputs is always > the same or not: > > for i in $(seq 1 1000); do curl -s -x "" -k > 'http://$HOST/...011_jquery-1.7.1.js' | md5sum ; done > > I tried varnish 3.0.2 and some newer trunks, the effect is still the > same. > > The same setup runs with the same config with varnish2.1.5 fine. (I had > to adapt the config parts of ESI enabling, as the syntax changed from 2.x > to 3.x). > > rgds, > derjohn New description: Hello, in our setup we have a varnish in front of several Tomcat7. When Tomcat7 delivers static content, it uses chunked tranfers. We'hit by a bug in that combination. The user gets the static content (e.g. jquery.js) and receives a 200 status, but the content sometimes (!) is not transferred completely. E.G. there jquery.js get truncated after some kilobytes. My observation was, that this happens mostly (only?) if the backend is reused. In the logs I see such error msgs, which correlate to the error: {{{ 19 Debug c Hit send timeout, wrote = 11680/21115; retrying 19 Debug c Write error, retval = -1, len = 9435, errno = Resource temporarily unavailable }}} To test I use a simple script like that and look if the outputs is always the same or not: {{{ for i in $(seq 1 1000); do curl -s -x "" -k 'http://$HOST/...011_jquery-1.7.1.js' | md5sum ; done }}} I tried varnish 3.0.2 and some newer trunks, the effect is still the same. The same setup runs with the same config with varnish2.1.5 fine. (I had to adapt the config parts of ESI enabling, as the syntax changed from 2.x to 3.x). rgds, derjohn -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 14:07:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 14:07:37 -0000 Subject: [Varnish] #1120: Too many variants will crash varnish In-Reply-To: <043.b453568250b2299558ca6342b681fdb3@varnish-cache.org> References: <043.b453568250b2299558ca6342b681fdb3@varnish-cache.org> Message-ID: <052.87e368a189cee5f3501909a47eadcd0e@varnish-cache.org> #1120: Too many variants will crash varnish ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [0679d603fe4dad3027206f0cb272cd9c4aedb557]) Be much more cautious about how much workspace we have to build predictive vary string. Fixes #1120 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 14:08:58 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 14:08:58 -0000 Subject: [Varnish] #1117: error - varnishncsa[473]: segfault at 0 ip 00007fd645a00022 In-Reply-To: <047.78536ce4e57383a6a091e8d8777b70f6@varnish-cache.org> References: <047.78536ce4e57383a6a091e8d8777b70f6@varnish-cache.org> Message-ID: <056.e79aef337ccc2b66008fffd7dc46489f@varnish-cache.org> #1117: error - varnishncsa[473]: segfault at 0 ip 00007fd645a00022 -----------------------+---------------------------------------------------- Reporter: webmaster | Type: defect Status: new | Priority: highest Milestone: | Component: varnishncsa Version: 3.0.0 | Severity: critical Keywords: | -----------------------+---------------------------------------------------- Description changed by phk: Old description: > Hi All, the below pasted are the messages (/var/log/messages) i am > getting in my server and everytime this message comes, the varnishncsa > services gets stopped. I would appreciate if anybody could help us and > let us know a solution for this. > > 12.so[7f40e8b5c000+175000] > Mar 24 20:39:28 slonj360c kernel: varnishncsa[2298]: segfault at 0 ip > 00007f4e8f762022 sp 00007fff49b88d58 error 4 in > libc-2.12.so[7f4e8f6e2000+175000] > Mar 25 03:46:47 slonj360c kernel: varnishncsa[29073]: segfault at 0 ip > 00007f329746b022 sp 00007fff67ce9b18 error 4 in > libc-2.12.so[7f32973eb000+175000] > Mar 25 06:37:19 slonj360c kernel: varnishncsa[10802]: segfault at 0 ip > 00007f63be1d1022 sp 00007fff5b286678 error 4 in > libc-2.12.so[7f63be151000+175000] > Mar 25 13:17:45 slonj360c kernel: varnishncsa[3473]: segfault at 0 ip > 00007fe666026022 sp 00007fff09f51978 error 4 in > libc-2.12.so[7fe665fa6000+175000] > Mar 25 19:40:16 slonj360c kernel: varnishncsa[473]: segfault at 0 ip > 00007fd645a00022 sp 00007fff578004a8 error 4 in > libc-2.12.so[7fd645980000+175000] New description: Hi All, the below pasted are the messages (/var/log/messages) i am getting in my server and everytime this message comes, the varnishncsa services gets stopped. I would appreciate if anybody could help us and let us know a solution for this. {{{ 12.so[7f40e8b5c000+175000] Mar 24 20:39:28 slonj360c kernel: varnishncsa[2298]: segfault at 0 ip 00007f4e8f762022 sp 00007fff49b88d58 error 4 in libc-2.12.so[7f4e8f6e2000+175000] Mar 25 03:46:47 slonj360c kernel: varnishncsa[29073]: segfault at 0 ip 00007f329746b022 sp 00007fff67ce9b18 error 4 in libc-2.12.so[7f32973eb000+175000] Mar 25 06:37:19 slonj360c kernel: varnishncsa[10802]: segfault at 0 ip 00007f63be1d1022 sp 00007fff5b286678 error 4 in libc-2.12.so[7f63be151000+175000] Mar 25 13:17:45 slonj360c kernel: varnishncsa[3473]: segfault at 0 ip 00007fe666026022 sp 00007fff09f51978 error 4 in libc-2.12.so[7fe665fa6000+175000] Mar 25 19:40:16 slonj360c kernel: varnishncsa[473]: segfault at 0 ip 00007fd645a00022 sp 00007fff578004a8 error 4 in libc-2.12.so[7fd645980000+175000] }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 14:19:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 14:19:49 -0000 Subject: [Varnish] #1123: VGZ_WrwGunzip mangles output in trunk In-Reply-To: <044.24c29928fd58165e12884c3c404c9c4a@varnish-cache.org> References: <044.24c29928fd58165e12884c3c404c9c4a@varnish-cache.org> Message-ID: <053.c62e085ba5250de27051bff95878189c@varnish-cache.org> #1123: VGZ_WrwGunzip mangles output in trunk --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [f992125b545fdd1d090941f2ee8b7c9cd6c29dc8]) Reset output buffer on VGZ_WrwFlush() Fixes: #1123 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 16 16:54:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Apr 2012 16:54:32 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <056.15f540b59786091aff9750899213fe5c@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) ------------------------------------------------------------------------------+ Reporter: campisano | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: blocker Keywords: child died pushing vcls failed #012CLI communication error (hdr) | ------------------------------------------------------------------------------+ Comment(by campisano): Hi phk, I had increase the connect_timeout to 5s few days ago. What's the defalut value for it? BTW, I don't consider the message 'Child (17381) not responding to CLI, killing it.' a problem in my case, 'Pushing vcls failed:#012CLI communication error (hdr)' appear more interesting but the problem is that the varnish was freezed at all. Did you seen the log file in attachment? Thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 17 09:27:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Apr 2012 09:27:52 -0000 Subject: [Varnish] #1118: Varnish docs should elaborate on ESI SRC a bite more In-Reply-To: <045.1c6a71deda4de08b9c60868f7e45de22@varnish-cache.org> References: <045.1c6a71deda4de08b9c60868f7e45de22@varnish-cache.org> Message-ID: <054.e7db0a502a310fd75e4b90eb11c647c0@varnish-cache.org> #1118: Varnish docs should elaborate on ESI SRC a bite more ---------------------------+------------------------------------------------ Reporter: derjohn | Owner: scoof Type: documentation | Status: new Priority: normal | Milestone: Component: documentation | Version: 3.0.0 Severity: normal | Keywords: ---------------------------+------------------------------------------------ Changes (by scoof): * owner: => scoof Comment: There are no known ESI specific limits, so I'm not sure what you want us to document? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 18 19:45:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Apr 2012 19:45:26 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <052.1bfb5dd352c8da5e5468250291e168f9@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+----------------------------------------------------- Reporter: acdha | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Keywords: ----------------------+----------------------------------------------------- Comment(by acdha): @phk: is there anything we could do to help with debugging? I have enough redundancy to be able to run a diagnostic build or verify a patch under load if that would be useful. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 18 19:52:57 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Apr 2012 19:52:57 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <052.7958d7ddd150a6756612f461e7eaa4ae@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+----------------------------------------------------- Reporter: acdha | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Keywords: ----------------------+----------------------------------------------------- Comment(by eikeon): @cc -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 10:07:24 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 10:07:24 -0000 Subject: [Varnish] #575: Python Tools Enhancement In-Reply-To: <047.95fe56a68edf7ef669084bc4b47f21e1@varnish-cache.org> References: <047.95fe56a68edf7ef669084bc4b47f21e1@varnish-cache.org> Message-ID: <056.5c4c0a94c0b6cd546ff1b4fbf38e23f7@varnish-cache.org> #575: Python Tools Enhancement --------------------------------+------------------------------------------- Reporter: justquick | Owner: kristian Type: enhancement | Status: closed Priority: low | Milestone: Component: varnishadm | Version: trunk Severity: minor | Resolution: worksforme Keywords: python enhancement | --------------------------------+------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Old description: > I have revamped the Python interface to the Varnish management port into > a more robust application. I have written a new module (python-varnish) > and have posted it on github. Here are some of the features: > > * Uses `telnetlib` instead of raw sockets > * Implements `threading` module > * Can run commands across multiple Varnish instances > * More comprehensive methods, closely matching the management API > (purge_*, vcl_*, etc.) > * Unittests > > The code is available at [http://github.com/justquick/python-varnish > http://github.com/justquick/python-varnish] > > This implementation is currently in use in production for > [http://www.washingtontimes.com The Washington Times] > > It is part of an upcoming release of a project of mine using this module > in conjunction with [http://www.djangoproject.com the django web > framework]. > > Python-Varnish is under the New BSD license and I would be willing to > commit this module into your trunk. > > Contact me: justquick [@] gmail.com New description: I have revamped the Python interface to the Varnish management port into a more robust application. I have written a new module (python-varnish) and have posted it on github. Here are some of the features: * Uses `telnetlib` instead of raw sockets * Implements `threading` module * Can run commands across multiple Varnish instances * More comprehensive methods, closely matching the management API (purge_*, vcl_*, etc.) * Unittests The code is available at [http://github.com/justquick/python-varnish http://github.com/justquick/python-varnish] This implementation is currently in use in production for [http://www.washingtontimes.com The Washington Times] It is part of an upcoming release of a project of mine using this module in conjunction with [http://www.djangoproject.com the django web framework]. Python-Varnish is under the New BSD license and I would be willing to commit this module into your trunk. Contact me: justquick [@] gmail.com -- Comment: We decided at VUG5 that the python-API (and for that matter other $LANG- APIs) will not live in the Varnishd distribution, for a number of good reasons. This ticket therefore belongs whereever the python-API will be maintained, and we close it here. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 10:10:28 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 10:10:28 -0000 Subject: [Varnish] #805: Negative ReqEnd accept time (ESI enabled) and hanging request In-Reply-To: <044.509d9294d033556339c411a50e9af4f6@varnish-cache.org> References: <044.509d9294d033556339c411a50e9af4f6@varnish-cache.org> Message-ID: <053.3901a720427b560d8e8b61854a506f75@varnish-cache.org> #805: Negative ReqEnd accept time (ESI enabled) and hanging request ----------------------+----------------------------------------------------- Reporter: tesdal | Owner: phk 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 Comment: None of the e*vtc testcases does this in -trunk, so I belive we have fixed it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 10:27:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 10:27:37 -0000 Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors In-Reply-To: <045.b50cb54e3bd5afe3e9a281f9de622d6f@varnish-cache.org> References: <045.b50cb54e3bd5afe3e9a281f9de622d6f@varnish-cache.org> Message-ID: <054.519c833302b5ac06855e05be8de553e3@varnish-cache.org> #864: Varnishlog crashes when searching for 503 errors ------------------------+--------------------------------------------------- Reporter: kriller | Owner: Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishlog | Version: 2.1.5 Severity: normal | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => worksforme Comment: This seems to have mysteriously have gone away now. Can't reproduce under heavy load any more... Please re-open if you still have issues like this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 10:46:38 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 10:46:38 -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.5ac7171819a44e0307095a21c74c89cd@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu ----------------------+----------------------------------------------------- Reporter: askalski | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: sess_mem leak n_sess race condition ----------------------+----------------------------------------------------- Comment(by martin): For leaking sessions you might also want to try out the patch 8306db9a95c7b3022fdeee038b1e6973f46382f9. This is not applicable in trunk, but this patch will go into the next 3.0 release. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 11:46:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 11:46:29 -0000 Subject: [Varnish] #1026: varnishd immediate segfault on armv7, seeminly strict-aliasing violations In-Reply-To: <041.58951bc1bacb408becb240d0e7491fac@varnish-cache.org> References: <041.58951bc1bacb408becb240d0e7491fac@varnish-cache.org> Message-ID: <050.1df163b53e71ec93b526b678c1d063c4@varnish-cache.org> #1026: varnishd immediate segfault on armv7, seeminly strict-aliasing violations --------------------------------------+------------------------------------- Reporter: hno | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: strict-aliasing segfault | --------------------------------------+------------------------------------- Comment(by phk): Sorry about the delay in getting to this. I don't have an arm platform to test this on, so I'm a little bit handicapped with respect to reproducing the bug. I am pretty certain that the TAILQ_LAST macro works in FreeBSD on the arm platform, so I am not quite sure what to make of this panic. It is true that TAILQ_LAST does some non-nice pointer-gymnastics, but as far as I know, they are strictly pointer to pointer, so they should be safe. Can I get you to pull down a -trunk source tree, and use the autoconf.des file and see what happens then ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 14:04:46 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 14:04:46 -0000 Subject: [Varnish] #1017: ESI includes not getting parsed due to faulty comments In-Reply-To: <045.981863e14617d6b1135311ff58c5c5c9@varnish-cache.org> References: <045.981863e14617d6b1135311ff58c5c5c9@varnish-cache.org> Message-ID: <054.6d2a70ab8b67de08c24c7d7d658c4941@varnish-cache.org> #1017: ESI includes not getting parsed due to faulty comments -------------------------+-------------------------------------------------- Reporter: ddunlop | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: normal Resolution: worksforme | Keywords: esi, parsing -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Sorry about not getting to this earlier. I think Varnish behaves sensibly in this case, it sees the beginning of a comment, and ignores everything up to the end of a comment. The definition of a comment in XML is {{{ Comment ::= '' }}} (See: http://www.w3.org/TR/REC-xml/#sec-comments) Which specifically does not allow for a minus right before the "end of comment" sequence, (which is what causes the trouble in the example you show) so the comment never ends and Varnish does not process ESI inside comments. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 14:46:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 14:46:16 -0000 Subject: [Varnish] #1128: GZIP encoding with multiple members Message-ID: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> #1128: GZIP encoding with multiple members --------------------------------------------+------------------------------- Reporter: zviratko | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: gzip encoding multiple streams | --------------------------------------------+------------------------------- GZIP RFC allows multiple streams to be concatenated and then decompressed as one. Varnish fails in this scenario with: {{{ FetchError c straight read_error: -1 0 (Junk after gzip data) }}} Client is served a 503. In my case, the data in question is a JSON response made from two chunks, each compressed in application and served as one response (with correct headers and length). I confirmed the data is fine, and it works fine in browsers (apart from chrome/chromium that has a bug here as well). The only solution around this not serving it compressed to varnish, or using pipe. Attached is an example that causes this bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 14:49:28 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 14:49:28 -0000 Subject: [Varnish] #1128: GZIP encoding with multiple members In-Reply-To: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> References: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> Message-ID: <055.8606acd4e6c859a8eac05604dda5eb62@varnish-cache.org> #1128: GZIP encoding with multiple members -------------------------+-------------------------------------------------- Reporter: zviratko | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: worksforme | Keywords: gzip encoding multiple streams -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Yes, the RFC allows it, but none of the web-browsers I examined support it, so I decided that Varnish should not either. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 14:52:34 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 14:52:34 -0000 Subject: [Varnish] #1128: GZIP encoding with multiple members In-Reply-To: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> References: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> Message-ID: <055.18663ede98340af192d609f617d1dcf3@varnish-cache.org> #1128: GZIP encoding with multiple members -----------------------+---------------------------------------------------- Reporter: zviratko | Type: defect Status: reopened | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: | Keywords: gzip encoding multiple streams -----------------------+---------------------------------------------------- Changes (by zviratko): * status: closed => reopened * resolution: worksforme => Comment: Firefox 11.0 supports it IE8 supports it Chrome fails, but I filed them a separate bug, so I hope they will fix it. you see this for yourself by visiting http://beta.jobs.cz/firma/a and using pagination (it fails in chrome rightaway). But it works in FF and IE without problems. Please consider fixing it, it is only a matter of time before somebody else gets hit by this and it is a PITA to find and debug. While I believe in your KISS approach, it should not hinder bugfixing :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 15:05:09 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 15:05:09 -0000 Subject: [Varnish] #1128: GZIP encoding with multiple members In-Reply-To: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> References: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> Message-ID: <055.c5c515ac629b5e18192833ee57886e87@varnish-cache.org> #1128: GZIP encoding with multiple members -----------------------+---------------------------------------------------- Reporter: zviratko | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: invalid | Keywords: gzip encoding multiple streams -----------------------+---------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => invalid Comment: That's fine, but then it is a feature request, please add it to one of the Future_ wiki pages. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 15:08:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 15:08:59 -0000 Subject: [Varnish] #1128: GZIP encoding with multiple members In-Reply-To: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> References: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> Message-ID: <055.cae819e647507710ba4cac64d9b516fc@varnish-cache.org> #1128: GZIP encoding with multiple members -----------------------+---------------------------------------------------- Reporter: zviratko | Type: defect Status: reopened | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: | Keywords: gzip encoding multiple streams -----------------------+---------------------------------------------------- Changes (by zviratko): * status: closed => reopened * resolution: invalid => Comment: Nope, this breaks expected RFC functionality - it is a bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 15:37:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 15:37:35 -0000 Subject: [Varnish] #1128: GZIP encoding with multiple members In-Reply-To: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> References: <046.6e1d5301d9f6ad3d58164ff54c5eb2b4@varnish-cache.org> Message-ID: <055.596a2864747d5d6c999f27efc8ad1dc0@varnish-cache.org> #1128: GZIP encoding with multiple members -----------------------+---------------------------------------------------- Reporter: zviratko | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: invalid | Keywords: gzip encoding multiple streams -----------------------+---------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => invalid Comment: Listen, I asked you to put it in a Future_ wiki page because I call it a feature request. You may feel otherwise, but if I call it a feature request, that it is. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 16:17:46 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 16:17:46 -0000 Subject: [Varnish] #1069: `varnishd -C` does not return an appropriate return code In-Reply-To: <046.c09eb74cc1dfb5995c134c2376eb7e55@varnish-cache.org> References: <046.c09eb74cc1dfb5995c134c2376eb7e55@varnish-cache.org> Message-ID: <055.e5773a204c8ba5ee4241e4a78f7b2659@varnish-cache.org> #1069: `varnishd -C` does not return an appropriate return code -----------------------+---------------------------------------------------- Reporter: erikwebb | Type: defect Status: closed | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [8bf6c6d2891b50b04af463791fc380c359b1d02c]) Also reflect the VCC exit code through if -C is specified. Fixes #1069 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 16:19:14 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 16:19:14 -0000 Subject: [Varnish] #1041: sess_timeout being applied during HTTP request In-Reply-To: <044.b04da0d62332d14ff8ca139f1d963a82@varnish-cache.org> References: <044.b04da0d62332d14ff8ca139f1d963a82@varnish-cache.org> Message-ID: <053.331ffa7863cfc6f0f727d2d785f67bc1@varnish-cache.org> #1041: sess_timeout being applied during HTTP request --------------------+------------------------------------------------------- Reporter: insyte | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: duplicate Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: This is indeed identical to #849, closing this so we can track it there. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 16:21:44 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 16:21:44 -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.5b0f2472ea0751d565a5a0e059788a19@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 phk): See also #1041. There are a couple of issues in this: 1. We use sess_timeout also during client->varnish body transfer. It might be better with separate first/between timeouts like we have on the backend side. 2. We don't buffer the body we get from the client, so restart from VCL is never a good idea. 3. We have the automagic "try another fd" pseudo-restart, and it might happen in the middle of a body from the client. This would be less of an issue if 2. is fixed, but we still need a better way to handle that. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 16:27:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 16:27:59 -0000 Subject: [Varnish] #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data In-Reply-To: <044.dedba8f13c20d02f02a39731a1edea7c@varnish-cache.org> References: <044.dedba8f13c20d02f02a39731a1edea7c@varnish-cache.org> Message-ID: <053.9a6985c8130f2025284589edadd07a5e@varnish-cache.org> #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data ----------------------+----------------------------------------------------- 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 Comment: I just checked, this is fixed in -trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 16:36:15 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 16:36:15 -0000 Subject: [Varnish] #1118: Varnish docs should elaborate on ESI SRC a bite more In-Reply-To: <045.1c6a71deda4de08b9c60868f7e45de22@varnish-cache.org> References: <045.1c6a71deda4de08b9c60868f7e45de22@varnish-cache.org> Message-ID: <054.3306749901110e6c3f2e91c948286a8b@varnish-cache.org> #1118: Varnish docs should elaborate on ESI SRC a bite more ---------------------------+------------------------------------------------ Reporter: derjohn | Owner: scoof Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 3.0.0 Severity: normal | Resolution: worksforme Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => worksforme Comment: There are no limits in the ESI code, but obviously you may need backend_workspace (-trunk, worker_workspace <= 3.0x) to hold the URL while it is requested etc. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 16:39:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 16:39:13 -0000 Subject: [Varnish] #1121: Escaped double quote mark within a regex is not recognized In-Reply-To: <046.147b29dc39d34edc936f027d9f6f391a@varnish-cache.org> References: <046.147b29dc39d34edc936f027d9f6f391a@varnish-cache.org> Message-ID: <055.a37d61830fc0c3b2557eaf646a8247e1@varnish-cache.org> #1121: Escaped double quote mark within a regex is not recognized -------------------------+-------------------------------------------------- Reporter: gnotaras | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Resolution: worksforme | Keywords: -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: In general: use "long-strings" in VCL: they don't need quoting for magic chars. {{{ if (req.url ~ {"No Quote Problem "foobar" -- See ? "}) { }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 23 17:07:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Apr 2012 17:07:59 -0000 Subject: [Varnish] #1122: Backwards example in ESI documentation In-Reply-To: <051.d5180c83165975cdc200b44fb850485d@varnish-cache.org> References: <051.d5180c83165975cdc200b44fb850485d@varnish-cache.org> Message-ID: <060.4b1a73307915e4047022d97ce0b596f9@varnish-cache.org> #1122: Backwards example in ESI documentation ----------------------------+----------------------------------------------- Reporter: MatthewWilkes | Type: documentation Status: closed | Priority: low Milestone: | Component: documentation Version: trunk | Severity: trivial Resolution: fixed | Keywords: ----------------------------+----------------------------------------------- Changes (by Andreas Plesner Jacobsen ): * status: new => closed * resolution: => fixed Comment: (In [ad9356a952617bf97a539dfcc686142b7120d7f0]) Clean up docs about esi:remove and