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

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

Add a parameter "cli_banner" (default on) which injects an implicit
"banner" CLI command on all cli connections when opened.

The net result is that you get a CLI response when you connect to
the CLI ports:

	200 193     
	-----------------------------
	Varnish HTTP accelerator CLI.
	-----------------------------
	Type 'help' for command list.
	Type 'quit' to close CLI session.
	Type 'start' to launch worker process.

Presently the contents of the CLI response is "undefined", in the
sense that you should not programatically depend on anything besides
the "200" reply code.





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

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

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

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

to see if they get reused ended up being named "acceptors", which is a bad
name because we have another thread which accepts new connections.

Rename the "fake" acceptors to "waiters"



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

it when we have used the object anyway.



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

which point to the objects.

Preallocate objcore with obj+objhead before we enter locked
hash sections.

Rename objcore.list to objcore.lru_list.

Eliminate obj.list and objhead.hashlen



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

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

- Changelog item to specfile for the rpm package
- Added html doc to the rpm package



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

In the future, this will be the bits of a cached object we cannot
realistically expect to stay paged out for any period of time.



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

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