[squid-users] Squid caching bad objects

[Razor Cross]

On Mon, Jun 26, 2017 at 12:06 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> On 06/26/2017 10:11 AM, Razor Cross wrote:
>
> > We are using squid 3.5. for our server. Recently we have noticed that
> > squid is caching incomplete objects in case of chunked response.
> >
> > We have gone through the squid code. It looks likes squid is caching
> > incomplete response in case of EOF from the server even though it does
> > not receive the last empty chunk.
> >
> >
> >  if (eof) // already reached EOF
> >         return COMPLETE_NONPERSISTENT_MSG;
>
> You are looking at the wrong code. HttpStateData::persistentConnStatus()
> and related *_MSG codes do not determine whether the entire object was
> received. They determine whether
>
> (a) Squid should expect more response bytes and
>
> (b) The connection can be kept open if no more response bytes are expected.
>
> The COMPLETE_NONPERSISTENT_MSG return value is correct here (I am
> ignoring the sad fact that we are abusing the word "complete" to cover
> both whole and truncated responses).
>
>
> > Is this expected? Because of this problem, our server ends up serving
> > bad objects to the user.
>
> >What you describe sounds like a bug, but the exact code you are quoting
> >is not responsible for that bug. I di not study this in detail, but I
> >suspect that the COMPLETE_NONPERSISTENT_MSG case in
> >HttpStateData::processReplyBody() should be changed to call
> >StoreEntry::lengthWentBad("missing last-chunk") when lastChunk is false
> > and HttpStateData::flags.chunked is true.
>
>       We are able to reproduce the issue . If server socket is closed
after sending first chunk of data, squid is caching the partial object even
though it did not receive the remaining chunks. I feel it has to make sure
that lastchunk has received before caching the data.

>
> - Cross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170627/77e3805d/attachment.html>