Bug 31170

Summary: Chan.I.Messages: decide if the values of "content-type" body part keys must be normalized
Product: Telepathy Reporter: Mikhail Zabaluev <mikhail.zabaluev>
Component: tp-specAssignee: Simon McVittie <smcv>
Status: VERIFIED DUPLICATE QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium Keywords: patch
Version: git master   
Hardware: Other   
OS: All   
URL:
Whiteboard:
i915 platform: i915 features:

Description Mikhail Zabaluev 2010-10-27 10:23:12 UTC
The current specification of Channel.Interface.Messages does not require that the value of a body part key "content-type" must be normalized in some way. Some existing code, including the proposed implementation in bug #29377, uses case-sensitive string comparisons for the value, e.g. expecting it to be strictly lowercased "text/plain". MIME and derived specifications allow content types to be case-insensitive, so mixed-case values can be received from protocols.
The specification should be clear on what kind strictness is expected for messages passed by the client and message data signalled by the connection manager.

I'd say we should treat client-supplied values liberally (and thus change the comparisons to be case-insensitive in the CMs), but lowercase the values reported by CMs (as the current implementations happen to do).
Comment 1 Simon McVittie 2010-11-03 06:09:41 UTC
(In reply to comment #0)
> I'd say we should treat client-supplied values liberally (and thus change the
> comparisons to be case-insensitive in the CMs), but lowercase the values
> reported by CMs (as the current implementations happen to do).

Sounds right to me.
Comment 2 Simon McVittie 2010-11-08 08:33:07 UTC
Fixed in my messages branch with your proposed semantics. I'm going to try to round up low-handing Messages changes there, so more patches will follow; if you review this, please say "reviewed up to and including 12345abcde" or similar.
Comment 3 Simon McVittie 2010-11-08 09:19:43 UTC
I'm now using Bug #26838 for a round of Messages cleanup.

*** This bug has been marked as a duplicate of bug 26838 ***
Comment 4 Mikhail Zabaluev 2010-11-09 04:12:49 UTC
The issue has been resolved in bug #26838.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.