Re: metadata question.

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 - 03:42:03 MST