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):
http://umlaut.rubyforge.org/svn/trunk/lib/generators/mongrel_deploy_files/templates/umlaut_http.conf
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:
http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl
Hope that helps,
Jonathan
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.
>>