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

STP_START is the initial setup of a viable workerthread:  Dissecting
HTTP, getting vcl reference etc.

STP_RECV is invoking vcl_recv() and following orders.



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

element:

Add two checkpoints for the sessions workspace.

The first checkpoint is after the session fixed data, and move the
client address and port to workspace to see that this works.

The second checkpoint is after the, as received unadultered by VCL
http request.  Grab a copy of the http request matching this.

Implement rollback as an optional feature of restart in VCL.

Move various workspace initialization and resetting operations to more
suitable locations in the program flow.

I don't know if this is really usable, but now it's possible to do:

	backend b1 {
		set backend.host = "backend1";
		set backend.port = "80";
	}

	backend b2 {
		set backend.host = "backend2";
		set backend.port = "80";
	}

	sub vcl_recv {
		set req.backend = b1;
		remove req.http.cookie;

		if (req.restarts == 0) {
			set req.url = "foobar.html";
		} else {
			set req.backend = b2;
		}
	}

	sub vcl_fetch {
		if (obj.status != 200) {
			restart rollback;
		}
	}

And have it first look for "foobar.html" on one backend, and failing
that, try to give the user what they asked for from the other backend.


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

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

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

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

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

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

the connection first.  This fixes #168.


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

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

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

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

shouldn't need to malloc() / free() at all, but I don't have time to
figure out how to avoid it right now.


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

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

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

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

look for complete requests.


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

So far we support only the <esi:remove> element.

All other <esi:...> elements are ignored.



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

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

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

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

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

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

This is the meat of the XML-dissecting code.

In theory the task is pretty simple, but it gets complicated by the fact
that the XML input can be split over multiple pieces of storage, with
an element we care about straddling a boundary.

I have not decided what to do about ESI violations or XML syntax errors,
SHMlogging them, possibly controlled by a parameter might make sense.
For now mark them in the source.



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

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

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

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

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

Always enforce the 2GB filesize limit on 32bit architectures.
Clean up a couple of messages


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

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

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

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

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

chew than necessary.


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

front of the linked list where they will be found faster later on.


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

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

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

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

I thought so previously.



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

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