I have a piece of code like this in one of my views:
<%=link_to “link here”, :action=>‘my_action’, :id=>1 %>
It works fine on my local development machine, running Webrick over http
and it works fine on my testing server which is running single mongrel
instance behind Apache 1.3 as a proxy. On both the outcome link is this:
link here
However having deployed it to my live server, which is running a
mongrel_cluster behind Apache 2.2 and mod_proxy_balancer. That one just
gives the following:
link here
Both the development server and the live one are running over https and
they’re both running the same versions of everything so I’m guessing
it’s something about how the https variable is being passed on the live
server (where I am able to use the X_FORWARDED_PROTO ‘https’ header
rather than having to set it manually as I do on the testing server.
Aside from a few minor configuration differences (mostly database
connection strings) the two versions of the application are the same SVN
revision and entirely identical.
All help welcome, I’m starting to get very confused here.
Ben M. wrote:
Both the development server and the live one are running over https and
they’re both running the same versions of everything so I’m guessing
it’s something about how the https variable is being passed on the live
server (where I am able to use the X_FORWARDED_PROTO ‘https’ header
rather than having to set it manually as I do on the testing server.
Quick revision to my own comment here: It is nothing to do with the
https stuff as I have exactly the same problem when I run it over http
as I was having with https.
Ben M. wrote:
I have a piece of code like this in one of my views:
<%=link_to “link here”, :action=>‘my_action’, :id=>1 %>
Another addendum, the problem is in url_for and it only comes up in the
view-
url_for :action=>‘my_action’, :id=>1
returns the correct url if called from my action and the incorrect one
if called from the view.
If I make a call from the view to @controller.send(:url_for, options)
(which is the method that action_view::url_helper makes) it works
correctly, but if I comment everything else out in
action_view::url_helper.url_for aside from that line it doesn’t work in
spite of the fact there’s no real difference to the calls.
First thing I’d do is specify the controller name and see if that fixes
the
problem. I run into this all the time with partials.
<%=link_to “link here”, :action=>‘my_action’, :id=>1 %>
try
<%=link_to “link here”, :controller=>“whatevver”, :action=>‘my_action’,
:id=>1 %>
Brian H. wrote:
First thing I’d do is specify the controller name and see if that fixes
the
problem. I run into this all the time with partials.
<%=link_to “link here”, :action=>‘my_action’, :id=>1 %>
try
<%=link_to “link here”, :controller=>“whatevver”, :action=>‘my_action’,
:id=>1 %>
Makes no difference I’m afraid. Still just links to the controller name
with no action specified.
Ben M. wrote:
Ben M. wrote:
I have a piece of code like this in one of my views:
<%=link_to “link here”, :action=>‘my_action’, :id=>1 %>
Another addendum, the problem is in url_for and it only comes up in the
view-
url_for :action=>‘my_action’, :id=>1
returns the correct url if called from my action and the incorrect one
if called from the view.
If I make a call from the view to @controller.send(:url_for, options)
(which is the method that action_view::url_helper makes) it works
correctly, but if I comment everything else out in
action_view::url_helper.url_for aside from that line it doesn’t work in
spite of the fact there’s no real difference to the calls.
Further to this I actually went into actionview/helpers/url_helper.rb
and put a bunch of logging in to find what exactly was in the “options”
hash being passed to the controller. When I put the logging in, it
worked fine.
When I took the logging out again, it still worked.
That’s kind of good news, in that the application is working now, but a
little bit worrying because I don’t have much clue what the problem was
or how I can deal with it if it happens again (?except maybe putting the
logging back in?) which is a bit nerve-wracking in a production
server…
In conclusion to this, I think the problem was due to the
edgesoft_no_cookie plugin which I had installed but wasn’t actually
implementing anywhere in my system.