[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    RE: metadata question.
From:       "Robert Collins" <robert.collins () itdomain ! com ! au>
Date:       2001-01-28 22:53:15
Message-ID: EA18B9FA0FE4194AA2B4CDB91F73C0EF798E () itdomain002 ! itdomain ! net ! au
[Download RAW message or body]

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Monday, 29 January 2001 9:52 AM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: Re: metadata question.
> 
> 
> Adding it to the in-memory cache index as a temporary workaround is
> fine, but the goal MUST be to not have it there.
> 
> I don't see that it will need to conflict with ranges. For one thing
> partial replies SHOULD have a content-length, for another we need to
> handle them differently anyway.
> 
> /Henrik

Yes the goal is to have it stored on disk in some form, not in memory. 

This may be another case of not enough sleep combined with reading rfc's
:-], but...

when we start caching range responses, we will have a content-range
(?from mem) header, and MAY have a content length header. However if we
receive transfer-encoded range responses (quite likely - say pdf files),
we will have a content-range header but no content-length header.
Regarding handling them : that was my point - why put in place code that
will be obsolete or broken in the near future?

Rob

[prev in list] [next in list] [prev in thread] [next in thread]