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

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

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

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

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

can be listend on.

Fixes #97


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

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

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

backend.

The new logic is:
	If (HEAD)	/* happens only on pass */
		do not fetch body.
	else if (Content-Length)
		fetch body according to length
	else if (chunked)
		fetch body as chunked
	else if (other transfer-encoding)
		fail
	else if (Connection: keep-alive)
		fetch no body, set Length = 0
	else if (Connection: close)
		fetch body until EOF
	else if (HTTP < 1.1)
		fetch body until EOF
	else
		fetch no body, set Length = 0

let me know if this breaks anything that should work.

Fixes #400



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

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

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

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

Fixes #409



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

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

make VBE_free_bereq() and HSH_Deref() null their argument pointer.

Add HSH_Drop() for deorbiting unwanted busy objects.



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

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

basically "return(action)" instead of just "action".

The previos syntax is still available.



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

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

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

critbit hasher.



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

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

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

Enable SHA256 digests by default, and put it in the objhead.  This
increases the size of the objhead by 32 bytes, but may drop
a bit again later, when other now unnecessary fields go away.

Test SHA256 for correct operation on startup.

About the "critbit" lookup:

To enable this, use "-hcritbit" argument.

"Crit Bit" trees, are also known under various other names, the original
version of the idea is probably the PATRICIA tree.

The basic concept is a tree structure which has nodes only where necessary
to tell the indices apart.

Our version of it, has some additional bells and whistles.

First lookups do not require any locks until we reach the objhead
we were looking for, or until we need to insert one which wasn't
there.

Second, the branch nodes are part of the objhead, as all but the
very first will need one, this saves malloc operations big time.

Now the down-sides:

There are still missing bits, amongst these the "cooling off" list,
for objheads that have been dereferenced, but where the branch-node
is not.  Currently we just leak that memory.

There is a race relating to node deref and unlocked lookup that is
not closed, weird things may happen until I fix it.

I'd be interested to hear how long it survives before it croaks,
but apart from that, would not advocate that you use it, until
I fix those remaining issues.



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

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

add a couple of test-vectors to avoid it happening again.

And now for the funny and educational story:

In july of 1994, I added the "libmd" to FreeBSD, containing the
MD2, MD4 and MD5 functions from RFC 1319, RFC 1186 and RFC1321.

I meticulously replicated the test-vectors from the RFCs, so that
"make test" would validate the result.

Duing the intermediate 14 years, various slight shifts and adjustments
to things like the make(1) programs defaults, the shared library
resolution algorithm and other totally unrelated things, meant that
"make test" now tests the installed version of the library, rather
than the version you just built with "make all".

Needless to say, when I tested my patch yesterday, I didn't install
the built version, wanting first to hear what Colin Percival, FreeBSD
Security Wiz, generally swell fella and the guy who wrote this
SHA256 implementation, thought of these "stylistic" patches.



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

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

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

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

assert that we have one.



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

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

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

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

is set.



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

the thread-pool related params into a new file mgt_pool.c as proof.

The paramters happen in management process context, and should therefore
not end up in cache_* files for namespace and sanity reasons.



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

generic for comfort.



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

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

now.



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

of possibly relevant headers and only go with the fast path if we have
credible information that this is a big-endian platform.



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

In the end, it comes down to lack of POSIX definition of a way to find
out byte-endianess, sigh...



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

This does not do anything yet.



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