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

In VCL:
	purge_url(<regexp>)
	purge_hash(<regexp>)
	(for an interrim period purge(<regexp>) will be the same as purge_url).
In CLI
	url.purge <regexp>
	hash.purge <regexp>

purge_hash operates on the hash-string which results from vcl_hash(),
by default it is composed of:

	req.url "#" req.http.host "#"

To purge everything on the virtual host foo.bar.com:

In CLI:
	url.purge "#foo.bar.com#$"

In VCL:
	purge_hash("#foo.bar.com#$");


The general format, if you have defined vcl_hash(), is:

	Each "req.hash +=" operator appends the right hand side of the
	+= and a "#" separator.

You'll have to figure out your own regexps.


Under the hood:

Move the hash string from object to objecthead and save space while
we're at it.

Fix indentation in generated source.



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

for two weeks now.  Also fix inconsistent indentation.


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

This fixed #143



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

The race is not closed however, proper locking needs to be thought out.

An XXX comment documents this for now.



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

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

Ticket: 139


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

WS_Return() is now unused, comment it out.


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

Instead of assembling the entire hash-string in the workspace, use
a scatter gather approach, hinted by the VCL compiler.

This eliminates the workspace reservation which prevented regsub() from
working in vcl_hash, and reduces the size of the necessary workspace a
fair bit as well, at the cost of a little bit of complexity in the
hash implmentations.

Closes ticket 137 and possibly 141



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

hash string.


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

operations on the req.hash variable.

It is only a hint, because it merely counts how many times the parser
saw something being added to the req.hash variable.  If the operation
was in a subroutine which was called multiple times, the hint will not
reflect the number of actual operations.

For now we will deal with that at runtime, at the expense of a
failed transaction every time we run short.  If this becomes an issue,
an extensive topological analysis of the VCL program can give us
a definitive count.



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

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

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

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

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

Ticket 138



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

Ticket: 140


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

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

than when we don't find one.

This makes changing runtime paramters work again, without the need to
ask for a nonexistent parameter to trigger the update.

Ticket: 136



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

on 32-bit platforms.


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

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

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

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

used to determine which lock type (shared or exclusive) to use.


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

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

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1788 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@1787 d4fa192b-c00b-0410-8231-f00ffab90ce4

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

at the mercy of the TZ environment variable.


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

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