Re: http response headers

From: Dancer <dancer@dont-contact.us>
Date: Wed, 22 Apr 1998 04:46:01 +1000

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alex Rousskov wrote:
>
> Hi Dancer,
>
> Yes, the problem you are trying to address is real. There are many
> applications that would benefit from having variable size headers on disk.
> However, before people start submitting huge patches (hope I am not late this
> time!), I want to note that the solution you are proposing, IMHO, may not be
> acceptable.

That's much what I figured after getting my thoughts in order in
writing.

> On Tue, 21 Apr 1998, Dancer wrote:
>
> > Obvious problem:
> >
> > Orphaned headers. Since the headers go in at the end, the only way to
> > get them on disk (assuming the object is not being cached in memory
> > during the transfer) for another request to reference, is to know the
> > size of the object in advance (not always true) and be assured that it
> > is correct, write the offset, seek forward, write the headers, seek
> > back, and write the object as it comes in. Unpretty.
>
> Another obvious and even more ugly problem is that every IMS request would
> require two disk I/Os. First, to fetch offset info. Second, to fetch headers.
> Note that current implementation requires full HTTP headers to be memory
> resident to generate a 304 reply. Doing two full I/Os with a seek in between
> will slow down your IMS requests significantly. And there are often more than
> 30% of IMS-like requests in proxy traces.

*ouch* Of course...I don't normally think in terms of hard i/o.

> IMHO, your solution solves one problem but creates others. I would avoid
> spending time on debugging it. A better approach would be to write a high
> (Squid) level "Squid FS". Unfortunately(?), we do not have time for this in
> 1.2.

No problems. I'll let that churn around in the back of my head. It
deserves a few idle-cycles. I agree that we've no time for it at this
stage.

D

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ 
------END GEEK CODE BLOCK------
--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:47 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:45 MST