DeveloperSide.NET Forums
July 24, 2019, 12:33:49 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: 1 [2]
  Print  
Author Topic: Apache 2.0.49 - Broken mod_deflate, anyone?  (Read 45831 times)
0 Members and 1 Guest are viewing this topic.
admin
Administrator
Master of All Subjects
*****
Posts: 3272


View Profile WWW Email
« Reply #15 on: September 09, 2004, 05:52:24 PM »

If the file was "corrupt" the md5sum would have changed when going from server to client.

You cannot have a good file match a corrupted file's md5sum.

The problems in this thread are more than likely a result of a file being compressed twice, as a result of a configuration problem in Apache, or anything else down the line.  That, or your file is corrupt itself.

Test your file to make sure its good.  Turn off Apache's mod_deflate (or in your case mod_gzip ?) and see if it works.  Also check the headers, on the client/recieving side.

BTW, if you are using Apache to compress files, you did not turn ON any of PHP's compression directives under php.ini/cnf?
Logged

DeveloperSide.NET
Advanced PHP and MySQL Solutions for your Web Design and Development needs with Web.Developer Server Suite.
RetroWeb
Member
*
Posts: 8


View Profile
« Reply #16 on: September 09, 2004, 11:06:09 PM »

Quote from: "admin"
If the file was "corrupt" the md5sum would have changed when going from server to client.

You cannot have a good file match a corrupted file's md5sum.


The file was the same on the server as it was on my client's machine before he uploaded it. When he downloaded it back to his PC, it was corrupt and the md5sum had changed, thus proving that the corruption was caused in the process of downloading.

Quote from: "admin"
Test your file to make sure its good.  Turn off Apache's mod_deflate (or in your case mod_gzip ?) and see if it works.  Also check the headers, on the client/recieving side.

BTW, if you are using Apache to compress files, you did not turn ON any of PHP's compression directives under php.ini/cnf?


The file works fine before it's downloaded. We don't have mod_gzip installed. I'll try to get my client to check the headers.

We're not using any compression options in php.ini:

Code:
zlib.output_compression = Off
                                                                               
; You cannot specify additional output handlers if zlib.output_compression
; is activated here. This setting does the same as output_handler but in
; a different order.
;zlib.output_handler =



Any other ideas? Thanks for the help!

Matt :)
Logged
admin
Administrator
Master of All Subjects
*****
Posts: 3272


View Profile WWW Email
« Reply #17 on: September 10, 2004, 12:33:47 AM »

I take it the file gets corrupted no matter who downloads it?  Have you downloaded it yourself?

Is it a straight link?  No redirecting or PHP sendfile type of stuff?

You could try setting LogLevel under httpd.conf to debug for max output.  Maybe something will come up.

Also check the error_log
Logged

DeveloperSide.NET
Advanced PHP and MySQL Solutions for your Web Design and Development needs with Web.Developer Server Suite.
RetroWeb
Member
*
Posts: 8


View Profile
« Reply #18 on: September 10, 2004, 12:53:59 AM »

The problem is that when I downloaded it, I had no problems :)

It's a straight link - no PHP output or anything. I'll see what I can do with the logs - thanks :)

Matt
Logged
admin
Administrator
Master of All Subjects
*****
Posts: 3272


View Profile WWW Email
« Reply #19 on: September 10, 2004, 07:11:23 AM »

Then the problem is with your client and not Apache.  He could have all kinds of spyware, viruses, etc.. on his system.  Or maybe he just does not know what he is doing, in the first place.

Thats a really critical point to leave out, that only he has the problem.

He should try to download another file, similar extension and size, from another server.  Most of the GPL/open source progs out there should have a md5sum.
Logged

DeveloperSide.NET
Advanced PHP and MySQL Solutions for your Web Design and Development needs with Web.Developer Server Suite.
RetroWeb
Member
*
Posts: 8


View Profile
« Reply #20 on: September 10, 2004, 07:39:23 AM »

Thing is, he isn't having any problems downloading RAR or ZIP files from other servers in the same manner.

And I figured maybe my case was just an exception.

Matt
Logged
admin
Administrator
Master of All Subjects
*****
Posts: 3272


View Profile WWW Email
« Reply #21 on: September 11, 2004, 05:09:46 AM »

Are you sure that your Apache is not loading mod_gzip ?  I read your usenet post, you are not the admin of this server, nor have root access?

This would be another critical point.
You should verify this part yourself.

If your Apache 1.3.xx is not running mod_gzip, you should get another sysadmin.  You would save 50% of your traffic.  Also, your sysadmin could just be lying to you, not wanting to deal with this problem.

And dont listen to those responding in that usenet post...  mod_gzip is not "3rd party" mod_deflate.  And mod_deflate has no problems.  Its the client browser versions that do.  And those are easily corrected for server-side.
Logged

DeveloperSide.NET
Advanced PHP and MySQL Solutions for your Web Design and Development needs with Web.Developer Server Suite.
RetroWeb
Member
*
Posts: 8


View Profile
« Reply #22 on: September 11, 2004, 09:04:03 PM »

Quote from: "admin"
Are you sure that your Apache is not loading mod_gzip ?  I read your usenet post, you are not the admin of this server, nor have root access?


I am the owner of RetroWeb.net, a web hosting company. I have root access to all my servers. I'm not an expert at Linux, which is why I pay sysadmins to handle that. I do have some Linux knowledge however (I run in on a couple of workstations at home, including my main workstation which I'm typing on now) so I help out where I can. Trying to find an answer to this problem is a good example.

Matt :)
Logged
admin
Administrator
Master of All Subjects
*****
Posts: 3272


View Profile WWW Email
« Reply #23 on: September 11, 2004, 10:36:23 PM »

All you have to do is view Apache's httpd.conf file to see if there is a "LoadModule" line with "mod_gzip or gzip_module" in it.

It could also have been compiled in, and you could view all the compiled in modules with...
httpd -l (lowercase L)

Or just check the HTTP headers for something like "Content-Encoding: gzip"
Logged

DeveloperSide.NET
Advanced PHP and MySQL Solutions for your Web Design and Development needs with Web.Developer Server Suite.
RetroWeb
Member
*
Posts: 8


View Profile
« Reply #24 on: September 11, 2004, 10:50:42 PM »

Quote from: "admin"
All you have to do is view Apache's httpd.conf file to see if there is a "LoadModule" line with "mod_gzip or gzip_module" in it.


I did that originally... that's how I knew it's not installed. :) It wasn't compiled in either.

Matt
Logged
admin
Administrator
Master of All Subjects
*****
Posts: 3272


View Profile WWW Email
« Reply #25 on: September 11, 2004, 10:51:07 PM »

Either way, Apache without mod_gzip (or with it) would not selectively corrupt file.zip/rar only for your client (using IE and Firefox), each time and for no one else.

If your client can pull other files from your system, then he/she might be lying for some reason.  That or the client has something on his system that is causing this.

If your client cannot get any files with the zip/rar extension from your server, then the path the packets are taking could have a bad node in it.
Is the corruption consistent each time?  Are the md5sums the same for each download, or does he/she get a different hash each time?  What is the name of this file, and have you tried changing it, or the extension?
Logged

DeveloperSide.NET
Advanced PHP and MySQL Solutions for your Web Design and Development needs with Web.Developer Server Suite.
RetroWeb
Member
*
Posts: 8


View Profile
« Reply #26 on: September 11, 2004, 11:55:16 PM »

Quote from: "admin"
If your client can pull other files from your system, then he/she might be lying for some reason.  That or the client has something on his system that is causing this.


The way I see it is that you can never really know the exact circumstances of a problem someone else is having. He's using standard software (Windows XP, IE, Firefox, no download managers) but then there could be a multitude of other influential factors.

Quote from: "admin"
If your client cannot get any files with the zip/rar extension from your server, then the path the packets are taking could have a bad node in it.
Is the corruption consistent each time?  Are the md5sums the same for each download, or does he/she get a different hash each time?  What is the name of this file, and have you tried changing it, or the extension?


I haven't asked him to repeat the tests. The file ends in .rar and is composed of English characters, with an underscore in the middle. It's only about 10 characters long.

I'll see about repeating the tests.

Thanks,
Matt :)
Logged
RetroWeb
Member
*
Posts: 8


View Profile
« Reply #27 on: September 12, 2004, 10:45:15 PM »

Well, I fixed it :)

I commented out the bottom two lines:

 # AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
# Matt commented out the two lines below on 9th Sept 2004
# AddEncoding x-compress Z
# AddEncoding x-gzip gz tgz

Thanks for all your help, and I hope this helps someone else with any similar problems :)
Matt
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.9 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!