522679 - after redirect, server return text/html type page but browser reports that it's octet/stream and tries to save it as file

Status: UNCONFIRMED

(Firefox :: File Handling, defect)

Description

[Marcin Olak]

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

[Ria Klaassen (not reading all bugmail)]

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.

Comment 2

[Marcin Olak]

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

[Ria Klaassen (not reading all bugmail)]

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

Comment 4

[Marcin Olak]

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]

Comment 5

[Marcin Olak]

Sorry. Bad link. This one:

http://agile7.pl/download/firefox.avi

Comment 6

[Ria Klaassen (not reading all bugmail)]

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/

Comment 7

[Marcin Olak]

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

[bugs-mozilla]

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

[Michal 'hramrach' Suchanek]

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

[bugs-mozilla]

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

[bugs-mozilla]

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

[bugs-mozilla]

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

[Michal 'hramrach' Suchanek]

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

[bugs-mozilla]

Ouch. :(  Thanx for the explanation.