Are you sure this doesn’t break mongrel? Have you tested it?
thanks,
-g.
Are you sure this doesn’t break mongrel? Have you tested it?
thanks,
-g.
I just tried Mongrel, still works fine. I see no reason why it should be
affected.
(ab)
George M. schreef:
What version of Apache, gcc, and what general OS?
Are you not allowed to run your own web server at your providor?
What, generally, is the interest level in the small but growing Nitro
community in deploying with FastCGI?
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.
Path translations behind the URL generating helpers may be the thing
that breaks my idea of replacing Cgi.process with
AdapterHandlerMixin#handle_context
I also would need to see whether simply assigning context.in = STDIN is
sufficient for handling POST and other methods with request bodies.
Seems Cgi.process might be doing a bit more work there…
Arne’s adapter uses the AdapterHandlerMixin and handle_context – it’s
far more complete and polished than the partial hack I posted.
Also removes Cgi.process from cgi.rb as I thought might be desirable –
again, MongrelAdapter uses AdapterHandlerMixin#handle_context and should
be unaffected.
Yeah Arne!
I think I’ll give it a spin. Only open question so far is how well path
handling works with the router?
Arne B. wrote:
Well FastCGI should be good, but actually using CGI with Nitro isn’t
that easy. Nitro assumes that it handles the complete document-root,
while CGI scripts normally just handle a single URL. It takes some
clever server configuration to make this work the way it should. I
tried with Lighttpd, aliasing “/” to the nitro app script. This works
for the root, but not for other URL’s. I suppose with apache and
mod_rewrite it should be possible.
I find the routing works fine if you use this the cgi adapter before
handing the work off to AdapterHandlerMixin#handle_context:
uri = ENV['REQUEST_URI']
script_name = ENV['SCRIPT_NAME']
context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '')
Somewhere inside @application.dispatcher.dispatch_context(context) –
called from handle_context – everything is magically generated from
REQUEST_URI.
Question for George:
It looks to me like Cgi::Http::process in the current CgiAdapter could
be replaced by a little setup, leaving the heaving lifting to
AdapterHandlerMixin#handle_context. I suspect that handle_context is
likely to be better maintained, since it’s what MongrelAdapter uses.
This CGI adapter thing seems a little thing, but who knows – it might
hook that one 14-year old developer in Mozambique who only has CGI via a
friend’s account, and latches on to Nitro because it works with CGI…
then later turns into a super coder…
Robert M. 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)
mailto:[email protected]> wrote:
all the gnarly details are now handled by handle_context in
Og.thread_safe = false if defined?(Og) and
class CgiAdapterend
instance methods, but that's not all.
_______________________________________________
_______________________________________________
Nitro-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/nitro-general
–
Arne B.
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
[email protected]
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs