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

r4046:
Change the way we close client sessions.

Previously we always used SO_LINGER to make sure that all queued data
got transmitted, no matter under which circumstances we closed the
client connection.

Change this so that SO_LINGER is only activated for orderly connection
closure (ie: "Connection: close" from client or error handling), in
all other cases (usually the client connecting on us, abandon any data
queued for transmission.

This _may_ reduce the tendency of worker threads to get hung up on
network failures a little bit.

r4047:
r4046 forgot to reset SO_LINGER for pipe handling which basically
broke pipehandling.

Fixes #505

r4183:
Disable SO_LINGER when we time out a connection due to sess_timeout,
so that we do not RST connections that have still not transmitted
their
data.

Since we were able to get the writev(2) to detach the socket, we
should
not end up sleeping in the close(2) either.

We still RST the socket for all error conditions.

Ideally I would still like to RST connections that have no outstanding
data after their sess_timeout, in order to avoid the 2*RTT+misc
timeouts delays associated with loosing a TCP socket for a client
that have gone to meet some other IP#.

In particular with load-balancers, this allows the load balancer to
declare the session dead right away, and reuse it for something more
productive.

Unfortunately, this lacks OS support in all presently released
OS'es: you cannot ask if a socket is done transmitting what you
asked it to.

FreeBSD-8.0 will have experimental support for this (FIONWRITE)
and I will revisit it in that context.


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

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

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

Fixes #494



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

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

Thanks to "whocares" in the bts.

Fixes #455


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

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

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