Re: http response headers

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.

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.

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.

Thank you,

Alex.
Received on Tue Jul 29 2003 - 13:15:47 MDT