From: Williams, David A. <david.williams@USPTO.GOV> - 2009-02-20 18:18:38
Quick follow-up: I was able to use the slightly less aggressive
SecResponseBodyAccess Off but when I started to try to pin it down to a
rule or two, I had no luck. I tried SecRuleRemoveById "1-99999999" and
still had the problem.
Date: Fri, 20 Feb 2009 11:11:29 -0500
From: "Williams, David A." <david.williams@...>
Subject: [mod-security-users] Odd interation with Multiviews, SSI and
Content-Type: text/plain; charset=us-ascii
I've tried searching for others who seen this problem without
luck so perhaps I am somewhat unique. I'm configuring a section of a
web site for multilingual content using Multiviews. When SecRuleEngine
is ether On or DetectionOnly the response is rewritten with negotiated
content coming before the header.
For the URL test.html I have two physical files: test.html.en
and test.html.es (in English and Spanish respectively). Each of those
files uses the same server side include directive (<!--#include
virtual="ssi/left_nam.html"--> to load language appropriate navigation
files (ssi/left_nav.html.en and ssi/left_nav.html.es).
With SecRuleEngine off for that portion of the web site, a
request for test.html with either a browser-based language preference or
a cookie-based language preference, returns the content of test.html.en
(including ssi/left_nav.html.en in the correct part of the body) for
someone looking for English and the *.es version for someone looking for
Spanish. In both cases, the magic of content negotiation keeps the url
the same: test.html
When I have SecRuleEngine either on or DetctionOnly, the content
of the correct ssi/left_nav.html.* file is returned first to the browser
before the head and body of the file. It's as if the SSI tag was the
first line in the file. Non-content negotiated SSIs are rendered
With default logging, mod_security does not report any issues
with the request either in modsec_audit.log or error_log. Apache is
version 2.2.3, mod_security is 2.5.7, OS is CentOS 5.2.
At this point, I have SecRuleEngine off for that area of the
site, but I'm hoping to find a less aggressive approach to fixing the
Has anyone else seen this? Any suggestions for troubleshooting?
Systems Development and Maintenance Group
U.S. Patent & Trademark Office
Madison West, 4D35
Alexandria, VA 22314