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

here the filedescriptor may already be closed, so accept EBADF.

Reported by:	Xing Li <xing@litespeedtech.com>


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

With very short chunks, in this case 3 characters, our buffer may
contain not only the chunk length and the chunk data, but also the
next chunk length.

If the short chunk is the last chunk before the zero length chunk
at the end, unconditionally trying to fill the buffer before parsing
the length may hang because we already have everything there is to
have in the buffer.

The fix is to always try to parse the buffer before adding to it.

While here, tighten up and improve error checks of the code.

Reported by: Xing Li <xing@litespeedtech.com>



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

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

Code still not Alpha ready, but I think most concepts work now.


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

xxx or XXX.



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

with pthread_mutex_{lock,unlock}()



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

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

The "missing code" variants have xxx prefix

Introduce AN() (assert non-null) variant as well.



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

socket dismantling.

There is no way that close(2) should ever be able to return EINVAL,
but we've seen it.

Specifically assert on EBADF which is the check we're really after.



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

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

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

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

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

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

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

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

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

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

RFC2616.

Add the XID as "guru meditation" in the error HTML.



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

for setting them.

Collapse all the 'timeout' functions.

Add pipe_timeout parameter.



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

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

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

that we will actually have a timeout.


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

If we know the record length, only hold the mutex while we reserve
the space.  Until we change the first byte, nothing bad can happen.

XXX: a memory barrier is strictly speaking necessary before we assign
the first byte.

If there are no '%' in the format string, treat as fixed length for
speed.



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

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

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

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

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

graphically useful.



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

Autoscale vertical axis.


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

Eliminate the MD5 optional code.  There is no sufficiently strong
statistical basis for using MD5 that will outweigh the performance
penalty or "IT USES THE BR0K3N MD5 ALGORITM" cries on slashdot.

The only known artifact in CRC32 is that hashing it with a power
of two is slightly inefficient (a few percent in bucket length
standard deviation) if you have URLs with fixed width fields of
a limited charset (such as numeric) fields in them.

Avoid this by checking the hash width specified for power of two,
and reduce it by one telling the user why.

Using a hash width that is a prime number does provable advantage
over just not using power-of-two width.  I have heard a mathematician
say that this is inherent in the design of the polynomia chosen
for CRC algorithms error (optimized for bit error detection) but
the actual math is way beyond me.

Increase default hash width to 16383, which is probably still
smaller than it should be.



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

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

listening address ("port 80 on all interfaces")

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

Sort on length of key, then on digest.



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

Make nbuckets=nhash mandatory.

Order hash lists by the length of key instead of the key contents,
comparing the length is much faster.

Also compare disgest before we take the expensive content compare.

Use memcmp() for content compare instead of strcmp().

Use a two-pass algorithm for inserts to lower mutex contention.



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

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

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

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

been closed.

Pipe does this and would panic otherwise.


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