SeaMonkey/1.1a build 20060901 To reproduce: 1. Click on provided URL 2. Get a dialog that offer to save this file as j%2E1467-9590%2E2005%2E00331%2Ex.pdf Expected result: Mozilla should save this file as j.1467-9590.2005.00331.x.pdf

I guess this requires having no PDF plugin installed?

I have no PDF plugin installed.

The server sends Content-Disposition: inline; filename=j%2E1467-9590%2E2005%2E00331%2Ex.pdf why wouldn't we use that?

Why then I RMB click at URL (right in this bugreport) and select "Save Link Target As...", it offers to save j.1467-9590.2005.00331.x.pdf ?

save-link-as gives you the dialog before contacting the server.

(In reply to comment #3) > The server sends > Content-Disposition: inline; filename=j%2E1467-9590%2E2005%2E00331%2Ex.pdf > > why wouldn't we use that? > I have tested IE without PDF plugin installed and it offers to save j.1467-9590.2005.00331.x.pdf

Then file a bug with IE to use the filename the server tells it to use. You still haven't said why the Mozilla behavior is wrong.

From RFC 2183 I do not see why Mozilla should unescape provided filename value. But there is no reason to call IE behavior a "bug" either. RFC 2183 does not strictly specify how the filename value has to be processed. It says only that "the suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below)." Perhaps, I need change this bugreport to a feature request. A related quote from RFC 2183: ===cut=== [...] filename-parm := "filename" "=" value [...] 2.3 The Filename Parameter The sender may want to suggest a filename to be used if the entity is detached and stored in a separate file. If the receiving MUA writes the entity to a file, the suggested filename should be used as a basis for the actual filename, where possible. It is important that the receiving MUA not blindly use the suggested filename. The suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below). The receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter. The filename should be treated as a terminal component only. Portable specification of directory paths might possibly be done in the future via a separate Content-Disposition parameter, but no provision is made for it in this draft. Current [RFC 2045] grammar restricts parameter values (and hence Content-Disposition filenames) to US-ASCII. We recognize the great desirability of allowing arbitrary character sets in filenames, but it is beyond the scope of this document to define the necessary mechanisms. We expect that the basic [RFC 1521] `value' specification will someday be amended to allow use of non-US-ASCII characters, at which time the same mechanism should be used in the Content-Disposition filename parameter. Beyond the limitation to US-ASCII, the sending MUA may wish to bear in mind the limitations of common filesystems. Many have severe length and character set restrictions. Short alphanumeric filenames are least likely to require modification by the receiving system. The presence of the filename parameter does not force an implementation to write the entity to a separate file. It is perfectly acceptable for implementations to leave the entity as part of the normal mail stream unless the user requests otherwise. As a consequence, the parameter may be used on any MIME entity, even `inline' ones. These will not normally be written to files, but the parameter could be used to provide a filename if the receiving user should choose to write the part to a file. ===cut===

It looks like this bug is a dup of bug 206788 and bug 162765 that are FIXED. I'm confused. btw, a quote from bug 206788 comment 0: ===cut=== According to RFC2183, which defines the Content-disposition header, the filename= part of the header should be encoded as follows: filename-parm := "filename" "=" value Where 'value' is defined in RFC2045 as: value := token / quoted-string Where 'quoted-string' is defined in RFC822 as: quoted-string = <"> *(qtext/quoted-pair) <"> qtext = <any CHAR excepting <">, "\" & CR, and including linear-white-space> quoted-pair = "\" CHAR ===cut=== If so, Mozilla should unquote filename value given in Content-Disposition.

We do unquote things as needed. But in this case they're not quoted. They're URI-escaped. Frankly, I think this should be wontfix.

INVALID, not WONTFIX, right? Anyway, I agree.