Re: [RFC] cachemgr style updates

On 29/01/11 12:23, Alex Rousskov wrote:
> On 01/27/2011 04:20 AM, Amos Jeffries wrote:
>
>> I've been looking way ahead and considering the design changes we would
>> need to upgrade the cachemgr reports to browsable HTML content. Stuff
>> beyond the simple table conversion currently done by cachmgr.cgi.
>>
>> This will all depend on the internal server feature completion, as well
>> as the visible_hostname / unique_hostname reworking. So will be 3.3
>> release at the earliest.
>>
>>
>> Access:
>>
>> * via http://$visible_hostname/ or http://$unique_hostname/ requests
>> intercepted by the internal server feature. Also https:// if SSL/TLS
>> available.
>>
>> * Splitting the manager access out into a manager_access directive ACL
>> checklist.
>> Thus ACL restrictions and authentication becomes via real HTTP auth
>> process same as http_access. Without limits like only checking the
>> password or only one password per action/report.
>>
>>
>> Formats and Encoding:
>>
>> We will have to support the old cachemgr.cgi and squidclient requests
>> for some time. Which means we will have to support multiple output
>> formats in the cachemgr reports.
>>
>> * register the output types supported by the component as a parameter
>> during the registration action. So we can specify TXT, HTML, XML or any
>> other file formats which the report can be delivered in. Default to
>> start with just being TXT.
>>
>> * Using the URL filename portion to encode the type of report.
>> Alternative content formatting would appear under /.../action.html or
>> /.../action.xml etc.
>> The old API just requests /.../action as the path. So this can be
>> mapped to produce the old TXT format also available as /.../action.txt.
>> ** as a bonus "squidclient mgr:action.txt" could be requested already.
>> Making that interface somewhat forward-compatible.
>> ** cachemgr.cgi is obsolete with this feature so does not matter.
>>
>> Nothing unusual there from the user perspective. I hope.
>
> Sounds good to me.
>
> Your design seems to be compatible with our Cache Manager Phase 3 patch
> that Christos just posted for review:
>
> mgr:action
> becomes
> mgr:action.txt?worker=1
>
> Or, if you want to reuse the new parameter code at the expense of
> extension, you could do:
>
> mgr:action?worker=1&format=text/plain
>
> I hope Squid itself will not have to output reports in more than two
> formats (plain text and possibly "raw" XML of some sort). Beautification
> and post-processing should be done outside of Squid key processes for
> security and code quality reasons, IMO.

If we can do pure XML and get the browser to stylesheet it cleanly into
HTML for display then I would love to see that happen too. Otherwise we
will likely be stuck with xhtml for a while.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.10
   Beta testers wanted for 3.2.0.4