This post originated from an RSS feed registered with Ruby Buzz by Red Handed. Original Post: In and Out Filters for Hacked mod_ruby Feed Title: RedHanded Feed URL: http://redhanded.hobix.com/index.xml Feed Description: sneaking Ruby through the system Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Red Handed Latest Posts From RedHanded

I’ve been playing with an experimental MouseHole which uses an Apache output filter on content pulled through mod_proxy. On my Linux machine, mod_proxy is actually much slower than WEBrick::HTTPProxy, so there’s been no gain. Except the newly hacked input and output filters for mod_ruby.

May still have a pile of bugs, but download here: mod_ruby-filtered-12.27.2005.tar.gz.

To write your own filtered proxy:

 RubySafeLevel 0
 RubyTimeOut 10
 RubyAddPath /home/why/lib
 RubyRequire proxyTest

 
   ProxyRequests On
   
     Order deny,allow
     Deny from all
     Allow from 127.0.0.1
     RubyOutputFilter RewriterTest.instance REWRITER
     SetOutputFilter REWRITER
   
   ProxyVia On
 

And the proxyTest.rb looks like this:

 require 'singleton'

 class ProxyTest
   include Singleton

   def output_filter(filter)
     if filter.req.content_type !~ %r!text\/html!
       filter.pass_on
     else
       s = filter.read
       while s
         filter.write(s.gsub(/Ruby/i, "#{filter.req.content_type}"))
         s = filter.read
       end
       filter.close if filter.eos?
     end
   end
 end

So, yeah, the object must respond to input_filter or output_filter. (Turns to Shugo Maeda.) I think we should start duck typing mod_ruby. Rather than having to explicitly state the various handlers in the httpd.conf, we should use respond_to? in mod_ruby to scan for the capabilities of the class.