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).
(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.
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.
I'm now using Bug #26838 for a round of Messages cleanup. *** This bug has been marked as a duplicate of bug 26838 ***
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.