From varnish-bugs at varnish-cache.org Mon Aug 3 07:00:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 07:00:29 -0000 Subject: [Varnish] #1768: Problem with related unset http headers on req In-Reply-To: <043.e49f5eb052d823ef5060f1d4a6d644fd@varnish-cache.org> References: <043.e49f5eb052d823ef5060f1d4a6d644fd@varnish-cache.org> Message-ID: <058.b4721c14d28914003bd70cee39ed00e2@varnish-cache.org> #1768: Problem with related unset http headers on req ----------------------+---------------------------------------- Reporter: boris | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [2bb8ddef13e988216d58b2ed16f40e34db36a0cb]: {{{ #!CommitTicketReference repository="" revision="2bb8ddef13e988216d58b2ed16f40e34db36a0cb" Properly encode HTTP headers with weird characters to C identifiers. Please note that using underscore in HTTP headers is considered a really bad idea because many application frameworks map minus to underscore in environment variables. Fixes: #1768 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 07:23:30 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 07:23:30 -0000 Subject: [Varnish] #1734: segfault after vcl.state cold In-Reply-To: <055.ec7692e32d951e1b1e281c27d6c75658@varnish-cache.org> References: <055.ec7692e32d951e1b1e281c27d6c75658@varnish-cache.org> Message-ID: <070.72a6d8de3a446eb6c2c278cfbf40cc95@varnish-cache.org> #1734: segfault after vcl.state cold ---------------------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: vcl state cold warm | ---------------------------------+---------------------------------- Comment (by phk): Is this still reproducible ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 09:07:18 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 09:07:18 -0000 Subject: [Varnish] #1770: Incomplete parsing of -a options Message-ID: <043.b3943c51c2e5e8aefde5d8d3af079ffb@varnish-cache.org> #1770: Incomplete parsing of -a options ----------------------+----------------------------------- Reporter: Dridi | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: trivial | Keywords: listen proxy protocol ----------------------+----------------------------------- This obviously fails: {{{ $ bin/varnishd/varnishd -d -a 0:0,HTTP/2,PROXY -n $(mktemp -d) Error: Unknown protocol 'HTTP/2' }}} But not the other way around: {{{ $ bin/varnishd/varnishd -d -a 0:0,PROXY,HTTP/2 -n $(mktemp -d) Platform: Linux,4.0.8-200.fc21.x86_64,x86_64,-jnone,-smalloc,-smalloc,-hcritbit 200 287 ----------------------------- Varnish Cache CLI 1.0 ----------------------------- Linux,4.0.8-200.fc21.x86_64,x86_64,-jnone,-smalloc,-smalloc,-hcritbit varnish-trunk revision 6bb6523 Type 'help' for command list. Type 'quit' to close CLI session. Type 'start' to launch worker process. }}} I suppose it might be possible once H2 support lands to combine H?+PROXY, but right now I could check that you have [0,1] protocol in {{{MAC_Arg}}}. This can get confusing if you try to combine H1+PROXY. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 09:15:53 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 09:15:53 -0000 Subject: [Varnish] #1760: varnishstat -w dies if varnish is restarted. In-Reply-To: <046.e8f2d93bd8d8e1b13b5e3d08d51989fc@varnish-cache.org> References: <046.e8f2d93bd8d8e1b13b5e3d08d51989fc@varnish-cache.org> Message-ID: <061.be2d071b189bb278bb65ace546d8d9fc@varnish-cache.org> #1760: varnishstat -w dies if varnish is restarted. -------------------------+--------------------- Reporter: lkarsten | Owner: dridi Type: defect | Status: closed Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by Federico G. Schwindt ): * status: new => closed * resolution: => fixed Comment: In [561b56cececb80337df10b9d1ec2daebd7d28333]: {{{ #!CommitTicketReference repository="" revision="561b56cececb80337df10b9d1ec2daebd7d28333" Remove -w option from varnishstat For continuous updates we can always use a shell loop. Fixes #1760. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 10:42:53 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 10:42:53 -0000 Subject: [Varnish] #1770: Incomplete parsing of -a options In-Reply-To: <043.b3943c51c2e5e8aefde5d8d3af079ffb@varnish-cache.org> References: <043.b3943c51c2e5e8aefde5d8d3af079ffb@varnish-cache.org> Message-ID: <058.3c38c3c6f6a62bd57f1324b5be211579@varnish-cache.org> #1770: Incomplete parsing of -a options ----------------------------------+---------------------------------------- Reporter: Dridi | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: trivial | Resolution: fixed Keywords: listen proxy | protocol | ----------------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [c654ff91a1287d36ac5c61599cb4ae3d6be22236]: {{{ #!CommitTicketReference repository="" revision="c654ff91a1287d36ac5c61599cb4ae3d6be22236" Complain if there are sub-arguments to the -a protocol specs which don't understand them. Fixes: #1770 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 11:09:21 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 11:09:21 -0000 Subject: [Varnish] #1769: RH7 rpm missing In-Reply-To: <043.d7dc6c1662a1be420b6269b668069f8b@varnish-cache.org> References: <043.d7dc6c1662a1be420b6269b668069f8b@varnish-cache.org> Message-ID: <058.bf319f6dbf9f04604429dbaae104b53a@varnish-cache.org> #1769: RH7 rpm missing -----------------------+----------------------- Reporter: fgsch | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Changes (by fgsch): * status: new => assigned * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 11:36:51 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 11:36:51 -0000 Subject: [Varnish] #1771: External VDP filters can't change resp_len on cached objects Message-ID: <043.27e91c9316bcfd1a526056041b6f3036@varnish-cache.org> #1771: External VDP filters can't change resp_len on cached objects ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- If you push a VDP filter in vcl_deliver{} and it needs to change the object's length, changing req->resp_len in either the vmod or the VDP init function will be lost in cnt_vdp() for cached objects. For non-cached objects (bo != NULL) the filter could unset C-L to get away but if we are coming from vcl_hit{} there is no way around it. As per discussion on irc: 12:28 < phk> fgs, yes, right now. That's what I said yesterday: We need to move that C-L thing up before vcl_deliver{} To be addressed post release. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 12:03:57 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 12:03:57 -0000 Subject: [Varnish] #1766: Provide an access to the request stack for ESI subrequests In-Reply-To: <061.1d349b0d533297d66974ace897555d62@varnish-cache.org> References: <061.1d349b0d533297d66974ace897555d62@varnish-cache.org> Message-ID: <076.e7edc142941b9698ec2a729c28aaeff4@varnish-cache.org> #1766: Provide an access to the request stack for ESI subrequests ---------------------------------+---------------------- Reporter: lisachenko.it@? | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: invalid Keywords: ESI, request, stack | ---------------------------------+---------------------- Changes (by daghf): * status: new => closed * resolution: => invalid Comment: Hi In Varnish's ESI processing, the headers of the main object are already on the wire by the time we get around to start handling any of its ESI includes. So any solution involving editing a parent request header from an ESI child request simply isn't going to be possible. Slightly related to this, 4.1 adds a way to pass data from a top level request down to its ESI children. We've added req_top to VCL, which provides read-only access to the top level request's req object. I'll close this ticket now, feel free to start a discussion on the mailing list if you'd like to follow up. Regards, Dag Haavi Finstad -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 3 12:56:10 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Aug 2015 12:56:10 -0000 Subject: [Varnish] #1765: Assert error in HTTP_GetHdrPack() In-Reply-To: <045.4b17d56307161491ce5b016c887e550e@varnish-cache.org> References: <045.4b17d56307161491ce5b016c887e550e@varnish-cache.org> Message-ID: <060.8519ab9fe1ccb95d05ae1075870b3991@varnish-cache.org> #1765: Assert error in HTTP_GetHdrPack() --------------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: major | Resolution: fixed Keywords: Assert error | --------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [b26f9fff4877fbe1001c7f995df98f9241914e12]: {{{ #!CommitTicketReference repository="" revision="b26f9fff4877fbe1001c7f995df98f9241914e12" Don't insist headers have a space after the colon. Fixes #1765 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Aug 5 13:50:11 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 Aug 2015 13:50:11 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) Message-ID: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) -----------------------+-------------------- Reporter: tnt | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.1.0-TP1 | Severity: normal Keywords: | -----------------------+-------------------- On a given backend TCP connection, only the first request will have first_byte_timeout properly applied, all subsequent requests will wait indefinitely long (AFAICT). What I traced so far is that inside vbe_dir_gethdrs, it blocks on VBT_Wait on the second requests because state is STOLEN. And whatever event loop should be processing the STOLEN -> USED transition will not be triggered until a byte is received on the fd, which defeats the first_byte_timeout. (tested on 4.1.0-tp1 only) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Aug 5 14:12:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 Aug 2015 14:12:48 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) In-Reply-To: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> References: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> Message-ID: <056.75a99d050e783e847f1b18318750a846@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) --------------------+------------------------ Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: | --------------------+------------------------ Comment (by Dridi): My comments from the IRC: > my understanding is the following > we should pass a timeout to VBT_Wait, to be used with the underlying cond wait > the cond wait being done in a loop, that means more system calls to re- compute the deadline on each iteration > (which means it would probably not be done this way) > after a vbt wait, we could compute the remaining timeout and pass it to V1F_FetchRespHdr > I don't remember how vcl_pipe deals with timeouts, so that has to be considered too Then I wrote a test case: {{{ varnishtest "honour first-byte timeout on a stolen connection" server s1 { rxreq expect req.url == "/first" txresp -hdr "Connection: keep-alive" rxreq expect req.url == "/stolen" txresp delay 1.5 rxreq expect req.url == "/second" txresp } -start varnish v1 -vcl { backend s1 { .host = "${s1_addr}"; .port = "${s1_port}"; .max_connections = 1; .first_byte_timeout = 1s; } } -start client c1 { txreq -url "/first" rxresp expect resp.status == 200 sema r1 sync 2 sema r2 sync 2 txreq -url "/second" rxresp expect resp.status == 503 } -start client c2 { sema r1 sync 2 txreq -url "/stolen" rxresp expect resp.status == 200 sema r2 sync 2 } -start client c1 -wait }}} And the thing that is puzzling me is that I couldn't make the test pass by moving the '''delay''' right before the last '''txresp''' in s1. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Aug 5 15:10:22 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 Aug 2015 15:10:22 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) In-Reply-To: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> References: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> Message-ID: <056.9268063c806543506f3964c96301fa66@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) --------------------+------------------------ Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: | --------------------+------------------------ Comment (by tnt): New simplified test case : {{{ varnishtest "honour first-byte timeout on a stolen connection" server s1 { rxreq expect req.url == "/first" txresp -hdr "Connection: keep-alive" rxreq expect req.url == "/second" delay 2 txresp } -start varnish v1 -vcl { backend s1 { .host = "${s1_addr}"; .port = "${s1_port}"; .first_byte_timeout = 1s; } } -start client c1 { txreq -url "/first" rxresp expect resp.status == 200 txreq -url "/second" rxresp expect resp.status == 503 } -run }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 6 08:54:43 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Aug 2015 08:54:43 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) In-Reply-To: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> References: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> Message-ID: <056.b06e7db1be3693af178d57cf8eba4504@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) ----------------------+------------------------ Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Changes (by fgsch): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 6 11:37:03 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Aug 2015 11:37:03 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) In-Reply-To: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> References: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> Message-ID: <056.a090bf22147e0c6777d5eedb1085f131@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) ----------------------+------------------------ Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Comment (by Dridi): I didn't understand the problem initially, so your test case explains why I was puzzled in the first place. There's still something wrong however with VBC_Wait for it should be accounted to a timeout, and I still think the first_byte_timeout is the one. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 6 12:16:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Aug 2015 12:16:45 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) In-Reply-To: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> References: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> Message-ID: <056.35c862dd902c507e34f263818fce0079@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) ----------------------+------------------------ Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Comment (by tnt): The way I see it there is two ways to see this : - Either make VBC_Wait account for the timeout (and yes, first_byte would be the one here) then report any unused timeout to the rest of the process like you described. - Ensure VBC_Wait never blocks for long. After all it's mostly a lock/ownership change and the fact this only happens when bytes are exchanged on the fd is a bit weird to me. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 6 17:01:27 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Aug 2015 17:01:27 -0000 Subject: [Varnish] #1769: RH7 rpm missing In-Reply-To: <043.d7dc6c1662a1be420b6269b668069f8b@varnish-cache.org> References: <043.d7dc6c1662a1be420b6269b668069f8b@varnish-cache.org> Message-ID: <058.394dbb590d97b4d80e2fe6e77244323b@varnish-cache.org> #1769: RH7 rpm missing -----------------------+---------------------- Reporter: fgsch | Owner: fgsch Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: fixed Keywords: | -----------------------+---------------------- Changes (by fgsch): * status: assigned => closed * resolution: => fixed Comment: RPM deployed and instructions updated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 6 17:03:06 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Aug 2015 17:03:06 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) In-Reply-To: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> References: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> Message-ID: <056.e411e159d001a56eba768a6935d89a61@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) ----------------------+-------------------- Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by fgsch): * version: 4.1.0-TP1 => trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 7 16:08:16 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Aug 2015 16:08:16 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.b0ffd4e8f21dfaa5634f74f88240df47@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------------- Reporter: geoff | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by geoff): I'm afraid I can't test this patch. Our problem is in 4.0.3, whereas the patch applies to master as of July 26th, and the differences are too large for me to get a successful backport out of the merge conflicts. The patch is also much more comprehensive than just fixing the problem with the 204 response -- it covers a number of different cases concerning delivery, as well as the fetch error regarding backend responses. So I'd like to attempt a simpler patch for 4.0.3 to address the problem with 204 responses. If I'm reading the patch correctly, the essential step for that is in delivery: if resp.status == 204, set the wantbody flag (req->wantbody in 4.0.3) to false and remove the Content-Length header. When the wantbody flag is false, then neither ESI_Deliver() nor any VDP is called, and "Transfer-Encoding: chunked" is not generated. So no response body is delivered, nor any response headers that would require a body to be present. Would that suffice, or am I missing something? I also see `if (wantbody == 0) return;` in ESI delivery; is that necessary as well? If the wantbody flag is false, then it seems to me that delivery would never get to ESI delivery in the first place. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 7 16:09:10 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Aug 2015 16:09:10 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.f9011785de9d7e4ef38862769bc72366@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------------- Reporter: geoff | Owner: Poul-Henning Kamp Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------------- Changes (by geoff): * status: closed => reopened * resolution: fixed => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 7 16:17:57 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Aug 2015 16:17:57 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.ded78f0d0cc76d6650e56605d2117919@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------------- Reporter: geoff | Owner: Poul-Henning Kamp Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------------- Comment (by geoff): BTW, I'd be happy to take ownership of this ticket myself, for a simpler patch to be applied to 4.0.x. phk, if you can give me ACK/NACK as to whether I'm on the right track for a fix, then I'll take it from here. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 10 11:18:39 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Aug 2015 11:18:39 -0000 Subject: [Varnish] #1737: Assert error in SES_Close() In-Reply-To: <045.39de3dbb64534043c894a8b03f8152a8@varnish-cache.org> References: <045.39de3dbb64534043c894a8b03f8152a8@varnish-cache.org> Message-ID: <060.2c6f6823887750abd169019da42b575c@varnish-cache.org> #1737: Assert error in SES_Close() --------------------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: panic assert error | --------------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [9cd4a9004dbc150bce5b98e31339075e5ab79caf]: {{{ #!CommitTicketReference repository="" revision="9cd4a9004dbc150bce5b98e31339075e5ab79caf" The ESI_VDP would double-close sessions when a flush error happened before an ESI include at one level, and then again at a higher level. Fixed by not closing the session in this case, as that will be taken care of at the end of delivery anyways when V1L_FlushRelease is called. Fixes: #1737 Submitted by: Martin }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 10 11:56:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Aug 2015 11:56:26 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.fb931fc5a33a93eabbafaab8f06989b3@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------- Reporter: geoff | Owner: geoff Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Changes (by fgsch): * status: reopened => new * owner: Poul-Henning Kamp => geoff -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Aug 12 15:42:14 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Aug 2015 15:42:14 -0000 Subject: [Varnish] #1773: Incomplete code in VDP_ESI() Message-ID: <045.14db7aed651d70d979a54c13462b65e0@varnish-cache.org> #1773: Incomplete code in VDP_ESI() -----------------------------+---------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.0-TP1 | Severity: major Keywords: Incomplete code | -----------------------------+---------------------- {{{ Panic message: Incomplete code in VDP_ESI(), cache/cache_esi_deliver.c line 332: thread = (cache-worker) version = varnish-4.1.0-tp1 revision 0e4e1bc ident = Linux,3.2.0-4-amd64,x86_64,-junix,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4342f4: pan_ic+0x134 0x41da74: VDP_ESI+0x354 0x41b8c4: VDP_bytes+0x74 0x41bd72: VDP_DeliverObj+0x82 0x44df65: V1D_Deliver+0x245 0x436cf9: cnt_vdp+0x79 0x4372a4: CNT_Request+0x394 0x44eb03: HTTP1_Session+0x133 0x43a7a1: SES_Proto_Req+0x61 0x4493da: WRK_Thread+0x48a req = 0x7f8dafb1c020 { sp = 0x7f8dbeab0920, vxid = 68979429, step = R_STP_DELIVER, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7f8dbeab0920 { fd = 561, vxid = 47083597, client = 66.249.75.70 51200, step = S_STP_H1PROC, }, worker = 0x7f8dfe042c30 { stack = {0x7f8dfe043000 -> 0x7f8dfe037000} ws = 0x7f8dfe042e30 { id = "wrk", {s,f,r,e} = {0x7f8dfe0423d0,0x7f8dfe0423d0,(nil),+2040}, }, VCL::method = DELIVER, VCL::return = deliver, VCL::methods = {RECV, HASH, HIT, DELIVER}, }, ws = 0x7f8dafb1c220 { id = "req", {s,f,r,e} = {0x7f8dafb1e028,+1312,+253904,+253904}, }, http[req] = { ws = 0x7f8dafb1c220[req] "GET", "/my_uri", "HTTP/1.1", "Connection: Keep-alive", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "From: googlebot(at)googlebot.com", "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", "X-Forwarded-For: 66.249.75.70", "Host: my_host", "Surrogate-Capability: abc=ESI/1.0", "Accept-Encoding: gzip", }, http[resp] = { ws = 0x7f8dafb1c220[req] "HTTP/1.1", "200", "OK", " -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 13 09:51:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 Aug 2015 09:51:48 -0000 Subject: [Varnish] #1774: Assert error in vmod_get(), vmod_cookie.c Message-ID: <045.9cfaed1e1107cf0db01d70c215391d7c@varnish-cache.org> #1774: Assert error in vmod_get(), vmod_cookie.c --------------------------+-------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: vmod Version: 4.1.0-TP1 | Severity: major Keywords: Assert error | --------------------------+-------------------- {{{ Child (2570) Panic message: Assert error in vmod_get(), vmod_cookie.c line 230: Condition((cookie)->magic == 0x3BB41543) not true. thread = (cache-worker) version = varnish-4.1.0-tp1 revision 0e4e1bc ident = Linux,3.2.0-4-amd64,x86_64,-junix,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4342f4: pan_ic+0x134 0x7f812a7e2932: libvmod_cookie.so(vmod_get+0x92) [0x7f812a7e2932] 0x7f812a55d23a: vgc.so(VGC_function_vcl_recv+0x76a) [0x7f812a55d23a] 0x43fa4a: vcl_call_method+0x1ea 0x4415ea: VCL_recv_method+0x5a 0x437a22: CNT_Request+0xb12 0x44eb03: HTTP1_Session+0x133 0x43a7a1: SES_Proto_Req+0x61 0x4493da: WRK_Thread+0x48a 0x44994b: pool_thread+0x2b req = 0x7f8125d46020 { sp = 0x7f812540ec20, vxid = 67843, step = R_STP_RECV, req_body = R_BODY_WITH_LEN, restarts = 0, esi_level = 0, sp = 0x7f812540ec20 { fd = 13, vxid = 67839, client = 85.116.42.203 59126, step = S_STP_H1PROC, }, worker = 0x7f8123c22c30 { stack = {0x7f8123c23000 -> 0x7f8123c17000} ws = 0x7f8123c22e30 { id = "wrk", {s,f,r,e} = {0x7f8123c223d0,0x7f8123c223d0,(nil),+2040}, }, VCL::method = *RECV, VCL::return = abandon, VCL::methods = {RECV}, }, ws = 0x7f8125d46220 { id = "req", {s,f,r,e} = {0x7f8125d48028,+960,(nil),+253904}, }, http[req] = { ws = 0x7f8125d46220[req] "POST", "/my_uri", "HTTP/1.1", "User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98; Linux 3.3.8-3.3) [Netgem; 7.2.01-51; i-Player; netbox; netboxtv]", "Accept: */*", "Content-Type: application/x-www-form-urlencoded; charset=utf-8", "Accept-Encoding: gzip", "X-Forwarded-Host: my_host", "X-Forwarded-Server: my_host", "Connection: Keep-Alive", "Content-Length: 183", "Host: my_host -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 13 09:55:05 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 Aug 2015 09:55:05 -0000 Subject: [Varnish] #1774: Assert error in vmod_get(), vmod_cookie.c In-Reply-To: <045.9cfaed1e1107cf0db01d70c215391d7c@varnish-cache.org> References: <045.9cfaed1e1107cf0db01d70c215391d7c@varnish-cache.org> Message-ID: <060.18df8e954ef0ef08ae757f68f6aed8a2@varnish-cache.org> #1774: Assert error in vmod_get(), vmod_cookie.c --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: vmod | Version: 4.1.0-TP1 Severity: major | Resolution: invalid Keywords: Assert error | --------------------------+------------------------ Changes (by fgsch): * status: new => closed * resolution: => invalid Comment: Please report this at the cookie vmod issue tracker at https://github.com/lkarsten/libvmod-cookie. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 13 10:22:32 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 Aug 2015 10:22:32 -0000 Subject: [Varnish] #1775: Crash loading a VCL in cold state Message-ID: <043.07ca061777d498a319bb8bab48bebdde@varnish-cache.org> #1775: Crash loading a VCL in cold state ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- {{{ *** v1 1.6 debug| Child (18462) died signal=6 (core dumped)\n *** v1 1.6 debug| Child (18462) Panic message:\n *** v1 1.6 debug| Assert error in VSM_common_free(), common/common_vsm.c line 288:\n *** v1 1.6 debug| Condition((ptr) != 0) not true.\n *** v1 1.6 debug| thread = (cache-main)\n *** v1 1.6 debug| version = varnish-trunk revision f8a913d\n *** v1 1.6 debug| ident = Linux,3.16.0-4-amd64,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,epoll\n *** v1 1.6 debug| Backtrace:\n *** v1 1.6 debug| 0x44f3a0: pan_backtrace+0x20\n *** v1 1.6 debug| 0x44f1a3: pan_ic+0x363\n *** v1 1.6 debug| 0x47ba3f: VSM_common_free+0xef\n *** v1 1.6 debug| 0x45fe66: VSM_Free+0x76\n *** v1 1.6 debug| 0x4156de: VBE_Event+0x1be\n *** v1 1.6 debug| 0x4678e1: vcl_BackendEvent+0x121\n *** v1 1.6 debug| 0x463341: vcl_set_state+0x1a1\n *** v1 1.6 debug| 0x467463: VCL_Load+0x483\n *** v1 1.6 debug| 0x466289: ccf_config_load+0xd9\n *** v1 1.6 debug| 0x7f56e8553c34: libvarnish.so(+0xac34) [0x7f56e8553c34]\n *** v1 1.6 debug| \n *** v1 1.6 debug| \n }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 14 10:12:16 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Aug 2015 10:12:16 -0000 Subject: [Varnish] #1776: Assert error in VCL_Ref() Message-ID: <045.99c7ef8775cf68a5dd058430f01195d6@varnish-cache.org> #1776: Assert error in VCL_Ref() --------------------------+---------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.0-TP1 | Severity: major Keywords: assert error | --------------------------+---------------------- {{{ Child (721862) Panic message: Assert error in VCL_Ref(), cache/cache_vcl.c line 160: Condition(vcl->temp == vcl_temp_warm) not true. thread = (cache-worker) version = varnish-4.1.0-tp1 revision 0e4e1bc ident = Linux,3.2.0-4-amd64,x86_64,-junix,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4342f4: pan_ic+0x134 0x43fd15: VCL_Ref+0xb5 0x41aa28: VBO_GetBusyObj+0x1c8 0x425c1e: VBF_Fetch+0x8e 0x43877e: CNT_Request+0x186e 0x41e037: VDP_ESI+0x917 0x41b8c4: VDP_bytes+0x74 0x41bd72: VDP_DeliverObj+0x82 0x44df65: V1D_Deliver+0x245 0x436cf9: cnt_vdp+0x79 req = 0x7f62c3562020 { sp = 0x7f62d0128c20, vxid = 480064665, step = R_STP_MISS, req_body = R_BODY_NONE, restarts = 0, esi_level = 1, sp = 0x7f62d0128c20 { fd = 418, vxid = 480064655, client = 41.225.233.151 55203, step = S_STP_H1PROC, }, worker = 0x7f632ff12c30 { stack = {0x7f632ff13000 -> 0x7f632ff07000} ws = 0x7f632ff12e30 { id = "wrk", {s,f,r,e} = {0x7f632ff123d0,0x7f632ff123d0,(nil),+2040}, }, VCL::method = MISS, VCL::return = fetch, VCL::methods = {RECV, PASS, HASH, MISS, HIT, DELIVER}, }, ws = 0x7f62c3562220 { id = "req", {s,f,r,e} = {0x7f62c3564028,+10688,(nil),+253904}, }, http[req] = { ws = 0x7f62c3562220[req] "GET", "/_fragment?_path=threadId%3Dmomes-77323%26serialized_siteaccess%3DO%253A38%253A%2522eZ%255CPublish%255CCore%255CMVC%255CSymfony%255CSiteAccess%2522%253A3%253A%257Bs%253A4%253A%2522name%2522%253Bs%253A5%253A%2522momes%2522%253Bs%253A12%253A%2522matchingType%2522%253Bs%253A8%253A%2522host%253Amap%2522%253Bs%253A7%253A%2522matcher%2522%253BO%253A55%253A%2522eZ%255CPublish%255CCore%255CMVC%255CSymfony%255CSiteAccess%255CMatcher%255CMap%255CHost%2522%253A2%253A%257Bs%253A6%253A%2522%2500%252A%2500key%2522%253Bs%253A13%253A%2522dyn.momes.net%2522%253Bs%253A6%253A%2522%2500%252A -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 14 10:14:34 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Aug 2015 10:14:34 -0000 Subject: [Varnish] #1776: Assert error in VCL_Ref() In-Reply-To: <045.99c7ef8775cf68a5dd058430f01195d6@varnish-cache.org> References: <045.99c7ef8775cf68a5dd058430f01195d6@varnish-cache.org> Message-ID: <060.3e4864a38fbcf5a20225129fff59e1c8@varnish-cache.org> #1776: Assert error in VCL_Ref() --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: major | Resolution: Keywords: assert error | --------------------------+------------------------ Comment (by llavaud): full panic: {{{ Assert error in VCL_Ref(), cache/cache_vcl.c line 160: Condition(vcl->temp == vcl_temp_warm) not true. thread = (cache-worker) version = varnish-4.1.0-tp1 revision 0e4e1bc ident = Linux,3.2.0-4-amd64,x86_64,-junix,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4342f4: pan_ic+0x134 0x43fd15: VCL_Ref+0xb5 0x41aa28: VBO_GetBusyObj+0x1c8 0x425c1e: VBF_Fetch+0x8e 0x43877e: CNT_Request+0x186e 0x41e037: VDP_ESI+0x917 0x41b8c4: VDP_bytes+0x74 0x41bd72: VDP_DeliverObj+0x82 0x44df65: V1D_Deliver+0x245 0x436cf9: cnt_vdp+0x79 req = 0x7f62c3562020 { sp = 0x7f62d0128c20, vxid = 480064665, step = R_STP_MISS, req_body = R_BODY_NONE, restarts = 0, esi_level = 1, sp = 0x7f62d0128c20 { fd = 418, vxid = 480064655, client = 41.225.233.151 55203, step = S_STP_H1PROC, }, worker = 0x7f632ff12c30 { stack = {0x7f632ff13000 -> 0x7f632ff07000} ws = 0x7f632ff12e30 { id = "wrk", {s,f,r,e} = {0x7f632ff123d0,0x7f632ff123d0,(nil),+2040}, }, VCL::method = MISS, VCL::return = fetch, VCL::methods = {RECV, PASS, HASH, MISS, HIT, DELIVER}, }, ws = 0x7f62c3562220 { id = "req", {s,f,r,e} = {0x7f62c3564028,+10688,(nil),+253904}, }, http[req] = { ws = 0x7f62c3562220[req] "GET", "/_fragment?_path=threadId%3Dmomes-77323%26serialized_siteaccess%3DO%253A38%253A%2522eZ%255CPublish%255CCore%255CMVC%255CSymfony%255CSiteAccess%2522%253A3%253A%257Bs%253A4%253A%2522name%2522%253Bs%253A5%253A%2522momes%2522%253Bs%253A12%253A%2522matchingType%2522%253Bs%253A8%253A%2522host%253Amap%2522%253Bs%253A7%253A%2522matcher%2522%253BO%253A55%253A%2522eZ%255CPublish%255CCore%255CMVC%255CSymfony%255CSiteAccess%255CMatcher%255CMap%255CHost%2522%253A2%253A%257Bs%253A6%253A%2522%2500%252A%2500key%2522%253Bs%253A13%253A%2522dyn.momes.net%2522%253Bs%253A6%253A%2522%2500%252A%2500map%2522%253Ba%253A5%253A%257Bs%253A13%253A%2522www.momes.net%2522%253Bs%253A5%253A%2522momes%2522%253Bs%253A18%253A%2522admin.in.momes.net%2522%253Bs%253A11%253A%2522momes_admin%2522%253Bs%253A15%253A%2522admin.momes.net%2522%253Bs%253A11%253A%2522momes_admin%2522%253Bs%253A13%253A%2522dyn.momes.net%2522%253Bs%253A5%253A%2522momes%2522%253Bs%253A16%253A%2522dyn.in.momes.net%2522%253Bs%253A5%253A%2522momes%2522%253B%257D%257D%257D%26_format%3Dhtml%26_locale%3Dfr_FR%26_controller%3DLaMomesBundle%253AComments%253Aform", "HTTP/1.1", "Via: 1.1 PROXYPARC", "Referer: http://www.momes.net/Bricolages/Bricolages-par-themes", "User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.102 Safari/535.2", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3", "Connection: Keep-Alive", "Accept-Encoding: gzip", "X-Forwarded-For: 41.225.233.151", "Host: www.momes.net", "Surrogate-Capability: abc=ESI/1.0", "Cookie: cagr_shown=1; xtvrn=$518570$; eZSESSID191efd211983778510d54bef5c81f0d2=4r255auo20gesagmp28300oq35; xtan=-; xtant=1; tCdebugLib=1; testcookie=123; A2DCAPPV2=3321%3A1439546912%3A835117640; A2DCAPPVBD2=3321%3A1439546912%3A835117640", }, vcl = { srcname = { "input", "Builtin", "/etc/varnish/backends/probe.vcl", "/etc/varnish/backends/webssi.vcl", "/etc/varnish/backends/webdyn.vcl", "/etc/varnish/backends/webservice.vcl", "/etc/varnish/backends/bograph.vcl", "/etc/varnish/acl.vcl", "/etc/varnish/rules/init.vcl", "/etc/varnish/rules/recv.vcl", "/etc/varnish/rules/hash.vcl", "/etc/varnish/rules/hit.vcl", "/etc/varnish/rules/miss.vcl", "/etc/varnish/rules/backend_fetch.vcl", "/etc/varnish/rules/backend_response.vcl", "/etc/varnish/rules/backend_error.vcl", "/etc/varnish/rules/deliver.vcl", "/etc/varnish/rules/synth.vcl", }, }, objcore (REQ) = 0x7f6307e4e340 { refcnt = 1 flags = 0x2 objhead = 0x7f62ccd43640 stevedore = (nil) } flags = { wantbody, } }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 14 12:33:04 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Aug 2015 12:33:04 -0000 Subject: [Varnish] #1777: Range requests problem Message-ID: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> #1777: Range requests problem -----------------------+---------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.0-TP1 | Severity: normal Keywords: range | -----------------------+---------------------- Hello, I use Varnish 4.1.0-TP1 on debian wheezy. I have a strange problem with range requests, i request a page of the following size: {{{ curl 'http://my_host/my_uri' --silent --write-out 'size_download=%{size_download}\n' --output /dev/null size_download=32876 }}} Now if i request the url with a range lower than the 32876 bytes (page size), example: {{{ curl -i -H 'Range: bytes=0-32875' http://my_host/my_uri HTTP/1.1 206 Partial Content Date: Fri, 14 Aug 2015 12:14:37 GMT Set-Cookie: eZSESSIDac08b8c73ea29869f9b619cab686aebb=efcsqrs288hr30733qs18u29t4; expires=Sat, 15-Aug-2015 12:14:38 GMT; path=/ Set-Cookie: e1_provider=europe1; path=/; domain=.europe1.fr Vary: Accept-Encoding X-Server: webdynphp54-06 Content-Type: text/html; charset=UTF-8 X-Varnish-Hostname: webcache24 Age: 3 X-S-Maxage: 60 Cache-Control: max-age=120, public Accept-Ranges: bytes Content-Range: bytes 0-32875/* Content-Length: 32876 Connection: keep-alive }}} curl end normaly and i got a 206 response from varnish, everything is ok Now if i request with a range set to 32876, varnish response seem ok: {{{ curl -i -H 'Range: bytes=0-32875' http://my_host/my_uri HTTP/1.1 206 Partial Content Date: Fri, 14 Aug 2015 12:11:22 GMT Set-Cookie: eZSESSIDac08b8c73ea29869f9b619cab686aebb=kobb2cu9789ghsf1rqjpb7tcq7; expires=Sat, 15-Aug-2015 12:11:22 GMT; path=/ Set-Cookie: e1_provider=europe1; path=/; domain=.europe1.fr Vary: Accept-Encoding X-Server: webdynphp54-06 Content-Type: text/html; charset=UTF-8 X-Varnish-Hostname: webcache24 Age: 658 X-S-Maxage: 60 Cache-Control: max-age=120, public Accept-Ranges: bytes Content-Range: bytes 0-32876/* Content-Length: 32877 Connection: keep-alive }}} but curl end with the following error: {{{ curl: (18) transfer closed with 1 bytes remaining to read }}} This bug is problematic because most of crawler (Facebook, Google, ...) request page with a Range header and if the requested Range is greater than the page size, the crawler got a connection error. Thanks in advance for your help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 14 12:37:18 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Aug 2015 12:37:18 -0000 Subject: [Varnish] #1777: Range requests problem In-Reply-To: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> References: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> Message-ID: <060.b225a0838b41812102ddc2ffe35b68bf@varnish-cache.org> #1777: Range requests problem ----------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: range | ----------------------+------------------------ Changes (by fgsch): * status: new => needinfo Comment: Do you have any evidence that any of the crawlers will supply a range that covers a size larger than the actual size? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 14 12:41:22 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Aug 2015 12:41:22 -0000 Subject: [Varnish] #1777: Range requests problem In-Reply-To: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> References: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> Message-ID: <060.7980ad759f0e746e67181b93f044b461@varnish-cache.org> #1777: Range requests problem ----------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: range | ----------------------+------------------------ Comment (by llavaud): i have attached a varnishlog of the facebook crawler. the facebook crawler got the following error: Curl Error : RECV_ERROR Recv failure: Connection reset by peer -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 14 16:44:00 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Aug 2015 16:44:00 -0000 Subject: [Varnish] #1777: Range requests problem In-Reply-To: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> References: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> Message-ID: <060.711d3e494822ea00e9702cb4dd981526@varnish-cache.org> #1777: Range requests problem ----------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: range | ----------------------+------------------------ Comment (by llavaud): i have made an error in my first post, the second curl command is: curl -i -H 'Range: bytes=0-32876' http://my_host/my_uri -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 17 09:21:53 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Aug 2015 09:21:53 -0000 Subject: [Varnish] #1776: Assert error in VCL_Ref() In-Reply-To: <045.99c7ef8775cf68a5dd058430f01195d6@varnish-cache.org> References: <045.99c7ef8775cf68a5dd058430f01195d6@varnish-cache.org> Message-ID: <060.1bd80f364dc18570c57426466e8d9c46@varnish-cache.org> #1776: Assert error in VCL_Ref() --------------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: major | Resolution: fixed Keywords: assert error | --------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [0a800c5167b6e8ccd0df483bb69136c30199aac2]: {{{ #!CommitTicketReference repository="" revision="0a800c5167b6e8ccd0df483bb69136c30199aac2" It is OK to VCL_Ref a cooling VCL. Fixes: #1776 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 17 09:25:47 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Aug 2015 09:25:47 -0000 Subject: [Varnish] #1775: Crash loading a VCL in cold state In-Reply-To: <043.07ca061777d498a319bb8bab48bebdde@varnish-cache.org> References: <043.07ca061777d498a319bb8bab48bebdde@varnish-cache.org> Message-ID: <058.a6a9eb3faa373e11ff0a359052f2efa1@varnish-cache.org> #1775: Crash loading a VCL in cold state ----------------------+---------------------------------------- Reporter: fgsch | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [0dffa87db4bf9d449781d244a00745a23a02803d]: {{{ #!CommitTicketReference repository="" revision="0dffa87db4bf9d449781d244a00745a23a02803d" Fix loading of cold VCLs Fixes: #1775 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 17 13:23:58 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Aug 2015 13:23:58 -0000 Subject: [Varnish] #1778: Varnishstat oddity Message-ID: <041.23ee325c745521249f4c080cd31166ff@varnish-cache.org> #1778: Varnishstat oddity -------------------------+------------------- Reporter: phk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Keywords: -------------------------+------------------- On a machine with very low load, and only return(pass) processing: {{{ MAIN.threads_created 200 0.00 . 0.00 MAIN.n_object 0 0.00 . 0.08 MAIN.n_objectcore 0 0.00 . 2868040561934 MAIN.n_backend 6 0.00 . 6.00 MAIN.s_sess 3906 0.99 . 0.12 }}} There is *no* way that number can ever have been real, and I suspect we're doing a divide by zero or something similarly troubling. I have not seen it for any other counter. Restarting varnishstat returns the number to 0.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 17 13:27:24 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Aug 2015 13:27:24 -0000 Subject: [Varnish] #1777: Range requests problem In-Reply-To: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> References: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> Message-ID: <060.2a0211e8e88edf0021c7137b091a0358@varnish-cache.org> #1777: Range requests problem ----------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: range | ----------------------+------------------------ Changes (by slink): * cc: nils.goroll@? (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Aug 21 11:59:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Aug 2015 11:59:55 -0000 Subject: [Varnish] #1779: Test std.ip (m00011) failing on OS X Message-ID: <045.c141d2673f9da9e64a8a20409a51199a@varnish-cache.org> #1779: Test std.ip (m00011) failing on OS X ---------------------+------------------- Reporter: espebra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ---------------------+------------------- m00011 is currently failing on OS X 10.10.3 (Yosemite), tested with commit a2d7099ebc25709d8905e34e341bc3abb59eb1e2. Output from varnishtest attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Aug 25 15:44:40 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 25 Aug 2015 15:44:40 -0000 Subject: [Varnish] #1777: Range requests problem In-Reply-To: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> References: <045.d3c3e0d4f487aac59ecc8da34f8abef4@varnish-cache.org> Message-ID: <060.fac626d82cabeb0011da1d4c259915b2@varnish-cache.org> #1777: Range requests problem ----------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: fixed Keywords: range | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: needinfo => closed * resolution: => fixed Comment: In [121593312daabbef4e290a590b364a099980a8b7]: {{{ #!CommitTicketReference repository="" revision="121593312daabbef4e290a590b364a099980a8b7" Disable speculative Range handling on streaming transactions where we don't yet know the length. I attempted to add a way to determine if the object was big enough *yet* to satisfy the Range, but that was non-viable. Fixes: #1777 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Aug 25 17:49:39 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 25 Aug 2015 17:49:39 -0000 Subject: [Varnish] #1773: Incomplete code in VDP_ESI() In-Reply-To: <045.14db7aed651d70d979a54c13462b65e0@varnish-cache.org> References: <045.14db7aed651d70d979a54c13462b65e0@varnish-cache.org> Message-ID: <060.6f0654c6d8e2513d80b35707b51fd2b3@varnish-cache.org> #1773: Incomplete code in VDP_ESI() -----------------------------+------------------------- Reporter: llavaud | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: major | Resolution: worksforme Keywords: Incomplete code | -----------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I have no idea what is going on here, and there is not enough details to find out. Basically what happened was that the ESI-cmd-string was illegal ... somehow. Obviously the most likely cause is some obscure programming error in Varnish. I don't think it is the code actually creating/parsing the ESI-cmd-string, but writing through an invalid pointer might do it. I have improved the error-reporting a little bit, so that varnishlog contains clues if this happens again, but I am closing this ticket now (sorry about the "worksforme" it is the least bogus reason I have to choose from), because there is nothing more I can do. If this happens again, please reopen this ticket, and try to include any "Error" records in varnishlog output. Considering how many bytes Varnish' ESI code pushes every second all over the world, and that this is the first such bug-report for the code, the probability of this being a random non-ECC-detected RAM error on your machine isn't entirely unreasonable, and the ESI code is one of the few places where such an error has a high likelyhood of being being detected, so keep an eye out for that machine in general. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Aug 26 11:27:02 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 26 Aug 2015 11:27:02 -0000 Subject: [Varnish] #1733: Unstable test-cases In-Reply-To: <041.e3e9abd44efc9f6e731fb370c77db66e@varnish-cache.org> References: <041.e3e9abd44efc9f6e731fb370c77db66e@varnish-cache.org> Message-ID: <056.6b9871c7db8dc066ea8608b4f5cea005@varnish-cache.org> #1733: Unstable test-cases -------------------------+--------------------- Reporter: phk | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+--------------------- Comment (by ingvar): On Fedora's 32bit arches i686 and armv7hl tests/r01576 fails. I can reproduce this at least on f22 and f23 (though not on epel5 and epel6). https://kojipkgs.fedoraproject.org//work/tasks/5945/10835945/build.log https://kojipkgs.fedoraproject.org//work/tasks/6928/10836928/build.log On Fedora's secondary 64bit arches, at least on ppc64 and aarch64, tests/u00000 fails, tested on various build targets: https://kojipkgs.fedoraproject.org//work/tasks/7087/10837087/build.log http://arm.koji.fedoraproject.org//work/tasks/1211/3141211/build.log Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 27 07:01:49 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Aug 2015 07:01:49 -0000 Subject: [Varnish] #1625: if(req.backend_hint == b1) compiles, but does nothing In-Reply-To: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> References: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> Message-ID: <064.479e36ae7b1b0a3ea8e0d90800a653eb@varnish-cache.org> #1625: if(req.backend_hint == b1) compiles, but does nothing -------------------------+------------------------- Reporter: huguesalary | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Apologies for taking so long to reply to this. The variable you want is beresp.backend, that gives you the actual backend the fetch was made from. This variable is available in vcl_backend_response{}. The trouble here is the way directors came into Varnish wasn't entirely thought out, and that caused directors like round-robin to have a "hidden" backend, which does the actual selection only at fetch-time. The real trouble is that people like to assign backends in vcl_recv{}, but doing too much work there is a waste of time for all cache-hits, so we want to keep it light-weight and not actually do the selection there. Varnish 5 will be a good time to revisit this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Aug 27 12:17:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Aug 2015 12:17:26 -0000 Subject: [Varnish] #1778: Varnishstat oddity In-Reply-To: <041.23ee325c745521249f4c080cd31166ff@varnish-cache.org> References: <041.23ee325c745521249f4c080cd31166ff@varnish-cache.org> Message-ID: <056.28d068d7e41fa9f6014dba3668c124d8@varnish-cache.org> #1778: Varnishstat oddity -------------------------+-------------------- Reporter: phk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by aondio): Can't reproduce. Phk, do you, by any chance, remember if the numbers in the two non- reported columns(AVG_100 an AVG_1000) were real? -- Ticket URL: Varnish The Varnish HTTP Accelerator From chris.monteiro at spotlight.com Wed Aug 12 15:17:24 2015 From: chris.monteiro at spotlight.com (Chris Monteiro) Date: Wed, 12 Aug 2015 15:17:24 -0000 Subject: Functions in backend variables interpretted literally Message-ID: <84619A39D0EA2742A35E6A47CC81A7329139D06C@HQ-BP-EXH1.spotmain.com> Hi there I used dynamically named servers on EC2, my varnish bootstrap setup configures the vcl according to the server name e.g. i-f2dd2d2f Varnish doesn't like the hyphen in the back end name, so I replace it out, fair enough: if2dd2d2f Now it fails because the back end server name has the function 'if' in it! I now replace this out to: lol2dd2d2f I think it may be a bug that the 'if' function is interpreted in a back end variable definition like this. ________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, please delete it from your system, do not use or disclose the information in any way, and notify me immediately. The contents of this message may contain personal views that are not the views of Spotlight, unless specifically stated. --------------------------------------------------------------------------------------- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: