David Morton
2005-Nov-16 15:35 UTC
scgi routing problem not DRY (update to SCGI and caching not right)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I''m attempting to set up typo using the SCGI runner. As near as I can
tell,
here''s what happens, please tell me if I''m wrong:
The instructions for scgi and rails:
(http://wiki.rubyonrails.com/rails/pages/SCGI+Rails+Runner+with+Apache+2+on+Linux)
seem to indicate to set the scgi base to /scgi-bin/:
SCGIMount /scgi-bin/ 127.0.0.1:9999
and not
SCGIMount / 127.0.0.1:9999
as I would have done on first thought. Thinking about it, I conclude that if
the scgi engine is on / and not /scgi-bin/, then a conditional rewrite rule
isn''t needed/can''t be made, and thus page caching cannot work;
apache won''t
bypass running SCGI, which is how caching works.
By placing the scgi engine on /scgi-bin/, we use a conditional rewrite to run
scgi if a cached file is not found:
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /scgi-bin/$1 [QSA,L]
This introduces an ugly sgci-bin into our url, so the workaround is to double up
on the routes:
map.connect '':controller/:action/:id''
map.connect ''scgi-bin/:controller/:action/:id''
which makes rails recognize the scgi-bin part of the path, and still write
pretty urls too. However, this is kinda repetitive when one uses a bunch of
routes, as typo does.
So, in the end, I think I can get typo running in one of two ways:
1: mount scgi on /, leave routing alone, don''t use a rewriting rule.
Everything
works, except no page caching can be done, because there''s no way to
avoid scgi.
2: mount scgi on /scgi-bin and all taht, and add all the route commands to
rewrite the scgi-bin out of the request. Now routing will work.
In the end, we have a problem that in order to use SCGI, we either violate DRY
or we can''t cache pages.
- --
David Morton
Maia Mailguard - http://www.maiamailguard.com
Morton Software Design and Consulting - http://www.dgrmm.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDe1HASIxC85HZHLMRAqnMAJ9VYHnuPhp3/j1oG/1C9pYPTzHajQCdEGhI
3YmE/KhsB+cFLdQ6CaY2UiI=Q1DE
-----END PGP SIGNATURE-----
Paul Wright
2005-Nov-16 16:25 UTC
Re: scgi routing problem not DRY (update to SCGI and caching not right)
If there is a solution to this then I''d be very interested to hear it. I spent a while with Kyle in irc trying to work though this issue but in the end we settled on the non-DRY doubling up on routes as at least it works and allows non-Rails requests to be handled straight by apache which to me seems to be the Right Thing. I think it could be solved but it would require someone with intimate routes knowledge to know where to add in the prefix automatically when routes are loaded. Kyle tried a number of approaches but he seemed to always hit the problem that routes had already been loaded or could only be loaded once. Maybe the new plugin interface exposes some useful stuff? Paul. On 16/11/05, David Morton <mortonda-0/IDydmJJnNeoWH0uzbU5w@public.gmane.org> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I''m attempting to set up typo using the SCGI runner. As near as I can tell, > here''s what happens, please tell me if I''m wrong: > > The instructions for scgi and rails: > > (http://wiki.rubyonrails.com/rails/pages/SCGI+Rails+Runner+with+Apache+2+on+Linux) > > seem to indicate to set the scgi base to /scgi-bin/: > > SCGIMount /scgi-bin/ 127.0.0.1:9999 > > and not > > SCGIMount / 127.0.0.1:9999 > > as I would have done on first thought. Thinking about it, I conclude that if > the scgi engine is on / and not /scgi-bin/, then a conditional rewrite rule > isn''t needed/can''t be made, and thus page caching cannot work; apache won''t > bypass running SCGI, which is how caching works. > > By placing the scgi engine on /scgi-bin/, we use a conditional rewrite to run > scgi if a cached file is not found: > > RewriteRule ^([^.]+)$ $1.html [QSA] > RewriteCond %{REQUEST_FILENAME} !-f > RewriteRule ^(.*)$ /scgi-bin/$1 [QSA,L] > > This introduces an ugly sgci-bin into our url, so the workaround is to double up > on the routes: > > map.connect '':controller/:action/:id'' > map.connect ''scgi-bin/:controller/:action/:id'' > > which makes rails recognize the scgi-bin part of the path, and still write > pretty urls too. However, this is kinda repetitive when one uses a bunch of > routes, as typo does. > > So, in the end, I think I can get typo running in one of two ways: > > 1: mount scgi on /, leave routing alone, don''t use a rewriting rule. Everything > works, except no page caching can be done, because there''s no way to avoid scgi. > > 2: mount scgi on /scgi-bin and all taht, and add all the route commands to > rewrite the scgi-bin out of the request. Now routing will work. > > In the end, we have a problem that in order to use SCGI, we either violate DRY > or we can''t cache pages. > > - -- > David Morton > Maia Mailguard - http://www.maiamailguard.com > Morton Software Design and Consulting - http://www.dgrmm.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDe1HASIxC85HZHLMRAqnMAJ9VYHnuPhp3/j1oG/1C9pYPTzHajQCdEGhI > 3YmE/KhsB+cFLdQ6CaY2UiI> =Q1DE > -----END PGP SIGNATURE----- > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Trevor Squires
2005-Nov-16 17:25 UTC
Re: scgi routing problem not DRY (update to SCGI and caching not right)
Guys, this didn''t affect me on my OSX box running apache 1 for some reason (as in I didn''t need to double up on the connect calls). However, it *does* seem to be required on my apache 2 on linux server. I''ve got the guts of a plugin working 50% to fix this. I''ll ping when it''s done. Regards, Trevor On 16-Nov-05, at 8:25 AM, Paul Wright wrote:> If there is a solution to this then I''d be very interested to hear it. > I spent a while with Kyle in irc trying to work though this issue but > in the end we settled on the non-DRY doubling up on routes as at least > it works and allows non-Rails requests to be handled straight by > apache which to me seems to be the Right Thing. > > I think it could be solved but it would require someone with intimate > routes knowledge to know where to add in the prefix automatically when > routes are loaded. Kyle tried a number of approaches but he seemed to > always hit the problem that routes had already been loaded or could > only be loaded once. > > Maybe the new plugin interface exposes some useful stuff? > > Paul. > > On 16/11/05, David Morton <mortonda-0/IDydmJJnNeoWH0uzbU5w@public.gmane.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I''m attempting to set up typo using the SCGI runner. As near as I >> can tell, >> here''s what happens, please tell me if I''m wrong: >> >> The instructions for scgi and rails: >> >> (http://wiki.rubyonrails.com/rails/pages/ >> SCGI+Rails+Runner+with+Apache+2+on+Linux) >> >> seem to indicate to set the scgi base to /scgi-bin/: >> >> SCGIMount /scgi-bin/ 127.0.0.1:9999 >> >> and not >> >> SCGIMount / 127.0.0.1:9999 >> >> as I would have done on first thought. Thinking about it, I conclude >> that if >> the scgi engine is on / and not /scgi-bin/, then a conditional >> rewrite rule >> isn''t needed/can''t be made, and thus page caching cannot work; apache >> won''t >> bypass running SCGI, which is how caching works. >> >> By placing the scgi engine on /scgi-bin/, we use a conditional >> rewrite to run >> scgi if a cached file is not found: >> >> RewriteRule ^([^.]+)$ $1.html [QSA] >> RewriteCond %{REQUEST_FILENAME} !-f >> RewriteRule ^(.*)$ /scgi-bin/$1 [QSA,L] >> >> This introduces an ugly sgci-bin into our url, so the workaround is >> to double up >> on the routes: >> >> map.connect '':controller/:action/:id'' >> map.connect ''scgi-bin/:controller/:action/:id'' >> >> which makes rails recognize the scgi-bin part of the path, and still >> write >> pretty urls too. However, this is kinda repetitive when one uses a >> bunch of >> routes, as typo does. >> >> So, in the end, I think I can get typo running in one of two ways: >> >> 1: mount scgi on /, leave routing alone, don''t use a rewriting rule. >> Everything >> works, except no page caching can be done, because there''s no way to >> avoid scgi. >> >> 2: mount scgi on /scgi-bin and all taht, and add all the route >> commands to >> rewrite the scgi-bin out of the request. Now routing will work. >> >> In the end, we have a problem that in order to use SCGI, we either >> violate DRY >> or we can''t cache pages. >> >> - -- >> David Morton >> Maia Mailguard - http://www.maiamailguard.com >> Morton Software Design and Consulting - http://www.dgrmm.net >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.2 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >> >> iD8DBQFDe1HASIxC85HZHLMRAqnMAJ9VYHnuPhp3/j1oG/1C9pYPTzHajQCdEGhI >> 3YmE/KhsB+cFLdQ6CaY2UiI>> =Q1DE >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Trevor Squires http://somethinglearned.com
David Morton
2005-Nov-16 18:37 UTC
Re: scgi routing problem not DRY (update to SCGI and caching not right)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Wright wrote:> I think it could be solved but it would require someone with intimate > routes knowledge to know where to add in the prefix automatically when > routes are loaded. Kyle tried a number of approaches but he seemed toThis is the route (pun not intended) I was thinking of, but when I looked at the routing code, I was thoroughly confused. I''m anxious to see what Trevor has going with his plugin... - -- David Morton Maia Mailguard - http://www.maiamailguard.com Morton Software Design and Consulting - http://www.dgrmm.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDe3yBSIxC85HZHLMRAjsMAJ9Yp5eNGKd8g5ODb3Az/oszHorhpQCgmNkO YqSkS3XUSp5TmqR53C2M/GU=5HOc -----END PGP SIGNATURE-----
Trevor Squires
2005-Nov-16 22:28 UTC
Re: scgi routing problem not DRY (update to SCGI and caching not right)
I''ve completed a plugin that fixes this for me - it works fine on my install of typo. I''d rather not release it before it''s tested by at least one other person so if anyone is interested in testing it, please contact me off-list. Regards, Trevor On 16-Nov-05, at 8:25 AM, Paul Wright wrote:> If there is a solution to this then I''d be very interested to hear it. > I spent a while with Kyle in irc trying to work though this issue but > in the end we settled on the non-DRY doubling up on routes as at least > it works and allows non-Rails requests to be handled straight by > apache which to me seems to be the Right Thing. > > I think it could be solved but it would require someone with intimate > routes knowledge to know where to add in the prefix automatically when > routes are loaded. Kyle tried a number of approaches but he seemed to > always hit the problem that routes had already been loaded or could > only be loaded once. > > Maybe the new plugin interface exposes some useful stuff? > > Paul. > > On 16/11/05, David Morton <mortonda-0/IDydmJJnNeoWH0uzbU5w@public.gmane.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I''m attempting to set up typo using the SCGI runner. As near as I >> can tell, >> here''s what happens, please tell me if I''m wrong: >> >> The instructions for scgi and rails: >> >> (http://wiki.rubyonrails.com/rails/pages/ >> SCGI+Rails+Runner+with+Apache+2+on+Linux) >> >> seem to indicate to set the scgi base to /scgi-bin/: >> >> SCGIMount /scgi-bin/ 127.0.0.1:9999 >> >> and not >> >> SCGIMount / 127.0.0.1:9999 >> >> as I would have done on first thought. Thinking about it, I conclude >> that if >> the scgi engine is on / and not /scgi-bin/, then a conditional >> rewrite rule >> isn''t needed/can''t be made, and thus page caching cannot work; apache >> won''t >> bypass running SCGI, which is how caching works. >> >> By placing the scgi engine on /scgi-bin/, we use a conditional >> rewrite to run >> scgi if a cached file is not found: >> >> RewriteRule ^([^.]+)$ $1.html [QSA] >> RewriteCond %{REQUEST_FILENAME} !-f >> RewriteRule ^(.*)$ /scgi-bin/$1 [QSA,L] >> >> This introduces an ugly sgci-bin into our url, so the workaround is >> to double up >> on the routes: >> >> map.connect '':controller/:action/:id'' >> map.connect ''scgi-bin/:controller/:action/:id'' >> >> which makes rails recognize the scgi-bin part of the path, and still >> write >> pretty urls too. However, this is kinda repetitive when one uses a >> bunch of >> routes, as typo does. >> >> So, in the end, I think I can get typo running in one of two ways: >> >> 1: mount scgi on /, leave routing alone, don''t use a rewriting rule. >> Everything >> works, except no page caching can be done, because there''s no way to >> avoid scgi. >> >> 2: mount scgi on /scgi-bin and all taht, and add all the route >> commands to >> rewrite the scgi-bin out of the request. Now routing will work. >> >> In the end, we have a problem that in order to use SCGI, we either >> violate DRY >> or we can''t cache pages. >> >> - -- >> David Morton >> Maia Mailguard - http://www.maiamailguard.com >> Morton Software Design and Consulting - http://www.dgrmm.net >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.2 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >> >> iD8DBQFDe1HASIxC85HZHLMRAqnMAJ9VYHnuPhp3/j1oG/1C9pYPTzHajQCdEGhI >> 3YmE/KhsB+cFLdQ6CaY2UiI>> =Q1DE >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Trevor Squires http://somethinglearned.com