the gunk:

A persistent storage method, needs to know about "struct object" in
addition to regular storage allocations, in order to track ttl and
ban information etc.

Therefore, when we create an object, we call into the stevedore.c
to do so with STV_NewObject(), it picks an stevedore, and calls
the ->allocobj() method, which will allocate some storage, call
STV_MkObject() to turn it into an object, which can then be
fondled, before passing it back to STV_NewObject() an from there
to cache_center.c::cnt_fetch().

Non-persistent stevedores, don't define ->allocobj() and when
initialized by stevedore.c, get a suitable default function.

XXX: next steps, remove objcore argument from stv->alloc() and
remove stv->object() method entirely, now that we have a proper
calling order.





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

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

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

it belongs (more)



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

more extensive work to it.

[1] If I wanted to be buzzword compliant, I'd say "refactor" :-)



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

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

Clean up assert for proper use of busy flag



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

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

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

Make it possible to add a hit/miss item to varnishncsa as well as a
hit/miss/pass/pipe item.


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

Default to a parallelism of 3, and just use our own test driver


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

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

match a externally imposed prototype and which are therefore not subject
to argument refinements such as constification.

Define it so FlexeLint supresses 818, and remove manual 818 suppressions
througout.

Constify what we can.



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

Suggested by:	Vincent Wells


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

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

main handle and the object something which only the objcore knows
how to procure.

Replace the crude callbacks into the persistent module with a set
of methods on the objcore, which does whatever magic is necessary.

->getobj() returns a the object associated with this objcore, and
performs any cleanup necessary.

->updatemeta() signals that ban/ttl info on an objcore has changed.

->freeobj() releases any resources associated with the object.



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

with a valid obj.



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

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

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

Add a stevedore named "Transient" if the user did not already do that.
By default it is a size-unconstrained -smalloc.

Do not select the stevedore named "Transient" automatically.



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

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

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

magic symbols instead for consistency.

Various tightening of bolts and painting of scratches.



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

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

Fixes: #686



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

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

subject to refcounting.

Fixes: #812



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

contain comma-separated lists, can be spread over multiple header
lines.

There is no way of knowing if this rule applies to any header not
in RFC2616, short of chasing down the relevant standards document,
if any, for the particular header.
 
Considering the fact that HTTP header lines have no natural
limitation on length AND that RFC2616 already specifies a mechanism
for header-continuation, this doesn't add any value, at all.
 
It is hardly a surprise that nobody used this either, so until now,
we have ignored this silly stuff and just used the first header we
found.
 
But now Chromium, of all things, seems to find it necessary to
spread its Cache-Control across two lines, and we get to deal
with this crap.
 
Add a function for stitching multiple header lines into one, and
call it on Cache-Control in requests to deal with Chromiums issues.

Since we have it, call it preemptively on Cache-Control and Vary
in backend responses, since the C-code examines these fields.

XXX: At some point, add VCL support for collecting specific headers
this way.

Fixes: #686



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

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

They do what you expect.

Remove the native VCL "log" action.

Add generic VRT_StringList() which will build a STRING_LIST into
any sized buffer, so that std.log() can build the string on the stack.



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

(on error and unconditionally).

Drop the LOG into the /tmp/vtc.* directory if we leave it behind.

Sync usage() to reality.



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

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

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

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

specified:  -d, -b, -f, -S or -T

In human terms, this means that it is legal to start varnishd without
a Vcl or backend, but only if you have a CLI channel of some kind.



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

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

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

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

documented return, restart, reordered some docs for readability and elaborated on saint and grace mode

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

VM interfaces.

Fix an assert to be correct.




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