IGGY
No Guru Just Here To Help
Premium,MVM
join:2001-03-30
Chatham, IL
1 edit | reply to FROSTY
Re: [IE] IE7 corrupting ZIP files. Firefox does not.
HairyDairyMaid_WRT54G_Debrick_Utility_v48.zip Gives me an error. I'm using IE 7 with Vista 64 bit RTM. I even tried opening the zip file with WinRAR. That program gave me an error for that zip as well. The reason I tried that is do to the fact at one time there was a newer form of zip compression that had been giving Microsoft's utility an issue. This may have been fixed for Vista though. I've not seen this issue pop up on any other sites though. So I would tend to believe this is something specific to where the zip is being downloaded from.
--
Test PC Security
Cable Diagnostics
BLOG ZoneAlarm Help Vista x64 Insightbb Plus 15000/1500 BroadVox Direct |
|
OZO
Premium
join:2003-01-17
| reply to FROSTY
I just hope that may be someone will come with the idea why it's happening.
Common zip file header begins with two bytes 'PK'.
Download file is corrupted by adding right at the beginning:
'1F 8B 08 00 00 00 00 00 00 03'
followed by '00 31 80 CE 7F'. Then common header begins. Notice this set of 5 bytes. Similar sets will be inserted on a reguar basis.
E.g. before address 0x08031 - there is set '00 11 80 EE 7F'
Then before address 0x10042 - there is set '00 18 80 E7 7F'
Then before address 0x1805A - there is set '00 17 80 E8 7F'
and so on...
What the heck?
I was checking HairyDairyMaid_WRT54G_Debrick_Utility_v41.zip file download:
good file: 763,438 bytes, MD5=d2b31f3bb90070513f9fb8715d492278
bad file: 762,481 bytes, MD5=16d4af72c24d1277e8dd22b20f4d9dab
--
Keep it simple, it'll become complex by itself... |
|
severach
join:2002-09-12
Jackson, MI | »www.memtest.org/
I suspect the problem does not lie with the software. |
|
GeorgeCr
Funny it worked last time
Premium
join:2003-07-18
Sheffield,UK
clubs:  | reply to FROSTY
I've been using IE7 since launch and haven't had any problems with file downloads (including zip). |
|
brandon
Some truth included in this post.
Premium
join:2003-03-31
Hurley, MS
 ·AT&T Southeast
| reply to severach
said by severach  :» www.memtest.org/I suspect the problem does not lie with the software. I suspect you are way off base. |
|
swinn
join:2001-02-16
Clarksville, TN | reply to FROSTY
Right click the link and choose "Save Target As..." |
|
BoomerSooner
Premium
join:2004-02-11
·Pioneer Telephone ..
·Pioneer Internet
1 edit | reply to OZO
said by OZO :I was checking HairyDairyMaid_WRT54G_Debrick_Utility_v41.zip file download: good file: 763,438 bytes, MD5=d2b31f3bb90070513f9fb8715d492278bad file: 762,481 bytes, MD5=16d4af72c24d1277e8dd22b20f4d9dab Same thing I saw with the two test files I tried. In my case, the "good" file was 15 bytes larger than the "bad" file. Still think they inadvertently uploaded the files in ASCII format.
For whatever reason, IE6 and/or IE7 under Vista and/or those who ARE able to open the file have some type of mechanism on their PC's that "corrects" or "ignores" the bad formatting. Whether it be something within Windows itself or due to some download manager. I agree, would be interesting to figure out the hows and whys.
*edit* For those of you who'd like to try, here are links to the two files I uploaded. Just zip files containing the ORCA.MSI. ORCABAD.ZIP was uploaded in ASCII format, and ORCAGOOD.ZIP was uploaded in BINARY format. See how your particular setup works when you try to open each zip file. I use WINZIP and it tells me the ORCABAD.ZIP file is bad ...
»www.home-turf.com/orcabad.zip
»www.home-turf.com/orcagood.zip
--
I'll take "Things Only I Would Know" for $10,000. |
|
MIXZ1
join:2001-01-02
Mexico | reply to FROSTY
Win XP Pro SP2
IE 7
Winzip 10
No Problem at all. |
|
FROSTY
Premium,MVM
join:2000-08-10
Pinson, AL
clubs:
| reply to BoomerSooner
I stand corrected, the byte file size is different by 15 bytes as OZO pointed out. Thanks.
BoomerSooner , Winzip 8/9/10 & WinRar 3.60 both report your ORCABAD.ZIP as corrupt, while ORCAGOOD.ZIP opens correctly. I have no download managers. I've tried SaveAs, Open, Open in new Tab, Open in New Window. Same results with the files respectively. Would you say the problem lies in the method the file was uploaded versus a setting in IE, a registry key, or a system file?
--
"When you set yourself on fire and aim for the sky, you hope to leave behind some sparks of heat and light ... Like a vapor trail." - Neil Peart 2002 |
|
BoomerSooner
Premium
join:2004-02-11
·Pioneer Telephone ..
·Pioneer Internet
| My gut still tells me that they uploaded the files in ASCII format. Trust me, I've done it on NUMEROUS occasions when I "force" my FTP program to upload a particular file in ASCII then forget to change it or set it back to automatic.
The thing I'd like to know is why there are those who have no problem opening that "alleged" bad file. Is that a good thing or a bad thing? Is the file contained within the zip "good" or "bad". Could it have something (possibly not visible to the naked eye) wrong within it? I guess a good test would be to have someone who can open it EITHER way, to do a byte for byte comparison of the file contained within each zipfile. If they compare perfectly, then I'd say it has something to do with the way each persons PC is set up to download/translate a ZIP file (or possibly ANY "binary" type file).
Gotta run for a while. Will be back later today.
--
I'll take "Things Only I Would Know" for $10,000. |
|
therube
join:2004-11-11
Randallstown, MD
4 edits | reply to FROSTY
Interesting.
It is more then just the first few bytes of the file that are different.
This is from WinDiff. (Red is the valid version, yellow is corrupted version. Variances continue beyond & to the right, of what I have captured.)
I get the same md5 checksums as OZO for the file HairyDairyMaid_WRT54G_Debrick_Utility_v41.zip.
Downloaded via SeaMonkey, IE7 (XP SP2), & LeechFTP.
SeaMonkey & LeechFTP downloads are identical & valid.
IE7 download is corrupted.
It will not have anything to do with memory - as others are returning the exact same results.
If the file is being "served" incorrectly (& I'm only guessing on this) but like application/text vs. application/zip, IE could then be downloading it using one method, Mozilla, looking beyond what IE is, is downloading it using another method?
Or not? A header check shows:
HTTP/1.1 200 OK =>
Date => Tue, 09 Jan 2007 16:41:00 GMT
Server => Apache
Last-Modified => Tue, 30 Aug 2005 18:25:43 GMT
ETag => "f18001-ba62e-3ff91bd6537c0"
Accept-Ranges => bytes
Content-Length => 763438
Vary => Accept-Encoding,User-Agent
Connection => close
Content-Type => application/zip
http://www.webconfs.com/http-header-check.php |
|
severach
join:2002-09-12
Jackson, MI
| Yep, memory isn't it. I'm getting the same results. Now that I'm awake it only took a few minutes with Total Commander to see what's happening.
The FF file is the undamaged original ZIP. The IE7 ZIP has been encased in gzip which some programs including Windows Explorer barf on but Total Commander doesn't. Total Commander is able to enter the IE7 file, identify it as gz, and extract or compare the ZIP file inside. Though the .zip extension has been stripped from the inner file it is identical to the FF download. The IE7 file isn't damaged, it's just in a format that doesn't match it's extension which confuses rudimentary extension based programs like Windows Explorer. Programs that handle gzip and know how to determine the format of the file without depending on the extension will not show an error.
My second WAG is to say that the server is using gzip server side compression and IE7 is forgetting to remove the gzip wrapper. Looks like this bug lies squarely on the shoulders of the IE team. It might be handy to avoid gzip compression on already compressed files but I don't see any reason why webmasters should need to worry about that. I don't think IE7 is improving any standard here. |
|
therube
join:2004-11-11
Randallstown, MD
1 edit | said by severach :The IE7 ZIP has been encased in gzip ... the inner file it is identical to the FF download. You're right  !
I use Servant Salamander rather then Total Commander. SS can open .gz files, but it did not catch the fact that the downloaded ".zip" was in fact a .gz. Once renamed to *.gz, it opened it & extracted then enclosed .zip just fine. |
|
Irish Shark
Play Like A Champion Today
Premium,MVM
join:2000-07-29
Las Vegas, NV
| reply to javaMan
said by javaMan :said by Irish Shark :Also what is screwy is that I had no issues in Vista or XP Pro SP2. dmxrob6 also said that he had no issues. I can download it again and upload the reademe file or the PDF is you think that I am BSing. But you said you were using some kind of download manager, correct? Perhaps that is why. What are the results if you don't use it? I have done it both ways in Vista and XP and no issues.
--
"You can observe a lot by watching". Yogi Berra |
|
FROSTY
Premium,MVM
join:2000-08-10
Pinson, AL
clubs:
| reply to severach
severach found the source of the problem!
Many thanks!
As a test based on severach GZ info:
Renamed the .ZIP file downloaded with IE7 to .GZ.
Opened the .GZ file with both WinZIP and WinRAR.
Able to extract the inner file as a ZIP from either program.
Open that ZIP, and it works 100%.
I found this using google earlier today:
Turning off the default php zlib compression for IE browser download requests (and letting header content-length default to chunks) fixes the corrupted zip problem.
Now, does this have anything to do with IE7 encapsulating the file into GZip while leaving its extension as a ZIP? Or is there a registry key we can modify/create to prevent IE7 from encapsulating the file in GZip form? Or is this soley a bug that must be worked around?
--
"When you set yourself on fire and aim for the sky, you hope to leave behind some sparks of heat and light ... Like a vapor trail." - Neil Peart 2002 |
|
Lil Jon
Premium
join:2006-06-26
Lawrenceville, GA | reply to David
interesting! good thread |
|
OZO
Premium
join:2003-01-17
| reply to FROSTY
Good catch severach !
Now we know that file beginning with header similar to this one is in .gz format:
1F 8B 08 00 00 00 00 00 00 03
Next step is to find out why it's happening this way. I've checked communication between IE7 and web server when this accident happens. Take a look at log below:
+++GET 657+++
GET /utils/HairyDairyMaid_WRT54G_Debrick_Utility_v41.zip HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://downloads.openwrt.org/utils/HairyDairyMaid_WRT54G_Debrick_Utility_v41.zip
Accept-Language: en-us
UA-CPU: x86
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.0)
Host: downloads.openwrt.org
Connection: keep-alive
Accept-Encoding: gzip, x-gzip, deflate
RESP 657 : Vary killed: Accept-Encoding,User-Agent
+++RESP 657+++
HTTP/1.0 200 OK
Date: Tue, 09 Jan 2007 20:24:29 GMT
Server: Apache
Last-Modified: Tue, 30 Aug 2005 18:25:43 GMT
ETag: "f18001-ba62e-3ff91bd6537c0"
Accept-Ranges: bytes
Content-Encoding: gzip
Connection: close
Transfer-Encoding: chunked
Content-Type: application/zip
Cache-Control: public, max-age=86400
+++CLOSE 657+++
As we can see IE7 announces that it will accept encoding "gzip" and web server sends file that particular encoding method - "gzip". So, IE7 must to decode gzip-ed content and put output onto disk. As we see it's not happening in this particular case.
Second, I choose not to "Open" file, I specifically choose to "Download" that file. So, extension's interpretation on client side computer is irrelevant here. When I download a file - it should not be of IE7 or OS concern what content type is it. File should be written in file system as exact copy of the file in the web.
So, I think this is IE 7 bug that in some cases doesn't provide decoding (decompression) when it's required.
--
Keep it simple, it'll become complex by itself... |
|
OZO
Premium
join:2003-01-17
| reply to FROSTY
One more interesting thing for those who use Proxomitron v.4.5 with "NAOKO 4.5 CONFIG -- SIDKI 2006-09-03" filters.
If you choose "Bypass all filters" option - you will be able to download proper HairyDairyMaid_WRT54G_Debrick_Utility_v41.zip file. If you turn it off (applying all default filters) - you'll get corrupted file again (as in case with direct connection between IE7 and web server). It's a quite strange effect...
--
Keep it simple, it'll become complex by itself... |
|
FROSTY
Premium,MVM
join:2000-08-10
Pinson, AL
clubs:
1 edit |  OZO , yes, quite a strange effect indeed.
I'd like to thank everyone for taking the time and effort to help me troubleshoot this quirk with IE7. Especially severach . I'm sure I and others will run into this problem again with other websites. I would like to know why some had no problem while downloading natively with IE7. Almost like the GZip detection of IE7 was turned off for those users like Irish Shark .
--
"When you set yourself on fire and aim for the sky, you hope to leave behind some sparks of heat and light ... Like a vapor trail." - Neil Peart 2002 |
|
mmarinho
join:2007-02-04
Avenel, NJ
| reply to FROSTY
Vista RTM Ultimate. I also see this problem. In fact IE corrupts all http based downloads. Doesn't matter what it is, ZIP file, EXE file , etc. However it does not corrupt downloads that are transferred using an FTP link within IE. I have not had the time to research this issue and not sure what is causing it. Again on the same PC/OS using Firefox works fine for all downlods (HTTP or not).
-Manny |
|
