On Mon, 10 Oct 2011, William A. Rowe Jr. wrote:
This is an awfully noisy way to react to a non-existent explicit file request...
[Mon Oct 10 14:17:52.241413 2011] [core:info] [pid 10296:tid 1748] [client
fe80::9409:cb99:2430:a326:53938] File does not exist:
C:/Apache2x/htdocs/favicon.ico
[Mon Oct 10 14:17:52.242913 2011] [include:error] [pid 10296:tid 1748] [client
fe80::9409:cb99:2430:a326:53938] Could not parse expr "! $CONTENT_LANGUAGE" in
C:/Apache2x/error/include/top.html: syntax error, unexpected T_ERROR: Parse
error near '$'
[Mon Oct 10 14:17:52.242913 2011] [include:error] [pid 10296:tid 1748] [client
fe80::9409:cb99:2430:a326:53938] Could not parse expr "$HTTP_REFERER" in
C:/Apache2x/error/HTTP_NOT_FOUND.html.var: syntax error, unexpected T_ERROR:
Parse error
near '$'
What can we do here about mod_includes volume, when we simply EDONTCARE?
This was due to the error documents containing the old expr syntax (now
fixed). So this was a real issue and not EDONTCARE.
The error messages from ap_expr are not always nice, in part because bison
uses the token names from the source code in its error messages (and I
haven't found a way to change that). I have removed the 'syntax error,
unexpected T_ERROR:' from this one, but it is likely that there are more
places that need fixing.
