- 21 May, 2015 17 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Nils Goroll authored
(even if we exec env python, we should check early if we got one)
-
Nils Goroll authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
Instead of trying to steal vbc's away from the waiter, send the request and wait for the waiter to hand the vbc back to us. All waiters but poll still disabled ... coming up next.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
sparse fd-sets efficiently.
-
Poul-Henning Kamp authored
to ensure this order
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
Don't worry, they'll will come back later.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
and the ones which deal with fd's being waited on (Wait_*)
-
Nils Goroll authored
-
- 20 May, 2015 1 commit
-
-
Lasse Karstensen authored
-
- 18 May, 2015 12 commits
-
-
Poul-Henning Kamp authored
timestamps, when the Bereq timestamp is taken after our write(2) to the socket, which may have caused us to loose the CPU.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
webserver" and dispatches a thread for each incomming connection. This is an example use: server s0 { loop 10 { rxreq txresp -body "foo1" } rxreq txresp -hdr "Connection: close" -body "foo1" expect_close } -dispatch Each connection will spawn a dynamically created s%d instance starting with s1, s2 ... Each of these will respond to 11 requests on the accepted connection, the last response will have "Connection: close" and they will expect the other end (varnish) to do that. The main limitation on using this for bulk traffic tests is the finite and limited size of the vtc_log which varnishtest will collect (half a megabyte). Test b00048 is about as much traffic as will fit in the vtc_log.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Nils Goroll authored
Seen on a solaris vintage edition (snv_111b) as SIGSEGV caused by strlen(NULL) in r01036.vtc and r01037.vtc: a z_stream msg can be NULL.
-
https://tools.ietf.org/html/rfc7231#section-6.1Nils Goroll authored
Changes: * 302 Found * 307 Temporary Redirect Do not apply the default ttl, only set a ttl if Cache-Control or Expires are present. Responses with these status codes are not cacheable by default * 414 Request-URI Too Large Cacheable with "heuristic expiration" https://www.varnish-cache.org/patchwork/patch/251/
-
Martin Blix Grydeland authored
-
Martin Blix Grydeland authored
This hopefully makes l00002.vtc less prone to error.
-
Poul-Henning Kamp authored
over the weekend: Just because we have a bo doesn't mean we have a bo->beresp any more, find the C-L header in the req->resp.
-
- 17 May, 2015 8 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
64bit processors.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
We have to restart the server instance when we have writes which might fail.
-
Poul-Henning Kamp authored
-
- 16 May, 2015 2 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
are handled so fast that there may be no numerical difference between the start and end session timestamps. This is a consequence of our decision to use C type double (ieee 64bit FP) for timestamps, at the current distance from POSIX epoch, 1.5 billion seconds, the resolution is 238 nanoseconds.
-