[squid-dev] What is your opinion: Debugging and cache enhancement tool, what is the preferred implementation?
eliezer at ngtech.co.il
Thu Nov 19 10:54:54 UTC 2015
OK so I have been experimenting with some ICAP service for a very long
time now and I am thinking about writing some tool and I am considering
the options in the list.
Since squid has couple limits and will not cache some content many ask
again and again "why" it something not being cached.
The first answer is "debug_options XYZ". While it works and gives
everything still the admin needs to sit and do all these weird things
tracking down a single request over and over.
There is no option in squid to add some debugging response header which
will explain to the admin why it was not cached(yet).
Also redbot is nice but it has couple limits of usage which are pretty
obviates... it cannot be used in internal networks without installing
it, also it has a basic robot.txt obeying policy to prevent DOS and
More then that is the fact that different services are dynamic and based
on specific origin or limited to a country\ip\other unknown factor.
So RedBot is a great and informative tool but sometimes it just cannot
help the admin to know what happens in his system.
And RedBot is testing for basic RFC compatibility and not what squid can
or will decide.
With all the above I have two options:
- adding code to squid which with a on\off switch(can be some
debug_options level) will add an informative header... like many CDN
proxies does already.( returning the latest StoreID that is being used
by squid, since squid changes the StoreID in some cases after the
response started... "Vary" etc)
- Writing an ICAP service that will do the trick by adding these
informative headers externally based on the understanding of squid
I know that the best practical way to do that is to add this as a squid
feature, but since I do not like to work with C++ and since it is a
complex task to learn from 0(my brain have some "ram" cache only and a
good sleep many times just restarts the cache) I will prefer to write an
ICAP service that does that.
So pros and cons:
- simpler for me to write an ICAP service in Golang
- I will have some fun time with ICAP.
- ICAP service can be used with older versions of squid which are
already in production.
- It is unclear if it's a patch or feature and who will be willing to
patch squid for that and how long it would take.
So the question, do I open this as a bug on debug_options or a wanted
I do not know how fast I can write this ICAP service but it should not
take me more then couple weeks if I will work on my spare free time.
So unless someone is willing to work on such a patch\feature in the next
month or two the ICAP service path is the fastest.
Also my specific preference for the way it should be implemented is to
add into the http response some headers since these are visible to the
admin instantly and not requiring them to look-up in the debug log which
sometimes to my opinion just creeps and specially in a big production
If you have another idea how to implement the idea let me know.
More information about the squid-dev