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

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

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

addition of features to the ESI code.

The particular situation in #433 arises because a XML comment is not
bounded in length, the same way as an <esi:include...> element naturally
is.  This opens the window for trouble when large sections of XML is
commented out for some reason or another.

Bite the bullet and create a "storage-pointer" consisting of a pointer
to a storage segment and a pointer into that segment.

Add a main-loop which uses these pointers to walks over the entire
object, looking for stuff we care about, and handle each appropriately.

In addition to coping properly with the situation in #433, this code is
also close to 100 lines shorter and has a more logical structure.

The downside is that it is isn't quite as memory-access-alergic as the
previous version.  (I challenge anybody to measure the effect of this.)

Fixes: #433



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

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

tests cases.



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

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

I suspect a white-space cleanup got it at some point.



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

time sequencing of shmlog records for debugging purposes.



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

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

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

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

Add two test-cases for objects we should not esi parse.



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

the grim reaper has taken the object off the binheap to inspect it.



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

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

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

Fixes build failure


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

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

has closed the connection on us.

Fixes	#427



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

(The recent change that moved the compiler into its own subprocess
eliminates risk that a compiler error causes the management process
to die, you just do not get a sensible syntax error).

Fixes: #417



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

This hopefully finaly lays the sporadic
	assert(oe2->timer_when >= oe->timer_when);
panics to rest.



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

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

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

from VCL.

It is possible to instigate purges two ways from VCL now:

        sub vcl_recv {
		# Purge the req.url
                if (req.request == "PURGE") {
                        purge (req.url == req.url);
                        error 410;
                }

		# Take entire purge instruction from "Purge:" header
                if (req.request == "PURGESTR") {
                        purge ("" req.http.purge);
                        error 410;
                }

Testcase for this.



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

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

And add separate rxhdrs and rxbody primitives.

Submitted by: Yonatan Broza & Dmitry Rubinstein



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

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

the VCL compiler



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

of zero from serializing access to an object with very draconian
backend cache-control headers.

We could get far even with a one second TTL, but following our general
"there is a reason people put Varnish there in the first place" logic
we use the default_ttl parameter (default: 120 s) for this value.

If another value is desired, this can be set in vcl_fetch, even if it
looks somewhat counter-intuitive:

	sub vcl_fetch {
		if (obj.http.set-cookie) {
			set obj.ttl = 10s;
			pass;
		}
	}

Fixes #425



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

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

obviously should be freed.

This could fix 421 or make it much worse, but give us more info.



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

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

Only save the hash-string in the session workspace and objects when
this paramter is set to "on".

For sites with many small objects, this will save significant VM.

When this paramter is set to "off", the "purge.hash" facility will
not work, but this should not be a problem, because the new purging
facility allow much more expressive purging, the typical case
being:

	purge req.http.host ~ www.foo.com && req.url ~ "article2383"




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

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

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

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

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

purges before we test their numbers.



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

Let purge.list prune the tail of the list before dumping.



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

For instance:

	purge req.http.host ~ www.foo.com && req.url ~ "\.png$"
	purge obj.http.set-cookie ~ USER=383839

Now, why would you want purge on request headers and not object headers ?

Simple, some information the object does not have, the Host: header is
a good example.

Assuming that the Host: header is part of the hash we use to lookup
an object (as is the default), we can avoid copying that field into
the object (saving memory: O(nObjects)) by using the request value
to purge against.




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