Working With Rails

Sounds more like a server misconfiguration, especially if it doesn’t happen in your dev env. Unless you’re setting the content type, or using something unusual like send_file (but both of those should have shown up in your dev env).

Let’s start with you using pastie.org to paste the controllers with both actions in them. Post every method and filter that’s used for both handling the login, and rendering the blog admin page.

Also, is it possible for you to setup two pages that do the same thing but are non-admin pages, so we can actually have a look in your production environment? This will assist in seeing whether it’s a server misconfiguration.

Agree with “it sounds like a server misconfiguration”.

Try to append response.headers['Content-Type'] = 'text/html' as before_filter in your controller.

Thanks guys. I’ll make those controllers available in a little while.

Ok here goes. This is the first time I’ve used pastie, so I apologise if it doesn’t workout first time around.

I hope I’ve given you enough code to go on. If you need more please let me know. The code isn’t great but, hey, I’m quite new to Rails.

http://pastie.org/386202

Ok, so no red flags in your code. So, back to a Dreamhost misconfiguration.

I’m getting nowhere wit this problem. Have asked Dreamhost tech support and all they can say is there must be a problem with the code. I just don’t get it.

OK, so I try to access the login pages of my site at work where the interconnection is NOT wireless but wired. It all seems ok, on both MS IE and Firefox, under Windows. I go home to my wireless network and I have the octet-stream problem. I then connect my PC to my router using an ethernet cable (not wireless) and I managed to logon, logout and keep doing that about 10 times. I only had the problem once during those times. I’m wondering if the redirect information is occasionally getting lost and thus resulting in the error? A friend of mine also tried. He has a wireless network and the problem only occurred once or twice.

Ok, so you understand that you now sound insane to everyone else :)

I’m back to asking whether you can setup two other pages that do the same thing but are not admin pages, so we can take a look directly.

I realise that I sound insane. It’s driving me insane! :-)

Well, I’ve not setup any separate pages but I see no reason for not giving out my admin page. I have no content of any use at the moment on the site because of this problem so I’m not going to lose anything. The login page can be found at http://www.96methods.com/account/login. There is a dummy user with username of ‘test’ and password of ‘password’.

Any help would be gratefully received.

Thanks

I realise that I sound insane. It’s driving me insane! :-)

Well, I’ve not setup any separate pages but I see no reason for not giving out my admin page. I have no content of any use at the moment on the site because of this problem so I’m not going to lose anything. The login page can be found at http://www.96methods.com/account/login. There is a dummy user with username of ‘test’ and password of ‘password’.

Any help would be gratefully received.

Thanks

I realise that I sound insane. It’s driving me insane! :-)

Well, I’ve not setup any separate pages but I see no reason for not giving out my admin page. I have no content of any use at the moment on the site because of this problem so I’m not going to lose anything. The login page can be found at http://www.96methods.com/account/login. There is a dummy user with username of ‘test’ and password of ‘password’.

Any help would be gratefully received.

Thanks

Ok, it’s definitely your (their) webserver that’s broken. It’s to do with the auto gzip encoding which the web server is doing with the content, and the Content-Length header.

Here’s a pastie showing my wget sessions with your server: http://pastie.org/392650

Hopefully the comments in the pastie explain what the problem is, basically your server is reporting the original unzipped filesize as the Content-Length when the gzipped length is much smaller, meaning that the browser is crapping out because it’s expecting 1998 bytes and only getting 841. It’s actually receiving the right content, whether gzipped or not, but the Content-Length header that the server is sending is wrong.

Now for the bit which explains your insanity – web servers detect through some sort of black magic that I don’t know about – the network latency of the client they’re responding to, and based on this they decide whether it’s worthwhile gzipping content or not. For fast connections, they don’t bother because the overhead of gzipping isn’t worth the small transfer improvement, but for slower connections they do the gzipping thing. I guess that having the wifi in the mix causes the network latency algorithm to be triggered and so the server is gzipping the content for your wifi connection, but sending it uncompressed when you’re connected directly. So, not insane at all.

Btw, you can confirm all this by switching off the gzip encoding method in your browser, not sure about others but in firefox if you put about:config in your address bar then it brings up the configs, you’re looking for the network.http.accept-encoding key, and you just want to remove gzip from the list, then try logging in again, wired or wifi, and it should work then because the server doesn’t have the option of sending the gzipped version.

Jason, that’s fantastic. Thankyou VERY much for your assistance and time. It’s much appreciated.

My first thought was what do I need the Dreamhost tech. support people to actually do to resolve this problem. What can I get them to do, what do I need to spell out to them? But I wonder if there’s anything I can do, perhaps to my .htaccess file or even switch gzipping off perhaps?

Thanks again

Graham

After a bit of googling, I found that mod_fastcgi has known conflicts with mod_deflate that produce this precise problem. So my guess is that Dreamhost are using mod_fastcgi and that there’s no way to keep the deflating in play, and stay with Dreamhost.

You can switch off the deflating in .htaccess – I think it’s:

SetEnv no-gzip dont-vary