229785 - tries download of page instead of rendering it

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Heinrich Soebke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208

If I type in that URL, the "how to handle" dialog occurs (download, default
application, open with application ...)

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Expected Results:  
render the page without dialog.

Comment 1

[Heinrich Soebke]

Attachment: Hardcopy of the dialog

Comment 2

[Olivier Cahagne]

confirming 20031230 Linux.
Web Sniffer shows it sends a content-disposition header:

[...]
content-disposition:	name="68c77dcf.html"; filename="68c77dcf.html"
[...]
http://web-sniffer.net/?url=http%3A%2F%2Fwww.emprise.de%2Femprise.shtml&gzip=yes

fwiw, Opera 7.50 P1 (Linux) doesn't prompt user to save file and display it fine.

Comment 3

[Jo Hermans]

(mid-air collision)

That's because the browsers a series of redirections, and the last one (the
text/html file that you want tos ee) is send with these headers :

HTTP/1.1 200 OK^M
Date: Wed, 31 Dec 2003 16:01:25 GMT^M
Server: Apache/1.3.23 (Unix) mod_jk/1.1.0 PHP/4.1.0^M
content-description: 68c77dcf.html^M
Set-Cookie: JSESSIONID=F2357289D8624034F9A510E335F2B4E1;Path=/^M
content-disposition: name="68c77dcf.html"; filename="68c77dcf.html"^M
content-location: 68c77dcf.html^M
Transfer-Encoding: chunked^M
Content-Type: text/html^M


So there's a "Content-Disposition" header inside, and that's why Mozilla tries
to download the file instead of displaying. The error is actually on the
webserver's side : it should use the 'inline' parameter, and not the
'attachment' (which is the default used by Mozilla, although it should really be
included too). Or it shouldn't use Content-Disposition at all, because it
doesn't belong here.

Bug 185618 ?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

*** This bug has been marked as a duplicate of 185618 ***

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

actually wait, we may want to support that. we already special case this:
Content-Disposition: filename=foo [...]
we may want to extend that to name=foo

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 138207 [details] [diff] [review]
patch

I'd say we should do this.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 138207 [details] [diff] [review]
patch

r=bzbarsky

Comment 9

[Darin Fisher]

Comment on attachment 138207 [details] [diff] [review]
patch

sr=darin

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

thanks, checked in

alternate testcase url:
http://biesi.damowmow.com/mime.php?do=1&type=text/html&disposition=name=foo&filename=&quote=1&
(should be displayed with the patch, not without it)

Comment 11

[Stephen Donner [:stephend] Not actively reading bugmail]

http://www.emprise.de/emprise.shtml

and

http://biesi.damowmow.com/mime.php?do=1&type=text/html&disposition=name=foo&filename=&quote=1


both display fine using build 2004-06-30-08 on Windows XP.

Verified FIXED.

Comment 12

[Julian Reschke]

I believe adding support for the (unspecced) "name" parameter was a bad idea; back when it was added, no other UA supported it. As of today, only Chrome does as well (apparently copying from Firefox), but in a slightly different way. See http://greenbytes.de/tech/tc2231/#attwithnamepct).

I think this should be removed from both FF and Chrome, unless somebody is willing to precisely specify what it does, and how it's better than "filename".

Comment 13

[Julian Reschke]

(In reply to Julian Reschke from comment #12)
> I think this should be removed from both FF and Chrome, unless somebody is
> willing to precisely specify what it does, and how it's better than
> "filename".

-> Bug 776339