the time.

To be reenabled when the code supports the desired functionality.



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

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

size disks.

Submitted by:	wichert

Fixes ticket 283



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

principle of the situation.



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

routine.

Follow RFC2616 more closely, and make relative (ie: max-age) specifications
take precedence over absolute specifications (Expires:)

Add an explicit clock-skew window (parameter: clock_skew) and only
interpret Expires: in absolute terms if the Date: header is inside
this window.

Explicit check for the case where the backend sends an Expires: which
is before the Date:, even if the Date: is out side our window.




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

non-XML detector logic.

Add a testcase to see if it works and that we can override it.



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

picks off your loopback interface.



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

like XML.  Our definition of "looks like XML" is that the first
non-white-space character is '<'.

Add a new parameter "esi_syntax" with bits to steer the ESI parser.

Use the first bit to disable the "looks like XML" check.



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

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

Test caching of synthetic error pages (broken since 2266).  This will need revisiting once caching has been reimplemented.


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

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

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

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

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

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

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

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

there to stop us.

Fixes #281



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

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

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

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

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

The problem is that a TCP connection to 127.0.0.1 appearantly does
not originate on the loopback interface, but on some other interface
on the machine.



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

might not be there yet.



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

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

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

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

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

	Add IPv6 support (untested!)

	Implement evil-acls

IPv6 support
------------

I have implemented IPv6 filtering support, but I have done so blindly
as I have no IPv6 networks to test with.

Please double check before relying on this to work, and please report
your findings back to us.

Syntax
------

The ACL rules still have the same syntax, but the sematics have
expanded to handle IPv6 also:

    acl foo {

        "foohost";              // Match, if the address is one of the 
                                // ipv4 or ipv6 addresses of "foohost"

        ! "foohost";            // Fail, if...

        "192.168.1.7" / 24;     // Use mask for comparison:  The '7' is
                                // ignored

				// Implicit masks:
	!"172.16";		// Fail 172.16.0.0 to 172.16.255.255
	"10.0.0";		// Match 10.0.0.0 to 10.0.0.255
	

        "www.freebsd.org" / 24; // This will give compile error, because
                                // the "www.freebsd.org" has both ipv4 
                                // and ipv6 addresses, and using the same
                                // mask for both kinds do not make sense.

        ( ... );                // Ignore this rule if DNS lookup fails.

        ( ! "idiot.net" );      // If we can resolve "idiot.net", then
                                // return Failure to match, if we see them.
    }

Please notice that DNS lookup happens *only* on VCL compilation, if a
DNS record changes you need to recompile (ie: vcl.load or vcl.inline)
your VCL code again, it is not enough to just switch vcl (vcl.use).

(This is the same as with backend DNS lookups)

Evil-acls
---------

Most firewall or ip-filtering facilities, compile the lists of
networks and masks to a table, and matches proceed sequentially
through that table until the table is exhausted or a match is found.

Since we compile our ACLs into C-code, we might as well implement the
"evil-acl" concept, and compile the rules directly into C-code instead.

An ACL like this:

	acl foo {
		"172.16";
		!"172.16.17";
		"172.16.17.18";
		"172.16"/18;
	}

Compiles to:

	if (fam == 2) {
	 if (a[0] == 172) {
          if (a[1] == 16) {
           if (a[2] == 17) {
            if (a[3] == 18) {
             VRT_acl_log(sp, "MATCH bar " "172.16.17.18");
             return (1);
            }
            VRT_acl_log(sp, "NEG_MATCH bar " "172.16.17");
            return (0);
           }
           else if ((a[3] & 0xc0) == 0) {
            VRT_acl_log(sp, "MATCH bar " "172.16" "/18" );
            return (1);
           }
           VRT_acl_log(sp, "MATCH bar " "172.16");
           return (1);
          }
         }
        }
	VRT_acl_log(sp, "NO_MATCH bar");
	return (0);

As can be seen, for example the comparison with "172" is now shared
for all four rules in the ACL, instead of being carried out once for
each of the four rules.

In addition to this optimization, the C-compiler will of course use
its usual (and unusual) tricks to speed things up, quite likely inlining
the ACL code in the VCL functions where they are referenced.

It will also be noticed, that the compiler sorts the rules in "most
specific order".

This means that:
		"172.16.17.18";
gets tested before
		!"172.16.17";
even though it is listed later in the ACL.

Previously we tested the rules in the order given.



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

The following perl one-liner is useful:
perl -ne 'if( $print == 1 ) { exit if( /^$/ ); eval "print " . $_; } $print = 1 if /default_vcl/;' mgt_vcc.c 
Fixes #135 (for now)


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

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

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

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

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

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

-s file,<dir_or_file>,<size>,<granularity>
Fixes #244



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

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

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

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

Takes a string argument, so it is possible to do:

	 panic "Trouble with " req.url " (not the way I expected it!);



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