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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
