Hi,
over the last couple of months I've opened some tickets with suggested
fixes/improvements which haven't caught attention (yet).
I there anything more I could do to help or should I rather just remain quiet
and patient, which I will happily do?
Thanks, Nils
Hi Poul-Henning,
over the last couple of months I've opened some tickets with suggested
fixes/improvements which haven't caught attention (yet).
Solaris is sort of a tier-2 platform for us right now, partly because
we lack solaris machines and mostly because we lack time.
That's alright -
Hi,
I am referring to Paul-Henning's closing comment in
http://varnish-cache.org/ticket/701 :
We already have a length check on the total request: half the workspace. That
should probably become a parameter.
Currently, this is enforced by HTC_Rx checking the available space on the ws
with
Hi,
I need a new feature to always send backend get-if-modified-since requests if
the respective object already exists in the cache and update TTL, Expires etc.
Has anyone already looked into this?
If not, I will implement this feature.
Nils
___
Hi phk,
first of all, thank you for taking the time to respond. I agree with what you
wrote about the basic logic.
I could elaborate on some of the details you mentioned, but that would mostly
repeat what I've already posted.
What it really boils down to, IMHO, is that it can be done both ways.
r5452 breaks compilation for systems which don't have pthread_timedjoin_np().
This patch brings back the old code for such systems with one modification:
pthread_join() is only called if pthread_cancel() does not return an error.
Also, it changes exec_file_thread to exit with pthread_exit rather
Any feedback on this?
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
http://lists.varnish-cache.org/mailman/listinfo/varnish-dev
Hi Tollef and all,
apologies that this test was still contained in the patch. I had discussed this
with phk a long time ago already and we had agreed that it is unnecessary due to
the test phk had added:
http://www.varnish-cache.org/trac/changeset/4569
Thank you, Nils
As of r5507, phk has added a new implementation for systems without
pthread_timedjoin_np. Here's a one-liner to make it actually kill the test
thread upon timeout
Index: bin/varnishtest/vtc.c
===
--- bin/varnishtest/vtc.c
Hi,
I've written a patch for something which has annoyed me for long:
It's nice to have a really long grace period, such that even when all backend
servers go down, Varnish can keep most of a website up.
But setting a (really) long grace period (to catch most of the long tail) will
mean that
The attached patch will add read-only access to these new variables which
indicate if the backend response or object originated from a pass request.
See vcl.rst for more details.
Index: varnish-cache/doc/sphinx/reference/vcl.rst
===
Hi phk,
Find valid in-grace object - vcl_miss (with obj.*)
Find nothing usable - vcl_miss (without obj.*)
Now that we (finally) got to the point to actually implement this part of the
backend conditionals, the following question pops up: As obj.* may
$) {
./varnish-cache/doc/sphinx/reference/vcl.rst:} elsif (req.http.host ~
^images.example.com$) {
./varnish-cache/doc/sphinx/reference/varnishd.rst:req.http.host ~
^(www\.)example.com$ obj.set-cookie ~ USERID=1663
--
** * * UPLEX - Nils Goroll Systemoptimierung
Schwanenwik 24
22087 Hamburg
tel
It is not that it is not useful, it's just not the right way to fix it.
Shouldn't we normalize the host header anyway to maximize cache hit rates?
Nils
--
** * * UPLEX - Nils Goroll Systemoptimierung
Schwanenwik 24
22087 Hamburg
tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753
anyone on this list know IDN details well enough to confirm or
correct?
Under the assumption that my understanding is correct, I think we could have a
VMOD for IDN conversion, but the Host header should under no circumstances get
converted to unicode.
Nils
--
** * * UPLEX - Nils Goroll
On 02/18/11 01:32 PM, Tollef Fog Heen wrote:
| Shouldn't we normalize the host header anyway to maximize cache hit rates ?
| Relevant question in this context: Do we know how to ?
Normalise usually means rewriting from a list of various legal names to
the canonical name, so in the general
Hi,
- The keep interval now begins after ttl and grace have elapsed, so an
object is available for conditional requests after obj.ttl + obj.grace,
and is scheduled for eviction after obj.ttl + obj.grace + obj.keep. (In
previous versions of the patch, the keep interval began after ttl
728badd871b42342107bc6d8e7219b7a9f12241f Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Fri, 11 Mar 2011 17:36:54 +0100
Subject: [PATCH] Solaris: Test for SO_{RCV,SND}TIMEO needs NET_LIBS
---
configure.ac | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff
Hi phk,
can we come to a conclusion of this discussion?
My two cent:
- where the host header does not undergo site-specific normalization, case
folding it will once
- avoid multiplication of cache content for case variations of the host
header
- avoid case-insensitive matching (so
Hi Laurence and all,
sorry for the _very_ late response, I've been highly customer-demand driven and
(and chased by deadlines) during the last months, so much work I started on
Varnish stayed unfinished. The good news is that customers now demand more
Varnish work again, so I hope to return to
From f79b643dd4d6858a3bca4f4b1e0e0e8953409022 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Tue, 11 Oct 2011 21:14:28 +0200
Subject: [PATCH] synchronize ccf_listen_address() on hack_ready
Partly fixes #865
This fixes a race condition between the cli thread
From 2f2a7ad5844d735c7a459a5800a7d813c9a0a880 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Wed, 12 Oct 2011 20:15:54 +0200
Subject: [PATCH] Error handling for VTCP_blocking in CNT_Session
On systems which return errors for ioctl, close early in
STP_FIRST/STP_START
(hm, or should we rather have specific VTCP_Asserts ?)
From 88384aefdbfefbdd7f899a499211b8b260ad0ed0 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Thu, 13 Oct 2011 14:53:28 +0200
Subject: [PATCH] With SO_(RCV|SND)TIMEDOUT, we also see ETIMEO for ioctl()
---
include
Please review and comment on a first attempt to write down recommendations on
how to contribute to Varnish (based on a VUG5 dev day discussion):
https://www.varnish-cache.org/trac/wiki/Contributing
Thanks, Nils
___
varnish-dev mailing list
Hi Doc and All,
unfortunately, I don't have time for a closer look at this atm, but I'd like to
point out that I had posted a patch following an alternative approach in
2010-11:
https://www.varnish-cache.org/lists/pipermail/varnish-dev/2010-November/006600.html
At the time, the idea was to
for the solaris sandbox, which also fixes a nit in mgt_sandbox.c
Thanks, Nils
From 9438e59d8b87d0b5291e6fba6b3cb2d60dcb1f37 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Thu, 2 Aug 2012 17:38:13 +0200
Subject: [PATCH] since vcc/cc are running with privilege seperation now, they
also
Hi phk,
testing the new sandbox code I noticed that the tmpdir should be owned by
mgt_param.uid, otherwise unlinking the compiled .so will fail when
setuid(mgt_param.uid) succeeds.
Nils
On 08/ 2/12 06:53 PM, Nils Goroll wrote:
Hi Phk,
I have committed part 1, and generalized the idea
On 10/30/12 11:08 AM, Poul-Henning Kamp wrote:
I think that is a good idea. Warnings tend to become it always says that...
:) Here we go.
From 7a78a77d889b1a1c488c14ce836b33236d956601 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Mon, 29 Oct 2012 18:15:52 +0100
On 11/ 6/12 12:21 PM, gaurav singh wrote:
As i am new to Varnish cache, i would like to know the resources which can
help me start contributing to it.
Two starting points:
* https://www.varnish-cache.org/trac/wiki/DeveloperResources
* https://www.varnish-cache.org/trac/wiki/Contributing
Nils
2001
From: Nils Goroll nils.gor...@uplex.de
Date: Wed, 9 Jan 2013 19:32:04 +0100
Subject: [PATCH] portable cast from thread_id to (void *)
Fixes #932
---
bin/varnishreplay/varnishreplay.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/bin/varnishreplay/varnishreplay.c
Reduce warning noise from autoconf
Make automake happy
Pull in current ld-version-script.m4 which fixes the issue documented here:
https://lists.gnu.org/archive/html/bug-gnulib/2010-08/msg00198.html
From c24a91405479e7e5bd2633173cf5a24eabbd75fc Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor
parallel builds (make -jX) failed sporadically for the first compilation
(before dependency tracking information was available) due to the race
with python building vcc_if.h
From 8e2751a28b7cb6331b386fbf6e1a7b1bdeafb4b7 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Wed, 9
On 01/ 9/13 05:38 PM, Rangel, Raul wrote:
The reason I don't like the idea of making it protocol specific is that then I
have to add all that logic to each vcl_XXX_req method
IIUC in the SPDY case req.proto would refer to the SPDYfied HTTP version and not
to SPDY itself.
If you want to
On 01/ 9/13 11:17 AM, Poul-Henning Kamp wrote:
One possible consistent view is that _everything_ which might smell
the least of policy, should be in VCL. The obvious downside is
that VCL becomes quite complicated.
I strongly believe that this is the right way to go, otherwise we won't get
On 02/ 6/13 04:21 PM, Poul-Henning Kamp wrote:
I should warn you, that one very likely outcome of this, is that
_all_ directors gets expelled into VMODs in Varnish4.
YEAH! I love this kind of warning :)
phk, this sounds like a _very_ powerful approach with the potential to pave the
path
Based on what we discussed on Monday, I have tried to make up my mind about how
the VCL interface for proper gzip/gunzip handling with respect to ETags and Vary
could look like.
reviews welcome for https://www.varnish-cache.org/trac/wiki/ETags
Nils
FYI:
* http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/89110
- looks like https://www.varnish-cache.org/trac/ticket/927 at first sight
* http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/89115
- another one with ridiculously high Content-Length
these ones are
Hi,
after double checking with bz, we now have a date with just one Ifneedbe and
no real No, so I've fixed the date to September 6th:
https://www.varnish-cache.org/trac/wiki/VDD13Q3
Please confirm your participation on the wiki page.
If anyone needs assistance finding accommodation, please
Hi phk,
I am working on the patch for the expire superseded objects feature which I had
been asked to send. In preparation for this, I am looking at recent changes.
68a424092d589932c782c9514d340f1752f094a5 introduces HSH_Private and private_oh
for private objects, which before simply had a
On 09/13/13 09:43 AM, Poul-Henning Kamp wrote:
We instantiate an expiry-thread per thread-pool.
This sounds like an interesting idea and I hope to get around to devouring it in
detail.
For the time being: This does not change the fact that the exp thread will still
need to lock the
First a side note on the private_oh: Couldn't the code handle a second magic
private_oh which demands don't queue here and is always empty? This way we
would only need to take on the additional sync overhead when needed (for
debugging). (side note on the side note: why is this worrying me so
On 09/19/13 03:24 PM, Leif Johansson wrote:
Are there any significant limits in varnish that makes it hard to
keep dozens or even 100s of backends
No, just keep an eye on your file descriptor limit.
assuming they don't serve
up huge amounts of cacheable data each?
I don't see how
now with attachment
On 11/ 4/13 06:46 PM, Nils Goroll wrote:
can we come back to this one ?
Only casting to (void *) gives a
warning: cast to pointer from integer of different size
and I like -Wall
Thanks, Nils
From dd833610ddbf01c007163c9444f8c24e1a1f22fe Mon Sep 17 00:00:00 2001
From
Hi,
d9492da540430103b9dcd6844eb59b508c061d66 effectively breaks builds with gcc 3.4.
Should we make a statement regarding minimum supported compiler versions?
Nils
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
On 01/ 9/14 04:57 PM, Poul-Henning Kamp wrote:
Can you find out which particular option it is ?
I had already started work on a fix, so now that I know your intention I will
finish it.
Nils
___
varnish-dev mailing list
/ gcc 4.3.3
Nils
From bde10016e2a7543181f3a8534cbe13c94904d9b6 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Thu, 9 Jan 2014 19:03:12 +0100
Subject: [PATCH] fix build with --enable-developer-warnings and gcc3.4 gcc
4.3.3 on Solaris (and others maybe)
MIME-Version: 1.0
Hi Federico,
On 01/20/14 12:13 PM, Federico Schwindt wrote:
I was looking at your diff I don't understand the
-Wno-missing-field-initializers vs -Wno-extra. If the compiler doesn't support
the former why add the -Wno-extra instead of just not adding -Wno-missing... ?
Hm, your question seems
Thanks again to Guillaume and all of Arkena / SmartJOG for sponsoring a fun and
productive VDD!
I have moved everything from yesterday's etherpad over to the wiki and hope to
have left https://www.varnish-cache.org/trac/wiki/VDD14Q1 in a usable state now.
@phk: I have tried to make your life a
:29) Mithrandir / thfeen: well, we require pcre, readline and rst2man to
build.. I don't think ncurses is excessive.
From c1909c0fb4f245d0f2c95b8d65b66937398c2347 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Wed, 19 Mar 2014 20:10:46 +0100
Subject: [PATCH] create a hard
Working on
https://www.varnish-cache.org/trac/changeset/5321145882f6edd65bbeae24a7ff23cc6985f57e/
I noticed that the same inconsistencies exist for the docs - authored vs.
generated:
When srcdir != builddir, paths to generated rsts are wrong, so building in a
separate builddir does not work,
The automake authors are planning to activate subdir-objects unconditionally:
http://lists.gnu.org/archive/html/automake/2013-06/msg00040.html
- The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option. In order to smooth out the transition,
we
A note on an irc chat with phk: The issue can be avoided by not re-opening the
socket in vtc_server (that often).
At this point it remains unclear to me why Solaris returns EADDRINUSE sometimes.
The suggestion to use SO_REUSEPORT was of more general nature, as I stumbled
over it.
Another side
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.
On 06/05/14 03:43, Federico Schwindt wrote:
Currently this is done manually using ctx-req-sp-fd as an index to a
malloc'd
list. The
Trying to understand if I race a saw in 2.0.x still exists in master, I reviewed
some of the cash_hash.c and hash_*.c code.
The issue I feared could exist seems not to, but I believe I spottet a little
nit:
* HSH_DeleteObjHead is only called if hash_deref(oh) returned 0
- hcb_deref always
On 06/05/14 15:16, Nils Goroll wrote:
* HSH_DeleteObjHead is only called if hash_deref(oh) returned 0
- hcb_deref always returns 1, so for hcb we never call
my fault: hcb_cleaner calls HSH_DeleteObjHead, so this is correct.
Thanks to Martin for the explanation on irc.
Nils
On 02/06/14 15:04, Louis-Philippe Gauthier wrote:
In the graph bellow you can see that the memory kept growing even after the
malloc memory (12G) was full. I understand that there's a 1K overhead per
object
and that Varnish will use more then 12G, but it keeps growing even after the
I've just stumbled over this code in vtc_log.c:vtc_log()
if (lvl 0)
return;
if (lvl == 0)
vtc_error = 1;
if (pthread_self() != vtc_thread)
pthread_exit(NULL);
Opinions on adding an option to varnishtest to always abort()
for the case pbo =
oc-busyobj
PATCH 4/4 addresses races I have observed with objcore-busyobj bering set to
NULL while being accessed
Reviews appreciated
Thanks, Nils
From 583eb09cfbe174542d049e071f1a39237084c9f4 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Thu, 19 Jun 2014
On 26/06/14 12:17, Martin Blix Grydeland wrote:
I believe a strict exit from the VCL method before the next statement on an
error condition would be preferable to the no-ops.
my personal preference is to go even further than that.
We have got several use cases in production where we really
2001
From: Nils Goroll nils.gor...@uplex.de
Date: Thu, 10 Jul 2014 16:43:28 +0200
Subject: [PATCH] allow return(synth(...)) in vcl_deliver
This is possible now because synth responses do not go through deliver any more,
as error responses used to.
This concludes the fix for #1027 - the actual work
needed for the next patch
From ce9d7364b04f5ac4d65443b9d3ad319239179cc9 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Mon, 21 Jul 2014 13:20:59 +0200
Subject: [PATCH 2/3] add VCL_MET_MASK_CLIENT and VCL_MET_MASK_BACKEND
---
lib/libvcc/generate.py | 2 ++
1 file changed, 2
I thought we probably won't want to bump the major version, so I kept rollback
as a wrapper for rollback_req
Fixes #1512
From 8e9c19d716777853a8b5cca8d553e7b5bfec48b4 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Mon, 21 Jul 2014 14:30:00 +0200
Subject: [PATCH 3/3] Do
are there any plans for VRT_CacheReqBody ? move into std or the like?
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
Salut Guillaume,
I am going through patchwork and noticed
https://www.varnish-cache.org/patchwork/patch/138/ still being in status 'New'.
As this has not got marged, what would be an appropriate state for it?
Nils
___
varnish-dev mailing list
After an embarrassingly failing initial attempt, here's a patch to (hopefully)
fix #1555 and other build issues regarding libedit vs. libreadline.
@fgs: As discussed on irc, would be cool if you could check this on the build
farm
@all: would appreciate more test on different configs, especially
/varnish-dev
From 51cca2159306f0f7e2611e82d4ed157ee6dd8fe0 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Tue, 5 Aug 2014 17:42:01 +0200
Subject: [PATCH] Rework autocrap configuration for libedit/libreadline
As before, libedit is preferred over libreadline.
Fail configure
Thank you for the patch.
We have discussed it on irc and as we'd like to be able to have a size
argument (to be able to specify std.cache_req_body(50m);), phk will add an
approriate type to the vmod compiler and integrate your patch.
On 30/07/14 17:00, Meng Zhang wrote:
Just created one,
Hi,
I have started writing up a suggestion following an irc discussion about
Federicos patch. I wanted to suggest to also add stale-if-error (s-i-e) support
but really I don't see a way at the moment to achieve this without added
functionality in vcl - am I missing something?
For s-i-e, I think
Federico,
after our irc discussion, I could not come up with a more precise suggestion on
how to implement s-i-e due to the problems I have just posted in restarting for
bad synchronous responses, so unless there is or will be a way to achieve a
restart (not a retry) for the error response case,
does not change.
Nils
- --
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753
xmpp://sl...@jabber.ccc.de/
http://uplex.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlPpPjYACgkQYhlPtokm
From 45f390725a76e02d3bc4103bfa5dd715e51c3114 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Tue, 12 Aug 2014 13:04:03 +0200
Subject: [PATCH] Quote our etags used in tests.
Though it is quite common to see unquoted Etags, according to rfc2616
the entity-tag itself should
As discussed on IRC: I do very much appreciate that you've but this back onto
the agenda, this is important and Varnish needs to get the default Vary right.
But I think this needs to live in fetch (before calling v_b_r): The Vary header
does not depend upon the request, so it does not need to
On 26/08/14 12:46, Nils Goroll wrote:
But I think this needs to live in fetch (before calling v_b_r)
After further discussion, it became clear that vfp_gzip_init or at least some
code in cache_gzip.c could be an even better place.
___
varnish-dev
On 28/08/14 08:35, Geoff Simmons wrote:
When we find ourselves saying users should really understand and
documentation should make it clear, we have unmistakable indicators
of strong potential for confusion. %^)
Then my suggestion must be really bad.
What's yours?
At least Per and myself
On 27/08/14 23:34, Geoff Simmons wrote:
I think I'm unsure about what we're striving for in Varnish 4 --
wasn't the goal to move as much caching policy as possible out to VCL,
with good defaults in builtin.vcl?
I see a bit of a tendency that we are moving towards having C code provide
On 28/08/14 08:57, Poul-Henning Kamp wrote:
Btw, mildly related to this: Long time ago we talked about being able
to work on sub-parts of http headers:
if (INT(beresp.http.cache-control.max-age, 0) 1200) {
set beresp.http.cache-contro.max-age = 1200;
}
We may
For anyone not following the commit msgs: phk has just fixed this in
f2caddcff6d2018604b2ab83ec9bf0e12ec4d51a
On 26/08/14 19:59, Nils Goroll wrote:
What might be even more confusing is the fact that reading the ttl a second
later in vcl_hit will give 59 (seconds remaining in cache).
If Age
On 28/08/14 11:03, Martin Blix Grydeland wrote:
Having a nanny thread for this part is in my opinion too much complexity for
little gain.
I should have mentioned this in my first reply:
The main benefit I'd see is that currently closing BE conns depends on backend
requests being issued, so
On 28/08/14 08:57, Poul-Henning Kamp wrote:
Btw, mildly related to this: Long time ago we talked about being able
to work on sub-parts of http headers:
if (INT(beresp.http.cache-control.max-age, 0) 1200) {
set beresp.http.cache-contro.max-age = 1200;
}
We may
Hi,
on the weekend I have actually stumbled over the same cause that bug #1576 has
(but unfortunately have not immediately realized the connection) and have
changed our dcs_classifier vmod (which needs some reasonably large scratch
memory in the order of ~64k) to use the client workspace rather
On 02/09/14 19:56, Federico Schwindt wrote:
Only problem is that it's a build option.
Yes. But I don't see this as a disadvantage. I think we need to make a decision.
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
On 02/09/14 20:06, Federico Schwindt wrote:
What you mean not a disadvantage? Are you by any means suggesting to bundle
pcre
with Varnish?
If it saved considerable amounts of per-thread memory then I'd consider the
option.
Or, alternatively, realize that we need a larg-ish stack anyway and
On 02/09/14 21:24, Nils Goroll wrote:
Or, alternatively, realize that we need a larg-ish stack anyway
For all those who have not yet read pcrestack(3):
As a very rough rule of thumb, you should reckon on about 500 bytes per
recursion. Thus, if you want to limit your stack usage
On 02/09/14 21:50, Nils Goroll wrote:
On 02/09/14 21:45, Poul-Henning Kamp wrote:
What we really need is for pcre to tell us an estimate of how much
stack-space is needed during compilation
Is this possible? My understanding is that the recursion depth depends on the
data and thus all we
I don't think you're considering all the implications.
let me pull this straight: No, I did not mean to say we should pull in pcre. I
only wanted to start a discussion about what is the best option, I have not
thought through all implications. Again, I am not a pcre expert.
I did mean to say
Hi,
I had started https://www.varnish-cache.org/trac/wiki/Merge4.0 and fgs has made
some additions since. But seeing Martin pushing useful fixes to 4.0, I wonder if
we should rather all try to commit required fixes to 4.0.
Lasse, what's your preference?
Nils
Status on this from https://www.varnish-cache.org/trac/wiki/VDD14Q3 :
We might want to write or at least prototype a vmod for it, but nothing is
pushing me personally to do this with high priority.
The main motivation for my proposal was that we probably need more token/entity
editing in core
With this change, http_RemoveHdrToken also removes any values of an element
token seperated by equals (like foo=bar)
phk, does this work for you?
Thanks, Nils
From ed60be21f4a4af6bb69d05c810aa2adf5c4ecbd5 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Wed, 17 Sep 2014 18
reviewed and tested, looks good to me.
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
The reason for this is that regex match doesn't work on dynamic strings.
https://code.uplex.de/uplex-varnish/libvmod-re
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
df09f64cbc2e082fb94831a47cb416ba6711f575 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Sun, 28 Sep 2014 19:19:34 +0200
Subject: [PATCH] prototype - header element parsing
---
bin/varnishd/cache/cache.h | 24 +++
bin/varnishd/cache/cache_http.c | 310
test for the remove header
token example.
I'd very much appreciate feedback on this.
Nils
From f22f65fb8f00a322d798085df4c4a3647e9dd229 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Sun, 28 Sep 2014 20:18:40 +0200
Subject: [PATCH] prototype - header element parsing
Writing to bereq.uncacheable in backend_response and backend_error would only
make sense in the context of a retry. In most real world cases, writing to
be*resp*.uncacheable would be intended in backend_response and backend_error.
---
lib/libvcc/generate.py | 2 +-
1 file changed, 1 insertion(+),
isn't the point of bereq.uncacheable to get a late pass?
On 05/11/14 14:23, Federico Schwindt wrote:
I've been spending time writing tests for some other work I'm doing and I
found
bereq.uncacheable being writable, which doesn't make much sense to me.
We should revisit this later to check if we don't close the backend connection
unnecessarily.
In vbe_dir_finish() via VDI_Finish() we close the backend connection for
bo-doclose != SC_NULL
For a retry, we force a close via SC_RESP_CLOSE if bo-director_state !=
DIR_S_NULL
Can we rely on the
(supersedes Finish the director...)
- close the backend connection if required
- finish the director
- reset bo attributes
- reset VFPs
- signal bo readers that we had a failure if required
Fixes #1638
Fixes #1641
From a222f13fc1977f19effe52086ca2bc30dfa2dbd1 Mon Sep 17 00:00:00 2001
From: Nils
with heuristic expiration
From 19b8290645ef64da7fce02a425b14b9d892160c6 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Thu, 18 Dec 2014 10:57:28 +0100
Subject: [PATCH] Improve application of the default ttl by response status
code
Ref: https://tools.ietf.org/html/rfc7231
From d1701c99b24e2455c44566c29fe7d5a01140df64 Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Thu, 18 Dec 2014 13:18:55 +0100
Subject: [PATCH] expose response 304 status to VCL
---
bin/varnishd/cache/cache_fetch.c | 3 ++-
bin/varnishd/cache/cache_http.c
Our interpretation of http://tools.ietf.org/html/rfc7234#section-4.1 is that
removing all whitespace from a header field only containing whitespace
equals to removing the header.
From 76eccf170a73fe22ea1990566f8f387921aef18e Mon Sep 17 00:00:00 2001
From: Nils Goroll nils.gor...@uplex.de
Date: Sat
irc:
On 27/12/14 19:33, Nils Goroll wrote:
Our interpretation of http://tools.ietf.org/html/rfc7234#section-4.1 is that
removing all whitespace from a header field only containing whitespace
equals to removing the header.
___
varnish-dev
1 - 100 of 240 matches
Mail list logo
