httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <>
Subject Re: mod_proxy and buff.c
Date Tue, 14 Mar 2000 18:29:20 GMT
Separately caching header and body seems most flexible to me, and
doesn't require a new function in buff.c, but does raise perf concerns
under heavy loads. There is the possibility of writing
ap_bgets_with_header() or something for this purpose, that would read
the header and body to separate buffers, and save the extra read.

Read() and write() should be avoided here. I've gotten in trouble about
this before. 8^)

Graham Leggett wrote:
> Hi all,
> I have a bit of a sticky problem, maybe someone with a better
> understanding of buff.c could point my confused brain in the right
> direction :)
> Right now the need exists for mod_proxy to store updated headers that
> are returned as part of a 304 Not Modified response on a cache entry
> revalidation. The most sensible place to store these headers are at the
> end of the cache file - here they are easy to write (and overwrite) as
> new headers replace old ones.
> The problem is that when we read the cache file in, we need to read the
> cache file non-linearly, ie we need to read in the cache file header,
> then the request and response headers, then jump to the end to read any
> updated headers, then back to the start of the body ready to ship data.
> 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.
> 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?
> Can I use read() and write() functions instead to read the headers in?
> Or is this the "wrong" way to do it?
> What about splitting body and headers into two separate files? Or would
> this cause too much of a resource drain?
Chuck Murcko

View raw message