Open Bug 522679 Opened 15 years ago Updated 1 year 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)

3.5 Branch
x86
Windows XP
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.
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
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.
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
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]
Sorry. Bad link. This one:

http://agile7.pl/download/firefox.avi
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/
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.
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.)
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.
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)
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.
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.)
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
Ouch. :(  Thanx for the explanation.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.