353113 - Periods in file names are escaped with %2E while saving to disk

Status: RESOLVED INVALID

(Core Graveyard :: File Handling, defect)

Description

[Max Alekseyev]

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

Comment 1

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

I guess this requires having no PDF plugin installed?

Comment 2

[Max Alekseyev]

I have no PDF plugin installed.

Comment 3

[Andrew Schultz]

The server sends
Content-Disposition: inline; filename=j%2E1467-9590%2E2005%2E00331%2Ex.pdf

why wouldn't we use that?

Comment 4

[Max Alekseyev]

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  ?

Comment 5

[Andrew Schultz]

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

Comment 6

[Max Alekseyev]

(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

Comment 7

[Andrew Schultz]

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.

Comment 8

[Max Alekseyev]

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===

Comment 9

[Max Alekseyev]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.

Comment 11

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

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