I have found that debugging squid, the excellent web proxy, is difficult.
I believe this is for a number of reasons, but primarily because I’m a developer, and just want to get squid working. I’ve found that I do this with a lot of tasks that are required of the small independent developer with time pressures–CSS/UI development, database design, system administration. All these are things that can be done well by competent specialists, but my clients often don’t have the money to hire them, or time to find them, so they get me. What they get is not in depth CSS knowledge and in depth knowledge of the entire user interface problem domain, for example. Rather, clients get my ability to figure out the problem (based, to a large extent on internet knowledge and to a lesser extent on my deep understanding of web applications and how they should behave) and my tenacity to test and test again to ensure that corner cases are dealt with. It’s a tradeoff.
Regardless, squid is hard for me to debug, and I found this page which lists all the options for the cache.log debugging parameters useful. However, not all that useful–‘client side routines’, number 33, apparently includes squid ACL parsing. Rather, I’ve found the Squid FAQ to be the single most helpful document in terms of my understanding squid enough to ‘get things done’. However, this time I ended up viewing the access log of my http server, while deleting my browser cache multiple times, to confirm that caching was set up the way I thought I had configured it.
[tags]squid,getting things done[/tags]