I'm starting to get a good idea about the uses debug levels are put to
the client and server side components. There is one useful change I
think we need to make in level-2.
The Problem:
We are often facing the situation where users need to locate header
details for tracking some issue down. At present that means using
external tools (with variable amounts of accuracy) or enabling level-9
for the protocol handling sections.
Section 11 (HTTP) in particular has a large amount of debug about
*how* its processed in level 3-6 which is irrelevant for a traffic
trace, but would be more helpful if the traffic trace was available when
viewing them.
Proposed solution:
The sections 6-12 are dedicated to the RFC protocol handling. Parsing
and specific feature handling is spread over other debug sections.
So, what I am wondering is if anyone objects to formally dedicating
level 2 of these sections to displaying the RFC protocol syntax from the
wire and any background WARNING: which are not important enough for level-1.
This would be protocol syntax only. No body data.
NP: FTP states already use this level for such debug. I'm just now
looking at it for HTTP headers and making it a documented level description.
That would make our debug levels for sections 6-12:
0 - critical issues
1 - important issues the admin should look at fix
2 - on-wire protocol syntax being received and sent
3+ - general details about what Squid does with the protocol received
The downside is a lot of cache.log text if people do ALL,2. But I think
the benefits are worth it.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.8 and 3.1.12.2
