308569 - CalDAV should specify HTTP charset as UTF8

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Comment 1

[Matthew (lilmatt) Willis]

Dan,
Where and when should we be declaring it? Each time we PUT?

Comment 2

[Helge Hess]

Bug 311265 is probably a DUP to this one.

The charset should be specified in all requests which transport textual content (text/*, XML, iCalendar, etc). That is, not only in PUT but also in PROPFIND / REPORT.

Comment 3

[Simon Paquet [:sipaq]]

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

Comment 4

[Bruno Browning]

Of nsIWebDAVService, we currently use:
putFromString with Content-Type set to "text/calendar; charset=utf-8"
remove (no textual content)
report with Content-Type set to "text/xml; charset=utf-8" and Accept-Charset set to "utf-8,*;q=0.1"

We'll probably soon start using getResourceProperties, which behaves like report in this regard.

So I'm setting qawanted to see who agrees that this is fixed.

Comment 5

[cmtalbert]

I applaud your use the QAWanted flag, but could you include some steps to reproduce the behavior you would like tested?

My thought to test this is to send up an ICS file full of Japanese characters and ensure those characters come down unmolested on another system. 

What do you think?

Comment 6

[Bruno Browning]

Actually, I think that if we can't roundtrip events full of Japanese characters to a CalDAV server, that's a different bug. The way I read this one (and we may need to ask dmose precisely what he meant) has to do with how mozcal declares the charset in the HTTP headers that it emits. Since the data we send to the CalDAV server is either XML or iCalendar, that data should always be UTF-8, and that fact should be clear in the headers. So to test it we need someone (other than me, who wrote a patch in a closely-related bug, 311263) to use something along the lines of Wireshark to examine the headers in data we send to make sure they're appropriate.  And to some extent I think that QA here means having someone agree as to what "appropriate" means here, since the wording of the bug is a little, um, vague.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Comments 4 and 6 both seem correct to me.  As far as "appropriate" strings, I think "containing 'charset=utf-8'" or something similar" is what we're looking for here.

Comment 8

[Bruno Browning]

per comment #7 and dmose on irc, resolving FIXED