Rails: Why is this form triggering the wrong action? - ruby-on-rails

Question

I have a form in my app which is triggering the wrong controller action. Here's the rendered form:
<form id="edit_profile_1" class="simple_form profile windowed" method="post" enctype="multipart/form-data" action="/profiles/1" accept-charset="UTF-8">
<div style="margin:0;padding:0;display:inline">
<input type="hidden" value="✓" name="utf8">
<input type="hidden" value="put" name="_method">
<input type="hidden" value="..." name="authenticity_token">
</div>
....
</form>
So, pretty much a normal form. On my local environment this works fine, it triggers the profiles#update action. However, when deployed on Heroku for some reason this is triggering the profiles#show action, and therefore is not working.
What gives? Has anyone encountered this error before, and do you know how to fix it?
-EDIT- #Laas: Here's the production log:
2011-05-20T21:41:38+00:00 app[web.1]: Started GET "/account" for 98.201.59.6 at 2011-05-20 14:41:38 -0700
2011-05-20T21:41:40+00:00 heroku[router]: GET www.fourthenvironment.org/account dyno=web.1 queue=0 wait=0ms service=2212ms bytes=8672
2011-05-20T21:41:40+00:00 app[web.1]: Connected to NewRelic Service at collector-6.newrelic.com:80
2011-05-20T21:41:40+00:00 heroku[router]: GET www.fourthenvironment.org/javascripts/rails.js dyno=web.1 queue=0 wait=0ms service=2ms bytes=5176
2011-05-20T21:41:41+00:00 heroku[router]: GET www.fourthenvironment.org/javascripts/jquery.144.min.js dyno=web.1 queue=0 wait=0ms service=3ms bytes=78865
2011-05-20T21:41:42+00:00 heroku[router]: GET www.fourthenvironment.org/stylesheets/style.css dyno=web.1 queue=0 wait=0ms service=3ms bytes=63444
2011-05-20T21:41:47+00:00 heroku[router]: GET www.fourthenvironment.org/favicon.ico dyno=web.1 queue=0 wait=0ms service=4ms bytes=1672
2011-05-20T21:41:50+00:00 app[web.1]:
2011-05-20T21:41:50+00:00 app[web.1]:
2011-05-20T21:41:50+00:00 app[web.1]: Started POST "/profiles/1" for 98.201.59.6 at 2011-05-20 14:41:50 -0700
2011-05-20T21:41:50+00:00 heroku[router]: POST www.fourthenvironment.org/profiles/1 dyno=web.1 queue=0 wait=0ms service=102ms bytes=420
2011-05-20T21:41:50+00:00 app[web.1]: THIS SHOULD NOT BE TRIGGERED
2011-05-20T21:41:50+00:00 heroku[router]: GET www.fourthenvironment.org/profiles/1 dyno=web.1 queue=0 wait=0ms service=30ms bytes=414
2011-05-20T21:41:50+00:00 app[web.1]:
2011-05-20T21:41:50+00:00 app[web.1]:
2011-05-20T21:41:50+00:00 app[web.1]: Started GET "/account" for 98.201.59.6 at 2011-05-20 14:41:50 -0700
Note the "THIS SHOULD NOT BE TRIGGERED". Here's the controller:
class ProfilesController < ApplicationController
before_filter :authenticate_user!
def show
puts "THIS SHOULD NOT BE TRIGGERED"
redirect_to account_path
end
def edit
#profile = Profile.find(params[:id])
end
def update
puts "profiles#update"
#profile = Profile.find(params[:id])
if #profile.update_attributes(params[:profile])
redirect_to account_path, :notice => t('user.notice.updated')
else
render :action => 'edit'
end
end
end

Answer 1

It turns out the issue was related to the use of the SSL-Requirement Gem. For some reason if you send a request from an SSL page to a non-SSL page while using SSL-requirement it gets redirected. So, to fix, enable SSL-requirement on both ends of the request, and it will work. It looks like going from SSL to non SSL the gem only allows gets -- hence the bug. This looks to be irrelevant as of Rails 3.1 since a new SSL requirement functionality will be baked-in and the gem will not be required.
Many thanks to the Heroku staff for helping isolate this.

Answer 2

Seems to be identical to this problem routing-issues-with-multi-part-forms-on-heroku.
As it is only few days old, maybe it is not a coincidence and there's something awry with Heroku?

Answer 3

Why is the form tag hard coded? Use the form_tag helper
http://api.rubyonrails.org/classes/ActionView/Helpers/FormTagHelper.html