[PREVIEW] Error page format codes upgrade

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 07 Apr 2013 17:48:25 +1200

What this does is convert ErrorState object to using the generic
libformat.la parser and macro expansions instead of its own rather
limited custom ones for error pages and deny_info URL creation.

This patch is a [PREVIEW] instead of [PATCH] because of the large
performance issues detailed in NOTES below which I would like to see
fixed before this goes into trunk. Any assistance there would be
welcome. Other than that it appears to be fully working for at least the
default level of build tests and a test page using all the codes appears
to be correct.

Change Summary:
1) register the 1-byte error page macros as libformat codes
2) convert the ErrorState::Convert macro expander to use those codes
instead of char literals
3) extend the libformat to handle several process-wide informational
macros and a human-readabhe RFC1123 time format
4) extend the Format::assemble method to call the adapted
ErrorState::Convert function when it encounters byte codes requiring
ErrorState special handling
5) convert the ErrorState::ConvertText and ErrorState::DenyInfoLocation
methods to use the libformat API to parse and assemble the output page

NOTES:
*a) Several of the error page macros are better served by other
logformat macro expansions. However on some the interaction between
deny_info and ERR_* template usages has required that the
ErrorState::Convert logics be used for now. I am not sure at this poiint
if they should stay in ErrorState long term and be treated like the
Ssl::ErrorDetails macros, or be shifted to libformat.

*b) Doing a whole parse cycle for every error response is very costly.
We are already loading the text page files on every error response. This
adds the un-optimized libformat parser lag on top of that. To avoid this
we really need to add a cache for error page templates and strings, such
that each one is only loaded and parsed once. From that we can more
speedily assemble the expansions final output.

*c) For now AccessLogEntry equired by the libformat API is generated by
ErrorState just before use. Ideally the code creating the ErrorState
should pass it an already filled out ALE object for the transaction.
This way we will get a lot more of the libformat macros filled out.

*d) To manage libformat calling ErrorState::Convert as a method, and
recursive macros saving on AccessLogEntry object creation this adds an
ErrorState* to AccessLogEntry and vice versa. For now creating a
circular referance loop at runtime. The ALE object is "owned" by the
ErrorState so the ErriorState::ale_ is a Pointer, whereas the
AccessLogEntry::errorDetails is a raw-pointer explicitly set/unset only
set when teh AccessLogEntry is in use by ErrorState code, and
unconditionally dropped to avoid circular existence dependencies.
    ** any assistance making a design to avoid this circular linkage is
welcome.

Amos

Received on Sun Apr 07 2013 - 05:48:30 MDT

This archive was generated by hypermail 2.2.0 : Thu Apr 18 2013 - 12:00:06 MDT