172693 - [FIXr]Wrong extension appended when cgi script returns unrecognized content type

Status: VERIFIED FIXED

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

Description

[Bill Law]

This bug might replicate an existing one, but I couldn't find one that addressed
this specific issue (note that there are a fair number of bugs dealing with some
aspect of file etensions).  Regardless, I want this one to address this precise
issue:

If a cgi script returns an unrecognized (by Mozilla) content type, then we will
try to find a content handler based on the file extension in the URL.  That is
almost always guaranteed to result in the wrong thing.  A cgi script name has
nothing to do with the content type of the data returned by said script.  E.g.,
foobar.asp doesn't return ".asp" data.

Usually, the result of this attempt to find a handler based on the URL file
extension simply results in us appending the same file extension on the
suggested file name when the user ultimately chooses to save to disk. 
Typically, a cgi such as "foobar.exe?download=something" returns content of type
application/foo and specifies a content disposition header like "attachment;
filename=something.foo".  We don't know what to do with application/foo, so we
try to match based on the extension.  That  leads us to suggest that the user
save the file as "foobar.foo.exe" which makes no sense.

Patch coming shortly.

Comment 1

[Bill Law]

Attachment: fix

The patch has three components:

1. Checks for a cgi query URL (presence of "?args") and if found, avoids lookup
for a helper app based on the file extension in the URL.
2. In the same situations (a cgi query) leaves the "temp file extension" blank
instead of using the file extension from the URL.  This will result in the name
being suggested to the user not having the cgi extension tacked on.
3. In the case of a CGI script, we get the suggested file name from only the
*base* part of the URL.  That is, we ignore the extension.  So for example, we
suggest the name "foobar" (with extension based on the content type, such as
"foobar.doc" if the content type is application/msword) instead of
"foobar.cgi".

Boris has looked at this already and given preliminary approval.  I'd like for
him to add r=/sr= here (preferably the latter).

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 101778 [details] [diff] [review]
fix

r/sr=bzbarsky.	In the future, we should look at the channel as well and treat
it as a "cgi" if it has postdata, but right now we don't have the channel in
that code where we need it (I plan to fix that sometime...).

Comment 3

[Hansoo Kim]

FYI,

Patch needed for 1.0.1.

Thanks.

Comment 4

[timeless]

1.0.1 was released. we should not worry about the 1.0 branch until we have made
a good fix for the trunk and have tested it on the trunk for a while.

Comment 5

[Michael Dunn]

Internal reference:
http://bugscape.netscape.com/show_bug.cgi?id=18009

Comment 6

[Hansoo Kim]

Bill,

Has it been checked into trunk yet ?

Thanks

Comment 7

[slusarz]

This is still broken in Build 2002110708 [Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.2b) Gecko/20021107].  A workaround for this is to use the hack
we use in Horde for IE browsers which have broken Content-Disposition handling
(http://cvs.horde.org/diff.php/horde/lib/Browser.php?r1=1.36&r2=1.37&ty=h) -
namely put the filename in the PATH_INFO element and the extension as the last
argument in the URL.

I have no appliction/octet-stream handler set up in my preferences.

Thus, http://example.com/download.php -- a script which will send headers for
downloading the file test.doc as MIME type 'application/octet-stream' -- is
currently saved on windows as test.doc.php.

However, if you use the URL http://example.com/download.php/test?f_ext=/test.doc
-- the file is correctly saved as test.doc.

Comment 8

[Hixie (not reading bugmail)]

If the font-size is equal to the line-height, but the font used has characters
that bleed outside its em square, then there will be overlap. The background/
borders/etc go around the font box, which is only indirectly related to the
font- size and not at all related to the line-height.

Comment 9

[Susie Wyshak]

Bill - Is this the issue that affects http://dgl.microsoft.com ? 

Marking nsbeta1.

Comment 10

[Samir Gehani]

Nav triage team: nsbeta1+ 

Comment 11

[Judson Valeski]

ian's comment #8 was intended for another bug; not applicable to this one.

Comment 12

[Boris Zbarsky [:bzbarsky]]

taking to check in

Comment 13

[Boris Zbarsky [:bzbarsky]]

checked in.

Comment 14

[Chris Petersen]

Verified on the 2003-06-09-08 win32 trunk.