Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 28799 invoked by uid 500); 14 Mar 2000 18:27:25 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 28783 invoked from network); 14 Mar 2000 18:27:25 -0000 Sender: chuck@Trintech.COM Message-ID: <38CE8500.445E7A9B@topsail.org> Date: Tue, 14 Mar 2000 13:29:20 -0500 From: Chuck Murcko Organization: The Topsail Group X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i686) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: mod_proxy and buff.c References: <38CE1B70.315ED02A@sharp.fm> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N 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 Chuck Murcko Here: chuck.murcko@trintech.com There: chuck@topsail.org