My vote:
Put it in the reply structure, filled in by the store when the object is
swapped in.
How to manage it in the store is a tricker issue, given that you only
know the length when the whole object has been retreived. But if the
object is stored in canonical form then it should be quite easy (file
size - headers).
/Henrik
Robert Collins wrote:
>
> Ok. The connection can still be persistent when transfer-encoding is present, so I'm not too worried from that angle. What does
> concern me is range requests on hits.
>
> However, it is a MUST NOT requirement that we can't send a 206 (partial content) unless we know the full entity length - thus my
> question.
>
> clientBuildReplyHeader parses the headers from the stored entity, which had no content-length because it was received transfer
> encoded. (I'm testing with two squids in series).
>
> So I can modify clientBuildReplyHeader to set rep->content_length via a store function, or perhaps the store should set it when we
> get the storeEntry?
>
> And the question of persistence on that information still stands :-]
>
> Rob
>
> ----- Original Message -----
> From: "Henrik Nordstrom" <hno@hem.passagen.se>
> To: "Robert Collins" <robert.collins@itdomain.com.au>
> Cc: <squid-dev@squid-cache.org>
> Sent: Sunday, January 28, 2001 9:33 PM
> Subject: Re: metadata question.
>
> > Robert Collins wrote:
> > >
> > > I'm hoping I can get a pointer in the right direction here....
> > >
> > > In the TE code we are required to remove the content-length header when sending TE encoded data. Likewise when we receive TE
> encoded
> > > data we do not recieve a content-length header. I calculate the content length based on the data received (at this point
> assuming
> > > that if it's cacheable it's a full response).
> > >
> > > What do I need to do to store (just in swap.state for now) the content length that we receive so that future hits are able to
> use it
> > > on client_side.
> >
> >
> > The client_side headers are all built in
> > client_side.c:clientBuildReplyHeader
> >
> > It is not strictly required to store the length. It is OK to send the
> > HTTP/1.0 client reply without content-length, but the connection cannot
> > be kept persistent then.
> >
> > /Henrik
> >
> >
Received on Sun Jan 28 2001 - 09:23:19 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:26 MST