Add a byte to the length field, but retain the 255 bytes restriction
for now.

Add symbolic names for the header fields and macros for multi-byte
fields, and uses these throughout.   This will make it easier next time.



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

that for the managers CLI event-engine:

React to POLLNVAL as we would to POLLHUP


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

See also http://www.version2.dk/artikel/5153 if you read danish.



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

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

I find out where to put ad-hoc stuff like this in the tree.


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

as opposed to unhandled esi: elments which we complain about in
varnishlog.

Thus, if you want to get a short comment into the shmlog, the
easiest way is to do something like <esi:say a="Hi Mom"> which will
result in a shmlog record:
   11 ESI_xmlerror c at 25: ESI 1.0 unimplemented element "<esi:say Hi Mom>"
But the length of the message is truncated to avoid dumping the entire
source document into the shmlog.

Snip out any unknown esi: element.

While the ESI 1.0 specification doesn't address this directly, my
impression from the document is that they should never leak through
to the client.



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

storage boundaries.  Complain if it isn't closed at the end.


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

gracefully.


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

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

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

storage chunks.



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

to parse due to lack of bytes.


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

parts, otherwise we will get trouble (#167 ?) later.


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

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

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

evaluated even if we don't bother to check the result.  We should trust
the compiler to eliminate code that has no effect.


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

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

to feed to h_ncsa(), so it is up to h_ncsa() to interrupt it if reopen
is non-zero.

Also remove a superfluous call to VSL_Arg() as was previously done in
varnishlog(1).


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

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

we get around to delete the kevent.



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

do anything about the associated session.

May be relevant relative to: #162

(Bitmap functions slightly general, for possible later reuse)



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

Don't take a detour around cache_response.c, go directly to
cache_synthetic.c.

Don't wast time and energy mucking about with pseudo-objects,
just synthesize the error body directly in the workspace and
send it from there.

Close the session after sending error response, freeing up
resources sounds like a good strategy. (XXX: for futher study).

This might be related to #167



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

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

given circumstances is fair game.


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

Collect any messages from the C-compiler and pass them on to the
user, but do not take them as evidence of a failed compilation,
check the returnvalue for that.

To avoid confusion, explicitly say when the VCL program was compiled.


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

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

from which it tries to extract as much useful information as possible before
it croaks.  The corresponding macro is spassert(), which assumes you have
a struct sess *sp in scope.  This should help a lot with bugs like #167
where important information is not available post-mortem (because sp->obj
points into the cache, which is not included in the core dump)


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

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

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

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

requires the child to be restarted or the VCL script to be reloaded.


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

important functional change is that the source is no longer piped to the
compiler; instead, the source file name (which now ends in .c) is passed
on the command line.  This makes it *much* easier to support non-GNU
compilers.

The cc_command parameter processed by a custom function instead of sprintf;
"%s" is replaced with the source file name, "%o" is replaced with the output
file name, and "%%" is replaced with a single "%".


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

placeholder characters after the placeholders.


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

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

with it.


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

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

can't delay disarming it, or we will have a race between the acceptor and
a worker thread.  This will need revisiting at some later date.


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

press 3 for 2^3 = 8 seconds)


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

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

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