git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3961 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3960 d4fa192b-c00b-0410-8231-f00ffab90ce4

Solaris (and we do not need them)



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3959 d4fa192b-c00b-0410-8231-f00ffab90ce4

Approved by:    phk, ssm



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3958 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3957 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3820 d4fa192b-c00b-0410-8231-f00ffab90ce4

Don't try to rush waiting sessions of refcount is zero, there cannot be
any (they would hold a reference).

Should be merged to 2.0.3



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3817 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3752 d4fa192b-c00b-0410-8231-f00ffab90ce4

- Added html doc to the rpm package


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3751 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3749 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3748 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3747 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3746 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3745 d4fa192b-c00b-0410-8231-f00ffab90ce4

Overhaul the ESI parser in light of #433 and the prospect of future
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/branches/2.0@3744 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3743 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3742 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3741 d4fa192b-c00b-0410-8231-f00ffab90ce4

Update this test to actually test what it should.

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



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3740 d4fa192b-c00b-0410-8231-f00ffab90ce4

Make it possible (at great performance loss) to force straight
time sequencing of shmlog records for debugging purposes.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3739 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3738 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3737 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3736 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/branches/2.0@3735 d4fa192b-c00b-0410-8231-f00ffab90ce4

Close a race where VCL tries to modify the obj.ttl at the same moment
the grim reaper has taken the object off the binheap to inspect it.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3734 d4fa192b-c00b-0410-8231-f00ffab90ce4

Merge r3564: Move mybe{32,64}enc definitions outside of ifdef so we work on 64 bit BE platforms too.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3733 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3732 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fixes build failure



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3731 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3730 d4fa192b-c00b-0410-8231-f00ffab90ce4

Stop processing ESI elements as soon as we discover that the client
has closed the connection on us.

Fixes   #427



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3729 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/branches/2.0@3728 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/branches/2.0@3727 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3726 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3725 d4fa192b-c00b-0410-8231-f00ffab90ce4

Implement the new-purge case where the entire expression comes
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/branches/2.0@3724 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3723 d4fa192b-c00b-0410-8231-f00ffab90ce4

Don't append a CRNL to the body.

And add separate rxhdrs and rxbody primitives.

Submitted by: Yonatan Broza & Dmitry Rubinstein



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3722 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3721 d4fa192b-c00b-0410-8231-f00ffab90ce4

Move the purgable variables into a CPP table, so we can share them with
the VCL compiler



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@3720 d4fa192b-c00b-0410-8231-f00ffab90ce4

Enforce a minimum ttl for "hit for pass" objects to prevent a value
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/branches/2.0@3719 d4fa192b-c00b-0410-8231-f00ffab90ce4