63656 - Mozilla should recognize RFC2231 enconding of filename parameter

Status: RESOLVED WORKSFORME

(MailNews Core :: Internationalization, defect)

Description

[Makoto Kato [:m_kato]]

The filename parameter of Content-Disposition must uses RFC2231.
But Mozilla cannot corrently recognize filename parameter which uses RFC2231.

Comment 1

[Makoto Kato [:m_kato]]

Attachment: sample mail

Comment 2

[Makoto Kato [:m_kato]]

Attachment: patch

Comment 3

[Keyser Sose]

Adding RFE and patch keyword. Marking NEW, so someone will decide if this is a
good idea or not.

Comment 4

[nhottanscp]

You need to get a review by rhp for the patch.

I have a couple questions. You changed to support parameter continuation but the
patch does not have the code to unfold continuations. Has that already existed
in mozilla?
The patch does not do the decoding and instead converts from UTF-8 to specified
charset. Does that mean the decoding and the unfolding are done somewhere else
already?

Comment 5

[nhottanscp]

Remove RFE and reassign to Kato san, please get r=/sr= and check in.

Comment 6

[Katsuhiko Momoi]

Can you tell us if your patch covers/parses the following
items in RFC 2231?

1. Encoding name
2. Language name
3. Lightweight encoding used in RFC 2231

I don't know if we use Language name info right now
but potentially it may be used to set fonts correctly
in some cases.

Comment 7

[Makoto Kato [:m_kato]]

Momoi-san,
Langauge paramter does not watch since Mozilla uses Unicode/UTF-8 only by 
internal.  And font should not set since filename is not releted to font.

Comment 8

[Katsuhiko Momoi]

Kato-san,

Language name is optional and I don't think we should be
paying attention to it. So, yes, as long as we parse it
and ignore it, that is OK with me.

By the way, Keyser raised an issue if this is a good
thing. It is a good thing to implement because this
is the only acceptable way of transmitting non-ASCII
filenames.

Comment 9

[Katsuhiko Momoi]

QA contact to ji.

Comment 10

[Makoto Kato [:m_kato]]

I forgot the answer for hotta-san.

> I have a couple questions. You changed to support parameter continuation
> but the patch does not have the code to unfold continuations. Has that
> already existed in mozilla?

RFC2231 encoding is already implemented.  But this isn't used for filename 
parameter.  Probably, netscape engineeers don't understand abount encoding of 
filename parameter of Content-Disposition.  I told keith (the author of RFC).

> The patch does not do the decoding and instead converts from UTF-8 to
> specified charset. Does that mean the decoding and the unfolding are
> done somewhere else already?

mime_decode_filename() function decodes from RFC2047's encoding to UTF-8.
So I converted to UTF-8.

Comment 11

[nhottanscp]

Okay, please get this reviewed by rhp or ducarroz.

Comment 12

[Makoto Kato [:m_kato]]

rhp, can you review??

Comment 13

[Jean-Francois Ducarroz]

FYI, I am replacing rhp now.

Instead of doing the following pattern 4 time:
+          if (charset)
+          {
+            // this is seem to be a mail which supports RFC2231.
+            MIME_ConvertString(charset, "UTF-8", tmp->real_name, &fname);
+            PR_Free(charset);
+            charset = nsnull;
+          }
+          else
+            fname = mime_decode_filename(tmp->real_name);

Can you pass the charset to mime_decode_filename() and change this function do
the right job. Something like:

...
fname = mime_decode_filename(tmp->real_name, charset);
PR_FREEIF(charset);
...

Thanks

Comment 14

[Makoto Kato [:m_kato]]

Attachment: new fix at 2001/01/19

Comment 15

[Makoto Kato [:m_kato]]

ducarroz, could you review?

Comment 16

[Jean-Francois Ducarroz]

Twice you do:
+        PR_FREEIF(charset);
+        charset = nsnull;
as the macro PR_FREEIF will set the variable to 0, you don't need to do it
yourself. Appart that, R=ducarroz

Comment 17

[David :Bienvenu]

you could use an XPIDLCString for the charset, along with getter_Copies - then
you wouldn't need to put the PR_FREEIF's in at all. If you do that, or
ducarroz's suggestion, then sr=bienvenu

Comment 18

[Makoto Kato [:m_kato]]

check in

Comment 19

[John G. Myers]

This fix was designed poorly.  Had I been asked, I would have refused an r=.

The conversion to UTF-8 should be done in MimeHeaders_get_parameter().  It 
should not be the responsibility of every single caller to 
MimeHeaders_get_parameter(). The "charset" parameter of 
MimeHeaders_get_parameter() should be removed.

Comment 20

[Makoto Kato [:m_kato]]

Do you mean the following change?

char *
MimeHeaders_get_parameter (const char *header_value, const char *parm_name, 
                           char **charset, char **language)
 ->

char *
MimeHeaders_get_parameter (const char *header_value, const char *parm_name, 
                           char **language)

Comment 21

[nhottanscp]

Reassign to nhotta.

Does this still happen?

Comment 22

[ji]

This problem doesn't exist on 04/08 trunk build.
Marked it wfm. Kato, please feel free to reopen it if you still see this problem.