On 8/24/21 18:36, Dridi Boukelmoune wrote:
>
> They should ideally provide a version, but since we have packaging
> that could compete with first party packages we can't really predict
> what version we would go against.
Got it.
> I think the reason why we didn't want the traditional separation
Hello,
The spec file for RPM packages:
https://raw.githubusercontent.com/varnishcache/pkg-varnish-cache/master/redhat/varnish.spec
... has this passage:
Provides: varnish-libs%{?_isa} = %{version}-%{release}
Provides: varnish-libs = %{version}-%{release}
Obsoletes: varnish-libs
Provides:
On 5/28/21 17:50, Dridi Boukelmoune wrote:
>
> First, we already have a relationship between bereq.uncacheable and
> bereq.uncacheable: the former implies the latter.
Presumably you meant to write that bereq.uncacheable implies
beresp.uncacheable.
My quick and superficial first reaction to the
On 7/28/20 13:52, Martin Grigorov wrote:
>
> I've just posted an article [1] about comparing the performance of Varnish
> Cache on two similar
> machines - the main difference is the CPU architecture - x86_64 vs aarch64.
> It uses a specific use case - the backend service just returns a static
>
On 6/17/20 16:56, Nils Goroll wrote:
> On 17/06/2020 10:00, Emilio Fernandes wrote:
>> 1.1) curl -s
>> https://packagecloud.io/install/repositories/varnishcache/varnish-weekly/script.deb.sh
>> | sudo bash
>
> The fact that, with my listmaster head on, I have not censored this posting,
> does not,
On 11/9/19 13:34, Nils Goroll wrote:
>
> Could we extend the .vmod interface by something like
>
> $Function VOID foo (STRING, ...)
>
> which would turn into a va_args argument of the previous type?
It's worth pointing out that the variable arg syntax in the VMOD
function call is one
On 9/16/19 16:31, Poul-Henning Kamp wrote:
>
>> The EXPLICIT_BZERO check is still AC_REQUIRE'd in varnish.m4, from
>> VARNISH_PREREQ and _VARNISH_CHECK_DEVEL, which are used in VMOD
>> development. Since it's not defined now, this leads to a cascade of
>> error messages when autogen.sh is called
On 9/16/19 14:35, Geoff Simmons wrote:
>
> The EXPLICIT_BZERO check is still AC_REQUIRE'd in varnish.m4, from
> VARNISH_PREREQ and _VARNISH_CHECK_DEVEL, which are used in VMOD
> development. Since it's not defined now, this leads to a cascade of
> error messages when autog
On 9/16/19 13:37, Poul-Henning Kamp wrote:
> Solved in #3057
Repeating my comment in github on the commit (to make sure that everyone
can see it):
The EXPLICIT_BZERO check is still AC_REQUIRE'd in varnish.m4, from
VARNISH_PREREQ and _VARNISH_CHECK_DEVEL, which are used in VMOD
development. Since
To help get an overview of what the VSL refactoring will be all about, I
applied some grep-foo to current master to find the VSL*() calls in the
code, so that we can see how log data are currently formatted by
varnishd. Results are on the github wiki:
On 5/3/19 10:51, Dridi Boukelmoune wrote:
>
> First we lose the ability to treat the whole record as a single sting
> out of the box. The client will need to reconstruct the string from
> the various field types that may constitute a record. Think string and
> regex operators.
Yes, Martin and I
On 4/12/19 16:37, Dridi Boukelmoune wrote:
>
> Interesting, for textual logs the effect of vsl_reclen is
> straightforward but how should we deal with binary records truncation?
On 4/12/19 16:52, Nils Goroll wrote:
> As before - truncate?
>
> For the fixed part, we can make sure that vsl_reclen
On 4/11/19 15:45, Poul-Henning Kamp wrote:
>
> Sorry, I got distracted by a disk (actually NVME) failure on my laptop
> yesterday, and have not tought more about it. Can we conclude on
> this monday morning instead ?
np
I hope your data's OK.
--
** * * UPLEX - Nils Goroll Systemoptimierung
I'm not sure if we have a consensus, but I'd like to summarize what I've
understood from the conversation so far. I at least would be willing to
go ahead on this basis.
- The "source of truth" and generation of code and docs for SLT tags
follows the model of .vsc files and the vsctool. So data
On 4/10/19 16:24, Nils Goroll wrote:
>
> I wonder though if all things considered (format string parsing, definition
> lookup, varargs processing) this pays off. I got no data on this, but one
> counter-argument might be that, for custom functions, one would expect no/very
> few conditionals, so
On 4/10/19 09:13, Poul-Henning Kamp wrote:
>
Responding out of order by taking the last two points first, because
they become relevant again further down.
> Far out:
>
> Given this level of abstraction we could reorder the arguments
> between VSL and presentation, so for instance timestamp
Hello all,
UPLEX may get support to develop a PR as a first step to implementing VIP23:
https://github.com/varnishcache/varnish-cache/wiki/VIP-23:-Refactor-VSL-to-support-extracting-structured-data-from-%22binary%22-log-payloads
Whether we get the support is yet to be finalized, but if so we'll
Hello all,
I'm writing in the hope that someone will be better versed in emacs-lisp
than I am.
For a while we've had a very simple .dir-locals.el at the root of the
project directory, which goes a long way towards automating fulfillment
of style(9) for Emacs users, but doesn't quite make it.
On 10/8/18 18:55, Federico Schwindt wrote:
>
> It might be a bit earlier but personally knowing the where and when for the
> next VDD will help immensely to sort the time off at work and whatnot,
> especially the date.
>
> Do we have any ideas or suggestions?
I thought that the time frame
On 09/11/2018 09:36 AM, Nils Goroll wrote:
> On 10/09/18 12:53, Carlos Abalde wrote:
>> Problem is I'm not sure I'm understanding what are the
>> implications of that change for VMOD developers.
>
> now documented here:
>
>
On 09/10/2018 12:53 PM, Carlos Abalde wrote:
>
> I assume
> https://github.com/varnishcache/varnish-cache/commit/f03948f48445be4dbea5f389ac4168b4a6befc6c
> is related with the PRIV_TASK and PRIV_TOP change mentioned in section
> 'Changes for developers' in
>
On 05/16/2018 09:56 AM, Poul-Henning Kamp wrote:
>
> It would have to be possible to say
>
> vmod.tell somevcl::somevmod "bla bla bla"
>
> To target a single one, but it is probably ill-advised to insist
> on always only targeting a single one.
... and then it's easy to imagine syntax
On 05/03/2018 10:49 AM, Dridi Boukelmoune wrote:
>> Illustrated example: varnishadm backend.list output
>>
>> Backend name Admin Probe Last change
>> boot.b1 probe 0/8 badWed, 02 May 2018 13:22:10
>> GMT
>> boot.b2
On 12/10/2017 06:36 PM, Reza Naghibi wrote:
> Basically, the user adds VFP
> processors via VCL as usual with an optional position.
What did you mean here by "as usual"? A user doesn't have a means to add
VFPs or VDPs via VCL -- I thought that this discussion is about how that
would work.
>-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/23/2016 09:42 AM, Geoff Simmons wrote:
> On 11/22/2016 11:22 PM, Nils Goroll wrote:
>> On 22/11/16 14:41, David CARLIER wrote:
>>> You probably thought of it but is there any plan (next year ?)
>>> to impleme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/12/2017 01:09 PM, Geoff Simmons wrote:
>
> Again I'm writing in the hope of soliciting opinions, this time
> pondering support for UDS in the PROXY protocol.
I should have mentioned that the last mail was entirely about
receiv
Hello again,
As with the listen addresses yesterday: this commit on a fork of
Varnish is a first attempt to implement UDSen as the connect address
for backends:
https://github.com/slimhazard/varnish-cache/commit/3ac2202de88ca18c9bc0a3d3b095fff1a53aaed3
And there are notes in the Wiki about the
Hello all,
This commit on a fork of Varnish is a first stab at implementing UDS
as a listen address:
https://github.com/slimhazard/varnish-cache/commit/881a18613ceb86be5eca721200667d4bb0f20cf6
I've written some notes in the Wiki about issues that I think are
worth attention:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
This will be comments on this part of the thread so far, and on the
current state of the draft in Wiki.
On 05/15/2017 11:41 AM, Dridi Boukelmoune wrote:
>>
>> For connect(2), BSD-derived systems don't care about permissions
>> on the UDS path at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/25/2017 04:42 PM, Dridi Boukelmoune wrote:
>
>> ## Access permissions on the listen address For the ``-a``
>> address, I suggest an optional means of specifying who can access
>> the UDS: ``` varnishd -a unix:/path/to/uds:uid=foo,gid=bar ```
On 04/25/2017 04:42 PM, Dridi Boukelmoune wrote:
>>
>> # How? ## Address notation I suggest that we require a prefix
>> such as ``unix:`` to identify UDS addresses (nginx uses
>> ``unix:``, haproxy uses ``unix@``): ``` varnishd -a
>> unix:/path/to/uds
>
> This should be enough:
>
> varnishd -a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/12/2017 11:14 PM, Poul-Henning Kamp wrote:
> We are now in *HARD* code freeze until the 5.1 release on
> wednesday.
>
> All commits outside the doc/ subtree requires my explicit OK, and
> the change will have to be important before I grant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/06/2017 09:35 PM, Dridi Boukelmoune wrote:
>
> Do the keepers of the blessed script that sends git commit emails
> know why sometimes commit don't land in varnish-commit?
>
> The only pattern I have identified so far is that we don't get
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/23/2016 09:47 AM, David CARLIER wrote:
>
> ... some people start to install pcre2 over pcre due to pcre's
> security flaws
Is there something to be worried about? I'm looking at the CVEs for
pcre, and it looks to me like there's nothing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/02/2016 08:10 PM, Nils Goroll wrote:
>
> - varnish is running in "do how the backend says" mode - backend
> devs know when to make responses uncacheable
Just so that you know what that's all about, to understand the use case:
We have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello all,
As phk asked for at VDD, here are varnishd params that I know of being
set in production. This is for 4.0.3, so some of them are no longer in
use for 4.1.2 and master.
- -p waiter
- -p vcl_dir
- -p feature (to disable esi xml check)
-
On 15/06/16 10:50, Guillaume Quintard wrote:
>
> On 15/06/16 09:48, Dridi Boukelmoune wrote:
> > varnish-cli could be changed so that experimental params
> > don't show up by default with `param.show -l`, requiring a new flag
> like -x for
> > instance.
>
> People tend to think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/17/2016 01:42 PM, Poul-Henning Kamp wrote:
> Does it make any sense to have two "API" libraries any more ?
Would that mean that all of libvarnish becomes a public API, as VSL
and VSC are now?
If so, you probably can best answer the question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/18/2016 11:26 AM, Arianna Aondio wrote:
>
> it may be useful to know when a backend's health changed. Please
> find attached a patch that expose last_changed in "varnishadm
> backend.list".
Very minor quibble -- "Last updated" might be
On 03/09/2016 06:47 PM, Devon H. O'Dell wrote:
>
> I also worry about using SO as a support mechanism. Apart from the
> concerns that Dridi mentioned, there are other problems with the
> entire SO model of having questions answered.
To be honest, I only see a number of downsides to SO as a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/07/2015 03:33 PM, Martin Blix Grydeland wrote:
>
> The leaves the question if we want to subject our users to a
> default change though...
Unless there is a larger hue and cry among users for a new default, I
don't yet see compelling reasons
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/07/2015 02:30 PM, Rubén Romero wrote:
>
> While on the topic of changing defaults, I think we should include
> Surrogate-Control and ESI parsing in to the builtin VCL as
> discussed yesterday.
>
> This was discussed last year:
>
://uplex.de
From 002e858f3ffe0e7c90e03f92bc30b6b8c1e085cd Mon Sep 17 00:00:00 2001
From: Geoff Simmons <ge...@uplex.de>
Date: Sun, 6 Dec 2015 14:56:18 +0100
Subject: [PATCH] add a remove_backend() method to each of the directors in the
VMOD
---
bin/varnishtest/tests/d0.vtc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/30/2015 10:06 AM, Federico Schwindt wrote:
>
> The problem with your test is that while you're delaying the
> accept(), the connection is not refused (the socket is in listen
> state) so you are actually exercising the read timeout
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/04/2015 11:58 AM, Poul-Henning Kamp wrote:
>
>
> Ok, wrapping this subject up:
>
> Right now PRIV_foo is named with a mix of lifetime and visibility,
> and we seem to need to be able to control both aspects.
>
> The easiest and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/16/2015 10:55 AM, Poul-Henning Kamp wrote:
>
> One of my background-tasks is to put the "hands-off!" items in
> clearly marked #include files.
OK
> It's monday morning. [...]
All good. I can go with what's possible at the moment. Get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/16/2015 12:24 AM, Dridi Boukelmoune wrote:
>
> I believe you're not supposed to use VCL_DelBackend directly, and
> static backends are owned by the VCL. You're not supposed to
> tamper with them.
>
> What is the use case?
It's for a VMOD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/16/2015 10:53 AM, Dridi Boukelmoune wrote:
>
> VRT_delete_backend ?
Sure.
> I don't even know how you would delete the backend without
> breaking the type system. If you reference it from a VMOD you
> should get a const struct director and
Hello all,
The patch and test case in the attachment demonstrate VCL_DelBackend()
crashing on assertion failure, at least when called from a VMOD. It's
failing AN(ptr) on line 288 of common/common_vsm.c, because be->vsc is
NULL (VSM_Free(be->vsc) called by VBE_Event()).
The crash happens when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/03/2015 09:27 AM, Dridi Boukelmoune wrote:
>
> I just realized that a VCL_HasBackend (or VRT) function for VMODs
> to "ensure" uniqueness would be racy by nature.
Yep, classic TOCTOU race. In addition to the fact that, if we do have
it, it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/2/15 7:20 PM, Kacper Wysocki wrote:
>
> Oh. I hadn't seen req.backend.name.
It's beresp.backend.name, not available until vcl_backend_response().
- --
UPLEX Systemoptimierung
Scheffelstraße 32
22301 Hamburg
http://uplex.de/
Mob:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/02/2015 09:03 AM, Poul-Henning Kamp wrote:
>
>> So unless we add a requirement like "you have to call
>> VCL_Something() to 'register' the director/backend", so that
>> VCL_Something() can change the name, I don't think we can use
>> suffixes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/02/2015 09:32 AM, Dridi Boukelmoune wrote:
> Sorry for the frenchism but it's turning into a "dialogue de sourd"
> :(
Dridi, mon ami, ce n`est pas grave. %^)
My impression is that we're all insistently agreeing with each other.
> In the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/02/2015 12:27 PM, Poul-Henning Kamp wrote:
>
> * struct director without a struct backend do not appear in
> CLI/VSM unless the VMOD implements all the stuff for this.
What about a VMOD for backends that don't speak HTTP over TCP? I have
felstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
From 7172c2273d2db45e8cbe02c8ddf5e62f43e8943d Mon Sep 17 00:00:00 2001
From: Geoff Simmons <ge...@uplex.de>
Date: Sun, 1 Nov 2015 12:16:29 +0100
Subject: [PATCH] add VCL_HasBackend()
+49 176 636 90917
Fax +49 40 42949753
http://uplex.de
From 36a70014cbd27599b64f3b42dd0caab29eaa4b55 Mon Sep 17 00:00:00 2001
From: Geoff Simmons <ge...@uplex.de>
Date: Sun, 1 Nov 2015 15:49:39 +0100
Subject: [PATCH] add documentation about backend naming for VMOD authors
---
doc/sphinx/reference/directors.rst | 58 +++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/30/2015 05:19 PM, Kacper Wysocki wrote:
>
> slightly related to this, could we possibly allow accessing the
> name in VCL, like
>
> if(req.backend_hint ~ "zool") { /* do something */ }
If you can wait until vcl_backend_response(), you do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/02/2015 12:42 AM, Poul-Henning Kamp wrote:
>
>>> But that reminds me: What was the consensus on my proposal for
>>> .%d suffix for colliding backend names ?
The previous conversation was just you and me talking, so I don't know
if we could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/27/2015 01:25 PM, Poul-Henning Kamp wrote:
>
> Yes, uniqueness of backend names affect only CLI and VSM.
>
> The former only if people get confused, the latter always because
> the VSM counter segment is named based on the backend name, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/27/2015 03:48 PM, Poul-Henning Kamp wrote:
>
> The varnish-cache.org homepage will be generated from doc/sphinx in
> the repository, that saves us a CMS and a database. If we later
> find out we need something stronger, we can do that.
Two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/26/2015 01:32 PM, Arianna Aondio wrote:
> Hi, as discussed at bugwash today, I'm posting a patch that makes
> private pointers(PRIV_TASK, PRIV_TOP, PRIV_VCL) available in VMODS
> objects. Please refer to trac ticket #1800 for more details.
As
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello all,
I'd like to get back to some questions I asked in IRC earlier today. I
guess I didn't make the problem clear, so let me try to explain why I
think this is critical.
struct director has the fields vcl_name and name, and struct backend
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello all,
Are those two things the same object, by any chance?
That is, when a VMOD has functions or methods with a PRIV_VCL
parameter, and also implements the event function, do the *vmod_priv's
passed into their implementations point to the
Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
From 0dbed187416e2b4bf22f12deb021839f109c6e58 Mon Sep 17 00:00:00 2001
From: Geoff Simmons <ge...@uplex.de>
Date: Mon, 10 Aug 2015 18:40:38 +0200
Subject: [PATCH] for response status 204, like 30
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello all,
At VDD this morning, phk asked for suggestions about includes that
would someday comprise public APIs. Here's what I found from grepping
VMODs and standalone apps that I maintain or work with:
"miniobj.h"
"vas.h"
"vcs_version.h"
"vcl.h"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/01/2015 01:29 PM, Dridi Boukelmoune wrote:
>> Have I understood correctly that vcli.h will now be available to
>> VMODs (at least at init time)?
>
> I don't think we've mentioned this file, I'd say no.
What I had in mind is what has turned
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 8/12/15 5:16 PM, Arianna Aondio wrote:
Hi, as discussed this afternoon on IRC with Federico, here is a
patch for a std_vmod function for converting from real to int.
+VCL_INT __match_proto__(td_std_time2real)
+vmod_real2integer(VRT_CTX,
Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
From 54061934ad87f692ed4a2edc42825bf74b745ecf Mon Sep 17 00:00:00 2001
From: Geoff Simmons ge...@uplex.de
Date: Sun, 24 May 2015 21:34:25 +0200
Subject: [PATCH] std.ip
Hello all,
Currently a VSL tool such as varnishlog crashes with the option -L 0
when the first transaction is read -- AN(vtx) in vsl_dispatch.c, since
the vslq-incomplete list is empty.
Transaction limit 0 doesn't make any sense, so this patch enforces -L 0.
Best,
Geoff
--
** * * UPLEX -
Hello,
vsl.h requires stdint.h but currently doesn't include it, hence the patch.
Best,
Geoff
--
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
diff --git a/include/vapi/vsl.h
Hello all,
I had been using varnishncsa -r for testing in Varnish 3 -- for a tool
whose output should be the same as varnishncsa in the default case --
and I'd like have it back for Varnish 4.
Obviously not widespread use case, but since the patch is a one-liner,
and everything else seems to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/25/2015 11:07 AM, Poul-Henning Kamp wrote:
Right now we have two timeouts:
timeout_idle - close idle connections after this long. [5 sec]
timeout_req - max time to collect req.hdrs (first-last byte) [2
sec].
Maybe we should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
http://dev.otto.de/2015/03/19/varnish-developer-day-15q1-loft-6/
Mostly a high-level overview of what we use Varnish for at Otto.
by Hutzsch
Enjoy
- --
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/10/2015 09:53 PM, Poul-Henning Kamp wrote:
+('beresp.is_304',
I think the name looks ugly-ish, but I can't decide if I think
there is value in explicitly mentioning 304 vs. more clarity in a
more descriptive name
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
commit 468a0472fa313dbff69269afc085957642011abc Author: Nils Goroll
nils.gor...@uplex.de mailto:nils.gor...@uplex.de Date: Tue
Jan 6 22:24:21 2015 +0100
Expose is_hit to VCL as resp.is_hit
A very common idiom in just about every Varnish
.
Best,
Geoff
--
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
From 6b325249809aa8f8a9fc66ba56b19bd2ffe8dc11 Mon Sep 17 00:00:00 2001
From: Geoff Simmons ge...@uplex.de
Date: Mon, 15 Dec
Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
From dc609db7f64e6067be6958aabf32af40c898eaf0 Mon Sep 17 00:00:00 2001
From: Geoff Simmons ge...@uplex.de
Date: Fri, 14 Jun 2013 09:06:21 +0200
Subject: [PATCH 1/1] add a port
Hello all,
The patch in the attachment backports commit 2144dc78, a fix for
mgt_cli.c, to version 3.0.6. The fix catches one of conditions for
calling MGT_Child_Cli_Fail() that had previously been missed. The patch
would have to be applied to the 3.0 branch.
When the CLI between management and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/18/2014 08:58 PM, Federico Schwindt wrote:
I had some time on the plane today so here's a quick stab at
getting Surrogate-Control support as discussed during the vdd.
Disabled by default. Only max-age is supported with this patch.
We had
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 9/1/14 7:01 PM, Nils Goroll wrote:
According to http://tools.ietf.org/html/rfc7230#section-3.2 we
cannot assume some special character not to be contained in a
header token/entity name or value.
Maybe so, but in practice this sort of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/28/2014 08:26 AM, Nils Goroll wrote:
This definitely is the case with fgs' proposed patch,
vcl_backend_fetch still has the final word.
All right, then it really might be bike-shedding to worry too much
about whether it's done in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/06/2014 08:39 AM, Nils Goroll wrote:
Hi Federico,
I must say I don't understand the first part of your email about
the delete keyword and what you intend to express about calling
vmod methods.
Frederico had written:
One of the reasons
Fax +49 40 42949753
http://uplex.de
From 7af9af36f3c10810a821ab71ae4d1096e721 Mon Sep 17 00:00:00 2001
From: Geoff Simmons ge...@uplex.de
Date: Sun, 30 Mar 2014 14:43:16 +0200
Subject: [PATCH 1/1] clarify elements of the public VSL API
---
include/vapi/vsl.h | 37
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/27/2014 03:07 PM, Lasse Karstensen wrote:
I'm going through the documentation, and came over our handling of
bereq.http.Connection: close in vcl_pipe. In the builtin VCL
(previously default.vcl) there is a commented out line that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/23/2013 02:33 PM, Poul-Henning Kamp wrote:
The writev() to the kernel doesn't happen until WRW_FlushRelease(), so
at the very least the timestamp should be taken after that.
OK
But...
The time you measure is only the time to hand the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/15/2013 01:56 PM, Martin Blix Grydeland wrote:
I am missing a Treq field, which is the time it took to send the request
to the backend in the first place. Would be used to search for network
issues (or slow piping of passed client request
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- --
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/01/2013 10:50 AM, Poul-Henning Kamp wrote:
The Makefile for varnishtest is patched so that if you have TMPDIR
defined in the environment before 'make check' is called, then
varnishtest uses that, otherwise it uses /tmp.
Shouldn't we
--
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de
From ed2319af5e6cb8fd1a48c8ca68074fb67f2f0f4f Mon Sep 17 00:00:00 2001
From: Geoff Simmons ge...@uplex.de
Date: Tue, 1 Oct 2013 12:56:45 +0200
:00:00 2001
From: Geoff Simmons ge...@uplex.de
Date: Mon, 30 Sep 2013 20:53:52 +0200
Subject: [PATCH] Option to choose another root tmp-directory in varnishtest make check
---
bin/varnishtest/Makefile.am |3 ++-
bin/varnishtest/vtc_main.c | 11 +--
2 files changed, 11 insertions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/20/2013 02:07 PM, Dridi Boukelmoune wrote:
vcl_request
vcl_bereq
vcl_forward
vcl_transmit
Maybe vcl_prefetch(), since this will be just before a fetch.
Best,
Geoff
- --
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/20/2012 04:26 AM, 苏瑞钦（贝汉） wrote:
varnish-3.0.2 no varnishstat command
why ??
That can happen if you don't have curses installed when you install Varnish.
If you need to install curses/ncurses libraries, then installing Varnish
again
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/ 6/12 10:29 AM, Poul-Henning Kamp wrote:
In message 501ab0a0.30...@schokola.de, Nils Goroll writes:
Thanks for the refactoring, as always, your version of the same
idea is cleaner. :)
Here's a patch for the solaris sandbox, which also
Hello all,
The enclosed patch, for the current 3.0 branch, fixes the build error
for the Solaris port reported in Trac ticket #1167.
Best,
Geoff
$ git show
commit 1f4006e83a3b257c9a604dd40b857d6292608b46
Merge: b50bbd6 b164c06
Author: Dag Haavi Finstad da...@varnish-software.com
Date: Mon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 3/23/12 4:11 PM, s...@crucially.net wrote:
Only if people change the cache-control. Expires could be turned
into a uint64 and safely updated, though expires is generally
frowned upon.
To be sure I understand your argument, are you saying
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1/13/12 2:18 PM, Poul-Henning Kamp wrote:
By default all backend fetches which can find a candidate for it,
will try to IMS against the backend. If you do not want that, you
remove the bereq.http.IMS header in vcl_pass{}/vcl_miss{}
What
The attached patch (by slink) is a one-liner for
waiter/cache_waiter_ports.c, the code was referencing sp-t_open where
it should have been sp-t_idle, which was causing assertion failures on
idle session timeouts.
--
** * * UPLEX - Nils Goroll Systemoptimierung
Schwanenwik 24
22087 Hamburg
Tel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello all,
Yesterday there was a discussion about this subject on the
#varnish-hacking IRC channel, and we decided that a summary should be
sent up to varnish-dev, to ask for feedback. @phk, I hope we can get
your opinions.
For background on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/10/12 04:41 PM, Jocelyn De La Rosa wrote:
First of all thank you Geoff for updating the experimental-ims branch
yesterday!
You're welcome, but I hope the update didn't create a lot conflicts for
you. I didn't want to announce anything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/ 5/11 11:34 AM, Per Buer wrote:
1) grace
The Squid people call this stale-while-revalidate which I think is an
OK name. It tells us a lot more than what grace does.
3) keep
Today, grace is set in vcl_fetch also. I think it would
1 - 100 of 112 matches
Mail list logo
