Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Perhaps I'm missing some necessary module or bit of configuration. Set this server up a few days ago, Apache 2, Ubuntu 10.04. Put a site up on it. Visit the site, notice that the bottom edges of .png images are sliced off. Also, the last little bit of a flash animation didn't seem to run.

The files on the server's filesystem appear to be intact -- the bottom edges of the .pngs do not appear sliced-off if I grab the file via SCP. But they do in the browser or when grabbed with wget.

Comparing with the same files served up from on a different server, I noticed that on the .png and .swf files, the new server is sending a somewhat smaller number in the Content-Length header. I figure this is where the problem is, but don't know what would be causing this or what to do about it.

share|improve this question
    
Is the data being compressed by Apache? Verify that the Content-Length is still wrong when compression is not involved. – Shane Madden Sep 19 '11 at 16:10
    
I think Deflate is being used. If my company had a real server-admin instead of my developer self, I wouldn't have to ask, but: how do I turn off said compression? – centipedefarmer Sep 19 '11 at 16:54
    
On Ubuntu, a2dismod deflate. – Shane Madden Sep 19 '11 at 17:03
1  
Well here it is folks... apparently these files were being served up via the Rails app through a Metal thing (for some reason that I don't fully understand, the app greatly predates my involvement with it). The discrepancy in Content-Lengths was due to having Ruby 1.8.7 (actually REE) on the server where it worked correctly versus 1.9 on the new server and this Metal thing setting the Content-Length based on the value returned by #length called on the file contents -- – centipedefarmer Sep 19 '11 at 18:28
1  
it was giving a length in "characters" rather than bytes, interpreting certain byte combinations as multibyte characters. Having it read the file in binary mode straightened it out. – centipedefarmer Sep 19 '11 at 18:28

From the comments

Well here it is folks... apparently these files were being served up via the Rails app through a Metal thing (for some reason that I don't fully understand, the app greatly predates my involvement with it). The discrepancy in Content-Lengths was due to having Ruby 1.8.7 (actually REE) on the server where it worked correctly versus 1.9 on the new server and this Metal thing setting the Content-Length based on the value returned by #length called on the file contents

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.