https://bz.apache.org/bugzilla/show_bug.cgi?id=57531
--- Comment #3 from Brian Behlendorf <[email protected]> --- I am hitting this too, oddly also with the same specific error, 400 Bad Gateway, with the default config file thus pulling in HTTP_BAD_GATEWAY.html.var. I wonder if it's related to this snippet from: https://httpd.apache.org/docs/2.4/upgrading.html#misc "Multi-language error documents from 2.2.x may not work unless they are adjusted to the new syntax of mod_include's #if expr= element or the directive SSILegacyExprParser is enabled for the directory containing the error documents." Is your "400.html" the same file as the stock HTTP_BAD_GATEWAY.html.var? I tried to see if there was any particular error in HTTP_BAD_GATEWAY.html.var relating to the #if expr= syntax and didn't find anything obvious. Nor could I reproduce the error with my hand-cobbled HTTP requests designed to trigger 400 responses, but I do get them in production, so realistic traffic can trigger it. However, when I change my config to eliminate ONLY the following line from my extra/httpd-multilang-errordoc.conf: #ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var that stopped all my core dumps, so it strongly suggests either a bug in that error message's server-parsed HTML (which still shouldn't trigger a core dump!!) or an error while processing a bad HTTP request that makes setting up the CGI environment variables fail spectacularly. Hoping this can get some attention from folks who'd know... -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
