Topic: Problems with Media Temple and post requests

I'm not certain, but I think I'm having a problem with my app
receiving post requests in production. I've got two distinct problems
that only manifest themselves in production on a Media Temple Grid
Server plan. I'm using Capistrano to deploy and I'm running Rails
1.2.3.

The first problem is that I've got a form that auto-submits when a
select menu is changed. The form submits, but doesn't appear to submit
a post request. I've got an if statement checking if request.post?
that returns false, and I don't see anything indicating a post request
in the production.log file. It works perfectly on my development
machine, though.

The second problem is that my create actions aren't being invoked in
certain cases where I'm using attachment_fu. It's a similar problem,
where post requests don't seem to be processed correctly in
production. Basically, I submit a form using RESTful conventions and
the index action is invoked instead of the create action.

I'm wondering if these two problems are related in that they both
involve improper handling of post request in production. I posted some
additional detail here as well: http://www.railsweenie.com/forums/6/topics/1378

If somebody has experienced this, or thinks they know what's going on,
I'd appreciate any help you can provide. I can't seem to track down
the problem, and I'm completely out of ideas.

Thanks much!

Re: Problems with Media Temple and post requests

How is the form being submitted automatically when the select menu changes? Are you using javascript? Can you post that?

You might want to try taking Rails out of the picture entirely. Take the HTML from your rails site and make a few static pages. Does the same problem exist for the static pages? Check your web server logs to see if it's receiving a POST request properly.

Does the behavior change when using a different web browser?

Railscasts - Free Ruby on Rails Screencasts

Re: Problems with Media Temple and post requests

Ryan, thanks for your reply.

The javascript and form are like so:

<form action="/files" method="post">
<select id="upload_user_id" name="upload[user_id]" onchange="this.form.submit()">
<option value="0">User</option>
<option value="2">trevor</option>
<option value="4">Artie</option>
</select>
</form>

The "index" action that catches this form contains code like this:

if request.post?
flash[:notice] = "post"
else
flash[:notice] = "no post"
end

I'll try to make some static pages that do the same actions, but I'm just stumped as to why this would work in development and not in production.

Re: Problems with Media Temple and post requests

Hmm, that all looks correct to me. It'll be interesting to see how the static files behave.

Railscasts - Free Ruby on Rails Screencasts

Re: Problems with Media Temple and post requests

Hi ryanb, the host finally got back to me, and it looks as though they've figure out what's going wrong. I'm not sure how to work around the problem yet, though, but at least it's something. Here's what they said:

Trevor,

The problem you are running into is not caused by code or configuration, but coincidence.  Your controller is exposed as "/files" and you have a directory in your public folder called files.

When your form is created, the action is "/files".  When this post request hits the Grid, Apache sees that request (http://app.com/files) and that there is a directory there, and so appends a slash (http://app.com/files/) and redirects the browser to the new URL.  This is standard Apache behavior since most requests for a directory name are usually for the directory's contents rather than the directory itself.  Since Apache does the redirect, the post turns into a get before your Rails application even has a chance to see it.  To test this out, rename your files directory to any other name and you will see that the post request starts working again.

And, seeing that you are also having issues with the /headers and /avatars and that there are matching directories in your public directory, the same issue is probably happening there.

I'm still completely confused as to why this would be happening on their servers but not on my development machine. I also don't yet know how to work around the problem, as I'd prefer to not change the location of the files I'm uploading into public/files or the named routes that I'm using. Perhaps there's some way to force my will upon Apache smile

One thing that's definitely different between my development environment and your production environment is that I'm using symlinks in production to save uploaded files in shared/system/files. I actually did a write-up on my blog about how exactly I'm doing this:

http://www.almosteffortless.com/2007/03 … chment_fu/

Maybe these symlinks are part of the problem? They're certainly different to what I'm doing on my machine, which is simply storing the files in public/files and ignoring them in Subversion.

P.S. Railscasts is AWESOME. Good work! I've watched all of them already and subscribed to the podcast feed.

Last edited by trevorturk (2007-04-04 20:20:34)

Re: Problems with Media Temple and post requests

I got a response on the Rails Deployment mailing list that makes me think this is a problem with Media Temple:

http://groups.google.com/group/rubyonra … 0586ab0474

Re: Problems with Media Temple and post requests

That's really good info to know. Glad you found out the problem.

As for the solution, what Ezra said on the deployment mailing list sounds right. It's some kind of Apache config. If they won't change the primary config file, you might be able to use a ".htacceses" file.

Railscasts - Free Ruby on Rails Screencasts

Re: Problems with Media Temple and post requests

Yeah, it's a really obscure problem. I nearly tore my increasingly gray hair out trying to figure out what was going on for about 2 full days.

I'll wait and see what they're response is to my ticket, and if I have to resort to modifying my own .htaccess file, I'll post the solution here.

Re: Problems with Media Temple and post requests

I got some responses from Media Temple about this, but it looks like they're saying that there is nothing wrong with their configuration. I disagree, but I think I've reached the end of the line with their support team.

If you're curious, I've posted on the progress here:

http://groups.google.com/group/rubyonra … 0586ab0474

The summary:

In short, posting a form to something like avatars_url in an attempt
to invoke a create action will be (wrongly) redirected to the index
action if there is a public/avatars directory (or, more specifically,
a symlink in that location that points to shared/system/avatars). MT
says that Apache is picking up the request and redirecting it to the
index action before Rails sees it because of the existence of this
folder/symlink in the public directory. Apparently, this is the
intended behavior, which strikes me as odd... I would think that using
"avatars_path" for the url SHOULD work fine in any deployment
scenario.

Am I crazy?