httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: mod_proxy and buff.c
Date Wed, 22 Mar 2000 01:46:51 GMT
On Tue, 14 Mar 2000, Graham Leggett wrote:

> The ap_bgets() function that is being used in all of this does not allow
> lseek'ing to my understanding, which prevents me from jumping to the end
> of the file to fetch the updated headers.

you could implement bseek without causing very much havoc in the rest of
buff.c.

if you do this, i suggest you seek to buffer-size boundaries only (i.e.
round down whatever the user passes in) and refill the buffer from there.  
this seems to handle most of the performance cases i've worked with with
seekable buffers before.

> Does anyone have any suggestions on how to fix this? Is putting headers
> at the end of the file the most efficient way of doing this?

do like zip does -- store a little directory at the end of the file.

append the headers to the response, and then append a small structure:

struct foo {
	off_t start_of_headers;
	unsigned long magic;
};

where magic is set to some special value indicating this is an apache
httpd cache file, and start_of_headers is something you get from a btell()
before writing the headers.  oh, you'll have to implement btell() :)

or you could just use read/write/lseek.  probably easier.

then when re-serving the cached file, just read a good 4k buffers worth
from the end of the file and you'll get the entire headers in most of the
cases anyhow.

Dean


Mime
View raw message