[squid-users] Multiple responses in cache objects

[Tobias Wolter]

Hey Amos,

On Tue, 2018-04-24 at 02:20 +1200, Amos Jeffries wrote:
> On 24/04/18 00:43, Tobias Wolter wrote:
> > Cheers,
> > 
> > I'm having some pretty weird issues with a customer's squid
> > installation - we're seeing multiple responses in a single cache
> > object.
> > 
> 
> Please note the:
> 
> > X-Transformed-From: HTTP/0.9
> 
> ... in your example cached objects.
> 
> Squid should not be caching these. Which implies that a) you have
> some config settings forcing things to cache when they are not
> supposed to, and b) either upstream server or client is broken.

I was wondering about these, that's a good hint.

>  * do you have any refresh_pattern rules forcing it to do so?

Aye, some files were CSS files which are forced into caching. I was
speculating that the refresh_patterns might be involved, but didn't
see the connection.

>  * what version of Squid are you running?

3.5.21 on whatever patches SUSE baked into it.


>  * have you tried the latest Squid version?
>  there have been a few fixes in detection this protocol version for
> Squid-4.

Sadly non-negotiable, I'll have to make do (or tell them, ultimatively,
that it can't be done).

> Squid is apparently receiving HTTP/0.9 response objects (a raw data
> stream of octets) not HTTP 1.0 or 1.1 objects (stream of messages
> with specific start and end points to each message object).

Yup, will look into how *that* is happening.

> How do you determine that "successful" for the server?
>  using any tool that hides away the protocols octet-level format
> details
>  (eg curl, wget, browser, etc) can hide the HTTP/0.9 oddity from
> view.

Yeah, I've only been loooking at high-level clients since that's pretty
much where it broke; since it at least by assumption had always been
"working" (read: no visible/reported breakage) thus far, I didn't
bother to check for this; especially as the application hasn't been
updated in the timeframe where errors were reported.

> Locate the URL which was originally requested by the client. The
> first line of the cache file should be a single byte representing the
> request-method, then the URL in plain-text ending with newline (\n). 

my grep line handily found those; another option is to grep for '-1\s*-
1 unknown' in the cache_store_log, as there's a direct connection
between broken object storage and lack of cache timing, as we've found
out since I wrote the mail.

Kudos for the hints, Amos, they're great and'll help me a lot
(tomorrow, it's 22.54 local here).

-towo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180423/517563b8/attachment.sig>