[Nitro] Nitro on Apache

Arne Brasseur arne at arnebrasseur.net
Sat Oct 20 05:21:24 EDT 2007


Robert Mela schreef:
> Mongrel uses AdapterHandlerMixin#handle_context, not Cgi.process... so 
> it should be safe.
>
> It is possible to rip Cgi.process out of CgiAdapter and replace it 
> with the same handle_context that MongrelAdapter  uses.   It may even 
> then be possible to remove Cgi.process altogether -- need to grep to 
> see where else it's used.
I did grep and as far as I can tell only the old CGI and FastCGI 
adapters used it. That's why it's removed in my patch and replaced by 
CgiAdapter#process. It's a bit of a blend between the Mongrel handler 
and the original Cgi.process :)

As for the URI handling, I did experiment a bit with stripping the 
SCRIPT_NAME in the CGI adapter and redefining EncodeURI#encode_uri to 
add it again. This should work. I left it out because it still had some 
edge cases that didn't behave right. Maybe it could be added again. 
Either way some documentation on how to set up your server so this isn't 
necessary, or how to adapt Nitro if it is necessary would be good.

(ab)
>
> George Moschovitis wrote:
>> Are you sure this doesn't break mongrel? Have you tested it?
>>
>> thanks,
>> -g.
>>
>>
>>
>> On 10/19/07, *Arne Brasseur* < arne at arnebrasseur.net 
>> <mailto:arne at arnebrasseur.net>> wrote:
>>
>>     Ok, this should fix FastCGI (and also CGI).
>>
>>     Cgi.process has been factored out into a seperate handler class
>>     and adapted to the way things currently work.
>>
>>     I've tested both CGI and FastCGI with Lighttpd and wrote a Tip on
>>     OxyWTF on how to configure Lighttpd for FastCGI.
>>
>>     (ab)
>>
>>     Arne Brasseur schreef:
>>>     Patience, I'm almost done with this.
>>>
>>>     (ab)
>>>
>>>     Robert Mela schreef:
>>>      
>>>>     Here's an initial cracking of the nut.  Needs much refinement.
>>>>
>>>>     I have no idea whether this handles posts or not -- my hope is 
>>>> all the     gnarly details are now handled by handle_context in 
>>>> adapter.rb
>>>>     .
>>>>
>>>>     If the approach is acceptable then there's probably a lengthy 
>>>> method     in raw/cgi.rb that can be removed.
>>>>
>>>>
>>>>     require "raw/adapter"
>>>>
>>>>     # No multi-threading.
>>>>     Og.thread_safe = false if defined?(Og) and     
>>>> Og.respond_to?(:thread_safe)
>>>>
>>>>     module Raw
>>>>
>>>>     # A plain CGI adapter. To be used only in development
>>>>     # environments, this adapter is *extremely* slow for
>>>>     # live/production environments. This adapter is provided for
>>>>
>>>>     # the sake of completeness.
>>>>
>>>>      class CgiAdapter
>>>>        include AdapterHandlerMixin
>>>>             def start(server)     # for server in context of CGI 
>>>> this is start,     middle and end!
>>>>          @application = server # expected by handle_context in     
>>>> adapter.rb
>>>>          context = Context.new(server)
>>>>          context.env = ENV
>>>>          uri = ENV['REQUEST_URI']
>>>>          script_name = ENV['SCRIPT_NAME']
>>>>          context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '')
>>>>
>>>>          handle_context( context )
>>>>          puts "Content-type: #{context.content_type}"
>>>>          context.response_headers['Content-length'] =     
>>>> context.output_buffer.length
>>>>          context.response_headers.each
>>>>      { |k,v| puts "#{k}: #{v}" }
>>>>          puts "\n"
>>>>          puts context.output_buffer
>>>>        end
>>>>      end
>>>>     end
>>>>
>>>>        
>>>>>     Arne Brasseur wrote:
>>>>>          
>>>>>>     This seems the way to go, but unfortunately mod_proxy is not 
>>>>>> an     option for me. I'm on shared hosting with little chance of 
>>>>>> changing     apache's configuration, except by .htaccess files. 
>>>>>> It seems both cgi
>>>>>>     and fcgi adapters are simply broken because of changes to the 
>>>>>>     adapter interface. E.g. what used to be class methods are now 
>>>>>>     instance methods, but that's not all.
>>>>>>
>>>>>>     Would it be hard to fix them? Or just one of them? I'm not too
>>>>>>     concerned about performance at this point, if it runs I'd be 
>>>>>> happy.     If they're not being fixed please add a big BROKEN 
>>>>>> sign or remove     them altogether.
>>>>>>
>>>>>>     Thank you (once again)!
>>>>>>
>>>>>>     (ab)
>>>>>>                             
>>>>>     _______________________________________________
>>>>>     Nitro-general mailing list
>>>>>     Nitro-general at rubyforge.org
>>>>>      <mailto:Nitro-general at rubyforge.org>
>>>>>     http://rubyforge.org/mailman/listinfo/nitro-general
>>>>>           
>>>>     _______________________________________________
>>>>     Nitro-general mailing list
>>>>     Nitro-general at rubyforge.org
>>>>      <mailto:Nitro-general at rubyforge.org>
>>>>     http://rubyforge.org/mailman/listinfo/nitro-general
>>>>         
>>>       
>>
>>
>>     --     Arne Brasseur
>>     http://www.arnebrasseur.net
>>     http://www.zhongwiki.com
>>     http://www.bankske.org
>>     arne at arnebrasseur.net <mailto:arne at arnebrasseur.net>
>>        
>>
>>     _______________________________________________
>>     Nitro-general mailing list
>>     Nitro-general at rubyforge.org <mailto:Nitro-general at rubyforge.org>
>>     http://rubyforge.org/mailman/listinfo/nitro-general
>>
>>
>>
>>
>> -- 
>> http://gmosx.me.gr
>> http://phidz.com
>> http://blog.gmosx.com
>> http://cull.gr
>> http://www.joy.gr
>> http://nitroproject.org
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


-- 
Arne Brasseur
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
arne at arnebrasseur.net



More information about the Nitro-general mailing list