181555 - charset when publishing calendars (HTTP PUT)

Status: VERIFIED DUPLICATE of bug 167800

(Calendar :: General, defect)

Description

[Julian Reschke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016

When publishing calendars using HTTP PUT, Calendar should provide the character
set in the HTTP content-type header. This would enable the server to
subsequently serve the file with proper charset information.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Potter]

OK... Anyone know how to do this?

Comment 2

[Mike Potter]

From email:
Depends on how much control the Calendar has over the request headers. I'd
assume that if it can specify the mime type, it can also specify the
encoding? Such as:

Content-Type: foo/bar; charset=UTF-8

Comment 3

[Mike Potter]

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

Comment 4

[Jens Greven]

This also applies to calendars published via ftp. It can even lead to calendar
file corruption.

Comment 5

[XandreX]

confirming for my 2003061213-cal. This is an issue for people using non-ASCII
characters.
Still, though I understand that using the charset when doing an HTTP upload, the
problem remains for an FTP upload. How's that ? Should a new bug be filled ?

Comment 6

[XandreX]

After reading netscape.public.mozilla.calendar (though I have manaed to lose
that interesting post again), I think that it is not a network transfer problem,
but rather a double UTF-8 encoding.

Seems like a calendar stored only locally is converted UTF-8 only once, whereas
a calendar stored on a server (http https or ftp) seems to be converted twice to
UTF-8.

Comment 7

[Eric Belhaire]

*** This bug has been marked as a duplicate of 167800 ***

Comment 8

[R.J. Keller]

VERIFIED

Comment 9

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!