<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: mod_security and Drupal 6.2 issues.</title>
	<atom:link href="http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/</link>
	<description>Nerdy. Deal with it. Or go away.</description>
	<lastBuildDate>Fri, 09 Sep 2011 17:01:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Jake Schlachter</title>
		<link>http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/comment-page-1/#comment-317</link>
		<dc:creator>Jake Schlachter</dc:creator>
		<pubDate>Sun, 03 Oct 2010 12:08:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.convolutedtheory.com/?p=15#comment-317</guid>
		<description>After doing an hour of web research on this, here&#039;s what I think is going on.  

mod_security on Dreamhost (and possibly other hosting providers) ships with default rules that will intermittently bite Drupal users.  Each of these rules is just a regex match on text in a node, or the URL being requested.  The rule is triggered intermittently - a reload usually solves the problem (and fails to trigger the rule).

The &quot;page&quot; that is &quot;not found&quot; is not actually the page the user is looking for. It&#039;s internal_error.html that is to be served when PHP dies prematurely, on account of being blocked by mod_security for this request.  Creating the internal_error.html file in the Drupal root should fix that problem.

You can add the rules above to your .htaccess file for your site, if you don&#039;t have root permissions on your server.  Instead of using LocationMatch, which is not valid for .htaccess, use this instead:


SecRuleRemoveById 960010
SecRuleRemoveById 960015
SecRuleRemoveById 960032
SecRuleRemoveById 950107


Hope that helps.  I have just made the change on my web server, and am waiting to see if any additional mod_security errors will be generated.  (They look like &quot;Premature end of script headers&quot; in the httpd error.log)</description>
		<content:encoded><![CDATA[<p>After doing an hour of web research on this, here&#8217;s what I think is going on.  </p>
<p>mod_security on Dreamhost (and possibly other hosting providers) ships with default rules that will intermittently bite Drupal users.  Each of these rules is just a regex match on text in a node, or the URL being requested.  The rule is triggered intermittently &#8211; a reload usually solves the problem (and fails to trigger the rule).</p>
<p>The &#8220;page&#8221; that is &#8220;not found&#8221; is not actually the page the user is looking for. It&#8217;s internal_error.html that is to be served when PHP dies prematurely, on account of being blocked by mod_security for this request.  Creating the internal_error.html file in the Drupal root should fix that problem.</p>
<p>You can add the rules above to your .htaccess file for your site, if you don&#8217;t have root permissions on your server.  Instead of using LocationMatch, which is not valid for .htaccess, use this instead:</p>
<p>SecRuleRemoveById 960010<br />
SecRuleRemoveById 960015<br />
SecRuleRemoveById 960032<br />
SecRuleRemoveById 950107</p>
<p>Hope that helps.  I have just made the change on my web server, and am waiting to see if any additional mod_security errors will be generated.  (They look like &#8220;Premature end of script headers&#8221; in the httpd error.log)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Drupal and mod_security : Part 2 &#171; ConvolutedTheory</title>
		<link>http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/comment-page-1/#comment-198</link>
		<dc:creator>Drupal and mod_security : Part 2 &#171; ConvolutedTheory</dc:creator>
		<pubDate>Sat, 27 Feb 2010 23:30:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.convolutedtheory.com/?p=15#comment-198</guid>
		<description>[...] gotten quite a few emails regarding my last post about Drupal and mod_security, and what those rules I&#039;m removing actually do. Well, I&#039;ll [...]</description>
		<content:encoded><![CDATA[<p>[...] gotten quite a few emails regarding my last post about Drupal and mod_security, and what those rules I&#39;m removing actually do. Well, I&#39;ll [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: epiraces</title>
		<link>http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/comment-page-1/#comment-193</link>
		<dc:creator>epiraces</dc:creator>
		<pubDate>Wed, 24 Feb 2010 16:03:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.convolutedtheory.com/?p=15#comment-193</guid>
		<description>Hi,

It would be great if you can post on why these rules are required. They were quite helpful for me. I linked them from this post http://drupal.org/node/717738#comment-2622358 but not so sure how to explain them</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>It would be great if you can post on why these rules are required. They were quite helpful for me. I linked them from this post <a href="http://drupal.org/node/717738#comment-2622358" rel="nofollow">http://drupal.org/node/717738#comment-2622358</a> but not so sure how to explain them</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Drupal Batch Job Problems? Check mod_security PHP Extension &#124; DrupalEasy</title>
		<link>http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/comment-page-1/#comment-95</link>
		<dc:creator>Drupal Batch Job Problems? Check mod_security PHP Extension &#124; DrupalEasy</dc:creator>
		<pubDate>Wed, 03 Jun 2009 18:33:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.convolutedtheory.com/?p=15#comment-95</guid>
		<description>[...] Reconfigure mod_security [...]</description>
		<content:encoded><![CDATA[<p>[...] Reconfigure mod_security [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PiciMaci</title>
		<link>http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/comment-page-1/#comment-43</link>
		<dc:creator>PiciMaci</dc:creator>
		<pubDate>Mon, 22 Dec 2008 21:04:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.convolutedtheory.com/?p=15#comment-43</guid>
		<description>Hi!

 Please explain me why? What are these rules watching and which function are they blocking?</description>
		<content:encoded><![CDATA[<p>Hi!</p>
<p> Please explain me why? What are these rules watching and which function are they blocking?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mod_security and Drupal 6.2 issues.</title>
		<link>http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/comment-page-1/#comment-2</link>
		<dc:creator>mod_security and Drupal 6.2 issues.</dc:creator>
		<pubDate>Thu, 02 Oct 2008 14:42:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.convolutedtheory.com/?p=15#comment-2</guid>
		<description>[...] Go to the author&#8217;s original blog: mod_security and Drupal 6.2 issues. [...]</description>
		<content:encoded><![CDATA[<p>[...] Go to the author&#8217;s original blog: mod_security and Drupal 6.2 issues. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

