From varnish-bugs at projects.linpro.no  Mon Jun  2 19:45:46 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 02 Jun 2008 19:45:46 -0000
Subject: [Varnish] #235: Varnish Linux performance
In-Reply-To: <057.939e5a37a22cf5a6a639947d809cd9b1@projects.linpro.no>
References: <057.939e5a37a22cf5a6a639947d809cd9b1@projects.linpro.no>
Message-ID: <066.d0ec49cf38f651941b5ccd2e8f50b3cf@projects.linpro.no>

#235: Varnish Linux performance
-------------------------+--------------------------------------------------
 Reporter:  rafaelumann  |        Owner:  phk   
     Type:  defect       |       Status:  closed
 Priority:  high         |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:  performance  |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Committed as submitted.

 Thanks!

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/235#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun  5 11:24:25 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 05 Jun 2008 11:24:25 -0000
Subject: [Varnish] #243: Missing errorhandling code in cnt_lookup(),
	cache_center.c line 543 when using restart
Message-ID: <051.539cb17941e27ba7fa220f0600cf22ee@projects.linpro.no>

#243: Missing errorhandling code in cnt_lookup(), cache_center.c line 543 when
using restart
----------------------+-----------------------------------------------------
 Reporter:  drewr     |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  major     |    Keywords:       
----------------------+-----------------------------------------------------
 I switched to using the {{{restart}}} action in hopes of using multiple
 backends, but threads started dying with this message:
 {{{
 2008-06-04 17:34:35.095805500 start child pid 14915
 2008-06-04 17:34:35.101414500 Child said (2, 14915): <<Child starts>>
 2008-06-04 17:34:35.101444500 Child said (2, 14915): <<managed to mmap
 32212254720 bytes of 32212254720>>
 2008-06-04 17:34:35.101448500 Child said (2, 14915): <<Ready>>
 2008-06-04 17:34:42.243450500 Child said (2, 14915): <<Missing
 errorhandling code in cnt_lookup(), cache_center.c line 543:>>
 2008-06-04 17:34:42.243462500 Child said (2, 14915): <<  Condition((p) !=
 0) not true.>>
 2008-06-04 17:34:42.251317500 Cache child died pid=14915 status=0x6

 }}}

 Here's my vcl:
 {{{
 backend s3 {
   .host = "207.171.183.117";
   .port = "80";
 }

 backend web1 {
   .host = "web1";
   .port = "80";
 }

 acl purge {
   "localhost";
   "127.0.0.1";
   "web1";
 }

 sub vcl_recv {
   set req.grace = 30s;
   if (req.request == "GET" && req.url ~ "\.(gif|jpg|swf|css|js)$") {
     if (req.restarts == 0) {
       set req.backend = web1;
     } else {
       set req.backend = s3;
     }
     lookup;
   }
   if (req.request == "PURGE") {
     if (!client.ip ~ purge) {
       error 405 "Not allowed.";
     }
     lookup;
   }
 }

 sub vcl_fetch {
   if (obj.status != 200) {
     restart;
   }

   set obj.grace = 30s;
   set obj.ttl = 1209600s;
   remove obj.http.Set-Cookie;
 }

 sub vcl_hit {
   if (req.request == "PURGE") {
     set obj.ttl = 0s;
     error 200 "Purged.";
   }
 }

 sub vcl_miss {
    if (req.request == "PURGE") {
      error 404 "Not in cache.";
    }

    if (req.http.user-agent ~ "spider") {
      error 503 "Not presently in cache";
    }
 }
 }}}

 And my start options:
 {{{
 $VARNISHD \
     -a 0.0.0.0:8000 \
     -T 127.0.0.1:8001 \
     -f $VARNISHCONF \
     -F \
     -h classic,150001 \
     -n $CACHEDIR \
     -P $CACHEDIR/varnishd.pid \
     -s file,$CACHEDIR/cache,30GB \
     -p thread_pools=4 \
     -p lru_interval=3600 \
     -u $USER
 }}}

 I'm using {{{trunk at 2646}}}.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/243>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun  5 18:12:06 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 05 Jun 2008 18:12:06 -0000
Subject: [Varnish] #240: Second and subsiquent ESI includes are not cached
In-Reply-To: <048.96d1a92b1118c5e88d7130ed74d67c36@projects.linpro.no>
References: <048.96d1a92b1118c5e88d7130ed74d67c36@projects.linpro.no>
Message-ID: <057.d74421a67b32f3b0a3a4959a1cf84bcd@projects.linpro.no>

#240: Second and subsiquent ESI includes are not cached
-------------------------+--------------------------------------------------
 Reporter:  jt           |        Owner:  phk  
     Type:  defect       |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  major        |   Resolution:       
 Keywords:  esi include  |  
-------------------------+--------------------------------------------------
Comment (by jt):

 Yes, this is now fixed in trunk. Thanks!

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/240#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun  6 21:15:57 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 06 Jun 2008 21:15:57 -0000
Subject: [Varnish] #240: Second and subsiquent ESI includes are not cached
In-Reply-To: <048.96d1a92b1118c5e88d7130ed74d67c36@projects.linpro.no>
References: <048.96d1a92b1118c5e88d7130ed74d67c36@projects.linpro.no>
Message-ID: <057.d80212a706b5202f8d469efd01606cd6@projects.linpro.no>

#240: Second and subsiquent ESI includes are not cached
-------------------------+--------------------------------------------------
 Reporter:  jt           |        Owner:  phk   
     Type:  defect       |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  major        |   Resolution:  fixed 
 Keywords:  esi include  |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/240#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun  6 21:32:43 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 06 Jun 2008 21:32:43 -0000
Subject: [Varnish] #243: Missing errorhandling code in cnt_lookup(),
	cache_center.c line 543 when using restart
In-Reply-To: <051.539cb17941e27ba7fa220f0600cf22ee@projects.linpro.no>
References: <051.539cb17941e27ba7fa220f0600cf22ee@projects.linpro.no>
Message-ID: <060.0e68f7b06a61e66df793b213a7039e98@projects.linpro.no>

#243: Missing errorhandling code in cnt_lookup(), cache_center.c line 543 when
using restart
----------------------+-----------------------------------------------------
 Reporter:  drewr     |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  varnishd  |      Version:  trunk     
 Severity:  major     |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 The short explanation:

 You have run out of session workspace.

 Try increasing the parameter sess_workspace, that should fix it.

 The long explanation:

 When you do a restart, we start all over again, and amongst other things,
 that means rebuilding the hash string for the request, because in addition
 to selecting a different backend, one could also imagine trying a
 different hash strategy to find a matching object.

 Unfortunately, the hash is often one of the major memory consumers, and
 therefore this will put stress on the session workspace.

 In theory, a really inteligent VCL compiler could tell if it was safe to
 reuse the previously built hash, but that is not in the cards any time
 soon.

 The other relevant point is, if it is possible to release the memory used
 during the attempt that restarted, rather than just keep piling more on
 top of it.

 This is more feasible, but still a bit of nasty work, but I'll put it on
 the post-2 todo list.

 And yes, running out of session memory should be handled more gracefully.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/243#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun  6 21:41:28 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 06 Jun 2008 21:41:28 -0000
Subject: [Varnish] #242: Segfault on Set Header in vcl_hit Assert error
	in WS_Reserve(), cache_ws.c line 103:
In-Reply-To: <049.b9726f6e4df7e7ea64ccd784ec34e269@projects.linpro.no>
References: <049.b9726f6e4df7e7ea64ccd784ec34e269@projects.linpro.no>
Message-ID: <058.61aaeb9d7f4a498f74f70522ac590b36@projects.linpro.no>

#242: Segfault on Set Header in vcl_hit  Assert error in WS_Reserve(), cache_ws.c
line 103:
--------------------+-------------------------------------------------------
 Reporter:  sky     |        Owner:  des       
     Type:  defect  |       Status:  closed    
 Priority:  normal  |    Milestone:            
Component:  build   |      Version:  1.1.2     
 Severity:  normal  |   Resolution:  worksforme
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme

Old description:

> (gdb) bt
> #0  0x000000373cc30055 in raise () from /lib64/libc.so.6
> #1  0x000000373cc31af0 in abort () from /lib64/libc.so.6
> #2  0x000000373d8024fc in lbv_assert () from /usr/lib64/libvarnish.so.0
> #3  0x0000000000417bb8 in WS_Reserve ()
> #4  0x0000000000415f52 in VRT_l_obj_status ()
> #5  0x0000000000416bc3 in VRT_SetHdr ()
> #6  0x00002aaaeb459f96 in ?? ()
> #7  0x000000004a00cc3f in ?? ()
> #8  0x000000001ac43088 in ?? ()
> #9  0x000000001ac43088 in ?? ()
> #10 0x0000000000413cac in VCL_hit_method ()
> #11 0x000000000040984f in CNT_Session ()
> #12 0x0000000000410a33 in WRK_QueueSession ()
> #13 0x0000000000410c73 in WRK_QueueSession ()
> #14 0x000000373dc062f7 in start_thread () from /lib64/libpthread.so.0
> #15 0x000000373ccce85d in clone () from /lib64/libc.so.6
>

> Changing
>
> sub vcl_hit {
>         if (req.request == "PURGE") {
>                 set obj.ttl = 0s;
>                 error 200 "Purged.";
>         }
>
>         if (!obj.cacheable) {
>                 pass;
>         }
>         set obj.http.X-Cache = "HIT";
>         deliver;
> }
>
> to
>
> sub vcl_hit {
>         if (req.request == "PURGE") {
>                 set obj.ttl = 0s;
>                 error 200 "Purged.";
>         }
>
>         if (!obj.cacheable) {
>                 pass;
>         }
>        if(obj.http.X-Cache == "MISS") {
>                 set obj.http.X-Cache = "HIT";
>        }
>         deliver;
> }

New description:

 {{{
 (gdb) bt
 #0  0x000000373cc30055 in raise () from /lib64/libc.so.6
 #1  0x000000373cc31af0 in abort () from /lib64/libc.so.6
 #2  0x000000373d8024fc in lbv_assert () from /usr/lib64/libvarnish.so.0
 #3  0x0000000000417bb8 in WS_Reserve ()
 #4  0x0000000000415f52 in VRT_l_obj_status ()
 #5  0x0000000000416bc3 in VRT_SetHdr ()
 #6  0x00002aaaeb459f96 in ?? ()
 #7  0x000000004a00cc3f in ?? ()
 #8  0x000000001ac43088 in ?? ()
 #9  0x000000001ac43088 in ?? ()
 #10 0x0000000000413cac in VCL_hit_method ()
 #11 0x000000000040984f in CNT_Session ()
 #12 0x0000000000410a33 in WRK_QueueSession ()
 #13 0x0000000000410c73 in WRK_QueueSession ()
 #14 0x000000373dc062f7 in start_thread () from /lib64/libpthread.so.0
 #15 0x000000373ccce85d in clone () from /lib64/libc.so.6
 }}}


 Changing
 {{{
 sub vcl_hit {
         if (req.request == "PURGE") {
                 set obj.ttl = 0s;
                 error 200 "Purged.";
         }

         if (!obj.cacheable) {
                 pass;
         }
         set obj.http.X-Cache = "HIT";
         deliver;
 }
 }}}
 to
 {{{
 sub vcl_hit {
         if (req.request == "PURGE") {
                 set obj.ttl = 0s;
                 error 200 "Purged.";
         }

         if (!obj.cacheable) {
                 pass;
         }
        if(obj.http.X-Cache == "MISS") {
                 set obj.http.X-Cache = "HIT";
        }
         deliver;
 }
 }}}

Comment:

 This ticket is a bit on the thin side, but in general when you get a panic
 that involves WS_Reserve() or WS_Alloc(), then you have likely run out of
 workspace, most often session workspace,
 but in seldom cases object workspace.

 Both of these can be changed with their respective parameters.

 Be aware that obj_workspace affects every cached object, and thus scales
 with the number of these, whereas sess_workspace only scales with the
 number of worker threads.

 I will not rule out that the default for sess_workspace is an order of
 magnitude too low.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/242#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun  6 22:05:08 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 06 Jun 2008 22:05:08 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
In-Reply-To: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
References: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
Message-ID: <058.e71253e18b00ddccb912dda14dd1aa15@projects.linpro.no>

#203: X-Forwarded-For handling
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des   
     Type:  enhancement    |       Status:  closed
 Priority:  normal         |    Milestone:        
Component:  documentation  |      Version:  trunk 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 I have changed the spelling to use capital X & F in -trunk.

 Footnote:

 PHP's {{{$headers["bla"]}}} is not RFC 2616 compliant, if the index is not
 case-folded, as section 4.2  of RFC2616 quite clearly states:

 {{{
    HTTP header fields, which include general-header (section 4.5),
    request-header (section 5.3), response-header (section 6.2), and
    entity-header (section 7.1) fields, follow the same generic format as
    that given in Section 3.1 of RFC 822 [9]. Each header field consists
    of a name followed by a colon (":") and the field value. Field names
    are case-insensitive. [...]
 }}}

 It could be argued, that "HTTP header fields" should be read to only
 include such headers as RFC2616 defines, such that that "X-Forwarded-For"
 header could have case-sensitive semantics, but that wouldn't make PHP's
 compliance problem any smaller really, as the RFC2616 strings would still
 be handled wrong.

 I wonder how many PHP programs out there you could trick by using all
 lower-case or upper-case HTTP headers.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/203#comment:8>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun  6 22:08:47 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 06 Jun 2008 22:08:47 -0000
Subject: [Varnish] #241: Varnish gets stuck, stops responding
In-Reply-To: <052.7305c1bbe0e17a9adeb70af90b7b47a0@projects.linpro.no>
References: <052.7305c1bbe0e17a9adeb70af90b7b47a0@projects.linpro.no>
Message-ID: <061.7ad5dc6ce6a67c5718024a7291b69394@projects.linpro.no>

#241: Varnish gets stuck, stops responding
----------------------+-----------------------------------------------------
 Reporter:  anders    |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  high      |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I suspect this was me messing up the non-blocking mode changes, it should
 be fixed in -trunk as of #2651.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/241#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun  9 16:24:16 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 09 Jun 2008 16:24:16 -0000
Subject: [Varnish] #244: Option to set the page size
Message-ID: <052.f900a16ab635a784fad9de9dea3e354e@projects.linpro.no>

#244: Option to set the page size
-------------------------+--------------------------------------------------
 Reporter:  anders       |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 Please add an option to set a fixed page size for Varnish's allocations.
 With large data sets and many small objects, this leads to upto 10% better
 (less) use of VM space to fit the same data.

 I have been using, and I am still using the attached patch from PHK. I
 just want this to be an option so that I don't have to patch Varnish to
 set this value.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/244>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 10 13:07:16 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 10 Jun 2008 13:07:16 -0000
Subject: [Varnish] #245: Trunk doesn't build on OS X 10.5 (Leopard)
Message-ID: <051.90cd2e2621b56be7efc017396819fbcc@projects.linpro.no>

#245: Trunk doesn't build on OS X 10.5 (Leopard)
--------------------+-------------------------------------------------------
 Reporter:  peter   |       Owner:  des  
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 Tried to build the latest trunk version (2659) on OS X but got a compile
 error:
 {{{
 mgt_param.c:690:2: error: invalid preprocessing directive #elseif
 }}}
 After making the following changes the problem was fixed:
 {{{
 Index: bin/varnishd/mgt_param.c
 ===================================================================
 --- bin/varnishd/mgt_param.c    (revision 2659)
 +++ bin/varnishd/mgt_param.c    (working copy)
 @@ -687,7 +687,7 @@
                 MUST_RELOAD,
  #ifdef __APPLE__
                 "exec cc -dynamiclib -Wl,-undefined,dynamic_lookup -o %o
 %s"
 -#elseif defined(__SOLARIS__)
 +#elif defined(__SOLARIS__)
                 "exec cc -shared -fpic -c %o %s"
  #else /* default: GCC on Linux & FreeBSD */
                 "exec cc -fpic -shared -Wl,-x -o %o %s"
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/245>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 10 13:29:19 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 10 Jun 2008 13:29:19 -0000
Subject: [Varnish] #245: Trunk doesn't build on OS X 10.5 (Leopard)
In-Reply-To: <051.90cd2e2621b56be7efc017396819fbcc@projects.linpro.no>
References: <051.90cd2e2621b56be7efc017396819fbcc@projects.linpro.no>
Message-ID: <060.7e3026f0c790657735cbe17d7643387b@projects.linpro.no>

#245: Trunk doesn't build on OS X 10.5 (Leopard)
--------------------+-------------------------------------------------------
 Reporter:  peter   |        Owner:  des   
     Type:  defect  |       Status:  closed
 Priority:  normal  |    Milestone:        
Component:  build   |      Version:  trunk 
 Severity:  normal  |   Resolution:  fixed 
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 committed, thanks

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/245#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 10 17:42:42 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 10 Jun 2008 17:42:42 -0000
Subject: [Varnish] #246: Make req available in vcl_deliver
Message-ID: <058.53d2945701dca8896a94831a3f392163@projects.linpro.no>

#246: Make req available in vcl_deliver
--------------------------+-------------------------------------------------
 Reporter:  alex.taggart  |       Owner:  phk  
     Type:  enhancement   |      Status:  new  
 Priority:  normal        |   Milestone:       
Component:  varnishd      |     Version:  trunk
 Severity:  normal        |    Keywords:       
--------------------------+-------------------------------------------------
 The req field is not accessible in vcl_deliver which prevents one from
 using logic dependent upon request data prior to delivering the content.

 See discussion: http://thread.gmane.org/gmane.comp.web.varnish.misc/1655

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/246>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 11 12:46:21 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 11 Jun 2008 12:46:21 -0000
Subject: [Varnish] #247: Varnish sends 304 header for ESI pages although
	some of the included objects might have changed
Message-ID: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no>

#247: Varnish sends 304 header for ESI pages although some of the included
objects might have changed
----------------------+-----------------------------------------------------
 Reporter:  peter     |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 I've replicated the ESI example of the Wiki using PHP. My VCL (which is
 based on the example from the man page) looks like follows:
 {{{
 backend default {
   .host = "dev";
   .port = "http";
 }

 sub vcl_recv {
   set req.http.X-Forwarded-For = client.ip;
   set req.http.Host = "dev";
   lookup;
 }

 sub vcl_pipe {
   pipe;
 }

 sub vcl_pass {
   pass;
 }

 sub vcl_hash {
   set req.hash += req.url;
   set req.hash += req.http.host;
   hash;
 }

 sub vcl_hit {
   deliver;
 }

 sub vcl_miss {
   fetch;
 }

 sub vcl_fetch {
   if (!obj.valid) {
       error;
   }

   if (req.url == "/test.html") {
       esi;  /* Do ESI processing */
       set obj.ttl = 24 h;
   } elseif (req.url == "/date.php") {
       set obj.ttl = 1m;
   }

   insert;
 }

 sub vcl_deliver {
   deliver;
 }

 sub vcl_timeout {
   discard;
 }

 sub vcl_discard {
   discard;
 }
 }}}
 The PHP script (date.php) is responsible for printing the current date.

 Everything seems to work fine. The date.php file output is cached for a
 minute and if I keep refreshing my browser I get to see a new version
 after a minute. The ESI include inside the test.html file also seems to
 work fine because the date is displayed inline if I request the test.html
 file.

 However, when I keep refreshing the test.html file the browser receives a
 304 Unmodified header and after that doesn't seem to do a new request
 anymore. Even after a minute if I do a simple refresh in the browser I
 still get to see the old date. Only if I force a refresh using SHIFT-
 REFRESH I get to see the new date.

 So although the ESI include works fine, and the inline content is being
 updated, it seems that the headers that get send by Varnish are not
 entirely correct.

 But this might also be my fault in some way?

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/247>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 11 12:56:54 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 11 Jun 2008 12:56:54 -0000
Subject: [Varnish] #248: Varnish doesn't automatically send host header if
	back-end is specified using hostname
Message-ID: <051.58adfa174b689b331ef946f723ea9929@projects.linpro.no>

#248: Varnish doesn't automatically send host header if back-end is specified
using hostname
----------------------+-----------------------------------------------------
 Reporter:  peter     |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 Not sure if this really is a bug.

 I specified my back-end using it's hostname. However the server in
 question serves more than one domain using virtual hosts. It seems Varnish
 only uses the hostname to resolve the IP of the server. It doesn't however
 send a "Host: ..." header with the same hostname to the server. This means
 the server isn't able to determine for which host a page is requested and
 it falls back to the default (if there is any). I expected however that it
 would send a host header with the back-end hostname.

 I've solved this for my specific case by adding the host header myself
 using the following VCL code:
 {{{
 sub vcl_recv {
   set req.http.Host = "dev";
   lookup;
 }
 }}}
 My back-end specification looks like follows:
 {{{
 backend default {
   .host = "dev";
   .port = "http";
 }
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/248>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 12 14:21:15 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 12 Jun 2008 14:21:15 -0000
Subject: [Varnish] #249: regsub
Message-ID: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>

#249: regsub
--------------------+-------------------------------------------------------
 Reporter:  ebik    |       Owner:  des  
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 Replacement string parsing is broken in current trunk.
 First of all, when handling $0, ..., $9 there shoud be used 's' instead of
 'sub'. Strage
 things happen when you try using them now.
 Second '&' is valid url character thus it should not be replaced in any
 case. Moreover
 it does the same as $0, thus the if (*s == '&') branch is not needed at
 all.
 Third, if we want to send "$0" to server we cannot, thus I suggest "$$" to
 translate as "$".
 Then "$$0" translates to "$0".

 I'm attaching proposal patch.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/249>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 12 14:42:10 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 12 Jun 2008 14:42:10 -0000
Subject: [Varnish] #238: regsub only replaces one occurance
In-Reply-To: <053.504a720132fa7a84012e00981861c60d@projects.linpro.no>
References: <053.504a720132fa7a84012e00981861c60d@projects.linpro.no>
Message-ID: <062.6007f6cc6205c9bd2814f5b258941075@projects.linpro.no>

#238: regsub only replaces one occurance
----------------------+-----------------------------------------------------
 Reporter:  galaxor   |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  high      |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  major     |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by ebik):

 Replying to [comment:1 phk]:
 > Your patch uses needless much memory on the workspace, a better and
 smaller fix committed in #2640.

 And your patch is broken. regsub("abcde","a(bcd)e","f$1g") now returns
 "fbcd1g".
 Now there is no way to include "&" in output.
 Also you say you just add regsuball, but you modified behavior of regsub.
 You document ALL changes
 you made in your commit. Moreover you SHOULD split your commit to two
 commits. One adding regsuball
 and to one that changes the behaviour of regsub.
 See ticket #249. (I found this ticket after opening that one.)

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/238#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 12 14:44:08 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 12 Jun 2008 14:44:08 -0000
Subject: [Varnish] #249: regsub
In-Reply-To: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
References: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
Message-ID: <059.64ede7c64a5fb10c939b7ab858ddcde8@projects.linpro.no>

#249: regsub
--------------------+-------------------------------------------------------
 Reporter:  ebik    |        Owner:  des  
     Type:  defect  |       Status:  new  
 Priority:  normal  |    Milestone:       
Component:  build   |      Version:  trunk
 Severity:  normal  |   Resolution:       
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by ebik):

 Now I found that this was broken by fixing #238 in commit 2460 by phk.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/249#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 12 15:42:29 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 12 Jun 2008 15:42:29 -0000
Subject: [Varnish] #250: POST error when using Opera
Message-ID: <050.f7179b97ee045b3deb2bdae4b32537be@projects.linpro.no>

#250: POST error when using Opera
--------------------+-------------------------------------------------------
 Reporter:  duja    |       Owner:  des                
     Type:  defect  |      Status:  new                
 Priority:  normal  |   Milestone:  Varnish 2.0 release
Component:  build   |     Version:  trunk              
 Severity:  normal  |    Keywords:                     
--------------------+-------------------------------------------------------
 Info from mailing list:

 What I have is a form login that has 3 input fields, username, password
 and security code (from captcha).

 When opera is making the POST it receives a 200 OK and NOT a 302 Moved
 Temp. as expected.

 This is the request that Opera is making:

    13 RxRequest    c POST
    13 RxURL        c /takelogin.php
    13 RxProtocol   c HTTP/1.1
    13 RxHeader     c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
    13 RxHeader     c Host: mydomain.com:8080
    13 RxHeader     c Accept: text/html, application/xml;q=0.9,
 application/xhtml+xml, image/png, image/jpeg, image/gif,
 image/x-xbitmap, */*;q=0.1
    13 RxHeader     c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
    13 RxHeader     c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
    13 RxHeader     c Accept-Encoding: deflate, gzip, x-gzip, identity,
 *;q=0
    13 RxHeader     c Referer: http://mydomain.com:8080/login.php
    13 RxHeader     c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
    13 RxHeader     c Cookie2: $Version=1
    13 RxHeader     c Connection: Keep-Alive, TE
    13 RxHeader     c TE: deflate, gzip, chunked, identity, trailers
    13 RxHeader     c Content-Length: 63
    13 RxHeader     c Content-Type: application/x-www-form-urlencoded

 My vcl has this code when POST are received:

         if(req.request != "GET" && req.request != "HEAD") {
                 set req.http.Connection = "close";
                 pass;
         }

 This code usually works with FF and IE but NOT with Opera.

 If I remove "set req.http.Connection = "close";"

 the login process works with no problem.

 I have had problems with POSTs before, thats why I've been using
 Connection = "close" on POSTs.

 Here is the whole error log:
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1213029670
    13 SessionClose - timeout
    13 StatSess     - 82.182.xx.xx 1306 0 1 2 0 0 2 744 6750
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1213029673
    13 SessionOpen  c 82.182.xx.xx 1307 0.0.0.0:8080
    13 ReqStart     c 82.182.xx.xx 1307 803913450
    13 RxRequest    c POST
    13 RxURL        c /takelogin.php
    13 RxProtocol   c HTTP/1.1
    13 RxHeader     c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
    13 RxHeader     c Host: mydomain.com:8080
    13 RxHeader     c Accept: text/html, application/xml;q=0.9,
 application/xhtml+xml, image/png, image/jpeg, image/gif,
 image/x-xbitmap, */*;q=0.1
    13 RxHeader     c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
    13 RxHeader     c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
    13 RxHeader     c Accept-Encoding: deflate, gzip, x-gzip, identity,
 *;q=0
    13 RxHeader     c Referer: http://mydomain.com:8080/login.php
    13 RxHeader     c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
    13 RxHeader     c Cookie2: $Version=1
    13 RxHeader     c Connection: Keep-Alive, TE
    13 RxHeader     c TE: deflate, gzip, chunked, identity, trailers
    13 RxHeader     c Content-Length: 63
    13 RxHeader     c Content-Type: application/x-www-form-urlencoded
    13 VCL_call     c recv
    13 VCL_return   c pass
    13 VCL_call     c pass
    13 VCL_return   c pass
    14 TxRequest    - POST
    14 TxURL        - /takelogin.php
    14 TxProtocol   - HTTP/1.1
    14 TxHeader     - User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
    14 TxHeader     - Host: mydomain.com:8080
    14 TxHeader     - Accept: text/html, application/xml;q=0.9,
 application/xhtml+xml, image/png, image/jpeg, image/gif,
 image/x-xbitmap, */*;q=0.1
    14 TxHeader     - Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
    14 TxHeader     - Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
    14 TxHeader     - Accept-Encoding: deflate, gzip, x-gzip, identity,
 *;q=0
    14 TxHeader     - Referer: http://mydomain.com:8080/login.php
    14 TxHeader     - Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
    14 TxHeader     - Cookie2: $Version=1
    14 TxHeader     - Content-Type: application/x-www-form-urlencoded
    14 TxHeader     - X-Varnish: 803913450
    14 TxHeader     - X-Forwarded-For: 82.182.xx.xx
    14 RxProtocol   - HTTP/1.1
    14 RxStatus     - 200
    14 RxResponse   - OK
    14 RxHeader     - Date: Mon, 09 Jun 2008 16:41:14 GMT
    14 RxHeader     - Server: Apache
    14 RxHeader     - X-Powered-By: PHP/5.2.0-8+etch10
    14 RxHeader     - Content-Length: 23
    14 RxHeader     - Content-Type: text/html; charset=UTF-8
    13 ObjProtocol  c HTTP/1.1
    13 ObjStatus    c 200
    13 ObjResponse  c OK
    13 ObjHeader    c Date: Mon, 09 Jun 2008 16:41:14 GMT
    13 ObjHeader    c Server: Apache
    13 ObjHeader    c X-Powered-By: PHP/5.2.0-8+etch10
    13 ObjHeader    c Content-Type: text/html; charset=UTF-8
    14 BackendReuse - mydomain
    13 TTL          c 803913450 RFC 120 1213029674 1213029674 0 0 0
    13 VCL_call     c fetch
    13 VCL_return   c pass
    13 Length       c 23
    13 VCL_call     c deliver
    13 VCL_return   c deliver
    13 TxProtocol   c HTTP/1.1
    13 TxStatus     c 200
    13 TxResponse   c OK
    13 TxHeader     c Server: Apache
    13 TxHeader     c X-Powered-By: PHP/5.2.0-8+etch10
    13 TxHeader     c Content-Type: text/html; charset=UTF-8
    13 TxHeader     c Content-Length: 23
    13 TxHeader     c Date: Mon, 09 Jun 2008 16:41:14 GMT
    13 TxHeader     c X-Varnish: 803913450
    13 TxHeader     c Age: 0
    13 TxHeader     c Via: 1.1 varnish
    13 TxHeader     c Connection: keep-alive
    13 ReqEnd       c 803913450 1213029674.708000898 1213029674.780754805
 0.003840923 0.072657347 0.000096560
     0 StatAddr     - 82.182.xx.xx 0 76 14 47 0 0 30 12274 157175


 # varnishd -V
 varnishd (varnish-trunk)
 Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS


 What I should mention is that the problem can be solved by another method.

 If I remove the Cookie2 AND TE header it all works out fine:

        remove req.http.Cookie2;
        remove req.http.TE;

         if(req.request != "GET" && req.request != "HEAD") {
                 set req.http.Connection = "close";
                 pass;
         }

 This works!

 But I must remove BOTH Cookie2 and TE header, else it wont work.

 * I will add more info from varnishlog as soon as Im home

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/250>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 12 18:39:43 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 12 Jun 2008 18:39:43 -0000
Subject: [Varnish] #249: regsub
In-Reply-To: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
References: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
Message-ID: <059.3aef5f4c6971677e5121874037f2e516@projects.linpro.no>

#249: regsub
--------------------+-------------------------------------------------------
 Reporter:  ebik    |        Owner:  des  
     Type:  defect  |       Status:  new  
 Priority:  normal  |    Milestone:       
Component:  build   |      Version:  trunk
 Severity:  normal  |   Resolution:       
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by ebik):

 I'm sorry. Now I see that I wrongly filled 'Component' field of this
 ticket. So this should be assigned to 'phk' probably. Can you fix this for
 me?

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/249#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 14 22:15:48 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 14 Jun 2008 22:15:48 -0000
Subject: [Varnish] #249: regsub
In-Reply-To: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
References: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
Message-ID: <059.f235d1eb1d83c40fb1ddb2aa04af703d@projects.linpro.no>

#249: regsub
----------------------+-----------------------------------------------------
 Reporter:  ebik      |        Owner:  phk  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * owner:  des => phk
  * component:  build => varnishd

Comment:

 Why does your patch remove support for the '&' replacement ?

 Poul-Henning

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/249#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From ebik at jyxo.com  Mon Jun 16 09:47:25 2008
From: ebik at jyxo.com (Tomas Ebenlendr)
Date: Mon, 16 Jun 2008 11:47:25 +0200
Subject: [Varnish] #249: regsub
In-Reply-To: <059.f235d1eb1d83c40fb1ddb2aa04af703d@projects.linpro.no>
References: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
	<059.f235d1eb1d83c40fb1ddb2aa04af703d@projects.linpro.no>
Message-ID: <485636AD.5090405@jyxo.com>

Varnish wrote:
> #249: regsub
> ----------------------+-----------------------------------------------------
>  Reporter:  ebik      |        Owner:  phk  
>      Type:  defect    |       Status:  new  
>  Priority:  normal    |    Milestone:       
> Component:  varnishd  |      Version:  trunk
>  Severity:  normal    |   Resolution:       
>  Keywords:            |  
> ----------------------+-----------------------------------------------------
> Changes (by phk):
> 
>   * owner:  des => phk
>   * component:  build => varnishd
> 
> Comment:
> 
>  Why does your patch remove support for the '&' replacement ?
> 
>  Poul-Henning

In fact, that patch should be split in two patches: one replacing 'sub' with 's'.
(Because this is fix).

And another with removing '&' and adding '$$'. (Because this is feature.)

I need to get from "/foo/bar" to "/article?section=foo&id=bar" and I have no way
how to include '&' in result of substitution now.
I want: regsub(req.http.location,"/([a-z]*)/([a-z]*)","/article?section=$1&id=$2"),
but I want to somehow 'escape' the '&'.

I removed '&' because '$0' does the same. Maybe we can add '$&' to be consistent
with perl.


From varnish-bugs at projects.linpro.no  Mon Jun 16 20:24:17 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 16 Jun 2008 20:24:17 -0000
Subject: [Varnish] #249: regsub
In-Reply-To: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
References: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
Message-ID: <059.dadb6d31167f6255bbd90042b504832e@projects.linpro.no>

#249: regsub
----------------------+-----------------------------------------------------
 Reporter:  ebik      |        Owner:  phk  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by ebik):

 Replying to [comment:3 phk]:
 > Why does your patch remove support for the '&' replacement ?
 >
 > Poul-Henning
 This patch should be splitted in two patches. One should fix broken
 behaviour of $0, $1, ... $9, and the other one shoud remove '&' and add
 '$$'.
 The '&' can be simulated by '$0'. I need to substitue '/foo/bar' by
 'script.php?dir=foo&id=bar'. And there is no way to include '&' in
 replacement now. Maybe there should be '$&' which is consistent with perl
 language.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/249#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 18 15:26:43 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 18 Jun 2008 15:26:43 -0000
Subject: [Varnish] #251: segfault on regsub on missing http header
Message-ID: <053.7cb6f09f72a61371c4ef3dabb7f5ec43@projects.linpro.no>

#251: segfault on regsub on missing http header
----------------------+-----------------------------------------------------
 Reporter:  wichert   |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 Observed in current trunk. I have a regular expression in vcl_fetch to
 filter incoming cookies:

 {{{
 if (req.url ~ "VirtualHostRoot/?$" && ! req.http.cookie ~ "__ac" ) {
     set req.http.cookie = regsub(req.http.cookie,
 ".*mainchain=%22([^%22]*%22).*", "mainchain=$1");
 }
 }}}

 When a request without a cookie header comes in varnishlog only shows
 this:
 {{{
     0 CLI          - Rd vcl.use boot
     0 CLI          - Wr 0 200
     0 CLI          - Rd start
     0 Debug        - "Acceptor is epoll"
     0 CLI          - Wr 0 200
     0 WorkThread   - 0x6fcdb104 start
    13 SessionOpen  c 10.7.0.113 51006
     0 CLI          - Rd vcl.load boot ./vcl.1P9zoqAU.o
     0 CLI          - Wr 0 200 Loaded "./vcl.1P9zoqAU.o" as "boot"
 }}}

 a strace of the varnish processes shows varnish segfaulting. I am guessing
 regsub gets a NULL input string and does not handle that correctly.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/251>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 18 15:28:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 18 Jun 2008 15:28:31 -0000
Subject: [Varnish] #252: % escapes in strings undocumented
Message-ID: <053.41aaa680254412e34a8b52b625610d61@projects.linpro.no>

#252: % escapes in strings undocumented
---------------------------+------------------------------------------------
 Reporter:  wichert        |       Owner:  des  
     Type:  documentation  |      Status:  new  
 Priority:  low            |   Milestone:       
Component:  documentation  |     Version:  trunk
 Severity:  normal         |    Keywords:       
---------------------------+------------------------------------------------
 I had to write a regular expression which needed to match double-quotes,
 but could not determine how from the documentation. Looking around in the
 source revealed that one can use %<hexcode> escape sequences for
 situations like that. It would bit nice if vcl(7) documented that.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/252>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 19 03:29:44 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 19 Jun 2008 03:29:44 -0000
Subject: [Varnish] #253: Patch to make use of default_grace
Message-ID: <049.d041d9b03321d51c1e33c45d30462e37@projects.linpro.no>

#253: Patch to make use of default_grace
--------------------+-------------------------------------------------------
 Reporter:  sky     |       Owner:  des  
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 Currently, unless you set obj.grace, grace is set to NaN so the adding of
 the ttl to obj.grace results in another NaN. The object then timeouts
 within a second.

 This exposes HSH_Grace and calls it at the

 {{{
 Index: bin/varnishd/cache_expire.c
 ===================================================================
 --- bin/varnishd/cache_expire.c (revision 2735)
 +++ bin/varnishd/cache_expire.c (working copy)
 @@ -147,7 +147,7 @@
                 oe->timer_when = o->prefetch;
                 oe->timer_what = tmr_prefetch;
         } else {
 -               oe->timer_when = o->ttl + o->grace;
 +               oe->timer_when = o->ttl + HSH_Grace(o->grace);
                 oe->timer_what = tmr_ttl;
         }
  }
 Index: bin/varnishd/cache_hash.c
 ===================================================================
 --- bin/varnishd/cache_hash.c   (revision 2735)
 +++ bin/varnishd/cache_hash.c   (working copy)
 @@ -67,7 +67,7 @@

  static struct hash_slinger      *hash;

 -static double
 +double
  HSH_Grace(double g)
  {
         if (isnan(g))
 Index: bin/varnishd/cache.h
 ===================================================================
 --- bin/varnishd/cache.h        (revision 2735)
 +++ bin/varnishd/cache.h        (working copy)
 @@ -463,6 +463,7 @@
  void HSH_Ref(struct object *o);
  void HSH_Deref(struct object *o);
  void HSH_Init(void);
 +double HSH_Grace(double g);

  /* cache_http.c */
  const char *http_StatusMessage(unsigned);
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/253>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 19 07:12:29 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 19 Jun 2008 07:12:29 -0000
Subject: [Varnish] #254: 
Message-ID: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>

#254: 
--------------------+-------------------------------------------------------
 Reporter:  sky     |       Owner:  des  
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 Jun 19 06:29:59 varnish2 varnishd: Child (3635) said <<Assert error in
 exp_timer(), cache_expire.c line 300:>>
 Jun 19 06:29:59 varnish2 varnishd: Child (3635) said <<
 Condition(oe2->timer_when >= oe->timer_when) not true.>>

 I am trying to figure out what is going on, but it is only when I start
 putting load on the servers that they actually just go boom.

 Any advice on how to proceed?


 {{{
 backend default {
         .host = "xxxxx";
         .port = "80";
 }

 backend wikia {
         # should be changed to a 10.8 address
         .host = "xxxxx";
         .port = "80";
 }

 backend armchair {
         .host = "xxxxxx";
         .port = "80";
 }

 backend gamewikis {
         .host = "xxxxx";
         .port = "80";
 }


 # Below is a commented-out copy of the default VCL logic.  If you
 # redefine any of these subroutines, the built-in logic will be
 # appended to your code.

 ## Called when a client request is received
 #
 sub vcl_recv {


         if (req.http.Accept-Encoding) {
                 if (req.http.Accept-Encoding ~ "gzip") {
                     set req.http.Accept-Encoding = "gzip";
                 } elsif (req.http.Accept-Encoding ~ "deflate") {
                     set req.http.Accept-Encoding = "deflate";
                 } else {
                     # unkown algorithm
                     remove req.http.Accept-Encoding;
                 }
         }


         if (req.request == "PURGE") {
                 # acl check needed
                 purge_hash(req.http.purgeurl);
                 error 200 "Purged";
         }


         if (req.url == "/lvscheck.html") {
                 error 200 "varnish is okay";
         }

         if(req.http.host ~ "^(nwn|oblivion|meta|war|gw)$") {
                 set req.backend = wikia;
         } elsif(req.http.host ~ "(gw.wikia.com|gamewikis.org)$") {
                 set req.backend = gamewikis;
         } elsif(req.http.host ~ "^siwiki.sportsillustrated.cnn.com$") {
                 set req.backend = armchair;
         } elsif(req.http.host ~ "^thirdturn.armchairgm.com$") {
                 set req.backend = wikia;
         } elsif(req.http.host ~ "armchairgm.com$") {
                 set req.backend = armchair;
         } else {
                 set req.backend = wikia;
         }

         if (req.url ~ "/__utm.gif") {
                 set req.url = "/__utm.gif";
         }


         # might as well make them all look like /
         if (req.http.host == "216.151.156.11") {
                 set req.http.origurl = req.url;
         #       set req.url = "/";
         }


         if (req.request != "GET" && req.request != "HEAD" && req.request
 != "PURGE") {
                 pipe;
         }
         if (req.http.Expect) {
                 pipe;
         }
         if (req.http.Authenticate || req.http.Cookie ~
 "(UserID|_session)") {
                 pass;
         }
         lookup;
 }


 sub vcl_hash {
         set req.hash += req.url;
         set req.hash += req.http.host;
         hash;
 }

 #
 ## Called when entering pipe mode
 #
 #sub vcl_pipe {
 #       pipe;
 #}
 #
 ## Called when entering pass mode
 #
 #sub vcl_pass {
 #       pass;
 #}
 #
 ## Called when entering an object into the cache
 #


 #
 ## Called when the requested object was found in the cache
 #
 sub vcl_hit {


         if (!obj.cacheable) {
                 pass;
         }
         if (obj.http.X-Cache == "MISS") {
                 set obj.http.X-Cache = "HIT";
         }
         deliver;
 }
 #
 ## Called when the requested object was not found in the cache
 #
 sub vcl_miss {



         if (req.request == "PURGE") {
                 error 404 "Not in cache.";
         }
         fetch;
 }
 #
 ## Called when the requested object has been retrieved from the
 ## backend, or the request to the backend has failed
 #
 sub vcl_fetch {
         if (!obj.valid) {
                 error;
         }
         set obj.http.X-Cache = "MISS";
         remove obj.http.Vary;

         # this is the old wow ip, so issue redirect
         if (req.http.host == "216.151.156.11") {
                 set obj.http.origurl = req.http.origurl;
         }

         if (!obj.cacheable) {
                 set obj.http.X-Cacheable = "NO:Not-Cacheable";
                 pass;
         }
         if (obj.http.Cache-Control ~ "private") {
                 if(req.http.Cookie ~"(UserID|_session)") {
                         set obj.http.X-Cacheable = "NO:Got Session";
                 } else {
                         set obj.http.X-Cacheable = "NO:Cache-
 Control=private";
                 }
                 pass;
         }
         if (obj.http.Set-Cookie ~ "(UserID|_session)") {
                 set obj.http.X-Cacheable = "NO:Set-Cookie";
                 pass;
         }

         set obj.http.X-Cacheable = "YES";
         set obj.http.X-Cache = "MISS";
         set obj.grace = 10s;
         insert;
 }

 sub vcl_prefetch {
         pass;
 }

 #
 #
 ## Called before a cached object is delivered to the client
 #
 sub vcl_deliver {

         set resp.http.X-Served-By = "varnish2";

         # this is the old wow ip, so issue redirect
         if (resp.http.origurl) {
                 set resp.http.Location = regsub(resp.http.origurl, "^" ,
 "http://www.wowwiki.com");
                 set resp.status = 301;
                 set resp.response = "Moved Permanently";
                 deliver;
         }


     set resp.http.Cache-Control = "private, s-maxage=0, max-age=0, must-
 revalidate";
     remove resp.http.X-Vary-Options;
     remove resp.http.X-Powered-By;
     remove resp.http.X-Time-CPU-Time;
     remove resp.http.X-Request-Id;
     deliver;
 }

 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/254>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 19 07:15:21 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 19 Jun 2008 07:15:21 -0000
Subject: [Varnish] #254: 
In-Reply-To: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
References: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
Message-ID: <058.012e890548a33fc4a05d746c92e2b56c@projects.linpro.no>

#254: 
--------------------+-------------------------------------------------------
 Reporter:  sky     |        Owner:  des  
     Type:  defect  |       Status:  new  
 Priority:  normal  |    Milestone:       
Component:  build   |      Version:  trunk
 Severity:  normal  |   Resolution:       
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by sky):

 Running 2735

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/254#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 19 08:13:46 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 19 Jun 2008 08:13:46 -0000
Subject: [Varnish] #254: 
In-Reply-To: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
References: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
Message-ID: <058.94e21c2cd8fb9dcf548b0a7f2b746a56@projects.linpro.no>

#254: 
--------------------+-------------------------------------------------------
 Reporter:  sky     |        Owner:  des  
     Type:  defect  |       Status:  new  
 Priority:  normal  |    Milestone:       
Component:  build   |      Version:  trunk
 Severity:  normal  |   Resolution:       
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by sky):

 Just commenting out the assertion "worked" fine. It sustained
 www.wowwiki.com for 60 minutes.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/254#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 19 23:23:42 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 19 Jun 2008 23:23:42 -0000
Subject: [Varnish] #255: Varnish segfaults on certain response header sets
Message-ID: <055.2db80bcdd95846f89026ce28c359752f@projects.linpro.no>

#255: Varnish segfaults on certain response header sets
-----------------------+----------------------------------------------------
 Reporter:  rafrombrc  |       Owner:  phk  
     Type:  defect     |      Status:  new  
 Priority:  normal     |   Milestone:       
Component:  varnishd   |     Version:  trunk
 Severity:  critical   |    Keywords:       
-----------------------+----------------------------------------------------
 I'm testing varnish in front of a collection of HTTP services.  Depending
 on how I have things configured in my upstream app, the response headers
 can vary slightly.  Some combinations of response headers work fine, but
 others cause varnish to segfault, but only in cases where the response
 body is longer than approx 9000 bytes.

 Here's an example of a header set that does NOT cause the problem:

 Outgoing headers: (200 OK)
   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
 Plone/3.0.7 (svn/unreleased)
   Date: Thu, 19 Jun 2008 21:14:49 GMT
   Content-Length: 18347
   Expires: Mon, 22 Jun 1998 21:14:49 GMT
   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
   X-Caching-Rule-Id: 7
   Cache-Control: max-age=0, s-maxage=3600, must-revalidate
   Content-Type: text/html; charset=utf-8
   X-Header-Set-Id: cache-in-proxy-1-hour

 The following response headers cause varnish to crash:

 Outgoing headers: (200 OK)
   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
 Plone/3.0.7 (svn/unreleased)
   Date: Thu, 19 Jun 2008 21:14:49 GMT
   Content-Length: 18347
   Expires: Thu, 19 Jun 2008 21:14:49 GMT
   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
   X-Caching-Rule-Id: 7
   Cache-Control: must-revalidate, max-age = 0
   Content-Type: text/html; charset=utf-8
   X-Header-Set-Id: cache-in-proxy-1-hour

 Note that the only difference in the header sets are the Cache-Control and
 Expires headers.

 I can reproduce this problem with the varnish 1.1.2 release, the 1.2 svn
 branch, and the svn trunk.  I'm using Ubuntu 7.10.  'uname -a' generates
 the following:

 Linux parsifal 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008
 x86_64 GNU/Linux

 My VCL file and a core dump are attached.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/255>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 00:13:12 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 00:13:12 -0000
Subject: [Varnish] #255: Varnish segfaults on certain response header sets
In-Reply-To: <055.2db80bcdd95846f89026ce28c359752f@projects.linpro.no>
References: <055.2db80bcdd95846f89026ce28c359752f@projects.linpro.no>
Message-ID: <064.19168987cdf674891b3d91290b1f3b39@projects.linpro.no>

#255: Varnish segfaults on certain response header sets
-----------------------+----------------------------------------------------
 Reporter:  rafrombrc  |        Owner:  phk  
     Type:  defect     |       Status:  new  
 Priority:  normal     |    Milestone:       
Component:  varnishd   |      Version:  trunk
 Severity:  critical   |   Resolution:       
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by rafrombrc):

 whoops, the header lists got mangled, let's try that again.  here are the
 headers that work:

 {{{
 Outgoing headers: (200 OK)
   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
 Plone/3.0.7 (svn/unreleased)
   Date: Thu, 19 Jun 2008 21:14:49 GMT
   Content-Length: 18347
   Expires: Mon, 22 Jun 1998 21:14:49 GMT
   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
   X-Caching-Rule-Id: 7
   Cache-Control: max-age=0, s-maxage=3600, must-revalidate
   Content-Type: text/html; charset=utf-8
   X-Header-Set-Id: cache-in-proxy-1-hour
 }}}

 and here are the headers that cause the segfault:

 {{{

 Outgoing headers: (200 OK)
   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
 Plone/3.0.7 (svn/unreleased)
   Date: Thu, 19 Jun 2008 21:14:49 GMT
   Content-Length: 18347
   Expires: Thu, 19 Jun 2008 21:14:49 GMT
   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
   X-Caching-Rule-Id: 7
   Cache-Control: must-revalidate, max-age = 0
   Content-Type: text/html; charset=utf-8
   X-Header-Set-Id: cache-in-proxy-1-hour
 }}}

 again, you'll notice that the only difference btn the header sets is the
 Cache-Control and the Expires headers.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/255#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 07:15:56 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 07:15:56 -0000
Subject: [Varnish] #254: Condition(oe2->timer_when >= oe->timer_when)
	not true
In-Reply-To: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
References: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
Message-ID: <058.883919cedbe0ffffa4aa50c17e47709d@projects.linpro.no>

#254: Condition(oe2->timer_when >= oe->timer_when) not true
--------------------+-------------------------------------------------------
 Reporter:  sky     |        Owner:  des  
     Type:  defect  |       Status:  new  
 Priority:  normal  |    Milestone:       
Component:  build   |      Version:  trunk
 Severity:  normal  |   Resolution:       
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * summary:  => Condition(oe2->timer_when >= oe->timer_when) not true

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/254#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 07:33:04 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 07:33:04 -0000
Subject: [Varnish] #253: Patch to make use of default_grace
In-Reply-To: <049.d041d9b03321d51c1e33c45d30462e37@projects.linpro.no>
References: <049.d041d9b03321d51c1e33c45d30462e37@projects.linpro.no>
Message-ID: <058.9c7e5069b6613ce5aec3028a9ac626cc@projects.linpro.no>

#253: Patch to make use of default_grace
--------------------+-------------------------------------------------------
 Reporter:  sky     |        Owner:  des   
     Type:  defect  |       Status:  closed
 Priority:  normal  |    Milestone:        
Component:  build   |      Version:  trunk 
 Severity:  normal  |   Resolution:  fixed 
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Committed, thanks!

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/253#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 10:22:35 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 10:22:35 -0000
Subject: [Varnish] #249: regsub
In-Reply-To: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
References: <050.40c4cd188cff20327471f67846ab9698@projects.linpro.no>
Message-ID: <059.a43046580c9a5fb5660131407f8fc6fa@projects.linpro.no>

#249: regsub
----------------------+-----------------------------------------------------
 Reporter:  ebik      |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I have fixed this slightly different way.

 I've added '\' escaping of '$' and '&'

 I have retained the '&' replacement for now, but also added $$.

 I can see the point about '&' and query strings and will ponder dropping
 it before 2.0.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/249#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 12:44:08 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 12:44:08 -0000
Subject: [Varnish] #251: segfault on regsub on missing http header
In-Reply-To: <053.7cb6f09f72a61371c4ef3dabb7f5ec43@projects.linpro.no>
References: <053.7cb6f09f72a61371c4ef3dabb7f5ec43@projects.linpro.no>
Message-ID: <062.c6761965ea2f375280f31dcd51142a66@projects.linpro.no>

#251: segfault on regsub on missing http header
----------------------+-----------------------------------------------------
 Reporter:  wichert   |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Fixed in #2743

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/251#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 12:46:03 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 12:46:03 -0000
Subject: [Varnish] #215: regex matches sporadically on identical request
In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
Message-ID: <063.c18d17328461d2fb82cb74186e0086b7@projects.linpro.no>

#215: regex matches sporadically on identical request
----------------------+-----------------------------------------------------
 Reporter:  onitunes  |        Owner:  des  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  build     |      Version:  1.0.4
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by phk):

 Any news ?

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/215#comment:7>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 12:48:47 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 12:48:47 -0000
Subject: [Varnish] #224: Improved logging
In-Reply-To: <049.b840548eba4d9d14102064bf6f789678@projects.linpro.no>
References: <049.b840548eba4d9d14102064bf6f789678@projects.linpro.no>
Message-ID: <058.a6c28d95943200e0e805c689bb3c59b4@projects.linpro.no>

#224: Improved logging
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  des                      
     Type:  enhancement  |       Status:  new                      
 Priority:  normal       |    Milestone:  Varnish 2.0 code complete
Component:  varnishd     |      Version:  trunk                    
 Severity:  normal       |   Resolution:                           
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by phk):

 Just a quick comment while browsing tickets:

 "Every log line should be tagged with the XID of the request it belongs
 to, or 0 if it's not directly related to a request."

 We already have that linkage through the SHMLOG_ID (filedescriptor) field.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/224#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 13:09:35 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 13:09:35 -0000
Subject: [Varnish] #116: Support purging by hostname
In-Reply-To: <051.02818bc70c4abe7424ad7a5676154685@projects.linpro.no>
References: <051.02818bc70c4abe7424ad7a5676154685@projects.linpro.no>
Message-ID: <060.98590ea8882971b990598ad70c11e81f@projects.linpro.no>

#116: Support purging by hostname
---------------------------------+------------------------------------------
 Reporter:  gaute                |        Owner:  phk   
     Type:  enhancement          |       Status:  closed
 Priority:  normal               |    Milestone:        
Component:  varnishd             |      Version:  trunk 
 Severity:  normal               |   Resolution:  fixed 
 Keywords:  purge host hostname  |  
---------------------------------+------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This is actually possibly now, using the purge.hash facility.

 The hostname is part of the hash by default, so specifying an argument of
 something like
 {{{
      purge.hash "#hostname#"
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/116#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 13:24:40 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 13:24:40 -0000
Subject: [Varnish] #216: String concatenation in functions
In-Reply-To: <051.d8162fcb19c67b07da17c0349a8c725c@projects.linpro.no>
References: <051.d8162fcb19c67b07da17c0349a8c725c@projects.linpro.no>
Message-ID: <060.602b239326b5e313d2ccd626ea3733c6@projects.linpro.no>

#216: String concatenation in functions
----------------------+-----------------------------------------------------
 Reporter:  teddy     |        Owner:  phk      
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  After 2.0
Component:  varnishd  |      Version:  trunk    
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * milestone:  => After 2.0

Comment:

 You are right of course, string concatenation should work everywhere, but
 right now it only works for header assignment.

 To properly fix this, requires major surgery to the VCL compiler, which I
 don't want to do right before the 2.0 release.

 The obvious workaround is to use header assignmnt as a temporary variable:
 {{{
      set req.http.foobar = req.url "#" req.http.host "#";
      purge_hash(req.http.foobar);
      remove req.http.foobar;
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/216#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 13:26:40 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 13:26:40 -0000
Subject: [Varnish] #27: make workspace tweakable
In-Reply-To: <049.ec5fda2dd7fd99c9c870e9b86d6d46ee@projects.linpro.no>
References: <049.ec5fda2dd7fd99c9c870e9b86d6d46ee@projects.linpro.no>
Message-ID: <058.68dd98d1bd39a980ba432db1978d4c7a@projects.linpro.no>

#27: make workspace tweakable
-------------------------+--------------------------------------------------
 Reporter:  phk          |        Owner:  phk   
     Type:  enhancement  |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This can be closed.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/27#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 13:27:54 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 13:27:54 -0000
Subject: [Varnish] #163: killing telnet session crashes varnishd
In-Reply-To: <053.2f0d3841d36cfe83d60aec1b4a0995d6@projects.linpro.no>
References: <053.2f0d3841d36cfe83d60aec1b4a0995d6@projects.linpro.no>
Message-ID: <062.6a9c970c1a20b0dba4c969f096f5f0f1@projects.linpro.no>

#163: killing telnet session crashes varnishd
---------------------------------------------------+------------------------
 Reporter:  henning                                |        Owner:  phk   
     Type:  defect                                 |       Status:  closed
 Priority:  normal                                 |    Milestone:        
Component:  varnishd                               |      Version:  trunk 
 Severity:  normal                                 |   Resolution:  fixed 
 Keywords:  hup, console, telnet, assert, mgt_cli  |  
---------------------------------------------------+------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I belive this has been fixed for quite some time now.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/163#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 13:28:58 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 13:28:58 -0000
Subject: [Varnish] #65: Unbuffered loggin/Logging of spawning of children.
In-Reply-To: <048.23a954e89d8c27c0671592470964914d@projects.linpro.no>
References: <048.23a954e89d8c27c0671592470964914d@projects.linpro.no>
Message-ID: <057.a5d8e6bdc6e6b6187b00b4986375513b@projects.linpro.no>

#65: Unbuffered loggin/Logging of spawning of children.
-------------------------+--------------------------------------------------
 Reporter:  ay           |        Owner:  des                      
     Type:  enhancement  |       Status:  closed                   
 Priority:  normal       |    Milestone:  Varnish 2.0 code complete
Component:  varnishd     |      Version:  trunk                    
 Severity:  normal       |   Resolution:  fixed                    
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 This is fixed with the syslog logging of manager actions.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/65#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 14:37:12 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 14:37:12 -0000
Subject: [Varnish] #171: Support logging ip and port of varnishd instance
In-Reply-To: <051.21efc75058b817a53cfab09436020114@projects.linpro.no>
References: <051.21efc75058b817a53cfab09436020114@projects.linpro.no>
Message-ID: <060.e62badc07fc396d27fb7d72120748f26@projects.linpro.no>

#171: Support logging ip and port of varnishd instance
-------------------------+--------------------------------------------------
 Reporter:  Caleb        |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by phk):

 I have added the listen address to the SessionOpen record, since we have
 that for free.

 Putting the actual bound IP(+port) there would cost us a (cheap) system
 call, so I would prefer to avoid it by default, but we can make it an
 option controlled by a parameter.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/171#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 14:48:46 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 14:48:46 -0000
Subject: [Varnish] #171: Support logging ip and port of varnishd instance
In-Reply-To: <051.21efc75058b817a53cfab09436020114@projects.linpro.no>
References: <051.21efc75058b817a53cfab09436020114@projects.linpro.no>
Message-ID: <060.f37f3022448de86baaa62a35b34513ea@projects.linpro.no>

#171: Support logging ip and port of varnishd instance
-------------------------+--------------------------------------------------
 Reporter:  Caleb        |        Owner:  phk   
     Type:  enhancement  |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Actually, this was so trivial that I decided to just do it.

 The paramter is log_local_address, defaults to off.

 Fixed in #2745

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/171#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 14:52:24 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 14:52:24 -0000
Subject: [Varnish] #252: % escapes in strings undocumented
In-Reply-To: <053.41aaa680254412e34a8b52b625610d61@projects.linpro.no>
References: <053.41aaa680254412e34a8b52b625610d61@projects.linpro.no>
Message-ID: <062.1ec2c581047f05d0bb2d1cf5cb4929dd@projects.linpro.no>

#252: % escapes in strings undocumented
---------------------------+------------------------------------------------
 Reporter:  wichert        |        Owner:  des   
     Type:  documentation  |       Status:  closed
 Priority:  low            |    Milestone:        
Component:  documentation  |      Version:  trunk 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 fixed in 2746

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/252#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 14:55:46 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 14:55:46 -0000
Subject: [Varnish] #54: varnishstat gives improbable numbers
In-Reply-To: <051.f63a7d6af4cc6013f864c8504332f5dd@projects.linpro.no>
References: <051.f63a7d6af4cc6013f864c8504332f5dd@projects.linpro.no>
Message-ID: <060.0c3ed4144f77838d1260c26635b1b761@projects.linpro.no>

#54: varnishstat gives improbable numbers
-------------------------+--------------------------------------------------
 Reporter:  bjorn        |        Owner:  phk    
     Type:  defect       |       Status:  closed 
 Priority:  normal       |    Milestone:         
Component:  varnishstat  |      Version:         
 Severity:  normal       |   Resolution:  wontfix
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 This is a known issue, which have no general solution.

 The problem is that multiple threads may try to update the counters at the
 same time and if they race, updates may get lost.

 We try to minimize cases where this happens by updating counters under
 appropriate locks, but this is not always feasible.

 In the few remaining cases, the overhead and contention on a dedicated
 lock for the counters would be significant.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/54#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 14:58:03 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 14:58:03 -0000
Subject: [Varnish] #42: Support gzip / deflate
In-Reply-To: <049.d59f4a4f4d3ee7e02ab7104d5fd9647b@projects.linpro.no>
References: <049.d59f4a4f4d3ee7e02ab7104d5fd9647b@projects.linpro.no>
Message-ID: <058.3a750ea4a85054f1d77dca60ad989e09@projects.linpro.no>

#42: Support gzip / deflate
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk                      
     Type:  enhancement  |       Status:  closed                   
 Priority:  normal       |    Milestone:  Varnish 2.0 code complete
Component:  varnishd     |      Version:  trunk                    
 Severity:  normal       |   Resolution:  wontfix                  
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 I'm closing this ticket and moving the subject to the wikis "post-2.0"
 page.

 With respect to chunked encoding: varnish always eliminates that from the
 data stream.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/42#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 15:50:29 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 15:50:29 -0000
Subject: [Varnish] #102: RES_WriteObj() does not send body for POST
In-Reply-To: <049.0f1cd63b229c27c45e4086d98e976838@projects.linpro.no>
References: <049.0f1cd63b229c27c45e4086d98e976838@projects.linpro.no>
Message-ID: <058.e2093ee1f25b46f501fe9e3df5007762@projects.linpro.no>

#102: RES_WriteObj() does not send body for POST
----------------------+-----------------------------------------------------
 Reporter:  des       |        Owner:  des   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 I have entered a regression test for this feature using just this VCL:

 {{{
         if (req.request == "POST") {
                 set req.request = "GET";
         }
 }}}

 and as far as I can see, that works.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/102#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:15:08 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:15:08 -0000
Subject: [Varnish] #26: Various minor issues for consideration
In-Reply-To: <049.89c296a8383e891e88191c319ffe8bc9@projects.linpro.no>
References: <049.89c296a8383e891e88191c319ffe8bc9@projects.linpro.no>
Message-ID: <058.3b982647f4be0aed0891410fa5e758f8@projects.linpro.no>

#26: Various minor issues for consideration
-------------------------+--------------------------------------------------
 Reporter:  phk          |        Owner:  phk   
     Type:  enhancement  |       Status:  closed
 Priority:  low          |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This ticket has been overtaken by events:

 1. We log to syslog now, all output from the child process and all CLI
 comms.

 2. There are timestamps in the CLI PING/PONGs and request start/end
 records.

 3. We already do.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/26#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:27:23 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:27:23 -0000
Subject: [Varnish] #28: Doc input: CLI protocol
In-Reply-To: <049.01dcdd7ed49072dc7cf684a2b4e7bd05@projects.linpro.no>
References: <049.01dcdd7ed49072dc7cf684a2b4e7bd05@projects.linpro.no>
Message-ID: <058.cb8882e5ab1509487c88733b7b2b524a@projects.linpro.no>

#28: Doc input: CLI protocol
---------------------------+------------------------------------------------
 Reporter:  phk            |        Owner:  des   
     Type:  documentation  |       Status:  closed
 Priority:  normal         |    Milestone:        
Component:  documentation  |      Version:  trunk 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I have moved this to the wiki:
 http://varnish.projects.linpro.no/wiki/ManagementPort

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/28#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:29:48 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:29:48 -0000
Subject: [Varnish] #127: LRU hysteresis should be a parameter
In-Reply-To: <049.21c16a6a8b75ac119971b918086204a9@projects.linpro.no>
References: <049.21c16a6a8b75ac119971b918086204a9@projects.linpro.no>
Message-ID: <058.c49c47d1f99432281e42eee8084cd178@projects.linpro.no>

#127: LRU hysteresis should be a parameter
----------------------+-----------------------------------------------------
 Reporter:  des       |        Owner:  des   
     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:

 We have had that paramter for a long time: lru_interval

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/127#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:30:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:30:31 -0000
Subject: [Varnish] #64: Overflow in varnishstat
In-Reply-To: <058.6d128666aadcee84f53059da3db9a891@projects.linpro.no>
References: <058.6d128666aadcee84f53059da3db9a891@projects.linpro.no>
Message-ID: <067.dfd87b375ddb91667172bddf8e95bc1b@projects.linpro.no>

#64: Overflow in varnishstat
--------------------------+-------------------------------------------------
 Reporter:  ay at linpro.no  |        Owner:  phk  
     Type:  task          |       Status:  new  
 Priority:  normal        |    Milestone:       
Component:  varnishstat   |      Version:  trunk
 Severity:  normal        |   Resolution:       
 Keywords:  overflow      |  
--------------------------+-------------------------------------------------
Old description:

> We have a varnish (svn as of 2006-11-01). Varnishstat sometimes displays
> the following.
>
> 00:00:21
> Hitrate ratio:       10      100      172
> Hitrate avg:     0.6604   0.7549   0.7820
>
>          172         1.98         8.19 Client connections accepted
>          548         2.97        26.10 Client requests received
>          369         0.99        17.57 Cache hits
>           10         0.99         0.48 Cache hits for pass
>          168         0.99         8.00 Cache misses
>          179         1.98         8.52 Backend connections initiated
>          166         5.94         7.90 Backend connections recycles
>            0         0.00         0.00 Backend connections unused
>           56         0.00         2.67 N struct srcaddr
>           17        -4.95         0.81 N active struct srcaddr
>           39         0.00         1.86 N struct sess_mem
>           26        -5.94         1.24 N struct sess
>          175         1.98         8.33 N struct object
>          175         1.98         8.33 N struct objecthead
>          165         2.97         7.86 N struct smf
>            2         0.00         0.10 N small free smf
>            2         0.00         0.10 N large free smf
>           13         0.00         0.62 N struct vbe_conn
>           16         0.00         0.76 N worker threads
>           16         0.00         0.76 N worker threads created
>            0         0.00         0.00 N worker threads not created
>            0         0.00         0.00 N worker threads limited
>            0         0.00         0.00 N queued work requests
>           16         0.00         0.76 N overflowed work requests
>            0         0.00         0.00 N dropped work requests
>            0         0.00         0.00 N expired objects
>            0         0.00         0.00 N objects on deathrow
>            0         0.00         0.00 HTTP header overflows
>          152         1.98         7.24 Objects sent with sendfile
>          200         1.98         9.52 Objects sent with write
> 12961350068190840473 -5431088062805240832.00 -261209238358033856.00 Total
> Sessions
> 12961349728888425753 -5431088398748528640.00 -261209254515291712.00 Total
> Requests
> 12961349728888426744 -5431088398748527616.00 -261209254515291648.00 Total
> pipe
> 12961349728888425316 -5431088398748528640.00 -261209254515291744.00 Total
> pass
> 12961350703846000415 -5431087433443130368.00 -261209208088740544.00 Total
> fetch
> 12961349728888564487 -5431088398748525568.00 -261209254515285088.00 Total
> header bytes
>
>     10715740    831115.60    510273.33 Total body bytes
>           37         1.98         1.76 Session Closed
>            0         0.00         0.00 Session Pipeline
>            0         0.00         0.00 Session Read Ahead
>          501         5.94        23.86 Session herd
>        23144       475.25      1102.10 SHM records
>         1125        31.68        53.57 SHM writes
>            0         0.00         0.00 SHM MTX contention
>
> That looks like an integer overflow, while running the numbers seem to
> reset after a while, and the time-counter a the top is also reset.
>
> Runing CentOS release 4.4 on Xen 3.0

New description:

 We have a varnish (svn as of 2006-11-01). Varnishstat sometimes displays
 the following.
 {{{
 00:00:21
 Hitrate ratio:       10      100      172
 Hitrate avg:     0.6604   0.7549   0.7820

          172         1.98         8.19 Client connections accepted
          548         2.97        26.10 Client requests received
          369         0.99        17.57 Cache hits
           10         0.99         0.48 Cache hits for pass
          168         0.99         8.00 Cache misses
          179         1.98         8.52 Backend connections initiated
          166         5.94         7.90 Backend connections recycles
            0         0.00         0.00 Backend connections unused
           56         0.00         2.67 N struct srcaddr
           17        -4.95         0.81 N active struct srcaddr
           39         0.00         1.86 N struct sess_mem
           26        -5.94         1.24 N struct sess
          175         1.98         8.33 N struct object
          175         1.98         8.33 N struct objecthead
          165         2.97         7.86 N struct smf
            2         0.00         0.10 N small free smf
            2         0.00         0.10 N large free smf
           13         0.00         0.62 N struct vbe_conn
           16         0.00         0.76 N worker threads
           16         0.00         0.76 N worker threads created
            0         0.00         0.00 N worker threads not created
            0         0.00         0.00 N worker threads limited
            0         0.00         0.00 N queued work requests
           16         0.00         0.76 N overflowed work requests
            0         0.00         0.00 N dropped work requests
            0         0.00         0.00 N expired objects
            0         0.00         0.00 N objects on deathrow
            0         0.00         0.00 HTTP header overflows
          152         1.98         7.24 Objects sent with sendfile
          200         1.98         9.52 Objects sent with write
 12961350068190840473 -5431088062805240832.00 -261209238358033856.00 Total
 Sessions
 12961349728888425753 -5431088398748528640.00 -261209254515291712.00 Total
 Requests
 12961349728888426744 -5431088398748527616.00 -261209254515291648.00 Total
 pipe
 12961349728888425316 -5431088398748528640.00 -261209254515291744.00 Total
 pass
 12961350703846000415 -5431087433443130368.00 -261209208088740544.00 Total
 fetch
 12961349728888564487 -5431088398748525568.00 -261209254515285088.00 Total
 header bytes

     10715740    831115.60    510273.33 Total body bytes
           37         1.98         1.76 Session Closed
            0         0.00         0.00 Session Pipeline
            0         0.00         0.00 Session Read Ahead
          501         5.94        23.86 Session herd
        23144       475.25      1102.10 SHM records
         1125        31.68        53.57 SHM writes
            0         0.00         0.00 SHM MTX contention
 }}}

 That looks like an integer overflow, while running the numbers seem to
 reset after a while, and the time-counter a the top is also reset.

 Runing CentOS release 4.4 on Xen 3.0

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/64#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:32:39 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:32:39 -0000
Subject: [Varnish] #64: Overflow in varnishstat
In-Reply-To: <058.6d128666aadcee84f53059da3db9a891@projects.linpro.no>
References: <058.6d128666aadcee84f53059da3db9a891@projects.linpro.no>
Message-ID: <067.6fad83264ea1a70558158f944aefa19c@projects.linpro.no>

#64: Overflow in varnishstat
--------------------------+-------------------------------------------------
 Reporter:  ay at linpro.no  |        Owner:  phk   
     Type:  task          |       Status:  closed
 Priority:  normal        |    Milestone:        
Component:  varnishstat   |      Version:  trunk 
 Severity:  normal        |   Resolution:  fixed 
 Keywords:  overflow      |  
--------------------------+-------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Situation should be much better (but not perfect) now.

 Close this ticket.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/64#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:33:29 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:33:29 -0000
Subject: [Varnish] #6: Performance statistics
In-Reply-To: <049.5b74a04c5e4ab7eeebdfeb5f1d5af1b5@projects.linpro.no>
References: <049.5b74a04c5e4ab7eeebdfeb5f1d5af1b5@projects.linpro.no>
Message-ID: <058.1acdaba8c1b252eceb2a94aeb6dc735b@projects.linpro.no>

#6: Performance statistics
----------------------+-----------------------------------------------------
 Reporter:  des       |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This ticket is too vague to be of any use anymore.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/6#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:34:25 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:34:25 -0000
Subject: [Varnish] #144: Race in backend socket address replacement.
In-Reply-To: <052.869b9c75015371cffe23335fba6d1ce5@projects.linpro.no>
References: <052.869b9c75015371cffe23335fba6d1ce5@projects.linpro.no>
Message-ID: <061.2541fa3101fd3f597361fe5c7b8be63d@projects.linpro.no>

#144: Race in backend socket address replacement.
---------------------------------------+------------------------------------
 Reporter:  anders                     |        Owner:  phk        
     Type:  defect                     |       Status:  closed     
 Priority:  high                       |    Milestone:  Varnish 1.2
Component:  varnishd                   |      Version:  1.1        
 Severity:  major                      |   Resolution:  fixed      
 Keywords:  varnishd core dump sig 10  |  
---------------------------------------+------------------------------------
Changes (by phk):

  * status:  reopened => closed
  * resolution:  => fixed

Comment:

 This problem is fixed in trunk.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/144#comment:9>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:35:37 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:35:37 -0000
Subject: [Varnish] #190: VCL Sample
In-Reply-To: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no>
References: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no>
Message-ID: <066.a4ffc47709c975229c667ee60d2b082e@projects.linpro.no>

#190: VCL Sample
---------------------------+------------------------------------------------
 Reporter:  michael.lee    |        Owner:  des  
     Type:  documentation  |       Status:  new  
 Priority:  normal         |    Milestone:       
Component:  documentation  |      Version:  1.1.1
 Severity:  normal         |   Resolution:       
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * component:  build => documentation

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/190#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:37:50 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:37:50 -0000
Subject: [Varnish] #177: Backend tag in varnishtop
In-Reply-To: <049.ec63185a5f12c2ffffb82dc4504f8a3b@projects.linpro.no>
References: <049.ec63185a5f12c2ffffb82dc4504f8a3b@projects.linpro.no>
Message-ID: <058.665f0a150d9472e3ae84b1335e145bca@projects.linpro.no>

#177: Backend tag in varnishtop
------------------------+---------------------------------------------------
 Reporter:  akv         |        Owner:  phk   
     Type:  defect      |       Status:  closed
 Priority:  normal      |    Milestone:        
Component:  varnishtop  |      Version:  trunk 
 Severity:  normal      |   Resolution:  fixed 
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 For a very long time now, varnishtop and other tools have sported the
 "-b"(ackend) and "-c"(lient) options to handle this precise selection.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/177#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:39:47 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:39:47 -0000
Subject: [Varnish] #209: Blocking IP addresses
In-Reply-To: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
References: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
Message-ID: <062.997aaf2cc159eda52f35c8a9636237b5@projects.linpro.no>

#209: Blocking IP addresses
------------------------------+---------------------------------------------
 Reporter:  PK07030           |        Owner:  phk        
     Type:  task              |       Status:  closed     
 Priority:  normal            |    Milestone:  Varnish 1.2
Component:  varnishd          |      Version:  trunk      
 Severity:  normal            |   Resolution:  worksforme 
 Keywords:  Block IP address  |  
------------------------------+---------------------------------------------
Changes (by phk):

  * status:  reopened => closed
  * resolution:  => worksforme

Comment:

 Timing this ticket out for lack of response.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/209#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:46:03 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:46:03 -0000
Subject: [Varnish] #2: Error handling on backend connections
In-Reply-To: <049.712cb6908cc69138f4b965b8353a7113@projects.linpro.no>
References: <049.712cb6908cc69138f4b965b8353a7113@projects.linpro.no>
Message-ID: <058.bb0f21845e9182e9c8548674059a9cd1@projects.linpro.no>

#2: Error handling on backend connections
----------------------+-----------------------------------------------------
 Reporter:  des       |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Overtaken by events.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/2#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:46:17 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:46:17 -0000
Subject: [Varnish] #3: Move more policy to VCL
In-Reply-To: <049.6d92cb24a4bd2ccbec40a45ff85d1ec7@projects.linpro.no>
References: <049.6d92cb24a4bd2ccbec40a45ff85d1ec7@projects.linpro.no>
Message-ID: <058.79ce61dec5cf9469e160a4780583838a@projects.linpro.no>

#3: Move more policy to VCL
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk   
     Type:  enhancement  |       Status:  closed
 Priority:  low          |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Overtaken by events.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/3#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:47:01 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:47:01 -0000
Subject: [Varnish] #8: VCL completeness
In-Reply-To: <049.8948111148324535217a4c9812a5f0d0@projects.linpro.no>
References: <049.8948111148324535217a4c9812a5f0d0@projects.linpro.no>
Message-ID: <058.98dfff87764bcd26cc4362d547feb513@projects.linpro.no>

#8: VCL completeness
----------------------+-----------------------------------------------------
 Reporter:  des       |        Owner:  phk  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by phk):

 Overtaken by events.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/8#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:47:46 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:47:46 -0000
Subject: [Varnish] #29: VCL unload/discard leaks
In-Reply-To: <049.a87c2081704d3c7c50b84bc2034e194e@projects.linpro.no>
References: <049.a87c2081704d3c7c50b84bc2034e194e@projects.linpro.no>
Message-ID: <058.c4c9128f77479e162292076933dceec6@projects.linpro.no>

#29: VCL unload/discard leaks
----------------------+-----------------------------------------------------
 Reporter:  phk       |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  low       |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Close this for lack of reply.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/29#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:49:22 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:49:22 -0000
Subject: [Varnish] #178: Can't start varnish: cannot open shared object
	file: Permission denied
In-Reply-To: <056.2679c7d012dd994af1bbcfa9eb3525e4@projects.linpro.no>
References: <056.2679c7d012dd994af1bbcfa9eb3525e4@projects.linpro.no>
Message-ID: <065.241b545cdc335adf1639d99f01cc2d40@projects.linpro.no>

#178: Can't start varnish: cannot open shared object file: Permission denied
------------------------+---------------------------------------------------
 Reporter:  domgoergen  |        Owner:  des   
     Type:  defect      |       Status:  closed
 Priority:  normal      |    Milestone:        
Component:  build       |      Version:  1.1.1 
 Severity:  normal      |   Resolution:  fixed 
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Overtaken by events.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/178#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:50:26 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:50:26 -0000
Subject: [Varnish] #199: varnish bug?!
In-Reply-To: <051.07fad13d1ba0a317a4d53ab9fa5d543a@projects.linpro.no>
References: <051.07fad13d1ba0a317a4d53ab9fa5d543a@projects.linpro.no>
Message-ID: <060.4f58c5ef56083cd26402391cf8523d41@projects.linpro.no>

#199: varnish bug?!
----------------------+-----------------------------------------------------
 Reporter:  trall     |        Owner:  phk     
     Type:  defect    |       Status:  assigned
 Priority:  normal    |    Milestone:          
Component:  varnishd  |      Version:  1.1.2   
 Severity:  major     |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Old description:

> Hello
>
> varnishd seems to crash with the following message on debian etch,
> varnishd version 1.1.2 (backported from unstable)
>
> "
> Using old SHMFILE
> rolling(1)...
> rolling(2)...
> start child pid 17496
> Child said (2, 17496): <<Child starts
> managed to mmap 1073741824 bytes of 1073741824
> Ready
> CLI ready
> >>
> Assert error in ev_schedule_one(), mgt_event.c line 433:
>   Condition(evb->lpfd < evb->npfd) not true.
>   errno = 9 (Bad file descriptor)
> "
>
> this happens every time i start varnishd.

New description:

 Hello

 varnishd seems to crash with the following message on debian etch,
 varnishd version 1.1.2 (backported from unstable)
 {{{
 "
 Using old SHMFILE
 rolling(1)...
 rolling(2)...
 start child pid 17496
 Child said (2, 17496): <<Child starts
 managed to mmap 1073741824 bytes of 1073741824
 Ready
 CLI ready
 >>
 Assert error in ev_schedule_one(), mgt_event.c line 433:
   Condition(evb->lpfd < evb->npfd) not true.
   errno = 9 (Bad file descriptor)
 "

 this happens every time i start varnishd.
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/199#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:51:16 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:51:16 -0000
Subject: [Varnish] #199: varnish bug?!
In-Reply-To: <051.07fad13d1ba0a317a4d53ab9fa5d543a@projects.linpro.no>
References: <051.07fad13d1ba0a317a4d53ab9fa5d543a@projects.linpro.no>
Message-ID: <060.722301c4051553978102ca0280b29a40@projects.linpro.no>

#199: varnish bug?!
----------------------+-----------------------------------------------------
 Reporter:  trall     |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  1.1.2 
 Severity:  major     |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 Closed for lack of response.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/199#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 20:58:59 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 20:58:59 -0000
Subject: [Varnish] #205: Better Vary handling
In-Reply-To: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
References: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
Message-ID: <058.b1ed3f4f0caecfdad89f0b33065c8644@projects.linpro.no>

#205: Better Vary handling
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des   
     Type:  enhancement    |       Status:  closed
 Priority:  normal         |    Milestone:        
Component:  documentation  |      Version:  trunk 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 moved to FAQ.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/205#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 21:00:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 21:00:31 -0000
Subject: [Varnish] #152: Varnish 1.1.1 compile fails on Solaris 10
In-Reply-To: <053.a7b950c8b9db8b2dd5be8558033bb4aa@projects.linpro.no>
References: <053.a7b950c8b9db8b2dd5be8558033bb4aa@projects.linpro.no>
Message-ID: <062.7ff02690f378901558ffb4546197f3c4@projects.linpro.no>

#152: Varnish 1.1.1 compile fails on Solaris 10
---------------------+------------------------------------------------------
 Reporter:  jimlane  |        Owner:  des                
     Type:  defect   |       Status:  closed             
 Priority:  normal   |    Milestone:  Varnish 2.0 release
Component:  build    |      Version:  trunk              
 Severity:  normal   |   Resolution:  fixed              
 Keywords:           |  
---------------------+------------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 Close this ticket.

 Please open a new ticket with any further Solaris compat issues that may
 be found.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/152#comment:6>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 21:03:20 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 21:03:20 -0000
Subject: [Varnish] #117: Mac OS X: Running varnishd results in Assert
	error in mgt_CallCc(), mgt_vcc.c line 222
In-Reply-To: <048.aa559d5bd4edda6a4d13bc3d880bcb57@projects.linpro.no>
References: <048.aa559d5bd4edda6a4d13bc3d880bcb57@projects.linpro.no>
Message-ID: <057.755b2610b5a3745402e456053649fea8@projects.linpro.no>

#117: Mac OS X: Running varnishd results in Assert error in mgt_CallCc(),
mgt_vcc.c line 222
----------------------+-----------------------------------------------------
 Reporter:  oh        |        Owner:  des        
     Type:  defect    |       Status:  closed     
 Priority:  normal    |    Milestone:  Varnish 1.2
Component:  varnishd  |      Version:  1.0.4      
 Severity:  normal    |   Resolution:  fixed      
 Keywords:  mac os x  |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 It sounds like Mac OS/X does pretty strong memory management and the
 regexp code were leaking
 memory.

 In -trunk/2.x we have a proper "fini" code in our compiled VCL, so this
 should now work.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/117#comment:6>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Jun 20 21:04:17 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 20 Jun 2008 21:04:17 -0000
Subject: [Varnish] #118: mac os x: Running varnishd results in dyld:
	lazy symbol binding failed: Symbol not found: _strndup
In-Reply-To: <048.530f5b1a0bfe608510abfaf2329f9707@projects.linpro.no>
References: <048.530f5b1a0bfe608510abfaf2329f9707@projects.linpro.no>
Message-ID: <057.e706de417fd945dc9a63e14cbf754e77@projects.linpro.no>

#118: mac os x: Running varnishd results in dyld: lazy symbol binding failed:
Symbol not found: _strndup
--------------------+-------------------------------------------------------
 Reporter:  oh      |        Owner:  des       
     Type:  defect  |       Status:  closed    
 Priority:  normal  |    Milestone:            
Component:  build   |      Version:  trunk     
 Severity:  normal  |   Resolution:  worksforme
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => worksforme

Comment:

 This does not seem to be a varnish problem.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/118#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 08:41:59 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 08:41:59 -0000
Subject: [Varnish] #200: Varnish crashes in VBE_new_bereq (cache_backend.c)
In-Reply-To: <052.3d765983fa02fb4a4264f0672bbfa668@projects.linpro.no>
References: <052.3d765983fa02fb4a4264f0672bbfa668@projects.linpro.no>
Message-ID: <061.0330dbb5fa039ec8037111702bfeb19d@projects.linpro.no>

#200: Varnish crashes in VBE_new_bereq (cache_backend.c)
----------------------------------------------+-----------------------------
 Reporter:  anders                            |        Owner:  des   
     Type:  defect                            |       Status:  closed
 Priority:  normal                            |    Milestone:        
Component:  varnishd                          |      Version:  trunk 
 Severity:  normal                            |   Resolution:  fixed 
 Keywords:  varnishd core dump VBE_new_bereq  |  
----------------------------------------------+-----------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 I think this was the backend code race condition that is now fixed.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/200#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 08:47:06 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 08:47:06 -0000
Subject: [Varnish] #164: Varnishd core dumps because of segmentation
	violation
In-Reply-To: <052.056d420b6ae1f4a78c1b835427e4222f@projects.linpro.no>
References: <052.056d420b6ae1f4a78c1b835427e4222f@projects.linpro.no>
Message-ID: <061.9d050335470e23e1e4bb13df15d15b76@projects.linpro.no>

#164: Varnishd core dumps because of segmentation violation
--------------------------------+-------------------------------------------
 Reporter:  anders              |        Owner:  des        
     Type:  defect              |       Status:  closed     
 Priority:  high                |    Milestone:  Varnish 1.2
Component:  varnishd            |      Version:  trunk      
 Severity:  major               |   Resolution:  fixed      
 Keywords:  varnishd core dump  |  
--------------------------------+-------------------------------------------
Changes (by phk):

  * status:  reopened => closed
  * resolution:  => fixed

Comment:

 Time this one out, we have not seen this exact symptom for many months.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/164#comment:13>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 08:50:21 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 08:50:21 -0000
Subject: [Varnish] #170: Segmentation violation in HTC_Read at
	cache_httpconn.c:195
In-Reply-To: <052.544b68a3ff13ba083233aa7d256ffb88@projects.linpro.no>
References: <052.544b68a3ff13ba083233aa7d256ffb88@projects.linpro.no>
Message-ID: <061.31084e8050cda3ee8bb8f5a68b71c808@projects.linpro.no>

#170: Segmentation violation in HTC_Read at cache_httpconn.c:195
--------------------------------+-------------------------------------------
 Reporter:  anders              |        Owner:  phk   
     Type:  defect              |       Status:  closed
 Priority:  normal              |    Milestone:        
Component:  varnishd            |      Version:  trunk 
 Severity:  normal              |   Resolution:  fixed 
 Keywords:  varnishd core dump  |  
--------------------------------+-------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This one looks like fallout from the kqueue race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/170#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 08:51:51 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 08:51:51 -0000
Subject: [Varnish] #172: Varnish 1.1.1 segmentation violation
In-Reply-To: <052.fca1df448d9e42965b0e9fa8aeed6ee8@projects.linpro.no>
References: <052.fca1df448d9e42965b0e9fa8aeed6ee8@projects.linpro.no>
Message-ID: <061.044a2f57b66b03944cb94155d25a7426@projects.linpro.no>

#172: Varnish 1.1.1 segmentation violation
--------------------------------+-------------------------------------------
 Reporter:  anders              |        Owner:  phk   
     Type:  defect              |       Status:  closed
 Priority:  normal              |    Milestone:        
Component:  varnishd            |      Version:  1.1.1 
 Severity:  normal              |   Resolution:  fixed 
 Keywords:  varnishd core dump  |  
--------------------------------+-------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Looks like the backend address replacement race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/172#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 08:52:37 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 08:52:37 -0000
Subject: [Varnish] #175: Varnish 1.1.1 segmentation violation
In-Reply-To: <052.420bc273251aa4e9219a9aa80657b057@projects.linpro.no>
References: <052.420bc273251aa4e9219a9aa80657b057@projects.linpro.no>
Message-ID: <061.db7d0ea043597515a2fb4559855d87db@projects.linpro.no>

#175: Varnish 1.1.1 segmentation violation
----------------------+-----------------------------------------------------
 Reporter:  anders    |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  1.1.1 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This looks like the kqueue race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/175#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:30:55 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:30:55 -0000
Subject: [Varnish] #159: Assert error in exp_hangman()
In-Reply-To: <059.59a3857cd95372f151a9f630395e1734@projects.linpro.no>
References: <059.59a3857cd95372f151a9f630395e1734@projects.linpro.no>
Message-ID: <068.359052368f74d98b3739a2c080a6e351@projects.linpro.no>

#159: Assert error in exp_hangman()
---------------------------+------------------------------------------------
 Reporter:  janis.putrams  |        Owner:  phk   
     Type:  defect         |       Status:  closed
 Priority:  normal         |    Milestone:        
Component:  varnishd       |      Version:  trunk 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This one has not been seen in recent times.  Assume fixed.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/159#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:31:56 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:31:56 -0000
Subject: [Varnish] #156: Varnish 1.1 branch dies with assert error in
	WS_ReleaseP
In-Reply-To: <052.9636620d22b6f890a89073c2cf8ba817@projects.linpro.no>
References: <052.9636620d22b6f890a89073c2cf8ba817@projects.linpro.no>
Message-ID: <061.9f308405a945b7cde5146c452a959674@projects.linpro.no>

#156: Varnish 1.1 branch dies with assert error in WS_ReleaseP
-----------------------------------+----------------------------------------
 Reporter:  anders                 |        Owner:  phk   
     Type:  defect                 |       Status:  closed
 Priority:  high                   |    Milestone:        
Component:  varnishd               |      Version:  1.1   
 Severity:  major                  |   Resolution:  fixed 
 Keywords:  core dump WS_ReleaseP  |  
-----------------------------------+----------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Not seen in recent times, assume fixed.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/156#comment:6>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:32:50 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:32:50 -0000
Subject: [Varnish] #169: Varnishd crashes with assert error in bes_ClosedFd
In-Reply-To: <052.42606c7ce4f70ce00764b8871fcb46b7@projects.linpro.no>
References: <052.42606c7ce4f70ce00764b8871fcb46b7@projects.linpro.no>
Message-ID: <061.97eaceb0918fda7b8e4c44e166deb4b5@projects.linpro.no>

#169: Varnishd crashes with assert error in bes_ClosedFd
----------------------+-----------------------------------------------------
 Reporter:  anders    |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This was caused by the backend address replacement race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/169#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:34:16 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:34:16 -0000
Subject: [Varnish] #142: Varnishd core dumps because of segmentation
	violation
In-Reply-To: <052.f72cc7589f3a3102380b0e8593362636@projects.linpro.no>
References: <052.f72cc7589f3a3102380b0e8593362636@projects.linpro.no>
Message-ID: <061.1c28bfa200d2c56aadd17dfa9f10bf25@projects.linpro.no>

#142: Varnishd core dumps because of segmentation violation
---------------------------------------+------------------------------------
 Reporter:  anders                     |        Owner:  phk   
     Type:  defect                     |       Status:  closed
 Priority:  high                       |    Milestone:        
Component:  varnishd                   |      Version:  1.1   
 Severity:  major                      |   Resolution:  fixed 
 Keywords:  varnishd core dump sig 11  |  
---------------------------------------+------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Looks like the kqueue session race was the cause of this.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/142#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:35:01 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:35:01 -0000
Subject: [Varnish] #194: Varnish crashes with assert error in HTC_Rx
	(cache_httpconn.c)
In-Reply-To: <052.ccc503c1ee28328bd887f0182ca58a42@projects.linpro.no>
References: <052.ccc503c1ee28328bd887f0182ca58a42@projects.linpro.no>
Message-ID: <061.fb1e61c112374b6ea4e78b0a496a9254@projects.linpro.no>

#194: Varnish crashes with assert error in HTC_Rx (cache_httpconn.c)
--------------------------------------------------------+-------------------
 Reporter:  anders                                      |        Owner:  phk   
     Type:  defect                                      |       Status:  closed
 Priority:  normal                                      |    Milestone:        
Component:  varnishd                                    |      Version:  1.2   
 Severity:  normal                                      |   Resolution:  fixed 
 Keywords:  varnishd core dump HTC_Rx cache_httpconn.c  |  
--------------------------------------------------------+-------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 kqueue acceptor race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/194#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:36:07 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:36:07 -0000
Subject: [Varnish] #174: Varnish dies on assert error in http_FilterFields
In-Reply-To: <052.230e482125e0eea67042054f08170efd@projects.linpro.no>
References: <052.230e482125e0eea67042054f08170efd@projects.linpro.no>
Message-ID: <061.476ae7c8ea4ed1652962e51694e3ecf5@projects.linpro.no>

#174: Varnish dies on assert error in http_FilterFields
--------------------------------------------------+-------------------------
 Reporter:  anders                                |        Owner:  phk   
     Type:  defect                                |       Status:  closed
 Priority:  high                                  |    Milestone:        
Component:  varnishd                              |      Version:  trunk 
 Severity:  major                                 |   Resolution:  fixed 
 Keywords:  varnishd core dump http_FilterFields  |  
--------------------------------------------------+-------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Another case of kqueue session race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/174#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:36:50 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:36:50 -0000
Subject: [Varnish] #180: Varnish core dump on Assert error in wrk_thread, 
	kern.ipc.maxpipekva problem?
In-Reply-To: <052.06c444aafd17907df1b1a198673d0246@projects.linpro.no>
References: <052.06c444aafd17907df1b1a198673d0246@projects.linpro.no>
Message-ID: <061.f1c6abc29e943fb54d9e1dde5a4a0c0a@projects.linpro.no>

#180: Varnish core dump on Assert error in wrk_thread, kern.ipc.maxpipekva
problem?
---------------------------------------------------------------+------------
 Reporter:  anders                                             |        Owner:  phk   
     Type:  defect                                             |       Status:  closed
 Priority:  normal                                             |    Milestone:        
Component:  varnishd                                           |      Version:  1.2   
 Severity:  normal                                             |   Resolution:  fixed 
 Keywords:  varnishd core dump wrk_thread kern.ipc.maxpipekva  |  
---------------------------------------------------------------+------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 We don't use pipes for worker pool synchronization any more.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/180#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:37:39 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:37:39 -0000
Subject: [Varnish] #195: Varnish crashes in RES_BuildHttp
	(cache_response.c)
In-Reply-To: <052.570abebb906f380f6b27b77133169c10@projects.linpro.no>
References: <052.570abebb906f380f6b27b77133169c10@projects.linpro.no>
Message-ID: <061.ef9ba0dbcaf4e35f5125f2d71c0cdcb7@projects.linpro.no>

#195: Varnish crashes in RES_BuildHttp (cache_response.c)
---------------------------------------------------------------+------------
 Reporter:  anders                                             |        Owner:  des   
     Type:  defect                                             |       Status:  closed
 Priority:  normal                                             |    Milestone:        
Component:  varnishd                                           |      Version:  1.2   
 Severity:  normal                                             |   Resolution:  fixed 
 Keywords:  varnishd core dump RES_BuildHttp cache_response.c  |  
---------------------------------------------------------------+------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Also the kqueue session race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/195#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:38:39 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:38:39 -0000
Subject: [Varnish] #110: varnishd leaking virtual memory
In-Reply-To: <056.670fe3911761765f5d209fdf09ceb74b@projects.linpro.no>
References: <056.670fe3911761765f5d209fdf09ceb74b@projects.linpro.no>
Message-ID: <065.7bb28d1bd3589c4043b21d75fca022e4@projects.linpro.no>

#110: varnishd leaking virtual memory
---------------------------------+------------------------------------------
 Reporter:  chrisrixon           |        Owner:  phk        
     Type:  defect               |       Status:  closed     
 Priority:  normal               |    Milestone:  Varnish 1.2
Component:  varnishd             |      Version:  1.0.4      
 Severity:  major                |   Resolution:  fixed      
 Keywords:  leak virtual memory  |  
---------------------------------+------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 We have plugged all memory leaks I'm aware off.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/110#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:39:27 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:39:27 -0000
Subject: [Varnish] #207: Varnishlog core dumps
In-Reply-To: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no>
References: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no>
Message-ID: <061.e931d615ca7bac2a146271072da8c40a@projects.linpro.no>

#207: Varnishlog core dumps
-----------------------------------+----------------------------------------
 Reporter:  anders                 |        Owner:  phk   
     Type:  defect                 |       Status:  closed
 Priority:  normal                 |    Milestone:        
Component:  varnishlog             |      Version:  trunk 
 Severity:  normal                 |   Resolution:  fixed 
 Keywords:  varnish log core dump  |  
-----------------------------------+----------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I'll blame this one on kqueue/session race.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/207#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:43:17 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:43:17 -0000
Subject: [Varnish] #211: Cache child died status=0x9 after ping timeout
In-Reply-To: <056.72e0a770b957db259bb8010e11a4ad09@projects.linpro.no>
References: <056.72e0a770b957db259bb8010e11a4ad09@projects.linpro.no>
Message-ID: <065.24aceb7a7fe8a763c9cba69c8666743d@projects.linpro.no>

#211: Cache child died status=0x9 after ping timeout
------------------------+---------------------------------------------------
 Reporter:  davecheney  |        Owner:  des   
     Type:  defect      |       Status:  closed
 Priority:  normal      |    Milestone:        
Component:  build       |      Version:  trunk 
 Severity:  normal      |   Resolution:  fixed 
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Old description:

> trunk, r2513.
>
> Child is killed by SIGTERM by the master process after failing ping
> timeout, happens every 8 to 24 hours.
>
> [root at rado varnish-cache]# /opt/varnish-svn/sbin/varnishd -F -a :80 -f
> default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish
> -p client_http11=on -p backend_http11=on -p sess_timeout=30 -s
> file,/var/lib/varnish/varnish_storage.bin,2G -P /var/run/varnish.pid
> storage_file: filename: /var/lib/varnish/varnish_storage.bin size 2048
> MB.
> Using old SHMFILE
> rolling(1)...
> rolling(2)...
> start child pid 1740
> Child said (2, 1740): <<Child starts>>
> Child said (2, 1740): <<managed to mmap 2147483648 bytes of 2147483648>>
> Child said (2, 1740): <<Ready>>
> Child not responding to ping
> Child not responding to ping
> Cache child died pid=1740 status=0x9
> Clean child
> Child cleaned
> start child pid 8242
> Child said (2, 8242): <<Child starts>>
> Child said (2, 8242): <<managed to mmap 2147483648 bytes of 2147483648>>
> Child said (2, 8242): <<Ready>>
>
> backend b1 { .host = "172.16.0.72"; }
> backend b2 { .host = "172.16.0.73"; }
>
> director default random {
>         {
>                 .backend = b1;
>                 .weight = 1;
>         }
>         {
>                 .backend = b2;
>                 .weight = 1;
>         }
> }
>
> sub vcl_recv {
>         set req.backend = b1;
>         set req.backend = b2;
>         set req.backend = default;
>         if (req.request != "GET" && req.request != "HEAD") {
>                 pipe;
>         }
>         if (req.http.Expect) {
>                 pipe;
>         }
>         if (req.http.Authenticate || req.http.Cookie) {
>                 lookup;
>         }
>         lookup;
> }
>
> sub vcl_fetch {
>         if (!obj.valid) {
>                 error;
>         }
>         if (!obj.cacheable) {
>                 pass;
>         }
>         if (obj.http.Set-Cookie) {
>                 insert;
>         }
>         insert;
> }

New description:

 trunk, r2513.

 Child is killed by SIGTERM by the master process after failing ping
 timeout, happens every 8 to 24 hours.
 {{{
 [root at rado varnish-cache]# /opt/varnish-svn/sbin/varnishd -F -a :80 -f
 default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish
 -p client_http11=on -p backend_http11=on -p sess_timeout=30 -s
 file,/var/lib/varnish/varnish_storage.bin,2G -P /var/run/varnish.pid
 storage_file: filename: /var/lib/varnish/varnish_storage.bin size 2048 MB.
 Using old SHMFILE
 rolling(1)...
 rolling(2)...
 start child pid 1740
 Child said (2, 1740): <<Child starts>>
 Child said (2, 1740): <<managed to mmap 2147483648 bytes of 2147483648>>
 Child said (2, 1740): <<Ready>>
 Child not responding to ping
 Child not responding to ping
 Cache child died pid=1740 status=0x9
 Clean child
 Child cleaned
 start child pid 8242
 Child said (2, 8242): <<Child starts>>
 Child said (2, 8242): <<managed to mmap 2147483648 bytes of 2147483648>>
 Child said (2, 8242): <<Ready>>
 }}}
 {{{
 backend b1 { .host = "172.16.0.72"; }
 backend b2 { .host = "172.16.0.73"; }

 director default random {
         {
                 .backend = b1;
                 .weight = 1;
         }
         {
                 .backend = b2;
                 .weight = 1;
         }
 }

 sub vcl_recv {
         set req.backend = b1;
         set req.backend = b2;
         set req.backend = default;
         if (req.request != "GET" && req.request != "HEAD") {
                 pipe;
         }
         if (req.http.Expect) {
                 pipe;
         }
         if (req.http.Authenticate || req.http.Cookie) {
                 lookup;
         }
         lookup;
 }

 sub vcl_fetch {
         if (!obj.valid) {
                 error;
         }
         if (!obj.cacheable) {
                 pass;
         }
         if (obj.http.Set-Cookie) {
                 insert;
         }
         insert;
 }
 }}}

Comment:

 This is correct behaviour.

 The question is why PING does not get a response.

 This ticket does not really help answer that, and a lot of work have been
 done on the usual suspects (thread pool for insance) since then, so I will
 close this ticket, inviting reopen should this issue reapper.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/211#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:44:35 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:44:35 -0000
Subject: [Varnish] #212: varnishd child not responding to ping and
	parent can't restart the child
In-Reply-To: <056.46cf6d90a9bd269550a4c9e066a3f12c@projects.linpro.no>
References: <056.46cf6d90a9bd269550a4c9e066a3f12c@projects.linpro.no>
Message-ID: <065.e2a68dfd3263683576ac08901e0680e1@projects.linpro.no>

#212: varnishd child not responding to ping and parent can't restart the child
------------------------+---------------------------------------------------
 Reporter:  lixiaohong  |        Owner:  phk   
     Type:  defect      |       Status:  closed
 Priority:  normal      |    Milestone:        
Component:  varnishd    |      Version:  1.2   
 Severity:  major       |   Resolution:  fixed 
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 We had a bug in child cleanup that would prevent client restarts, but I
 belive that is fixed.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/212#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:45:27 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:45:27 -0000
Subject: [Varnish] #219: Overflow when calculating remaining disk space
	on big disk (32 bits server)
In-Reply-To: <054.0a73771b24e0a77c48efe47a3dc4b7a1@projects.linpro.no>
References: <054.0a73771b24e0a77c48efe47a3dc4b7a1@projects.linpro.no>
Message-ID: <063.78652dc4bf078079ff8cb37de49fee1f@projects.linpro.no>

#219: Overflow when calculating remaining disk space on big disk (32 bits server)
--------------------------------------------------+-------------------------
 Reporter:  pcarrier                              |        Owner:  phk   
     Type:  defect                                |       Status:  closed
 Priority:  normal                                |    Milestone:        
Component:  varnishd                              |      Version:  trunk 
 Severity:  normal                                |   Resolution:  fixed 
 Keywords:  overflow ondisk disk space remaining  |  
--------------------------------------------------+-------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I belive this is fixed.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/219#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:47:57 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:47:57 -0000
Subject: [Varnish] #23: varnishlog improvement
In-Reply-To: <049.1a70de2c23080a9c0ccaafb07971ca00@projects.linpro.no>
References: <049.1a70de2c23080a9c0ccaafb07971ca00@projects.linpro.no>
Message-ID: <058.16d7c5b5bc3882e88c3ea21369de3324@projects.linpro.no>

#23: varnishlog improvement
-------------------------+--------------------------------------------------
 Reporter:  phk          |        Owner:  phk    
     Type:  enhancement  |       Status:  closed 
 Priority:  normal       |    Milestone:         
Component:  varnishlog   |      Version:  trunk  
 Severity:  normal       |   Resolution:  wontfix
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Moved to post-2.0 wiki.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/23#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:49:11 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:49:11 -0000
Subject: [Varnish] #36: setproctitle() on Linux
In-Reply-To: <049.9fd7ba599d87c5ed69347baecafab737@projects.linpro.no>
References: <049.9fd7ba599d87c5ed69347baecafab737@projects.linpro.no>
Message-ID: <058.71f6695bfbd5da1ea0fd89be99f5fd72@projects.linpro.no>

#36: setproctitle() on Linux
----------------------+-----------------------------------------------------
 Reporter:  des       |        Owner:  des                      
     Type:  defect    |       Status:  closed                   
 Priority:  normal    |    Milestone:  Varnish 2.0 code complete
Component:  varnishd  |      Version:  trunk                    
 Severity:  normal    |   Resolution:  wontfix                  
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Close this item for lack of interest.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/36#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:49:37 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:49:37 -0000
Subject: [Varnish] #20: tar storage
In-Reply-To: <049.b57a98c185f962c5d298f119f40c1751@projects.linpro.no>
References: <049.b57a98c185f962c5d298f119f40c1751@projects.linpro.no>
Message-ID: <058.73852da0e77e7bceb1c25cfc51bd83d0@projects.linpro.no>

#20: tar storage
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk    
     Type:  enhancement  |       Status:  closed 
 Priority:  normal       |    Milestone:         
Component:  varnishd     |      Version:  trunk  
 Severity:  normal       |   Resolution:  wontfix
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Move to post-2.0 wiki

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/20#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 09:56:09 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 09:56:09 -0000
Subject: [Varnish] #188: thread pileup in 1.x
In-Reply-To: <054.501398c9432dffc43debd3778be2327e@projects.linpro.no>
References: <054.501398c9432dffc43debd3778be2327e@projects.linpro.no>
Message-ID: <063.cf41630104f8be90fb587dfc1aafbeff@projects.linpro.no>

#188: thread pileup in 1.x
----------------------+-----------------------------------------------------
 Reporter:  steinove  |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  high      |    Milestone:        
Component:  varnishd  |      Version:  1.1.1 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  assigned => closed
  * resolution:  => fixed
  * summary:  thread pileup => thread pileup in 1.x

Comment:

 The thread-pool has had an overhaul recently, and at least on finn.no this
 has mitigated the problems somewhat, even if it has not completely solved
 the issue.

 I want to close this ticket, since it related to the old thread pool
 sizing code, to avoid mixing old symptoms with new symptoms, if thread
 pileups should still be a significant problem.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/188#comment:10>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 10:12:47 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 10:12:47 -0000
Subject: [Varnish] #254: Condition(oe2->timer_when >= oe->timer_when)
	not true
In-Reply-To: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
References: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
Message-ID: <058.b1e29b09da793ccb42df61c39a5e1389@projects.linpro.no>

#254: Condition(oe2->timer_when >= oe->timer_when) not true
--------------------+-------------------------------------------------------
 Reporter:  sky     |        Owner:  des   
     Type:  defect  |       Status:  closed
 Priority:  normal  |    Milestone:        
Component:  build   |      Version:  trunk 
 Severity:  normal  |   Resolution:  fixed 
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I belive this was caused by the change to assign NAN to grace fields to
 signify "use default", and that it is now fixed.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/254#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 10:15:12 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 10:15:12 -0000
Subject: [Varnish] #247: Varnish sends 304 header for ESI pages although
	some of the included objects might have changed
In-Reply-To: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no>
References: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no>
Message-ID: <060.bb0d0ca8f17ec89ed73142d20ae758ba@projects.linpro.no>

#247: Varnish sends 304 header for ESI pages although some of the included
objects might have changed
----------------------+-----------------------------------------------------
 Reporter:  peter     |        Owner:  phk  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by phk):

 I realize now that I have no idea what the correct expiry/TTL is for an
 ESI page.

 The correct default action is probably to set it to the minimum TTL of all
 the included page elements.

 Input on this question is most welcome.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/247#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 16:18:39 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 16:18:39 -0000
Subject: [Varnish] #250: POST error when using Opera
In-Reply-To: <050.f7179b97ee045b3deb2bdae4b32537be@projects.linpro.no>
References: <050.f7179b97ee045b3deb2bdae4b32537be@projects.linpro.no>
Message-ID: <059.2b8e18e3f59630167af8b0440233929b@projects.linpro.no>

#250: POST error when using Opera
--------------------+-------------------------------------------------------
 Reporter:  duja    |        Owner:  des                
     Type:  defect  |       Status:  new                
 Priority:  normal  |    Milestone:  Varnish 2.0 release
Component:  build   |      Version:  trunk              
 Severity:  normal  |   Resolution:                     
 Keywords:          |  
--------------------+-------------------------------------------------------
Old description:

> Info from mailing list:
>
> What I have is a form login that has 3 input fields, username, password
> and security code (from captcha).
>
> When opera is making the POST it receives a 200 OK and NOT a 302 Moved
> Temp. as expected.
>
> This is the request that Opera is making:
>
>    13 RxRequest    c POST
>    13 RxURL        c /takelogin.php
>    13 RxProtocol   c HTTP/1.1
>    13 RxHeader     c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
>    13 RxHeader     c Host: mydomain.com:8080
>    13 RxHeader     c Accept: text/html, application/xml;q=0.9,
> application/xhtml+xml, image/png, image/jpeg, image/gif,
> image/x-xbitmap, */*;q=0.1
>    13 RxHeader     c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
>    13 RxHeader     c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
>    13 RxHeader     c Accept-Encoding: deflate, gzip, x-gzip, identity,
> *;q=0
>    13 RxHeader     c Referer: http://mydomain.com:8080/login.php
>    13 RxHeader     c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
>    13 RxHeader     c Cookie2: $Version=1
>    13 RxHeader     c Connection: Keep-Alive, TE
>    13 RxHeader     c TE: deflate, gzip, chunked, identity, trailers
>    13 RxHeader     c Content-Length: 63
>    13 RxHeader     c Content-Type: application/x-www-form-urlencoded
>
> My vcl has this code when POST are received:
>
>         if(req.request != "GET" && req.request != "HEAD") {
>                 set req.http.Connection = "close";
>                 pass;
>         }
>
> This code usually works with FF and IE but NOT with Opera.
>
> If I remove "set req.http.Connection = "close";"
>
> the login process works with no problem.
>
> I have had problems with POSTs before, thats why I've been using
> Connection = "close" on POSTs.
>
> Here is the whole error log:
>     0 CLI          - Rd ping
>     0 CLI          - Wr 0 200 PONG 1213029670
>    13 SessionClose - timeout
>    13 StatSess     - 82.182.xx.xx 1306 0 1 2 0 0 2 744 6750
>     0 CLI          - Rd ping
>     0 CLI          - Wr 0 200 PONG 1213029673
>    13 SessionOpen  c 82.182.xx.xx 1307 0.0.0.0:8080
>    13 ReqStart     c 82.182.xx.xx 1307 803913450
>    13 RxRequest    c POST
>    13 RxURL        c /takelogin.php
>    13 RxProtocol   c HTTP/1.1
>    13 RxHeader     c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
>    13 RxHeader     c Host: mydomain.com:8080
>    13 RxHeader     c Accept: text/html, application/xml;q=0.9,
> application/xhtml+xml, image/png, image/jpeg, image/gif,
> image/x-xbitmap, */*;q=0.1
>    13 RxHeader     c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
>    13 RxHeader     c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
>    13 RxHeader     c Accept-Encoding: deflate, gzip, x-gzip, identity,
> *;q=0
>    13 RxHeader     c Referer: http://mydomain.com:8080/login.php
>    13 RxHeader     c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
>    13 RxHeader     c Cookie2: $Version=1
>    13 RxHeader     c Connection: Keep-Alive, TE
>    13 RxHeader     c TE: deflate, gzip, chunked, identity, trailers
>    13 RxHeader     c Content-Length: 63
>    13 RxHeader     c Content-Type: application/x-www-form-urlencoded
>    13 VCL_call     c recv
>    13 VCL_return   c pass
>    13 VCL_call     c pass
>    13 VCL_return   c pass
>    14 TxRequest    - POST
>    14 TxURL        - /takelogin.php
>    14 TxProtocol   - HTTP/1.1
>    14 TxHeader     - User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
>    14 TxHeader     - Host: mydomain.com:8080
>    14 TxHeader     - Accept: text/html, application/xml;q=0.9,
> application/xhtml+xml, image/png, image/jpeg, image/gif,
> image/x-xbitmap, */*;q=0.1
>    14 TxHeader     - Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
>    14 TxHeader     - Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
>    14 TxHeader     - Accept-Encoding: deflate, gzip, x-gzip, identity,
> *;q=0
>    14 TxHeader     - Referer: http://mydomain.com:8080/login.php
>    14 TxHeader     - Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
>    14 TxHeader     - Cookie2: $Version=1
>    14 TxHeader     - Content-Type: application/x-www-form-urlencoded
>    14 TxHeader     - X-Varnish: 803913450
>    14 TxHeader     - X-Forwarded-For: 82.182.xx.xx
>    14 RxProtocol   - HTTP/1.1
>    14 RxStatus     - 200
>    14 RxResponse   - OK
>    14 RxHeader     - Date: Mon, 09 Jun 2008 16:41:14 GMT
>    14 RxHeader     - Server: Apache
>    14 RxHeader     - X-Powered-By: PHP/5.2.0-8+etch10
>    14 RxHeader     - Content-Length: 23
>    14 RxHeader     - Content-Type: text/html; charset=UTF-8
>    13 ObjProtocol  c HTTP/1.1
>    13 ObjStatus    c 200
>    13 ObjResponse  c OK
>    13 ObjHeader    c Date: Mon, 09 Jun 2008 16:41:14 GMT
>    13 ObjHeader    c Server: Apache
>    13 ObjHeader    c X-Powered-By: PHP/5.2.0-8+etch10
>    13 ObjHeader    c Content-Type: text/html; charset=UTF-8
>    14 BackendReuse - mydomain
>    13 TTL          c 803913450 RFC 120 1213029674 1213029674 0 0 0
>    13 VCL_call     c fetch
>    13 VCL_return   c pass
>    13 Length       c 23
>    13 VCL_call     c deliver
>    13 VCL_return   c deliver
>    13 TxProtocol   c HTTP/1.1
>    13 TxStatus     c 200
>    13 TxResponse   c OK
>    13 TxHeader     c Server: Apache
>    13 TxHeader     c X-Powered-By: PHP/5.2.0-8+etch10
>    13 TxHeader     c Content-Type: text/html; charset=UTF-8
>    13 TxHeader     c Content-Length: 23
>    13 TxHeader     c Date: Mon, 09 Jun 2008 16:41:14 GMT
>    13 TxHeader     c X-Varnish: 803913450
>    13 TxHeader     c Age: 0
>    13 TxHeader     c Via: 1.1 varnish
>    13 TxHeader     c Connection: keep-alive
>    13 ReqEnd       c 803913450 1213029674.708000898 1213029674.780754805
> 0.003840923 0.072657347 0.000096560
>     0 StatAddr     - 82.182.xx.xx 0 76 14 47 0 0 30 12274 157175
>

> # varnishd -V
> varnishd (varnish-trunk)
> Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS
>

> What I should mention is that the problem can be solved by another
> method.
>
> If I remove the Cookie2 AND TE header it all works out fine:
>
>        remove req.http.Cookie2;
>        remove req.http.TE;
>
>         if(req.request != "GET" && req.request != "HEAD") {
>                 set req.http.Connection = "close";
>                 pass;
>         }
>
> This works!
>
> But I must remove BOTH Cookie2 and TE header, else it wont work.
>
> * I will add more info from varnishlog as soon as Im home

New description:

 Info from mailing list:

 What I have is a form login that has 3 input fields, username, password
 and security code (from captcha).

 When opera is making the POST it receives a 200 OK and NOT a 302 Moved
 Temp. as expected.

 This is the request that Opera is making:
 {{{
    13 RxRequest    c POST
    13 RxURL        c /takelogin.php
    13 RxProtocol   c HTTP/1.1
    13 RxHeader     c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
    13 RxHeader     c Host: mydomain.com:8080
    13 RxHeader     c Accept: text/html, application/xml;q=0.9,
 application/xhtml+xml, image/png, image/jpeg, image/gif,
 image/x-xbitmap, */*;q=0.1
    13 RxHeader     c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
    13 RxHeader     c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
    13 RxHeader     c Accept-Encoding: deflate, gzip, x-gzip, identity,
 *;q=0
    13 RxHeader     c Referer: http://mydomain.com:8080/login.php
    13 RxHeader     c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
    13 RxHeader     c Cookie2: $Version=1
    13 RxHeader     c Connection: Keep-Alive, TE
    13 RxHeader     c TE: deflate, gzip, chunked, identity, trailers
    13 RxHeader     c Content-Length: 63
    13 RxHeader     c Content-Type: application/x-www-form-urlencoded
 }}}
 My vcl has this code when POST are received:
 {{{
         if(req.request != "GET" && req.request != "HEAD") {
                 set req.http.Connection = "close";
                 pass;
         }
 }}}
 This code usually works with FF and IE but NOT with Opera.

 If I remove "set req.http.Connection = "close";"

 the login process works with no problem.

 I have had problems with POSTs before, thats why I've been using
 Connection = "close" on POSTs.

 Here is the whole error log:
 {{{
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1213029670
    13 SessionClose - timeout
    13 StatSess     - 82.182.xx.xx 1306 0 1 2 0 0 2 744 6750
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1213029673
    13 SessionOpen  c 82.182.xx.xx 1307 0.0.0.0:8080
    13 ReqStart     c 82.182.xx.xx 1307 803913450
    13 RxRequest    c POST
    13 RxURL        c /takelogin.php
    13 RxProtocol   c HTTP/1.1
    13 RxHeader     c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
    13 RxHeader     c Host: mydomain.com:8080
    13 RxHeader     c Accept: text/html, application/xml;q=0.9,
 application/xhtml+xml, image/png, image/jpeg, image/gif,
 image/x-xbitmap, */*;q=0.1
    13 RxHeader     c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
    13 RxHeader     c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
    13 RxHeader     c Accept-Encoding: deflate, gzip, x-gzip, identity,
 *;q=0
    13 RxHeader     c Referer: http://mydomain.com:8080/login.php
    13 RxHeader     c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
    13 RxHeader     c Cookie2: $Version=1
    13 RxHeader     c Connection: Keep-Alive, TE
    13 RxHeader     c TE: deflate, gzip, chunked, identity, trailers
    13 RxHeader     c Content-Length: 63
    13 RxHeader     c Content-Type: application/x-www-form-urlencoded
    13 VCL_call     c recv
    13 VCL_return   c pass
    13 VCL_call     c pass
    13 VCL_return   c pass
    14 TxRequest    - POST
    14 TxURL        - /takelogin.php
    14 TxProtocol   - HTTP/1.1
    14 TxHeader     - User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
    14 TxHeader     - Host: mydomain.com:8080
    14 TxHeader     - Accept: text/html, application/xml;q=0.9,
 application/xhtml+xml, image/png, image/jpeg, image/gif,
 image/x-xbitmap, */*;q=0.1
    14 TxHeader     - Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
    14 TxHeader     - Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
    14 TxHeader     - Accept-Encoding: deflate, gzip, x-gzip, identity,
 *;q=0
    14 TxHeader     - Referer: http://mydomain.com:8080/login.php
    14 TxHeader     - Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
    14 TxHeader     - Cookie2: $Version=1
    14 TxHeader     - Content-Type: application/x-www-form-urlencoded
    14 TxHeader     - X-Varnish: 803913450
    14 TxHeader     - X-Forwarded-For: 82.182.xx.xx
    14 RxProtocol   - HTTP/1.1
    14 RxStatus     - 200
    14 RxResponse   - OK
    14 RxHeader     - Date: Mon, 09 Jun 2008 16:41:14 GMT
    14 RxHeader     - Server: Apache
    14 RxHeader     - X-Powered-By: PHP/5.2.0-8+etch10
    14 RxHeader     - Content-Length: 23
    14 RxHeader     - Content-Type: text/html; charset=UTF-8
    13 ObjProtocol  c HTTP/1.1
    13 ObjStatus    c 200
    13 ObjResponse  c OK
    13 ObjHeader    c Date: Mon, 09 Jun 2008 16:41:14 GMT
    13 ObjHeader    c Server: Apache
    13 ObjHeader    c X-Powered-By: PHP/5.2.0-8+etch10
    13 ObjHeader    c Content-Type: text/html; charset=UTF-8
    14 BackendReuse - mydomain
    13 TTL          c 803913450 RFC 120 1213029674 1213029674 0 0 0
    13 VCL_call     c fetch
    13 VCL_return   c pass
    13 Length       c 23
    13 VCL_call     c deliver
    13 VCL_return   c deliver
    13 TxProtocol   c HTTP/1.1
    13 TxStatus     c 200
    13 TxResponse   c OK
    13 TxHeader     c Server: Apache
    13 TxHeader     c X-Powered-By: PHP/5.2.0-8+etch10
    13 TxHeader     c Content-Type: text/html; charset=UTF-8
    13 TxHeader     c Content-Length: 23
    13 TxHeader     c Date: Mon, 09 Jun 2008 16:41:14 GMT
    13 TxHeader     c X-Varnish: 803913450
    13 TxHeader     c Age: 0
    13 TxHeader     c Via: 1.1 varnish
    13 TxHeader     c Connection: keep-alive
    13 ReqEnd       c 803913450 1213029674.708000898 1213029674.780754805
 0.003840923 0.072657347 0.000096560
     0 StatAddr     - 82.182.xx.xx 0 76 14 47 0 0 30 12274 157175
 }}}

 {{{
 # varnishd -V
 varnishd (varnish-trunk)
 Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS
 }}}

 What I should mention is that the problem can be solved by another method.

 If I remove the Cookie2 AND TE header it all works out fine:
 {{{
        remove req.http.Cookie2;
        remove req.http.TE;

         if(req.request != "GET" && req.request != "HEAD") {
                 set req.http.Connection = "close";
                 pass;
         }
 }}}
 This works!

 But I must remove BOTH Cookie2 and TE header, else it wont work.

 * I will add more info from varnishlog as soon as Im home

Comment (by phk):

 reformat

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/250#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 16:32:29 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 16:32:29 -0000
Subject: [Varnish] #250: POST error when using Opera
In-Reply-To: <050.f7179b97ee045b3deb2bdae4b32537be@projects.linpro.no>
References: <050.f7179b97ee045b3deb2bdae4b32537be@projects.linpro.no>
Message-ID: <059.492f80c7798420d35a5bce7aff374ed5@projects.linpro.no>

#250: POST error when using Opera
--------------------+-------------------------------------------------------
 Reporter:  duja    |        Owner:  des                
     Type:  defect  |       Status:  new                
 Priority:  normal  |    Milestone:  Varnish 2.0 release
Component:  build   |      Version:  trunk              
 Severity:  normal  |   Resolution:                     
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by phk):

 First, why do you insert the Connection: closed in the first place ?  That
 trick only makes sense with "pipe" method.

 But irrespective of this, I have a hard time seeing what it does, because
 both the Connection and TE headers are already filtered out going through
 Varnish (notice how they are not in the TXheaders, so the backend will
 receive the same request either way.

 As to 200 vs 302 reply, that seems to be entirely up to the backend to
 decide, apart from what gets sent to the backend, I can't see how Varnish
 is or can be involved in that.

 As for deleting the Cookie2 and TE headers, Varnish never inspects either,
 and the latter is not sent to the backend, so I don't understand why you
 would have to remove TE and assume that the backend reacts to the lack of
 Cookie2 header.

 My best suggestion is that you capture varnishlog output from a client
 that works and compare it to this, and then examine what the backend
 actually does when it is called.

 I don't see anything that indicates that varnish is doing anything
 wrong...

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/250#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 16:33:03 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 16:33:03 -0000
Subject: [Varnish] #250: POST error when using Opera
In-Reply-To: <050.f7179b97ee045b3deb2bdae4b32537be@projects.linpro.no>
References: <050.f7179b97ee045b3deb2bdae4b32537be@projects.linpro.no>
Message-ID: <059.759709f4c975541fbba0d1471be88284@projects.linpro.no>

#250: POST error when using Opera
--------------------+-------------------------------------------------------
 Reporter:  duja    |        Owner:  des                
     Type:  defect  |       Status:  closed             
 Priority:  normal  |    Milestone:  Varnish 2.0 release
Component:  build   |      Version:  trunk              
 Severity:  normal  |   Resolution:  worksforme         
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/250#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 16:34:32 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 16:34:32 -0000
Subject: [Varnish] #215: regex matches sporadically on identical request
In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
Message-ID: <063.708d125368f93196543563d4c5a07b58@projects.linpro.no>

#215: regex matches sporadically on identical request
----------------------+-----------------------------------------------------
 Reporter:  onitunes  |        Owner:  des       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  build     |      Version:  1.0.4     
 Severity:  normal    |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 Time this ticket out for lack of response.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/215#comment:8>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 17:28:47 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 17:28:47 -0000
Subject: [Varnish] #256: Varnish Child Exits
Message-ID: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>

#256: Varnish Child Exits
----------------------+-----------------------------------------------------
 Reporter:  maxclark  |       Owner:  phk                      
     Type:  defect    |      Status:  new                      
 Priority:  normal    |   Milestone:  Varnish 2.0 code complete
Component:  varnishd  |     Version:  trunk                    
 Severity:  normal    |    Keywords:                           
----------------------+-----------------------------------------------------
 Approximately every 12 hours varnishd exits with the following error. The
 manager process restarts the child and the system does serve pages. We see
 this condition across all of our varnish instances. As an interesting side
 effect when the child dies the munin plugins do not return data.

 FreeBSD 7.0 amd64 w/ ULE scheduler
 Varnish 2.0-tp1

 Jun 21 05:09:27 can05 varnishd: Child (77717) said <<Assert error in
 STV_alloc(), stevedore.c line 71:>>
 Jun 21 05:09:27 can05 kernel: pid 77717 (varnishd), uid 101: exited on
 signal 6
 Jun 21 05:09:27 can05 varnishd: Child (77717) said <<  Condition((st) !=
 NULL) not true.>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Child starts>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<managed to mmap
 1073741824 bytes of 1073741824>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Ready>>

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/256>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 17:29:48 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 17:29:48 -0000
Subject: [Varnish] #256: Varnish Child Exits
In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
Message-ID: <063.04b3e73f91fe81a45561e321449ed622@projects.linpro.no>

#256: Varnish Child Exits
----------------------+-----------------------------------------------------
 Reporter:  maxclark  |        Owner:  phk                      
     Type:  defect    |       Status:  new                      
 Priority:  normal    |    Milestone:  Varnish 2.0 code complete
Component:  varnishd  |      Version:  trunk                    
 Severity:  normal    |   Resolution:                           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by maxclark):

 Log lines in a code block for easier reading.
 {{{
 Jun 21 05:09:27 can05 varnishd: Child (77717) said <<Assert error in
 STV_alloc(), stevedore.c line 71:>>
 Jun 21 05:09:27 can05 kernel: pid 77717 (varnishd), uid 101: exited on
 signal 6
 Jun 21 05:09:27 can05 varnishd: Child (77717) said <<  Condition((st) !=
 NULL) not true.>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Child starts>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<managed to mmap
 1073741824 bytes of 1073741824>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Ready>>

 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/256#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 18:59:43 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 18:59:43 -0000
Subject: [Varnish] #255: Varnish segfaults on certain response header sets
In-Reply-To: <055.2db80bcdd95846f89026ce28c359752f@projects.linpro.no>
References: <055.2db80bcdd95846f89026ce28c359752f@projects.linpro.no>
Message-ID: <064.5f3962226c41f3218954f3ca55fc8d70@projects.linpro.no>

#255: Varnish segfaults on certain response header sets
-----------------------+----------------------------------------------------
 Reporter:  rafrombrc  |        Owner:  phk   
     Type:  defect     |       Status:  closed
 Priority:  normal     |    Milestone:        
Component:  varnishd   |      Version:  trunk 
 Severity:  critical   |   Resolution:  fixed 
 Keywords:             |  
-----------------------+----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Old description:

> I'm testing varnish in front of a collection of HTTP services.  Depending
> on how I have things configured in my upstream app, the response headers
> can vary slightly.  Some combinations of response headers work fine, but
> others cause varnish to segfault, but only in cases where the response
> body is longer than approx 9000 bytes.
>
> Here's an example of a header set that does NOT cause the problem:
>
> Outgoing headers: (200 OK)
>   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
> Plone/3.0.7 (svn/unreleased)
>   Date: Thu, 19 Jun 2008 21:14:49 GMT
>   Content-Length: 18347
>   Expires: Mon, 22 Jun 1998 21:14:49 GMT
>   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
>   X-Caching-Rule-Id: 7
>   Cache-Control: max-age=0, s-maxage=3600, must-revalidate
>   Content-Type: text/html; charset=utf-8
>   X-Header-Set-Id: cache-in-proxy-1-hour
>
> The following response headers cause varnish to crash:
>
> Outgoing headers: (200 OK)
>   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
> Plone/3.0.7 (svn/unreleased)
>   Date: Thu, 19 Jun 2008 21:14:49 GMT
>   Content-Length: 18347
>   Expires: Thu, 19 Jun 2008 21:14:49 GMT
>   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
>   X-Caching-Rule-Id: 7
>   Cache-Control: must-revalidate, max-age = 0
>   Content-Type: text/html; charset=utf-8
>   X-Header-Set-Id: cache-in-proxy-1-hour
>
> Note that the only difference in the header sets are the Cache-Control
> and Expires headers.
>
> I can reproduce this problem with the varnish 1.1.2 release, the 1.2 svn
> branch, and the svn trunk.  I'm using Ubuntu 7.10.  'uname -a' generates
> the following:
>
> Linux parsifal 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008
> x86_64 GNU/Linux
>
> My VCL file and a core dump are attached.

New description:

 I'm testing varnish in front of a collection of HTTP services.  Depending
 on how I have things configured in my upstream app, the response headers
 can vary slightly.  Some combinations of response headers work fine, but
 others cause varnish to segfault, but only in cases where the response
 body is longer than approx 9000 bytes.

 Here's an example of a header set that does NOT cause the problem:

 {{{
 Outgoing headers: (200 OK)
   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
 Plone/3.0.7 (svn/unreleased)
   Date: Thu, 19 Jun 2008 21:14:49 GMT
   Content-Length: 18347
   Expires: Mon, 22 Jun 1998 21:14:49 GMT
   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
   X-Caching-Rule-Id: 7
   Cache-Control: max-age=0, s-maxage=3600, must-revalidate
   Content-Type: text/html; charset=utf-8
   X-Header-Set-Id: cache-in-proxy-1-hour
 }}}

 The following response headers cause varnish to crash:

 {{{
 Outgoing headers: (200 OK)
   Server: Zope/(Zope 2.10.5-final, python 2.4.4, linux2) ZServer/1.1
 Plone/3.0.7 (svn/unreleased)
   Date: Thu, 19 Jun 2008 21:14:49 GMT
   Content-Length: 18347
   Expires: Thu, 19 Jun 2008 21:14:49 GMT
   Last-Modified: Sun, 27 Nov 2005 05:41:47 GMT
   X-Caching-Rule-Id: 7
   Cache-Control: must-revalidate, max-age = 0
   Content-Type: text/html; charset=utf-8
   X-Header-Set-Id: cache-in-proxy-1-hour
 }}}
 Note that the only difference in the header sets are the Cache-Control and
 Expires headers.

 I can reproduce this problem with the varnish 1.1.2 release, the 1.2 svn
 branch, and the svn trunk.  I'm using Ubuntu 7.10.  'uname -a' generates
 the following:

 Linux parsifal 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008
 x86_64 GNU/Linux

 My VCL file and a core dump are attached.

Comment:

 This was a bug in the header field parsing code (http_GetHdrField()) which
 didn't like whitespace before the = in "max-age = 0".

 Fixed in #2760.

 Regression test created (r00255.vtc)

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/255#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 19:00:27 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 19:00:27 -0000
Subject: [Varnish] #256: Varnish Child Exits
In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
Message-ID: <063.bf2da3d9f9db11438f224bd90cdf180d@projects.linpro.no>

#256: Varnish Child Exits
----------------------+-----------------------------------------------------
 Reporter:  maxclark  |        Owner:  phk                      
     Type:  defect    |       Status:  new                      
 Priority:  normal    |    Milestone:  Varnish 2.0 code complete
Component:  varnishd  |      Version:  trunk                    
 Severity:  normal    |   Resolution:                           
 Keywords:            |  
----------------------+-----------------------------------------------------
Old description:

> Approximately every 12 hours varnishd exits with the following error. The
> manager process restarts the child and the system does serve pages. We
> see this condition across all of our varnish instances. As an interesting
> side effect when the child dies the munin plugins do not return data.
>
> FreeBSD 7.0 amd64 w/ ULE scheduler
> Varnish 2.0-tp1
>
> Jun 21 05:09:27 can05 varnishd: Child (77717) said <<Assert error in
> STV_alloc(), stevedore.c line 71:>>
> Jun 21 05:09:27 can05 kernel: pid 77717 (varnishd), uid 101: exited on
> signal 6
> Jun 21 05:09:27 can05 varnishd: Child (77717) said <<  Condition((st) !=
> NULL) not true.>>
> Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Child starts>>
> Jun 21 05:09:27 can05 varnishd: Child (39036) said <<managed to mmap
> 1073741824 bytes of 1073741824>>
> Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Ready>>

New description:

 Approximately every 12 hours varnishd exits with the following error. The
 manager process restarts the child and the system does serve pages. We see
 this condition across all of our varnish instances. As an interesting side
 effect when the child dies the munin plugins do not return data.

 {{{
 FreeBSD 7.0 amd64 w/ ULE scheduler
 Varnish 2.0-tp1

 Jun 21 05:09:27 can05 varnishd: Child (77717) said <<Assert error in
 STV_alloc(), stevedore.c line 71:>>
 Jun 21 05:09:27 can05 kernel: pid 77717 (varnishd), uid 101: exited on
 signal 6
 Jun 21 05:09:27 can05 varnishd: Child (77717) said <<  Condition((st) !=
 NULL) not true.>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Child starts>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<managed to mmap
 1073741824 bytes of 1073741824>>
 Jun 21 05:09:27 can05 varnishd: Child (39036) said <<Ready>>
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/256#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 19:07:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 19:07:31 -0000
Subject: [Varnish] #256: Varnish Child Exits
In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
Message-ID: <063.69048a95aa68878d50b2f9199790b675@projects.linpro.no>

#256: Varnish Child Exits
----------------------+-----------------------------------------------------
 Reporter:  maxclark  |        Owner:  phk                      
     Type:  defect    |       Status:  closed                   
 Priority:  normal    |    Milestone:  Varnish 2.0 code complete
Component:  varnishd  |      Version:  trunk                    
 Severity:  normal    |   Resolution:  worksforme               
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 This signals that varnish could not allocate storage.

 Assign more storage (check your -s arguments).

 If you have redefined vcl_discard(), reconsider your changes.

 Yes, the error handling needs to be better and more graceful.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/256#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Jun 21 19:57:39 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 21 Jun 2008 19:57:39 -0000
Subject: [Varnish] #226: Varnishd crashes on STV_alloc at stevedore.c:72
In-Reply-To: <054.5bcee183f43744c7725f00eb312fe1b7@projects.linpro.no>
References: <054.5bcee183f43744c7725f00eb312fe1b7@projects.linpro.no>
Message-ID: <063.1962d79ccd9860584627fba215de26e6@projects.linpro.no>

#226: Varnishd crashes on STV_alloc at stevedore.c:72
--------------------------------+-------------------------------------------
 Reporter:  dingdeng            |        Owner:  phk       
     Type:  defect              |       Status:  closed    
 Priority:  normal              |    Milestone:            
Component:  varnishd            |      Version:  1.2       
 Severity:  normal              |   Resolution:  worksforme
 Keywords:  varnishd STV_alloc  |  
--------------------------------+-------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 Sorry about the delay in replying.

 This means that varnish ran out of storage, check your -s arguments and
 give it more space if you can.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/226#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun 23 07:38:41 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 23 Jun 2008 07:38:41 -0000
Subject: [Varnish] #254: Condition(oe2->timer_when >= oe->timer_when)
	not true
In-Reply-To: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
References: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no>
Message-ID: <058.b0850ff6810ea0b0ed9fb2b39e75a4a8@projects.linpro.no>

#254: Condition(oe2->timer_when >= oe->timer_when) not true
--------------------+-------------------------------------------------------
 Reporter:  sky     |        Owner:  des     
     Type:  defect  |       Status:  reopened
 Priority:  normal  |    Milestone:          
Component:  build   |      Version:  trunk   
 Severity:  normal  |   Resolution:          
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by sky):

  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 If you mean #253 and http://varnish.projects.linpro.no/changeset/2737 ?

 I need to have that line commented out or I eventually hit this even with
 that applied.

 I do a lot of purges continuously, so I suspect that might be related.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/254#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun 23 08:09:02 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 23 Jun 2008 08:09:02 -0000
Subject: [Varnish] #247: Varnish sends 304 header for ESI pages although
	some of the included objects might have changed
In-Reply-To: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no>
References: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no>
Message-ID: <060.93412ce71291eac4b4205a93851828b9@projects.linpro.no>

#247: Varnish sends 304 header for ESI pages although some of the included
objects might have changed
----------------------+-----------------------------------------------------
 Reporter:  peter     |        Owner:  phk  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by sky):

 The last modified should be the youngest piece of ESI content.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/247#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun 23 14:33:08 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 23 Jun 2008 14:33:08 -0000
Subject: [Varnish] #257: make localstatedir configurable from commandline
Message-ID: <050.b334ae9fa7d76ac210fce08d1283e30b@projects.linpro.no>

#257: make localstatedir configurable from commandline
--------------------+-------------------------------------------------------
 Reporter:  ebik    |       Owner:  des  
     Type:  defect  |      Status:  new  
 Priority:  low     |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  minor   |    Keywords:       
--------------------+-------------------------------------------------------
 I'm evaluating varnish as ordinary user with no write support to
 /var/lib/. I have to patch source to have _.vsl file and compiled vcl
 files to reside in other location. (E.g. on ramdisk :) )

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/257>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun 23 15:57:25 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 23 Jun 2008 15:57:25 -0000
Subject: [Varnish] #256: Varnish Child Exits
In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
Message-ID: <063.57de39256be3a6efcf6518a75bf476c2@projects.linpro.no>

#256: Varnish Child Exits
----------------------+-----------------------------------------------------
 Reporter:  maxclark  |        Owner:  phk                      
     Type:  defect    |       Status:  reopened                 
 Priority:  normal    |    Milestone:  Varnish 2.0 code complete
Component:  varnishd  |      Version:  trunk                    
 Severity:  normal    |   Resolution:                           
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by maxclark):

  * status:  closed => reopened
  * resolution:  worksforme =>

Comment:

 Why would a system that has ample ram (4GB) and plenty of disk space (41GB
 Free) be able to start the process with a 1G storage pool and then after
 12 hours crash?

 We have not redefined vcl_discard - what else should we be looking at to
 resolve this?

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/256#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun 23 16:36:45 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 23 Jun 2008 16:36:45 -0000
Subject: [Varnish] #256: Varnish Child Exits
In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no>
Message-ID: <063.ac16fdacaa6b1a91075cdccaedbeb4a1@projects.linpro.no>

#256: Varnish Child Exits
----------------------+-----------------------------------------------------
 Reporter:  maxclark  |        Owner:  phk                      
     Type:  defect    |       Status:  reopened                 
 Priority:  normal    |    Milestone:  Varnish 2.0 code complete
Component:  varnishd  |      Version:  trunk                    
 Severity:  normal    |   Resolution:                           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by phk):

 Is this a 32 bit or 64 bit system ?

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/256#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun 23 16:42:41 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 23 Jun 2008 16:42:41 -0000
Subject: [Varnish] #257: make localstatedir configurable from commandline
In-Reply-To: <050.b334ae9fa7d76ac210fce08d1283e30b@projects.linpro.no>
References: <050.b334ae9fa7d76ac210fce08d1283e30b@projects.linpro.no>
Message-ID: <059.aff70223539caf91927bdbe5de93bbc2@projects.linpro.no>

#257: make localstatedir configurable from commandline
--------------------+-------------------------------------------------------
 Reporter:  ebik    |        Owner:  des   
     Type:  defect  |       Status:  closed
 Priority:  low     |    Milestone:        
Component:  build   |      Version:  trunk 
 Severity:  minor   |   Resolution:  fixed 
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 You can give an argument to the configure script to change it.

 I've put making it a runtime argument on the "post 2.0" wiki page.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/257#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Jun 23 16:49:01 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 23 Jun 2008 16:49:01 -0000
Subject: [Varnish] #258: Add Hostname to Error Pages
Message-ID: <054.18fe511275e5b9e1fc2c1eb7a73b6afd@projects.linpro.no>

#258: Add Hostname to Error Pages
-------------------------+--------------------------------------------------
 Reporter:  maxclark     |       Owner:  phk                      
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  Varnish 2.0 code complete
Component:  varnishd     |     Version:  trunk                    
 Severity:  normal       |    Keywords:                           
-------------------------+--------------------------------------------------
 Currently when varnish serves an error page (404/503, etc...) there is no
 way to determine which varnish server from a load balanced pool issued the
 error. Ideally I would like the ability to serve a custom error page with
 ESI includes but critically I need a way to identify the varnish instance
 which could be resolved just by adding the hostname into the outputted
 html.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/258>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 24 07:24:12 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 24 Jun 2008 07:24:12 -0000
Subject: [Varnish] #259: support for revalidating with 304,
	support for user-reloading
Message-ID: <050.6d118020109bff8153f1892f0127911c@projects.linpro.no>

#259: support for revalidating with 304, support for user-reloading
-------------------------+--------------------------------------------------
 Reporter:  ebik         |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 I would like to have possibility to 'invalidate' page in 'vcl_hit'. I.e. I
 want to reload the page from backend if I think the page is invalid (e.g.
 by some hint that browser sends to me [this can be used to DOS attack, but
 use of such feature is administrator's decision]).

 Next level is to have ability to 'revalidate' page from backend. I.e. I
 would like to send etag and/or last modified time from varnish to backend,
 which will be able to response with 304 not modified. This should be
 alternative to 'discard' option in 'vcl_discard' but it should be also
 available in 'vcl_hit' instead of 'invalidating' proposed above.

 And the most advanced stuff will be possibility to run the revalidation in
 background, i.e. return old page and request revalidation from backend at
 the same time, both by 'GET' or by 'HEADER' request.

 This will give the possibility to have page, e.g., 30 seconds in cache in
 'authoritative' way and next 5 minutes in 'unauthoritative' way (with
 revalidating from server) and then discarding.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/259>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 24 11:32:54 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 24 Jun 2008 11:32:54 -0000
Subject: [Varnish] #260: varnishd pid file is created with too restrictive
	file mode
Message-ID: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no>

#260: varnishd pid file is created with too restrictive file mode
----------------------+-----------------------------------------------------
 Reporter:  hans      |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 varnishd creates its pid file with the file mode 0600, which is too
 restrictive.  If one really wants to conceal the pid that a varnishd runs
 under, it is easy to put the pid file into a directory that is world-
 unreadable or use a proper umask.  The other way round, this problem is
 impossible to fix.  We need to check whether varnishd runs using a non-
 privileged process and we don't want that process to have elevated
 privilege just to read the varnishd pid file.  The fix is trivial, patch
 attached.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/260>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 24 11:42:11 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 24 Jun 2008 11:42:11 -0000
Subject: [Varnish] #260: varnishd pid file is created with too
	restrictive file mode
In-Reply-To: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no>
References: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no>
Message-ID: <059.eacb4f3a8464b0ad8fc3bdd74e33a92f@projects.linpro.no>

#260: varnishd pid file is created with too restrictive file mode
----------------------+-----------------------------------------------------
 Reporter:  hans      |        Owner:  des     
     Type:  defect    |       Status:  assigned
 Priority:  normal    |    Milestone:          
Component:  varnishd  |      Version:  trunk   
 Severity:  normal    |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by des):

  * owner:  phk => des
  * status:  new => assigned

Comment:

 Needs to be fixed in FreeBSD and merged over along with other bug fixes.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/260#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 24 11:44:59 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 24 Jun 2008 11:44:59 -0000
Subject: [Varnish] #260: varnishd pid file is created with too
	restrictive file mode
In-Reply-To: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no>
References: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no>
Message-ID: <059.cd53581ec737e3ee5651fa3284b45fb8@projects.linpro.no>

#260: varnishd pid file is created with too restrictive file mode
----------------------+-----------------------------------------------------
 Reporter:  hans      |        Owner:  des     
     Type:  defect    |       Status:  assigned
 Priority:  normal    |    Milestone:          
Component:  varnishd  |      Version:  trunk   
 Severity:  normal    |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by des):

 Correction: it is actually Varnish that selects the file mode.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/260#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 24 11:48:22 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 24 Jun 2008 11:48:22 -0000
Subject: [Varnish] #260: varnishd pid file is created with too
	restrictive file mode
In-Reply-To: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no>
References: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no>
Message-ID: <059.4ffaa1f8716710e823031d9cdeafd48c@projects.linpro.no>

#260: varnishd pid file is created with too restrictive file mode
----------------------+-----------------------------------------------------
 Reporter:  hans      |        Owner:  des     
     Type:  defect    |       Status:  assigned
 Priority:  normal    |    Milestone:          
Component:  varnishd  |      Version:  trunk   
 Severity:  normal    |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by des):

 Fixed in trunk.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/260#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 24 13:56:23 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 24 Jun 2008 13:56:23 -0000
Subject: [Varnish] #261: regexp on cookie header breaks the URL
Message-ID: <053.896b419e1b3e684893050768e36f7e80@projects.linpro.no>

#261: regexp on cookie header breaks the URL
----------------------+-----------------------------------------------------
 Reporter:  wichert   |       Owner:  phk                
     Type:  defect    |      Status:  new                
 Priority:  highest   |   Milestone:  Varnish 2.0 release
Component:  varnishd  |     Version:  trunk              
 Severity:  major     |    Keywords:                     
----------------------+-----------------------------------------------------
 Using varnish from trunk as of r2790.

 I have this bit of VCL:

 {{{
 sub vcl_recv {
     set req.backend = lb01;

     set req.url =
 "/VirtualHostBase/http/plone.customer.int:80/eli/VirtualHostRoot" req.url;

     if (req.request == "PURGE") {
         if (!client.ip ~ purge) {
             error 405 "Not allowed.";
         }
         lookup;
     }

     if (req.request == "POST") {
         pass;
     }

     if (req.http.If-None-Match) {
         pass;
     }

     if (req.url ~ "\.(gif|png|jpg|css|kss|js)") {
         remove req.http.cookie;
         lookup;
     }

     if (req.url ~ "VirtualHostRoot/?$" && ! req.http.cookie ~ "__ac" ) {
         if (req.http.cookie ~ "mainchain") {
                 set req.http.cookie = regsub(req.http.cookie,
 ".*mainchain=%22([^%22]*%22).*", "mainchain=\1");
         } else {
                 remove req.http.cookie;
         }
     }
 }
 }}}

 What this tries to do is sanitize the ''mainchain'' cookie when the user
 is looking at the frontpage. Strangely enough if a user tries to look at
 the frontpage varnish mangles the URL. Here is the relevant varnishlog:
 {{{
     9 ReqStart     c 10.121.10.84 41581 1274035111
     9 RxRequest    c GET
     9 RxURL        c /
     9 RxProtocol   c HTTP/1.1
     9 RxHeader     c Accept-Language: en
     9 RxHeader     c Accept-Encoding: gzip, deflate
     9 RxHeader     c Cookie: mainchain="89b21ac46cd08651c0fc0870a03470ec"
     9 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
 10_4_
 11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.18
     9 RxHeader     c Accept:
 text/xml,application/xml,application/xhtml+xml,text
 /html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
     9 RxHeader     c Cache-Control: max-age=0
     9 RxHeader     c Connection: keep-alive
     9 RxHeader     c Host: plone.customer.int
     9 VCL_call     c recv
     9 VCL_return   c pass
     9 VCL_call     c pass
     9 VCL_return   c pass
    11 TxRequest    b GET
    11 TxURL        b /VirtualHostBase/httcookie:
 mainchain=89b21ac46cd08651c0fc0
 870
    11 TxProtocol   b HTTP/1.1
    11 TxHeader     b Accept-Language: en
    11 TxHeader     b Accept-Encoding: gzip, deflate
    11 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
 10_4_
 11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.18
    11 TxHeader     b Accept:
 text/xml,application/xml,application/xhtml+xml,text
 /html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    11 TxHeader     b Host: plone.customer.int
    11 TxHeader     b cookie: mainchain=89b21ac46cd08651c0fc0870a03470ec"
    11 TxHeader     b X-Varnish: 1274035111
    11 TxHeader     b X-Forwarded-For: 10.121.10.84
    11 RxProtocol   b HTTP/1.0
    11 RxStatus     b 400
    11 RxResponse   b Bad Request
    11 RxHeader     b Date: Tue, 24 Jun 2008 13:50:58 GMT
    11 RxHeader     b Content-Length: 136
    11 RxHeader     b Content-Type: text/html
    11 RxHeader     b Server: Medusa/24763
     9 ObjProtocol  c HTTP/1.0
     9 ObjStatus    c 400
     9 ObjResponse  c Bad Request
     9 ObjHeader    c Date: Tue, 24 Jun 2008 13:50:58 GMT
     9 ObjHeader    c Content-Type: text/html
     9 ObjHeader    c Server: Medusa/24763
 }}}

 Notice how the cookie is suddenly inserted in the middle of the URL.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/261>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Jun 24 18:12:34 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 24 Jun 2008 18:12:34 -0000
Subject: [Varnish] #261: regexp on cookie header breaks the URL
In-Reply-To: <053.896b419e1b3e684893050768e36f7e80@projects.linpro.no>
References: <053.896b419e1b3e684893050768e36f7e80@projects.linpro.no>
Message-ID: <062.40eb39baeae917509fdaefd292a44426@projects.linpro.no>

#261: regexp on cookie header breaks the URL
----------------------+-----------------------------------------------------
 Reporter:  wichert   |        Owner:  phk                
     Type:  defect    |       Status:  closed             
 Priority:  highest   |    Milestone:  Varnish 2.0 release
Component:  varnishd  |      Version:  trunk              
 Severity:  major     |   Resolution:  fixed              
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Sorry, my mistake.

 Should be fixed in #2792.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/261#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 25 07:41:57 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 25 Jun 2008 07:41:57 -0000
Subject: [Varnish] #262: Varnish crashes on Assert error in
	htc_header_complete(), cache_httpconn.c line 60
Message-ID: <052.801527bce0bf2f3343b73d5928a385d2@projects.linpro.no>

#262: Varnish crashes on Assert error in htc_header_complete(), cache_httpconn.c
line 60
----------------------+-----------------------------------------------------
 Reporter:  anders    |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  major     |    Keywords:       
----------------------+-----------------------------------------------------
 Running Varnish trunk/2665 for around a week or so, I got the following
 assert:

 {{{
 Child said (2, 83498): <<Assert error in htc_header_complete(),
 cache_httpconn.c line 60:>>
 Child said (2, 83498): <<  Condition(*t->e == '\0') not true.>>
 Cache child died pid=83498 status=0x86
 }}}

 This is in FreeBSD 7.0/amd64 running on Intel hardware, with SCHED_ULE and
 a patch to set 2K page size in storage_file.c. At the time of the crash I
 had 4.33 million objects and 75 GB data in the cache.

 Startup parameters:

 varnishd_files="-s malloc,100G"
 varnishd_flags="-d -d -u root -g wheel -p obj_workspace=4096 -p
 lru_interval=3600 -h classic,500009 -p ping_interval=0 -p cli_timeout=30
 -p auto_restart=off -p thread_pools=4 -p thread_pool_max=1000 -p
 session_linger=40 -p listen_depth=4096 -p srcaddr_hash=20480 -p
 default_ttl=604800 -T localhost:8080 -f /usr/local/etc/varnish.vcl
 $varnishd_files -P /var/run/varnishd.pid"

 My VCL:

 {{{
 backend default {
              .host = "192.168.110.1";
              .port = "80";
         }
 acl purge {
         "192.168.100.1"/32;
 }

 sub vcl_recv {
         set req.grace = 5m;
         if (req.http.host ~ "^(bars.*.foo.no|bazcache.foo.no)$") {
                 if (req.request == "GET" || req.request == "HEAD") {
                         lookup;
                 } elsif (req.request == "PURGE") {
                         if (client.ip ~ purge) {
                                 lookup;
                         } else {
                                 error 405 "Not allowed.";
                         }
                 } else {
                         pipe;
                 }
         } else {
                 error 403 "Access denied. Contact cacheadmin at foo.no if you
 have problems.";
         }
 }


 sub vcl_miss {
         if (req.request ~ "^(PURGE)$") {
                 error 404 "Not in cache.";
         } else {
                 fetch;
         }
 }
 sub vcl_hit {
         if (req.request == "PURGE") {
                 set obj.ttl = 0s;
                 error 200 "Purged.";
         } else {
                 if (!obj.cacheable) {
                         pass;
                 } else {
                         deliver;
                 }
         }
 }
 sub vcl_fetch {
         set obj.grace = 5m;
         if (obj.status == 404 || obj.status == 401 || obj.status == 500) {
                 pass;
         }

         if (!obj.valid) {
                 error obj.status;
         }
         if (!obj.cacheable) {
                 pass;
         }

         if (obj.http.Cookie) {
                 remove obj.http.Cookie;
         }
         if (obj.http.Set-Cookie) {
                 remove obj.http.Set-Cookie;
         }
         insert;
 }
 }}}

 Backtrace (90 GB core dump, used 55 GB on a compressed filesystem):

 {{{
 (gdb) bt
 #0  0x0000000800d0efec in thr_kill () from /lib/libc.so.7
 #1  0x0000000800d98c5b in abort () from /lib/libc.so.7
 #2  0x000000080066fcef in lbv_assert (func=Variable "func" is not
 available.
 ) at assert.c:65
 #3  0x0000000000416477 in htc_header_complete (t=0x80c0010d0)
     at cache_httpconn.c:60
 #4  0x00000000004164c4 in HTC_Complete (htc=0x80c0010c0)
     at cache_httpconn.c:136
 #5  0x000000000040c108 in cnt_again (sp=0x80c001008) at cache_center.c:97
 #6  0x000000000040e209 in CNT_Session (sp=0x80c001008) at steps.h:32
 #7  0x000000000041871d in wrk_do_cnt_sess (w=0x7fff90484ac0, priv=Variable
 "priv" is not available.
 )
     at cache_pool.c:330
 #8  0x00000000004176d2 in wrk_thread (priv=0x806303250) at
 cache_pool.c:244
 #9  0x0000000800a96a88 in pthread_getprio () from /lib/libthr.so.3
 #10 0x00007fff90285000 in ?? ()
 Cannot access memory at address 0x7fff90485000
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/262>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 25 07:56:43 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 25 Jun 2008 07:56:43 -0000
Subject: [Varnish] #262: Varnish crashes on Assert error in
	htc_header_complete(), cache_httpconn.c line 60
In-Reply-To: <052.801527bce0bf2f3343b73d5928a385d2@projects.linpro.no>
References: <052.801527bce0bf2f3343b73d5928a385d2@projects.linpro.no>
Message-ID: <061.036ec2867aeda95c70ca54b674fcc092@projects.linpro.no>

#262: Varnish crashes on Assert error in htc_header_complete(), cache_httpconn.c
line 60
----------------------+-----------------------------------------------------
 Reporter:  anders    |        Owner:  phk  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  major     |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by phk):

 {{{
 (gdb) print *htc
 $2 = {magic = 1041886673, fd = 477, ws = 0x80c001078, rxbuf = {
     b = 0x80c0017b3 "\n", e = 0x80c0017b3 "\n"}, pipeline = {b = 0x0, e =
 0x0}}
 (gdb) print htc->rxbuf
 $3 = {b = 0x80c0017b3 "\n", e = 0x80c0017b3 "\n"}
 (gdb) print *htc->ws
 $5 = {magic = 905626964, id = 0x43590d "sess",
   s = 0x80c0017a0 "84.209.97.237", f = 0x80c0017b3 "\n",
   r = 0x80c0027b3 " GMT", e = 0x80c0037a0 '?' <repeats 200 times>...,
   overflow = 0}
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/262#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 25 10:00:59 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 25 Jun 2008 10:00:59 -0000
Subject: [Varnish] #262: Varnish crashes on Assert error in
	htc_header_complete(), cache_httpconn.c line 60
In-Reply-To: <052.801527bce0bf2f3343b73d5928a385d2@projects.linpro.no>
References: <052.801527bce0bf2f3343b73d5928a385d2@projects.linpro.no>
Message-ID: <061.58c8484eda7ee87f08f4200a2f8964bd@projects.linpro.no>

#262: Varnish crashes on Assert error in htc_header_complete(), cache_httpconn.c
line 60
----------------------+-----------------------------------------------------
 Reporter:  anders    |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  major     |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Fixed in 2801.

 Regression test case added.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/262#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 25 15:40:36 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 25 Jun 2008 15:40:36 -0000
Subject: [Varnish] #263: VCL fails to compile when using predefined backends
	in director
Message-ID: <050.a5321629f3a491f95845217996cb3f0f@projects.linpro.no>

#263: VCL fails to compile when using predefined backends in director
--------------------+-------------------------------------------------------
 Reporter:  adam    |       Owner:  des  
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 If I define a few backends, and then use them in a director (and just
 there), varnishd fails, complaining that the backends are 'unused'.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/263>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Jun 25 15:56:30 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 25 Jun 2008 15:56:30 -0000
Subject: [Varnish] #263: VCL fails to compile when using predefined
	backends in director
In-Reply-To: <050.a5321629f3a491f95845217996cb3f0f@projects.linpro.no>
References: <050.a5321629f3a491f95845217996cb3f0f@projects.linpro.no>
Message-ID: <059.8639793018756d1228b2da8556ee9b74@projects.linpro.no>

#263: VCL fails to compile when using predefined backends in director
--------------------+-------------------------------------------------------
 Reporter:  adam    |        Owner:  des   
     Type:  defect  |       Status:  closed
 Priority:  normal  |    Milestone:        
Component:  build   |      Version:  trunk 
 Severity:  normal  |   Resolution:  fixed 
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Fixed in 2801.

 Regression test case created.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/263#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Jun 26 09:23:28 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 26 Jun 2008 09:23:28 -0000
Subject: [Varnish] #264: server.port VCL variable
Message-ID: <050.5d9930495dd68b333b50efa6dc82d62a@projects.linpro.no>

#264: server.port VCL variable
-------------------------+--------------------------------------------------
 Reporter:  adam         |       Owner:  des  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  build        |     Version:  trunk
 Severity:  normal       |    Keywords:  vcl  
-------------------------+--------------------------------------------------
 It could be useful with a VCL variable that holds the port on which the
 server has answered the request, in the same way that server.ip holds the
 IP number.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/264>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator