Re: squid-3 development: stmem, endOffset(), range requests

On Mon, 23 Aug 2004, Adrian Chadd wrote:

> I've checked out a current squid-3 tree. It seems that the same
> problem exists as it did a few months ago.

I have not looked at it. Only forward porting of 2.5 bugfixes...

> * line 816 of src/http.cc does this:
>
> /* If the body size is known, we must wait until we've gotten all of it. */
> if (entry->mem_obj->endOffset() < reply->content_length + reply->hdr_sz)
> return INCOMPLETE_MSG;
>
> .. now, at this point, the whole point behind content_length + hdr_sz
> is the size of the _reply_. endOffset() is now _not_ the size of the
> reply anymore. It is the highest position of the object we know about.

What is the difference?

> Robert changed the way the stmem stuff worked so it now stores a
> splay tree of "chunks" of the object. You can stuff arbitrary ranges
> into memory here.

Ok.

> He changed what endOffset() _meant_ but didn't change the API call
> to reflect this.

So you say the difference is that before endOffset did indicate the amount
of data known for the object, but now there may be holes?

> In the Old Method, a range request from a _server_ would be treated
> as uncacheable, so the endOffset() would reflect the end of the server
> reply.

I assume you meant reply, not request..

and yes, it was uncacheable and no range processing would then be done on
the reply (in past range processing was still attempted in some cases but
this caused too many bugs)

> Robert, Henrik, does this all sound correct?

makes sense.

> Everything else actually seems to work out just fine, to be honest.

Good.

So how is the code now supposed to know if all needed data is available in
order to fix the lines above?

Regards
Henrik
Received on Mon Aug 23 2004 - 15:20:24 MDT