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

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

timestamps on a monotonic and the UTC timescales respectively.

Doubles are much more convenient than timespecs for comparisons etc.



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

Notice this facility is subject to change!

"regsub" is short for regular expression substitution and it is probably
easiest to explain with some examples:

	sub vcl_recv {
		set req.url = regsub(req.url, "#.*", "");
	}

This will replace the requests URL with the output of the regsub() function

regsub() takes three arguments: the string to be examined, a regular
expression and a replacement string.

In this case, everything after the first '#' is removed (replaced
with nothing).

The replacement string recognizes the following magic sequences:
	&	- insert everything matched by the regexp
	$0	- ditto.
	$1	- replace with the first submatch of the regexp
	$2	- replace with the second submatch of the regexp
	...
	$9	- replace with the ninth submatch of the regexp

(The $0..$9 syntax was chosen over the \0...\9 syntax in order to avoid
a nightmare of escape characters in the VCL source code.  Arguments and
suggestions are welcome).

A more advanced example:

	set bereq.http.ClientIP = regsub(client.ip, "(.*):(.*)", "$2 $1");

The client.ip variable expands to IP:port number, for instance
	127.0.0.1:54662

The regular expression "(.*):(.*)" results in the the following matches:
	& + $0		"127.0.0.1:54662"
	$1		"127.0.0.1"
	$2		"54662"

So the replacement string "$2 $1" results in "54662 127.0.0.1"

And the completed header which is sent to the backend will look like:

	"ClientIP: 54662 127.0.0.1"

An even more advanced example would be:

    set bereq.http.magic = "Client IP = " regsub(client.ip, ":", " port = ");

Where we also exploint the string concatenation ability of the "set" statement.

The result string is built in the request workspace, so you may need
to increase the workspace size if you do a lot of regsub()'s.

Currently there is no decent error handling for running out of workspace.


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

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

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

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

	set bereq.http.HeyYou = client.ip " asked for  " req.url;



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

Give vcc_StringVal() a return value to say if it did anything so we can
emit better error messages when confused.



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

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

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

(which are numeric, they'll follow shortly)

Unify the shmemlog tag used for failure to rewrite something, the Rx/Tx/Obj
distinction is not helpful enough to warrant the complexity of it.






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

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

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

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

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

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

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

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

	sub vcl_deliver {
		set resp.http.phk = "Beastie" "Rules";
	}

Would result in a new header line:

	phk: BeastieRules

Notice that strings are concatenated directly, you add spaces, commas etc
where you want them.

Other variables which have STRING format (or which can be converted to
STRING format) can also be used:

	sub vcl_deliver {
		set resp.http.phk = "Server is: " resp.http.server ;
	}

Could result in:

	phk: Server is: Apache/1.3.x LaHonda (Unix)




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

	sub vcl_deliver {
		remove resp.http.etag ;
		remove resp.http.server ;
	}



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

default VCL



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

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

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

the VCL methods vcl_miss and vcl_pass.



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

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

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

wires, rather than when they get manipulated in memory.


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

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

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

There should be no functional change as a result of this.



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

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

of timestamps and clock_gettime() throughout Varnish needs reviewing (as
per IRC discussion with phk)


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

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

current time, the latter returns the number of seconds since an object
was last requested.  The exact semantics of both are slightly fluid at
the moment, and will be revisited at a later date.


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

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

script.


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

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

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

processing pending messages before we exit.

Note that VSL_Dispatch() will read in log data as fast as it can, so when
working from a log file, varnishreplay will usually read in the entire file
into memory within the first few seconds.


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