I just recently moved my web application to production mode and published it online. While everything functioned ok locally, I have a very bizarre error now affecting my application. One of my controllers, Work, is not behaving properly. Whenever I call the action new, create, edit, or update I get all of the HTML generated to my browser (this happens in Firefox, Camino, and Safari) but the browser doesn''t interpret it. In Internet Explorer, however, the HTML is interpreted and I see the correct page. An example of what my production.log entries look like: Processing WorkController#new (for 70.35.119.123 at 2006-07-21 21:21:05) [GET] Session ID: 8bbed2b4b35205cbf3f4cb7d1a2e11e6 Parameters: {"action"=>"new", "controller"=>"work"} Rendering within layouts/application Rendering work/new Completed in 0.02647 (37 reqs/sec) | Rendering: 0.02156 (81%) | DB: 0.00415 (15%) | 200 OK [http://anngcoleman.com/work/new] So it looks like the 200 OK message should make the browser interpret the page. I am running it off of a shared hosting company (Dreamhost to be specific) which I understand throws a lot of uncertainty in the situation, but I would really appreciate any advice. Like I said, the HTML is generated but something isn''t coming through all the way. I''m completely stumped on this one.
>http://anngcoleman.com/work/newIs that the url that doesn''t work? Works fine for me. If not, sounds like a bad mime type being sent. IE will try to guess on things it''s not sure about, while other browsers are usually more strict. Try telneting to the port and do a GET /work/new HTTP/1.0 to see what the server is sending. Chris
You''re serving the page with the MIME type text/plain instead of text/ html. You can see this in Firefox by right-clicking on the page and choosing View Page Info. It''s unlikely to be a Dreamhost issue if the rest of your site is working right. Check your work controller and view to see what''s different from the rest of your site. - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-415-233-1000> On Jul 21, 2006, at 9:38 PM, Michael Klein wrote:> I just recently moved my web application to production mode and > published it online. While everything functioned ok locally, I have a > very bizarre error now affecting my application. One of my > controllers, Work, is not behaving properly. Whenever I call the > action new, create, edit, or update I get all of the HTML generated to > my browser (this happens in Firefox, Camino, and Safari) but the > browser doesn''t interpret it. In Internet Explorer, however, the HTML > is interpreted and I see the correct page. An example of what my > production.log entries look like: > > Processing WorkController#new (for 70.35.119.123 at 2006-07-21 > 21:21:05) [GET] > Session ID: 8bbed2b4b35205cbf3f4cb7d1a2e11e6 > Parameters: {"action"=>"new", "controller"=>"work"} > Rendering within layouts/application > Rendering work/new > Completed in 0.02647 (37 reqs/sec) | Rendering: 0.02156 (81%) | DB: > 0.00415 (15%) | 200 OK [http://anngcoleman.com/work/new] > > So it looks like the 200 OK message should make the browser interpret > the page. I am running it off of a shared hosting company (Dreamhost > to be specific) which I understand throws a lot of uncertainty in the > situation, but I would really appreciate any advice. Like I said, the > HTML is generated but something isn''t coming through all the way. I''m > completely stumped on this one. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
I''ve taken away the administration part so now the new action is revealed to the public. This might be helpful. when i do curl -I http://anngcoleman.com/work/new I get this: curl -I http://anngcoleman.com/work/new HTTP/1.1 200 OK Date: Sat, 22 Jul 2006 18:38:51 GMT Server: Apache/2.0.54 (Unix) PHP/4.4.2 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.1.4 #<Work: 0x40aa7184>Content-Type: text/html Set-Cookie: _session_id=497686cbf964a917030421f6d055e69a; path=/ Cache-Control: no-cache Content-Type: text/plain I guess the #<Work: 0x40aa7184>Content-Type: text/html is blocking out the content type. Can anyone tell me why #<Work: 0x40aa7184> is there or give me some idea of how to get rid of it? On 7/22/06, snacktime <snacktime@gmail.com> wrote:> >http://anngcoleman.com/work/new > > Is that the url that doesn''t work? Works fine for me. > > If not, sounds like a bad mime type being sent. IE will try to guess > on things it''s not sure about, while other browsers are usually more > strict. Try telneting to the port and do a GET /work/new HTTP/1.0 to > see what the server is sending. > > Chris > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Please post your work/new method, view, and layout. - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-415-233-1000> On Jul 22, 2006, at 11:42 AM, Michael Klein wrote:> I''ve taken away the administration part so now the new action is > revealed to the public. This might be helpful. when i do curl -I > http://anngcoleman.com/work/new I get this: > > curl -I http://anngcoleman.com/work/new > HTTP/1.1 200 OK > Date: Sat, 22 Jul 2006 18:38:51 GMT > Server: Apache/2.0.54 (Unix) PHP/4.4.2 mod_ssl/2.0.54 OpenSSL/0.9.7e > mod_fastcgi/2.4.2 DAV/2 SVN/1.1.4 > #<Work: 0x40aa7184>Content-Type: text/html > Set-Cookie: _session_id=497686cbf964a917030421f6d055e69a; path=/ > Cache-Control: no-cache > Content-Type: text/plain > > > I guess the #<Work: 0x40aa7184>Content-Type: text/html is blocking out > the content type. Can anyone tell me why #<Work: 0x40aa7184> is there > or give me some idea of how to get rid of it? > > On 7/22/06, snacktime <snacktime@gmail.com> wrote: >> >http://anngcoleman.com/work/new >> >> Is that the url that doesn''t work? Works fine for me. >> >> If not, sounds like a bad mime type being sent. IE will try to guess >> on things it''s not sure about, while other browsers are usually more >> strict. Try telneting to the port and do a GET /work/new HTTP/1.0 to >> see what the server is sending. >> >> Chris >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
I figured it out. For some reason in my form the check_box function was creating the error. Even when I did a simple <%= check_box "work", "display" %> the page would lose it''s conent-type. I worked around it by writing out the <input> tags myself. Glad that''s over with! On 7/22/06, Michael Klein <kleinishere@gmail.com> wrote:> I''ve taken away the administration part so now the new action is > revealed to the public. This might be helpful. when i do curl -I > http://anngcoleman.com/work/new I get this: > > curl -I http://anngcoleman.com/work/new > HTTP/1.1 200 OK > Date: Sat, 22 Jul 2006 18:38:51 GMT > Server: Apache/2.0.54 (Unix) PHP/4.4.2 mod_ssl/2.0.54 OpenSSL/0.9.7e > mod_fastcgi/2.4.2 DAV/2 SVN/1.1.4 > #<Work: 0x40aa7184>Content-Type: text/html > Set-Cookie: _session_id=497686cbf964a917030421f6d055e69a; path=/ > Cache-Control: no-cache > Content-Type: text/plain > > > I guess the #<Work: 0x40aa7184>Content-Type: text/html is blocking out > the content type. Can anyone tell me why #<Work: 0x40aa7184> is there > or give me some idea of how to get rid of it? > > On 7/22/06, snacktime <snacktime@gmail.com> wrote: > > >http://anngcoleman.com/work/new > > > > Is that the url that doesn''t work? Works fine for me. > > > > If not, sounds like a bad mime type being sent. IE will try to guess > > on things it''s not sure about, while other browsers are usually more > > strict. Try telneting to the port and do a GET /work/new HTTP/1.0 to > > see what the server is sending. > > > > Chris > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > >