Open
Bug 522679
Opened 14 years ago
Updated 6 months ago
after redirect, server return text/html type page but browser reports that it's octet/stream and tries to save it as file
Categories
(Firefox :: File Handling, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: marcin.olak, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) This page: http://miejsce.info/zobacz/?369bd9e893c8a77005c2b980ab5c4bf4&menu=0 redirects to that: http://miejsce.info/m/pl/369bd9e893c8a77005c2b980ab5c4bf4?type=1 When downloading the target page, browser behaves correctly. When downloading the redirect page, browser displays download window, suggesting that the resource retrieved is of octet/stream type. Which is not true. Rex Swain's HTTP Viewer (http://www.rexswain.com/httpview.html) confirms that both pages return text/html. Reproducible: Always Steps to Reproduce: Go to http://miejsce.info/zobacz/?369bd9e893c8a77005c2b980ab5c4bf4&menu=0 Actual Results: Browser redirects to: http://miejsce.info/m/pl/369bd9e893c8a77005c2b980ab5c4bf4?type=1 and tries to download it as octet/stream. Expected Results: Page should be displayed as in case of going directly to: http://miejsce.info/m/pl/369bd9e893c8a77005c2b980ab5c4bf4?type=1 which Firefox handles properly.
Comment 1•14 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5pre) Gecko/20091011 Shiretoko/3.5.5pre I see a map.
Version: unspecified → 3.5 Branch
Reporter | ||
Comment 2•14 years ago
|
||
Steps to reproduce (update): Open Firefox with blank session (blank tab, no url), paste http://miejsce.info/zobacz/?369bd9e893c8a77005c2b980ab5c4bf4&menu=0 into address bar. Reproducible in 30-50% of cases.
Comment 3•14 years ago
|
||
Unfortunately I can't reproduce it. Have you already tried in safe-mode / with a new profile? http://support.mozilla.com/en-US/kb/Safe+Mode http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile
Reporter | ||
Comment 4•14 years ago
|
||
Yes. I've tried. As I said. It sometimes load. And if it loads, it continues to work fine when refreshed. But sometimes it doesn't load and dialog pops out. Few clicks on refresh button gives the same effect but eventually it starts to work. Here's the video: http://agile7.pl/download/ff35_miejsce.avi [3.5MB]
Reporter | ||
Comment 5•14 years ago
|
||
Sorry. Bad link. This one: http://agile7.pl/download/firefox.avi
Comment 6•14 years ago
|
||
Hm no, I can't reproduce it, not one single time. Tested with a freshly unzipped nightly build and a new profile. Builds are downloadable here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/
Reporter | ||
Comment 7•14 years ago
|
||
Hi Ria, First of all - thanks for your commitment. Actually, I've tried the latest build and was also able to reproduce error. I tried on linux with FF version 3.0 and no error occurred. One difference in our platforms I can spot is that I use Win XP and you probably use Vista. Anyway, I changed provider of the site and error ceased to apear on Win XP either.
Comment 8•13 years ago
|
||
Hi! I noticed a similar issue with this file: http://people.freebsd.org/~nox/videodownloadhelper-log.txt (belongs to https://bugzilla.mozilla.org/show_bug.cgi?id=530793 ) The first time i visit it its displayed correctly (its text/plain), visiting it again i.e. when ff already has it in cache makes ff want to download it instead... (tested by going to http://people.freebsd.org/~nox/ and right-clicking on the file with `open in new tab' twice. Btw also ff doesn't seem to check the server for a newer version the second time, altho maybe it only does that after more time has passed?) First noticed on 3.6rc2 on freebsd, but also reproduced on the official 3.6 windows build in a win7 rc vbox guest (and iceweasel 3.5.6 on debian sid.)
Comment 9•12 years ago
|
||
This may happen when the server is unreliable and fails to send the headers (the connection is established but then the server fails to send any data). Happens all the time with any Firefox version up to (and including) 3.6. Perhaps Firefox could detect and special-case zero-length files but it won't help in cases when the server sends just a few bytes of junk.
Comment 10•12 years ago
|
||
I forgot about this ticket and had moved file mentioned in Comment 8 to http://people.freebsd.org/~nox/old/videodownloadhelper-log.txt when cleaning up my webspace; I can still reproduce the issue on 4.0b10 on the moved file, i.e. clicking the above link the second time when ff already has it in its cache makes ff want to download it although it is text/plain. And I _really_ doubt it's caused by the httpd sending truncated data `sometimes' as I can reproduce the bug every time... (that httpd calls itself httpd/1.4.x Gualala)
Comment 11•12 years ago
|
||
Addition to Comment 10: With 4.0b10 the behaviour has changed slightly: the third time I click the link it displays it again, the fourth time it tries to download it, then it displays it again, etc.
Comment 12•12 years ago
|
||
Further addition to Comment 10: I just did some network sniffing (wireshark) and it seems like 4.0b10 only queries the httpd every second time after the first click on the above link, http://people.freebsd.org/~nox/old/videodownloadhelper-log.txt and 3.6 doesn't query it at all anymore once it has the file in cache. (Well or maybe it only will after some timeout that wasn't reached.)
Comment 13•12 years ago
|
||
The file is text/plain, not text/html and contains ^Gs (bells) which probably causes Firefox treat the file as binary when the content is known (cached) and there is no way to avoid that which generally sucks. There is already bug 247509 bug 266410 and bug bug 509840 about this
Comment 14•12 years ago
|
||
Ouch. :( Thanx for the explanation.
Updated•6 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•