[Mongrel] Bare carriage returns in HTTP headers

Jonathan Rochkind rochkind at jhu.edu
Thu Mar 26 11:17:39 EDT 2009

My problem was with invalid query strings being sent to me by a vendor, 
not with problems in the header. So it won't be _exactly_ the same. I'm 
not sure if an apache rewrite map can change headers or not; it can 
change path/query string, which is all I needed. But I can show you what 
I did, in case it gives you ideas. It was a bit of a pain to figure out.

Here's the apache.conf I use to deploy my app (actually, this is a Rails 
erb template for such a file, but you'll figure it out):


The parts to pay attention to is just the part that uses a perl script 
as as an apache 'external rewrite map', here:

  # We want to re-write URLs with 'bad' < and > chars in the query
  # string (eg from EBSCO) to escape them. We use a perl script
  # that came with Umlaut to do that. 
  RewriteEngine on
  RewriteMap query_escape prg:<%= destination_path('script/umlaut/rewrite_map.pl') %>
  #RewriteLock /var/lock/subsys/apache.rewrite.lock
  RewriteCond %{query_string} ^(.*[\>\<].*)$
  RewriteRule ^(.*)$ $1?${query_escape:%1} [R,L,NE] 

And here's the simple Perl script that replaced illegal chars in URL 
path/query string:


Hope that helps,


Dido Sevilla wrote:
> On Wed, Mar 25, 2009 at 12:15 AM, Jonathan Rochkind <rochkind at jhu.edu> wrote:
>> I've run into other malformed HTTP requests in other circumstances, and the
>> solution I ended up with was using Apache rewrite maps to "fix" those
>> malformed requests before they even get to mongrel.  I'm not sure if that
>> solution would work for this particular error, but sounds like you've found
>> another one.
> Any hints on how I can do this? Obviously I have no control over what
> hits my HTTP server and must deal with the broken clients as best I
> can. Ironically, modifying the Mongrel parser to work around this
> particular broken HTTP client turned out to be a lot easier than
> sifting through the Apache documentation to find a particular module
> that would do what needed to be done...
>> I wouldn't hold my breath for that patch to be incorporated in mongrel
>> though, the mongrel philosophy seems to be to be conservative in what it
>> accepts.
> Neither do I expect it to get incorporated, in spite of its
> simplicity. The patch does not make me comfortable in the least.
> By the way, if control characters are not allowed in field values, why
> does the regex for field_value in the current SVN source have an any*
> expression rather than a more restrictive class of characters that it
> can accept? That means that we could put some other control character
> there and have Mongrel accept it anyway, in spite of its being
> prohibited by RFC 2616.

More information about the Mongrel-users mailing list