[squid-dev] What is your opinion: Debugging and cache enhancement tool, what is the preferred implementation?

[Eliezer Croitoru]

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 
service abusing.
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 
internals.

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:
+-ICAP:
- 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.
+-SQUID patch\feature:
- 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 
feature?
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 
system.
If you have another idea how to implement the idea let me know.

Thanks,
Eliezer