git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1784 d4fa192b-c00b-0410-8231-f00ffab90ce4

Based on Theo Schlossnagle's Solaris portability patch.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1783 d4fa192b-c00b-0410-8231-f00ffab90ce4

req.request is "HEAD".  This is what broke the RePurge test case.

Ideally, sp->wantbody would be controllable by VCL.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1780 d4fa192b-c00b-0410-8231-f00ffab90ce4

Made it possible to pass a vcl variable to error (error 200 backend.health).
Implemented a first attempt at an algorithm for checking the health of a backend. 
Negative values means the backend has problems, positive values means it is ok. 0 is neutral,
and could mean that it has been a while since the backend was asked for anything.
See the code for details.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1778 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1776 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1766 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1765 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1762 d4fa192b-c00b-0410-8231-f00ffab90ce4

sub vcl_recv {
	if (req.request == "REPURGE") {
		purge(req.url);
		error 404 "Purged";
	}
}



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1761 d4fa192b-c00b-0410-8231-f00ffab90ce4

to an unsigned int (which triggered warnings on some 64-bit platforms) and
printed with %08lx, incorrectly assume that it can be meaningfully cast to
a void * and printed with %p.  While still incorrect in general terms, the
latter turns out to be correct on the specific systems that we care about.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1754 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1753 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1752 d4fa192b-c00b-0410-8231-f00ffab90ce4

headers.  This fixes #128.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1751 d4fa192b-c00b-0410-8231-f00ffab90ce4

assumption about which is the default.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1750 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1749 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1748 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1745 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1743 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1738 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1735 d4fa192b-c00b-0410-8231-f00ffab90ce4

one stevedore to the next.  The LRU code is invoked as soon as any of the
stevedores fills up.

This algorithm is far from ideal, and will not work well with differently
sized stevedores, but it has the advantage of being simple and lock-free.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1734 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1733 d4fa192b-c00b-0410-8231-f00ffab90ce4

locking, which introduces a choke point.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1732 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1731 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1730 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1729 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1728 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1727 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1726 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1725 d4fa192b-c00b-0410-8231-f00ffab90ce4

Support for multiple cache files. The selecting of a cache file is done by a simple round-robin that selects
the first file in the list, and then moves it to the end. If the selected file hasn't got enough space, the next
one is tried. If no file has enough space, the LRU discarding is applied to the first file in the list.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1724 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1722 d4fa192b-c00b-0410-8231-f00ffab90ce4

Also, ignore the result of dlclose().


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1721 d4fa192b-c00b-0410-8231-f00ffab90ce4

glibtool, and has a version of automake 1.6 which does not exhibit the
bug I've observed on other platforms.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1720 d4fa192b-c00b-0410-8231-f00ffab90ce4

tentative definitions with non-tentative ones, thus sidestepping one
of the issues we have on MacOS X.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1719 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1718 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1717 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1716 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1715 d4fa192b-c00b-0410-8231-f00ffab90ce4

scenario where multiple clients each require different objects such that
the sum of the sizes of the objects is larger than the cache (or, in the
extreme case, one client requests an object which is larger than the
cache) causing STV_alloc() to enter an infinite loop.

This is not ideal - a better solution would be return NULL and have the
caller deal with the problem, possibly by returning a 503 result, or by
stalling the request for some time.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1714 d4fa192b-c00b-0410-8231-f00ffab90ce4