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

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

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

Maxim Sobolev <sobomax@FreeBSD.org>



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

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

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

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

	HTTP/1.1 1000\n\r\n\r
would panic us trying to find a suitable message for 1000.

Now we 503 the response instead.

Fixes #506



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

The old regress suite has been superseded by varnishtest, so nuke
this.

Fixes #493

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

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

This is in anticipation for set req.esi = off;


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

Fixes #502



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

broke pipehandling.

Fixes #505



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

Previously we always used SO_LINGER to make sure that all queued data
got transmitted, no matter under which circumstances we closed the
client connection.

Change this so that SO_LINGER is only activated for orderly connection
closure (ie: "Connection: close" from client or error handling), in
all other cases (usually the client connecting on us, abandon any data
queued for transmission.

This _may_ reduce the tendency of worker threads to get hung up on
network failures a little bit.



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

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

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

Fixes #329



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

and this prevented users from implementing "purge on POST" semantics
by looking up the POST requests and ditching the object found.

Now we only overwrite the request with "GET" if it is a HEAD, (the
internal "wantbody" flag tells hos how the response should be composed.)

The testcase shold probably be elevated to VCL example, with suitable
footnotes about URL sanitizing etc.

Fixes #444



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

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

add "-Wl,--as-needed" to EXTRA_DEVELOPER_CFLAGS to try to prevent
future unordering.

Fixes #486



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

fix for #498 -- if a return header overran the obj_workspace (but was small enough to fit in sess_workspace) the header is dropped and an empty slot is put in there -- rest of the code now detects this empty slot. It should probably ask VLC what to do if a header is dropped

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

with priv-sep.



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

Fixes #494



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

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

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

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

Tell the kernel that we expect to use this memory randomly -- affects how it reads up to page cache. On linux I saw a 10-20x decrease in IO from reading the disk

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

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

Thanks to "whocares" in the bts.

Fixes #455

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

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

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

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

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

probably s/Linpro/Redpill Linpro/ at some point.


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

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

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

of f_bavail), but the recommended I/O granularity.  The field we want
is f_frsize.  This should probably be abstracted away in libvarnish.


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

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

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

Some of us use git-svn, so embed the relevant commit ID in that case,
not just "exported" from svnversion.

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