87754 - darkbasic.com - "Save As" ignoring filename in invalid content-disposition header

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: English US, defect, P3)

Description

[Francisco León]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010623
BuildID:    2001062306

Mozilla cannot determine that there is a .jpg file there and then puts
download.php when saving it to disk

Reproducible: Always
Steps to Reproduce:
1.Go to url
2.Save image to disk


Actual Results:  Download.php file is shown (this is really the jpg)

Expected Results:  a little smarter to understand this is screen.jpg

Comment 1

[Keyser Sose]

COnfirmed
Platform: PC
OS: Windows 98
MOzilla build: 2001060703

Marking NEW.

Comment 2

[Francisco León]

I would have preferred that one of the netscape/mozilla developers would have
opened it (you may be one, i dont know) because i saw on another bug the
reference to files being named download.php before, but i cant remember what bug
was it.
Maybe it was the one that talked about gzip files being expanded after
downloading...

Comment 3

[neeti]

4.x behaves the same way

Comment 4

[benc]

->xp gui

Comment 5

[Francisco León]

Are you sure this is just GUI? Looks networking/http to me

Comment 6

[benc]

Based on my understanding, Necko doesn't draw the actual dialog box you see.

Comment 7

[Francisco León]

Perhaps we are not understanding each other. My bug report was about mozilla
confusing file names because of php code. I get the window with the dialog to
save "download.php" instead of somefile.jpg.
Is that GUI? 

Comment 8

[Jeremy M. Dolan]

Reseting priority.

The server is sending:

Content-Disposition: filename="screen.jpg"

Normally, servers send:

Content-Disposition: attachment; filename="foo"

I take it this is a server bug, or is leaving out the 'attachment' valid?
www.darkbasic.com is using Apache/1.3.14.

Sending back to networking.

Comment 9

[Doug Turner (:dougt)]

I believe that this is a xp-apps bug.  HTTP allows clients to peek at the http
headers.  Reassign to law.

Comment 10

[Christopher Hoess (gone)]

This is a server bug.  Look at RFC 2616, Section 19.5.1.  The BNF Grammar for
Content-Disposition says that the header *must* contain a disposition-type
before the disposition parameter(s) (filename).  The "normal" way of sending
(Content-Disposition: attachment; filename="foo") is correct.  Should go over to
Evang so darkbasic can fix their headers.

Comment 11

[Jeremy M. Dolan]

Thanks for the followthrough, Chris.

->Evang.  HTTP noncompliance at darkbasic.com

Comment 12

[Scott Davis]

Darkbasic.com is not the only non-complying server out there. I have noticed the
 problem downloading Solaris patches at sunsolve.sun.com. An example URL is
http://sunsolve.sun.com/pub-cgi/patchDownload.pl?target=108652&method=h (to
download the X11 server patch (108652) for Solaris 8 via HTTP.

HEAD http://sunsolve.sun.com/pub-cgi/patchDownload.pl?target=108652&method=h
HTTP/1.0

HTTP/1.0 200 OK
Date: Mon, 06 Aug 2001 01:05:59 GMT
Server: Apache/1.3.3 (Unix)
Content-disposition: filename="108652-35.zip"
Content-length: 7229442
Content-type: application/octet-stream

Comment 13

[Scott Davis]

I agree with Christopher Hoess that this is a server bug according to RFC 2616,
Section 19.5.1


However Section 19.3 Tolerant Applications commences with the paragraph:
   Although this document specifies the requirements for the
   generation of HTTP/1.1 messages, not all applications will
   be correct in their implementation. We therefore recommend
   that operational applications be tolerant of deviations
   whenever those deviations can be interpreted unambiguously.

Under this section, it is also a Mozilla bug to not offer the filename as the
default if a save file dialog is displayed, as the intent is unambiguous.

Comment 14

[Christopher Hoess (gone)]

Um, <Content-Disposition: inline; filename="foo"> is also a valid, though 
redundant, HTTP header.  Specifying only the filename is certainly ambiguous.  
Admittedly, I tend to disagree with section 19.3 (the woes of HTML, I think, 
should have taught us a few lessons about "tolerant" applications), but I don't 
think this header malformation can be thought of as "unambiguous".

Comment 15

[Linus Walleij]

I have experienced this problem too but in an even more annoying manner: sending
a valid HTTP/1.1 header like this

Content-Disposition: inline; filename="foo.png"

along with some binary data that is handled by the browser (in this case a png
image), will as expected cause the image to be displayed in the browser window.
Selecting "save as" from the menu or right-clicking the image and selecting save
will nevertheless use a filename drawn from the URI. This must be wrong - when
the server suggests a filename for something, it should be used. The same goes
for using "attachment" in place of "inline" (used in IE to force download of
handled filetypes). I have seen this information sent by way of things like:

Content-Type: image/x-png; name="foo.png"

too, but I don't know if that is really valid.

Comment 16

[Scott Davis]

I've also sent a bug report to SunSolve through their feedback URL
http://sunsolve.sun.com/pub-cgi/feedback.pl?type=pubsite to suggest they fix the
Content-disposition header.

I still believe that when the user has decided to save the file/URL, that the
broken header is unambiguous in that it contains a recommended filename. I agree
that it is ambiguous about whether the browser should immediately offer to save
the file, or display it (attachment vs inline) or something else, and have
accordingly removed my vote from this bug as it is now about dealing nicely with
broken servers.

Comment 17

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.

Comment 18

[Bob Clary [:bc] (inactive)]

Bill, unless you want to evang it, I will take it back.

Comment 19

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 20

[Christopher Aillon (sabbatical, not receiving bugmail)]

See bug 87743 for another related issue with this website.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Fixed by bug 121509 checkin

Comment 22

[Brant Gurganus]

Verified
2002022703/WinXP