172003 - [FIXr]If content-disposition is set and not "inline", assume "attachment"

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect, P2)

Description

[Boris Zbarsky [:bzbarsky]]

According to section 2.8 of rfc2183 (http://www.faqs.org/rfcs/rfc2183.html), if
there is a Content-Disposition header with a disposition value other than inline
or attachment, then the behaviour of attachment should be default.

As we do this, we need to watch out for headers like:

Content-Disposition: filename="foo"

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: This would do it...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 104991 [details] [diff] [review]
This would do it...

I need to fix the exthandler as well.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: there we go

Comment 4

[rpotts (gone)]

Comment on attachment 106052 [details] [diff] [review]
there we go

sr=[e-mail]

Comment 5

[Boris Zbarsky [:bzbarsky]]

fixed

Comment 6

[Phil "clef" Sweeney]

I'm investigating a regression that occured between these two nightly builds:

2002-11-13-08-trunk
2002-11-14-08-trunk

..that causes the following URL to behave incorrectly.  It should display an
image in the browser, but instead pops up a file save dialog (in Windows XP et al).

http://forums.skylinesaustralia.com/attachment.php?postid=98645

I suspect this checkin might be the cause of the regression.  Unfortunately I
don't have a build environment set up so I can't verify it.  Any ideas about
this Boris?  Thanks.

Comment 7

[Boris Zbarsky [:bzbarsky]]

That url sends the following header:

Content-disposition: atachment; filename=gunmetal_r33f.jpg

Note the missing "t" in "attachment" that caused us to show it inline before...
Seems that this site's author really wants that dialog to come up but just made
a typo.

Oh, and you can get the headers with wget or lynx or telnet or even Mozilla's
HTTP logging (which is enabled in opt builds like nightlies) -- no need for a
Mozilla tree.

Comment 8

[Phil "clef" Sweeney]

Yeah that typo is deliberate.  It relies on the previous behaviour of browsers
and to work around bugs in various implementations.

This has regressed before and had to be fixed.  The software used on that forum
is vBulletin and it used on thousands of sites, so this is pretty important.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> It relies on the previous behaviour of browsers

Which is almost uniformly buggy, as you note... and perpetuating those bugs is
not a good idea.

Sounds like we need an evangelism bug on vBulletin; would you mind filing it and
ccing me? I'm curious as to what they're trying to accomplish with that header.

Comment 10

[Phil "clef" Sweeney]

Some info from the vBulletin developers (dated 2001!)

http://www.vbulletin.com/forum/showthread.php?threadid=32285#post199055

The thing is, this has worked in Mozilla for ages now, so to change this could 
break a lot of sites.  Whether it's technically correct or not, that's what 
people expect Mozilla to do.  vBulletin is a commercial forum package and I 
doubt people are in a hurry to upgrade their sites.

Comment 11

[Boris Zbarsky [:bzbarsky]]

From that post:

> Making it 'atachement' works for both browsers as IE ignores it an treats it as 
> if it isn't there and Netscape accepts it at "attachment".

That last part is utterly wrong; we didn't treat "atachement" as "attachment"
till I landed this fix.  Further, the first paragraph of that post ("Netscape 6
on the other hand doesn't know what to call the file when you download it.") is
irrelevant -- the bug was fixed after Netscape 6.

It sounds like they want to be using "inline" in general instead of mucking with
mis-spelling "attachment".

So to sum up:

1)  I'm not reverting this change because one particular forum package is buggy
2)  We should have an evangelism bug on vBulletin to set the disposition to
    "inline".

Comment 12

[Phil "clef" Sweeney]

Filed evangelism bug 183653

Thanks for your assistance.

Comment 13

[Chris Petersen]

Verified per last comments

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 193955 has been marked as a duplicate of this bug. ***