24940 - Attachment send does not use HTTP charset to create content-type header

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[marina]

Steps to reproduce:
-go to the above URL;
-switch your encoding to KOI8-R;
-send page (File|Send page);
-go and get the message with this page attached;
-note: contents are displayed as garbage (no encoding change helps)
//this page has no META tag

Comment 1

[nhottanscp]

If no META tag in attachments, those messages can be seen either by the charset 
menu (bug 5938) or auto charset detection.
Could you try this with Russian auto detection ON?

Comment 2

[marina]

with Russian Autodetector on (View|Autodetection|Russian)i have the same results 
(garbage)  

Comment 3

[nhottanscp]

One more question, can you see the original page in browser (with Russian auto 
detection)?

Comment 4

[marina]

Yes, in browser everything looks correct.

Comment 5

[marina]

Attachment: this is a web page in question saved locally

Comment 6

[nhottanscp]

The web page has http charset sent by the server so it was always viewable.
The locally saved page (charset is windows-1251) cannot be auto-detected 
correctly by the browser too.
Generic Russian auto-detection problem, reassign to ftang.

Comment 7

[Katsuhiko Momoi]

By the way, I think this page should be viewable when we can
override the charset parameter of the attachment with 
Character coding menu. When we send mail, we can only
set KOI8-R as we don't have Windows-1251 in the menu
and this creates disparity between what the charset parameter
says this attachment is in and what the content really is.

One possible remedy would be for us to include Win-1251 into
the send menu. This way, new mail can be sensitive to the 
server-generated HTTP charset.

Comment 8

[Frank Tang]

reassign back to nhotta. This is not an auto detection problem. Without 
autodetection, the page can be viewed without problem since the HTTP charset is 
present. This is a mail sending problem, when the messanger send the mail, it 
should listen to the HTTP charset also. 

Comment 9

[nhottanscp]

I think the Russian detection code has a problem (it cannot detect the locally 
saved page, either in browser or mail). That is bigger problem than this 
particular HTTP charset problem (may be filed as a separate bug).
I change the summary specific to HTTP charset. Since this is not in an original 
spec (http://www.mozilla.org/projects/intl/mail-news-i18n-spec.html), mark as 
M16.

Comment 10

[nhottanscp]

Rich, is that possible to get HTTP charset (sent by the server) when generating 
a web page? Currently, we parse the page for META tag but not HTTP charset.

Comment 11

[rhp (gone)]

Oh, this is very possible. Let me work on this and I will send you a patch that 
should fix this issue in about an hour.

- rhp

Comment 12

[Katsuhiko Momoi]

The Russian Detection problems are known. There is at least one bug for improving detection
algorithm. For example, Bug 23920.

Comment 13

[rhp (gone)]

I'll take this one since I have a fix for it in my tree. I plan on checking it 
in as soon as we get an open tree.

- rhp

Comment 14

[rhp (gone)]

Attachment: Fix for this bug - apply from the same level as mozilla

Comment 15

[nhottanscp]

Thanks, that's quick. I'll update the spec.
So, use HTTP charset when available that has a higher priority than META (as 
browser).

Comment 16

[rhp (gone)]

Yes, I will use the HTTP return value as the charset if it is available.

- rhp

Comment 17

[rhp (gone)]

Yes, I will use the HTTP return value as the charset if it is available. Also, 
I tested by attaching the above Russian web page and sending it to myself and 
it all rendered fine without any charset menu tweaking :-)

- rhp

Comment 18

[rhp (gone)]

Checked in this fix.

- rhp

Comment 19

[Katsuhiko Momoi]

** Checked with 2/1/2000 Win32 M14 build **

I sent the following page along with a Japanese msg in the main body:

http://kaze:8000/TEST/eucb.html

This page comes with the server emitted EUC-JP charset info.

I received this msg with Mozilla and had no problme displaying
the main body (in ISO-2022-JP) and the attachment (in EUC-JP).
The source showed that the attachment had correct charset
parameter "EUC-JP" received from the server.

marina, please confirm that your Russian page (windows-1251) 
attachemtn can now be displayed with KOI8-R mail msg.

I'll mark the fix verified. Please re-open if there is a
problem with the Russian or other language cases.