git-svn-id: http://www.varnish-cache.org/svn/tags/varnish-2.1.3@5056 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5055 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5054 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5053 d4fa192b-c00b-0410-8231-f00ffab90ce4

Try to catch some common platforms with inline assembler.

I cannot possibly express the magnitude of this particular POSIX FAIL!



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5052 d4fa192b-c00b-0410-8231-f00ffab90ce4

Don't use tempnam(3) it results in a bogus compile time warning,
because we are not trying to create a file but a directory.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5051 d4fa192b-c00b-0410-8231-f00ffab90ce4

Candidate for merging into 2.1 branch


git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5050 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5049 d4fa192b-c00b-0410-8231-f00ffab90ce4

This allows logging to varnishlog with the VCL_Log tag.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5047 d4fa192b-c00b-0410-8231-f00ffab90ce4

r4859:
Make the critbit "Y" a independently allocated struct, rather than
using the objhead as carrier for it.

The time difference between objhead freeing and Y freeing is very
significant on systems with rolling URLS (ie: "article=%d") resulting
in far too many objheads being stuck on the cooling list.

r4860:
Also cool off objheaders

r4861:
Add a single write memory barrier, to be absolutely 100% sure that
the tree is sane at all points.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5046 d4fa192b-c00b-0410-8231-f00ffab90ce4

Reduces the number of pagefaults by roughly a factor 9.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5045 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5044 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5043 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5042 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5041 d4fa192b-c00b-0410-8231-f00ffab90ce4

We didn't create/destroy directors and backends in a consistent order,
and in some case we even destroyed directors more than once.

Always destroy in opposite order of creation (which follows VCL
source order).

Turn the bottom element of the array into (only) an indication
of which backend/director is the default.

Fixes:  #722



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5040 d4fa192b-c00b-0410-8231-f00ffab90ce4

this gives us compiler error messages rather than panics.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5039 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5038 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5037 d4fa192b-c00b-0410-8231-f00ffab90ce4

Attempt an even more comprehensive fix for a bug in Solaris:
If the remote end RST's a TCP connection, all socket related syscalls
seems to return EINVAL.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5036 d4fa192b-c00b-0410-8231-f00ffab90ce4

segments

r4973: Use WSP instead of VSL for ordering and performance

r4974: Minor nitpicking

r4975: Fix a bug when ESI elements span storage elements, which only
the tightfisted -smalloc would trigger.

Fixes: #719




git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5030 d4fa192b-c00b-0410-8231-f00ffab90ce4

In particular make the Length header match the actual composite object
sent to the client.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5029 d4fa192b-c00b-0410-8231-f00ffab90ce4

Merge r4980: Emit Length for client side right before ReqEnd, to summarize ESI transactions correctly.

Only emit Length and ReqEnd if we have an XID.

Fixes: #709
Fixes: #720



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5028 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fixes: #681



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5027 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5026 d4fa192b-c00b-0410-8231-f00ffab90ce4

I have no idea how I overlooked that a "bytes=-100" range was from the
end of the object, but I did.

Fixes #704.

Reported by:    Luc Saillard



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5025 d4fa192b-c00b-0410-8231-f00ffab90ce4

Submitted by:   Luc Saillard



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5024 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fixes: #700



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5023 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5022 d4fa192b-c00b-0410-8231-f00ffab90ce4

This really belongs in POSIX pthreads :-(



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5021 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4772 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4771 d4fa192b-c00b-0410-8231-f00ffab90ce4

Introduce a -storage spec, and default it -sfile,<workdir>,10m to
avoid mapping more VM than a 32bit machine can cope with, if /tmp is
huge.


git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4770 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4766 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4764 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fix one of those "nothing can possibly go wrong" bugs that are so
typical of "lets just try to get this into the release" features.

The resent addition of experimental Range: header support, broke
a cornercase in normal content delivery.

If an object was delivered from the backend using chunked encoding,
and was larger than the storage segment size (default: 128k) this
bug may bite.

The effect of the bug is that up to storage segment worth of junk
may be appended to the transmitted object.

This is mostly harmless, because the Content-Length header will make
the browser do the right thing, but certain load-balancers will
go cross-eyed and act really weird at the TCP level, spewing
interesting RST packets to the client.

This bug is only in 2.1.1, not in 2.1.0.

Fixes:                  #694
Isolated by:            ay
Fool who did this:      phk



git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4763 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4761 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4760 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4727 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@4725 d4fa192b-c00b-0410-8231-f00ffab90ce4