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 <rochk...@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.
_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users
