Rails views now display as verbatim HTML

Hello all. I am hoping this is some simple thing that you can help me
with. A few years ago I put together a couple of rails applications,
and they have been running nicely -- until I just did an upgrade of
the server they run on. They still run on the upgraded server (but
not in a way that is of any use). What happens now is that any view
gets rendered as verbatim HTML, the browser does not process any of
the HTML!!

I am running rails 2.3.5 (or so it tells me) and have no clue what
version I was running prior to the upgrade

I have made some progress on this.

I am running my rails apps as a mongrel cluster behind an
apache server with an Apache reverse proxy set up. This has
been just fine until very recently.

If I go directly to the mongrel server via http://localhost:8001
everything is fine. It is when I go to the apache "public" URL
that my pages do not render. Apparently apache is setting the
Content-Type to text/plain and this instructs the browser to not
render the html. It turns out that rails does not set the Content-Type
header at all, and Apache feels it just must do something.

I have attempted to use a before_filter in my application controler to
allow me to set headers['Content-Type'] in my application, but to no
avail. Rails still is not sending any Content-Type header at all (which
is perplexing and annoying).

At least now I understand what is wrong, and now either have to figure out
how to bully rails into sending a text/html Content-Type header or convince
Apache to set this for the proxied pages.

Any suggestions will be immediately put to the test.

How are you determining that? I can see (using Firebug) a content-type
header on any response from a standard mongrel-based app here, e.g.

Content-Type text/html; charset=utf-8

I use "telnet localhost 8001" then type "GET / HTTP/1.1" followed
by two returns and then I get the server response.

I use "telnet localhost 8001" then type "GET / HTTP/1.1" followed
by two returns and then I get the server response.

I'd suggest using Firebug for a more realistic environment (sending
Accept headers, etc. with the request) but regardless --

$ telnet localhost 3000
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying fe80::1...
telnet: connect to address fe80::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 200 OK
Connection: close
Last-Modified: Mon, 31 May 2010 15:05:02 GMT
Content-Type: text/html
Content-Length: 7625

....

What version of Ruby and Mongrel are you using?

I'd suggest using Firebug for a more realistic environment (sending
Accept headers, etc. with the request) but regardless --

What version of Ruby and Mongrel are you using?

Ruby is version 1.8.6
Rails is 2.3.5

However, this application was built long ago, probably with rails 1.2.3
and may be inheriting old behaviors.
The only rails now installed on my server though is 2.3.5

The headers I get from my old application are as follows:

(/u1/tom) cholla $ telnet localhost 8001
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 200 OK
Connection: close
Content-Length: 1877

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

Ruby is version 1.8.6
Rails is 2.3.5
Mongrel is 1.1.5

Are you absolutely sure the old version of rails isn't in the app's
vendor directory?

What's in /vendor, /vendor/gems and /vendor/plugins ?

Are you absolutely sure the old version of rails isn't in the app's
vendor directory?

At this point, there aren't many things I am absolutely sure of. :slight_smile:

What's in /vendor, /vendor/gems and /vendor/plugins ?

My application is at /u1/rails/micros
There is a directory /u1/rails/micros/vendor

The directory is empty (apart from another empty directory vendor/plugins)

All my rails "stuff" is at /usr/lib/ruby/gems/1.8/gems

The old rails versions used to be here also,
but were deleted months ago to avoid mischief and confusion.

Thanks for your help and valuable probing questions.

At this point, there aren't many things I am absolutely sure of. :slight_smile:

:slight_smile:

The old rails versions used to be here also,
but were deleted months ago to avoid mischief and confusion.

Is there a line in config/environment.rb that starts with
  RAILS_GEM_VERSION =

If so, what is it?

And what does `gem list --local` produce?

Is there a line in config/environment.rb that starts with
  RAILS_GEM_VERSION =

If so, what is it?

It is commented out and looks exactly like this:

#RAILS_GEM_VERSION = '1.2.3' unless defined? RAILS_GEM_VERSION

As I remember I commented this out about a year ago when I converted
from 1.2.3 to 2.3.5 or whatever 2.x.x version I converted to then.
As I remembered back then I did rake rails:update at the time and
this was a good thing to do then.

And what does `gem list --local` produce?

(~) cholla $ gem list --local

*** LOCAL GEMS ***

actionmailer (2.3.5, 1.3.3)
actionpack (2.3.5, 1.13.3)
actionwebservice (1.2.3)
activerecord (2.3.5, 1.15.3)
activeresource (2.3.5)
activesupport (2.3.5, 1.4.2)
cgi_multipart_eof_fix (2.5.0)
daemons (1.0.10)
fastercsv (1.2.1)
fastthread (1.0.7)
gem_plugin (0.2.3)
gettext (2.1.0)
hpricot (0.8.2)
locale (2.0.5)
mislav-will_paginate (2.3.2)
mongrel (1.1.5)
mongrel_cluster (1.0.5)
rack (1.1.0)
rails (2.3.5, 1.2.3)
rake (0.8.7, 0.7.3)
ruby-opengl (0.60.1)
sqlite3-ruby (1.2.4)
zoom (0.4.1)

I have this growing feeling that I need to start from scratch
with 2.3.5 and hand migrate my application.

(~) cholla $ gem list --local

Nothing's really jumping out at me from that list...

I have this growing feeling that I need to start from scratch
with 2.3.5 and hand migrate my application.

and having been there -- yeah, that's probably the quickest way to
resolve this :slight_smile:

My only suggestions:

1) If you don't have unit tests, you might want to try running your app
under the original version of Rails and write some before (re-)upgrading.
My first Rails apps had none, but I've learned :slight_smile:

2) Version control -- git is easy, but whatever -- is a blessing. It *will*
make the process much less stressful.

Good luck!

Hassan Schroeder wrote:

Hassan Schroeder wrote:
>> (~) cholla $ gem list --local
> Nothing's really jumping out at me from that list...

...except for the fact that you've still got the old Rails gems you
claim to have deleted.

Hmm, well (just guessing) I probably should have used gem itself to delete
them instead of going to /usr/lib/ruby/gems/1.8/gems and doing an rm -rf
on the old directories. Out of curiosity, what would have been the
proper way to delete them and keep gem informed?

Go to the root directory of your app and run script/about.
What does it say?

(/u1/rails/micros) cholla $ script/about
About your application's environment
Ruby version 1.8.6 (x86_64-linux)
RubyGems version 1.3.7
Rack version 1.1
Rails version 2.3.5
Active Record version 2.3.5
Active Resource version 2.3.5
Action Mailer version 2.3.5
Active Support version 2.3.5
Application root /u1/rails/micros
Environment development
Database adapter mysql
Database schema version 0

gem uninstall or gem cleanup.

Great, thanks, after gem cleanup I see:

[root@cholla rails]# gem list --local

*** LOCAL GEMS ***

actionmailer (2.3.5)
actionpack (2.3.5)
actionwebservice (1.2.3)
activerecord (2.3.5)
activeresource (2.3.5)
activesupport (2.3.5)
cgi_multipart_eof_fix (2.5.0)
daemons (1.0.10)
fastercsv (1.2.1)
fastthread (1.0.7)
gem_plugin (0.2.3)
gettext (2.1.0)
hpricot (0.8.2)
locale (2.0.5)
mislav-will_paginate (2.3.2)
mongrel (1.1.5)
mongrel_cluster (1.0.5)
rack (1.1.0)
rails (2.3.5)
rake (0.8.7)
ruby-opengl (0.60.1)
sqlite3-ruby (1.2.4)
zoom (0.4.1)

>> Go to the root directory of your app and run script/about.
>> What does it say?
>
> (/u1/rails/micros) cholla $ script/about
> About your application's environment
> Ruby version 1.8.6 (x86_64-linux)
> RubyGems version 1.3.7
> Rack version 1.1
> Rails version 2.3.5
> Active Record version 2.3.5
> Active Resource version 2.3.5
> Action Mailer version 2.3.5
> Active Support version 2.3.5
> Application root /u1/rails/micros
> Environment development
> Database adapter mysql
> Database schema version 0

OK, then that looks good to me. Is all that what you expected to see?

It looks swell to me, but I sure wish my application would run. :->

I'm gonna go play with firebug and verify this business of rails
not setting the Content-Type header. Then I am going to look into
why adding this bit of code to app/controllers/application_controller.rb
does not force rails to emit a Content-Type header:

class ApplicationController < ActionController::Base
    before_filter :set_content_type
    def set_content_type
      headers["Content-Type"] = "text/html; charset=utf-8"
    end
end

Once I get fed up with all that, I am probably going to throw in the towel
and act as though I am starting from scratch building my application under
2.3.5, via:

cd /u1/rails
mv micros micros_BAD
rails micros

And then move files one by one from micros_BAD to micros -- all this presuming
that I am inheriting something nasty in the scaffolding left over from
rails 1.2.3.

When doing some experiments to try to find out I was unable to explicitly set
the Content-Type by fiddling with the headers array, I took at look at the
file /u1/rails/my_app/log/mongrel.8000.log and I see lots of error tracebacks
from mongrel that ultimately come from a mongrel routine "send_cookies".

Some google searches on this error message leads me to the following discussion
on a site called "stackoverflow" that describes exactly the behavior I have
been seeing.

    http://stackoverflow.com/questions/2911852/problems-running-ruby-on-rails-apps-on-shared-hosted-server

These discussions link to the following proposed fix, which I am pondering.

    https://rails.lighthouseapp.com/projects/8994/tickets/4690

As they describe it, mongrel crashes when trying to put cookies
in the response header, the resulting HTTP header is incomplete
(missing Content-Type), i.e. exactly the problem I am seeing.

So this is a bug in mongrel 1.1.5 that has been causing trouble since
at least May of this year. I wonder if some official fix is in place yet.
Both discussions above label this as a problem with rails 2.3.8, which I
think is erroneous (it looks like mongrel 1.1.5 is the culprit, buy I may
be missing the point). In any event I am seeing the problem with rails
2.3.5 and mongrel 1.1.5

Indeed, when I run my app via script/server then telnet to port 3000, I do
get the proper Content-Type header, so this bug is specific to mongrel.

`script/server` will run mongrel if it's present -- the problem seems to
be with the mongrel_rails cluster stuff, rather than mongrel itself.

Maybe a good time to switch to Passenger :slight_smile:

I'll google on passenger in just a minute.

I have my problem fixed now. What I did was to hack on the file
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.5/lib/mongrel/cgi.rb

I added some code to the send_cookies() method, following the lead of
one of the fellows posting in the forums I mentioned,
(note the commented out reference to the uninitialized "options" array
that was, I think, the source of the problem)

Tom Trebisky wrote:

`script/server` will run mongrel if it's present -- the problem seems to
be with the mongrel_rails cluster stuff, rather than mongrel itself.

Maybe a good time to switch to Passenger :slight_smile:

I'll google on passenger in just a minute.

Definitely the nicest way to serve Rails apps.

I have my problem fixed now. What I did was to hack on the file
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.5/lib/mongrel/cgi.rb

Great! May I suggest contributing your patch back to the gem
maintainer, if you haven't already done so?

I'll keep this in mind if I ever have a MIME-type issue with Mongrel.
Always good to have the additional info.

Best,