git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4307 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4306 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4305 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4304 d4fa192b-c00b-0410-8231-f00ffab90ce4

r4184:
An explanatory comment.

r4185:
Add a ".initial" property to backend probe specifications.

This is the number of good probes we pretend to have already seen when
we start up, in order to speed up getting healthy backends.

The default value is one less than the .threshold, so the backend
will be set healthy if it manages to respond correctly to the very 
first probe we send to it.

(A bit of this commit leaked in during r4184)


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4303 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4302 d4fa192b-c00b-0410-8231-f00ffab90ce4

Add a complementary vsb_unquote() function.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4301 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4300 d4fa192b-c00b-0410-8231-f00ffab90ce4

varnishtop used to have a hard-coded max record length of 255 bytes.
This broke with the change that allows larger record length.  Use a
dynamic buffer instead.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4299 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4298 d4fa192b-c00b-0410-8231-f00ffab90ce4

AIX has a "struct thread" in pthread.h, which conflicts with our
struct thread.  Rename ours to replay_thread.

Fixes #531

Thanks to demik for patch


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4297 d4fa192b-c00b-0410-8231-f00ffab90ce4

AIX doesn't have WCOREDUMP, so compilation failed there.  Add #ifdef.

Partially addresses #531.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4296 d4fa192b-c00b-0410-8231-f00ffab90ce4

When hitting 304, ETag, Content-Location, Expires, Cache-control and
Vary should all be sent to the client.

See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
for some more details

Thanks to Rogério Schneider for the patch.

Fixes #529



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4295 d4fa192b-c00b-0410-8231-f00ffab90ce4

Add if-none-match support to allow people with compliant browsers to
save a decent chunk of bandwidth


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4294 d4fa192b-c00b-0410-8231-f00ffab90ce4

Previously, we did not print out the tag in -1 mode, just the value.
This has been changed so we now print both.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4293 d4fa192b-c00b-0410-8231-f00ffab90ce4

-1 mode in varnishtop was broken with the variable length shmlog
fields.  Fix this.

Fixes #514



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4292 d4fa192b-c00b-0410-8231-f00ffab90ce4

If we fail to start the child, set it to state stopping to prevent
auto_restart from looping over what is almost guaranteed to be a
problem it cannot solve.


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4291 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4290 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4289 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4288 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4287 d4fa192b-c00b-0410-8231-f00ffab90ce4

Hopefully make it slightly more obvious we are just the provider of
the caching software in the default vcl_error.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4286 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4285 d4fa192b-c00b-0410-8231-f00ffab90ce4

Kindly submitted by Rogério Schneider.

Fixes: #492



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4284 d4fa192b-c00b-0410-8231-f00ffab90ce4

Change the session handling logic, so that we hand any session back to
the herder, if the session_linger timer fires.

This means that a new session, will get a worker thread, but if
nothing happens within session_linger, it disembarks and lets the
herder handle the assembly of the request.

This actually simplifies the state engine, because the "again" state
(now renamed "wait) can also be used both for the first request.


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4283 d4fa192b-c00b-0410-8231-f00ffab90ce4

Merge r4073: Be much more consistent about snapshotting session workspace when doing an esi-include.

This should reduce the pressure on session workspace from nested
ESI includes considerably.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4282 d4fa192b-c00b-0410-8231-f00ffab90ce4

Instead of the acceptor thread doing it when reusing the session, have
the worker threads clean it out before putting it on the free list.

It could be, and probably was, argued that this is a performance
pessimization, but having thought much about it, I can't spot the
argument any longer, and certainly moving load off the acceptor thread
to the massively parallel worker threads is a good idea.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4281 d4fa192b-c00b-0410-8231-f00ffab90ce4

r4068:
There is probably a bug if an ESI subrequest turns ESI delivery back
on -- add reminder so I can circle back and extend the test for it

r4077:
It turns out that you could turn off ESI processing for subrequest and
completely hose the response. Ignore the flag if you are in a
subrequest.

r4081:
I am stupid, missing '/'



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4280 d4fa192b-c00b-0410-8231-f00ffab90ce4

Put an upper limit on how many sessions we will allocate before we
just drop new connections summarily.

The parameter is session_max, default is 100k and the stats variable
client_drop counts how many sessions were dropped.

This is mostly an anti-DoS measure and your feedback and experience
with it is most welcome.


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4260 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fix an inconsequential oversight in session management, and prevent it
from happening again:

We optimize session allocation, SES_New(), to minimize the amount of
locking the VCA_thread participates in with flip-flop lists of free
sessions: Allocate from one list, free to the other, flip lists only
when necessary.

This scheme only works if nobody but VCA_thread calls SES_New().

Background worker threads need dummy sessions and thus called into
SES_New() as well.

These calls all happen during startup, so they do in fact not mess up
the locking, but made mockery of a number of very stern comments.

Add SES_Alloc() for such "other uses" and enforce VCA_thread monopoly
with an assert.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4259 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4258 d4fa192b-c00b-0410-8231-f00ffab90ce4

Add a miniature facility for starting a background thread with its
own session and worker strutures all set up and ready.

Use this for the cache-timeout thread, instead of home-rolling it.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4257 d4fa192b-c00b-0410-8231-f00ffab90ce4

Note that to use this for full effect, varnishd should be installed
unstripped.

r4058:
Also remember compat execinfo.h file.

r4059:
Tell autocrap about compat/execinfo.h

r4060:
Attempt to add a stack backtrace to the panic message.

r4061:
Spit out more information on panic

r4062:
Autocrap the dladdr() functions existence.

r4063:
More autocrappery.

r4064:
Comment out unneeded function.

r4065:
Pass a void* to Symbol_Lookup() to avoid stdint requirement on
common.h



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4256 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4255 d4fa192b-c00b-0410-8231-f00ffab90ce4

written by Maxim Sobolev <sobomax@FreeBSD.org>



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4254 d4fa192b-c00b-0410-8231-f00ffab90ce4

The object will not have a ban yet in the 2.0 branch, so revert the
cache_hash part of r4252.


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4253 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4252 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4251 d4fa192b-c00b-0410-8231-f00ffab90ce4

r4052:
Be more paranoid about backend responses, a response of:
        HTTP/1.1 1000\n\r\n\r
would panic us trying to find a suitable message for 1000.

Now we 503 the response instead.

Fixes #506

r4053:
Regression test for #506



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4250 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fixes #502



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4249 d4fa192b-c00b-0410-8231-f00ffab90ce4