- 27 Nov, 2017 3 commits
-
-
Dag Haavi Finstad authored
This test case should not rely on first_byte_timeout/between_bytes_timeout.
-
Dag Haavi Finstad authored
The second time around, we force a fresh connection. The VCL user may choose to do 'return (retry);' in vcl_backend_error{} if further attempts are deemed warranted. Fixes: #2135
-
Dag Haavi Finstad authored
Passing a nonzero value will force a fresh backend connection.
-
- 14 Nov, 2017 4 commits
-
-
Pål Hermunn Johansen authored
-
Martin Blix Grydeland authored
-
Martin Blix Grydeland authored
-
Martin Blix Grydeland authored
We only want to return the connection early to the waiter when the request is empty. Correct the read timeout calculation to reflect that. Thanks to Stackpath for helping to debug this issue. Fixes: #2492
-
- 06 Nov, 2017 1 commit
-
-
Pål Hermunn Johansen authored
The commit 01fa472647fe431d09f4873f5d0cefe8b9b88919 did not in fact remove the effect of the cli_buffer value, but it did prevent varnish from crashing when setting the parameter very high. This reverts the change in the documentation.
-
- 31 Oct, 2017 3 commits
-
-
Dridi Boukelmoune authored
Fixes #2468
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
This helps write scripts like this: optstring=$(varnishd -x optstring) while getopts $optstring opt do case $opt in n) # handle $OPTARG ;; # handle other options *) # ignore unneeded options ;; esac done varnishd "$@" Otherwise if optstring is not kept in sync, getopts will stop processing options if it encounters one that is not specified.
-
- 28 Sep, 2017 1 commit
-
-
Pål Hermunn Johansen authored
-
- 27 Sep, 2017 1 commit
-
-
Pål Hermunn Johansen authored
-
- 26 Sep, 2017 2 commits
-
-
Federico G. Schwindt authored
-
Simon Vikstrom authored
-
- 25 Sep, 2017 1 commit
-
-
Pål Hermunn Johansen authored
If the cli buffer is allocated on the stack, the mgt process will crash hard for big values of this parameter. Instead we allocate on the heap. The new cli buffer an "auto" VSB. This means that the varnish parameter cli_buffer is ignored from now on, and the manual marks it as deprecated. Closes: #2382 Conflicts: bin/varnishd/mgt/mgt_cli.c
-
- 20 Sep, 2017 3 commits
-
-
Nils Goroll authored
This is a back port to 4.1, and the conflicts are partly a result of the non inclusion of 656982a5 in 4.1. (Back port by Pål Hermunn Johansen, hermunn@varnish-software.com) Conflicts: bin/varnishd/cache/cache_pool.c bin/varnishd/cache/cache_wrk.c
-
Nils Goroll authored
Having a stack on the heap just feels unclean, also this way we have a chance to get a red zone adjacent to the mapping just in case we manage to overflow the alt stack also. Ref: #2396
-
Nils Goroll authored
Ref: #2396
-
- 19 Sep, 2017 6 commits
-
-
Martin Blix Grydeland authored
The locking around the use of vcl_active does not include the checking of its magic value or the temperature asserts, leading to a race when changing vcl_active. Fixes: #2390
-
Mark Felder authored
-
Nils Goroll authored
Previously, we could run out of stack handling stack overflows, leaving users with unspecific SIGSEGV crashes and no panic message. By providing a single alternative stack exclusively for SIGSEGV handling where sigaltstack() is available, we increase chances for our signal handler to finish successfully. In particular, this will make it easier to diagnose stack overflows by comparing the failing address with the stack info from the panic output. This could be further improved by giving advise to increase thread_pool_stack if si_addr is near the stack boundaries. c00057.vtc now triggers a stack overflow instead of raising a SIGSEGV. Merges #2396
-
Nils Goroll authored
it was already used for more than SIGSEGV, so we should output the actual signal description. Conflicts: bin/varnishd/mgt/mgt_child.c
-
Nils Goroll authored
The previous code allowed the compiler to re-read nxt from rr->nxt which could have been incremented cocurrently. Fixes #2378
-
Martin Blix Grydeland authored
The file stevedore may return a buffer larger than asked for when requesting storage. Due to lack of check for this condition, the code to copy the synthetic error memory buffer from vcl_error would overrun the buffer. Patch by @shamger Fixes: #2429
-
- 11 Sep, 2017 2 commits
-
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
The goal of `req.ttl` is to allow lower requirements for known transactions (since this has to be done in VCL) but objects with an age higher than `req.ttl` would always be considered expired during lookup even if their actual TTL (obj.ttl) is still positive. Ignoring `req.ttl` gives a better control over explicit refreshes made to optimize latency and greatly reduces the risk of running into #1799 (for a subset of use cases). Refs #2422
-
- 05 Sep, 2017 3 commits
-
-
Pål Hermunn Johansen authored
My previous patch did not update the manual and the usage message for varnishtest concerning the default internal buffer size.
-
Pål Hermunn Johansen authored
Since SunOS needs a litt bit more workspace_thread, this test case needs to be updated. The default buffer size for vtc (configurable with -b) had to be increased. Conflicts: bin/varnishtest/vtc_main.c
-
Pål Hermunn Johansen authored
When the do..while loop in HSH_Purge executes on a oh with many popular variants, there is a potential problem with the "array" of oc pointers, allocated in the thread workspace. If many of the oc's have positive refcounts, they will fill up the array and EXP_Rearm(oc, now, ttl, grace, keep); (void)HSH_DerefObjCore(wrk, &oc, 0); will be called several on the same oc's. At the same time, the counter n_obj_purged will be updated with a too low number. The test case demonstrates how we get a too low value for this counter, but it is not able to force varnishd to use a siginificant amount of CPU. Conflicts: include/tbl/oc_flags.h bin/varnishd/cache/cache_hash.c bin/varnishd/cache/cache.h
-
- 22 Aug, 2017 1 commit
-
-
Nils Goroll authored
The use case are cluster requests: Intra-cluster bgfetches should trigger a synchronous fetch on the peer-varnish in order to avoid additional short-lived / expired objects being created. Or, in other words, a bgfetch should actually get a fresh object and not one in grace from another cache. Merges #2376 This is a back port of d7f8b531. Conflicts: bin/varnishd/cache/cache_fetch.c doc/changes.rst include/tbl/bo_flags.h
-
- 08 Aug, 2017 3 commits
-
-
Federico G. Schwindt authored
Fixes #2380.
-
Geoff Simmons authored
Closes: #2357
-
Federico G. Schwindt authored
Related to #2337 and #2366.
-
- 07 Aug, 2017 1 commit
-
-
Federico G. Schwindt authored
From Emmanuel Hocdet (manu-at-gandi-dot-net) via #2373.
-
- 01 Aug, 2017 3 commits
-
-
Pål Hermunn Johansen authored
-
Pål Hermunn Johansen authored
-
Martin Blix Grydeland authored
This fixes a denial of service attack vector where bogusly large chunk sizes in requests could be used to force restarts of the Varnish server. This is Varnish Security Vulnerability VSV00001 For more information visit: https://varnish-cache.org/security/VSV00001 Fixes: #2379
-
- 14 Jul, 2017 1 commit
-
-
Dridi Boukelmoune authored
-
- 28 Jun, 2017 1 commit
-
-
Pål Hermunn Johansen authored
-