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

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

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

object from the sessions to the client.


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

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

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

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

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

Let storage_file use sendfile(2) for it.



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

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

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

constraint in FreeBSD and we shouldn't really listen to it.

On my laptop I can mmap 2422MB file this way.

This may be so aggressive that it leaves insufficient address space for
malloc/threadstacks and other issues.

If we find a way to pick up a platform/architecture specific limit, we
can enforce that along the way.

For now people can just specify a saner and smaller "-sfile" size.



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

the stevedore.

This should probably be (fine-)tuned later on as it might be too aggressive
when faced with user errors.

Also, might it be possible to mmap() more than MAX_SIZE_T bytes if
it is done in multiple calls ?



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

A size can be specified in absolute terms (suffix: k, m, g, t supported),
but also as a percentage of the filesystems free space (suffix '%').

If the specified size is larger than an off_t can cope, we bisect 
repeatedly until it can.

If the size exceeds the available space of the filesystem, we truncate
to 80% of the free space.

Then round down to an integral number of blocks, sized by the larger
of the filesystem blocksize and the pagesize.

This was tricker than I'd expected...



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

about any optional arguments.


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

even though that's how FreeBSD's kernel does it.  In my private world
a leading underscore means "junk file, remove at your pleasure".



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

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

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

Pull the struct definition into _stevedore.h and include this from
cache.h and mgt.h, they both need to be able to see it.

Add the stevedore pointer as an argument to the stevedore alloc function
so multiple stevedores is possible later on.

Add the stevedore pointer to the storage object, so freeing it again is
possible.

Add -s argument processing to select a given stevedore, call it's ->init
method and pass the stevedore in the heritage.

In the cache process pick stevedore out from heritage, call its open method.




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

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

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

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

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

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

use writev() if possible.

vca_flush() must be called before any memory previosly given to
vca_write is overwritten, and after the last call to vca_write()



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

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

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

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

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

Add http_HdrIs() to check if we have a given header and if we do
if it has a given value.

Use it.

Ignore SIGPIPE since SO_NOSIGPIPE doesn't work reliably, (but set
it on accepted TCP connections anyway).

Update passing to match fetching, including a chunked encoding method.



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

connections and clean them out if the backend closes.


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

Loop until we have the entire chunk in chunked encoding



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

General bush-wacking in the fetch code.


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

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

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

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

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

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

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

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