368441 - Three custom-header prefs, three different formats

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Mike Cowperthwaite]

Mozilla supports three different prefs that are lists of custom headers.  Each one has a different format for the list:

mailnews.customHeaders:
  Each pref must end with ':' and separate from next with space(s)

mailnews.headers.extraExpandedHeaders
  Each pref must not end with ':' and separate from next with space(s)

mail.compose.other.header
  Each pref must not end with column, and separate from next with comma, 
  NO SPACE

This is a dumb state of affairs.

Each pref should be able to simply strip any colon, comma or whitespace between the list, and then concatenate the colon when needed in the program.

Comment 1

[Karsten Düsterloh]

Whitespace is not allowed in header names, comma is.
mail.compose.other.header is a known legacy atrocity.
mailnews.headers.extraExpandedHeaders is a new intolerant bastard. ;-)
(it's not multi-extension-safe)

Comment 2

[Wayne Mery (:wsmwk)]

Anything of value here?

Comment 3

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #2)

Anything of value here?

I think yes.
I tend to agree with comment 0, the current mess of three different formats for custom header prefs must be very confusing for users of this feature set. I'd also think that enterprise users are the most likely consumers, so we should support them better.

Let's analyse what we currently have, and come up with a more consistent approach.
I think we can easily tweak the splitting algorithms using smarter regex to be more flexible wrt input formats, along the expected result of comment 0.

Thoughts:

• At least, we should support (allow) a unified format for all three prefs.
• We should encourage (and use) a unified default format with ": " (colon, space) as separator (with the welcome side effect that valid headers having comma in header will be universally supported in accordance with RFC 5322).
• To avoid breaking legacy prefs or pref migrations, let's continue accepting legacy separators for each pref.
• Be tolerant wrt input formats, allow " " (space only) as a separator, and ignore spaces after any separator (": " | ", " | " ").

Analysis of current behaviour & Proposal for unified pref handling (legacy-tolerant)

	mailnews. customHeaders	mailnews.headers. extraExpandedHeaders	mail.compose. other.header
Applies to	advanced "Search messages" dialog	message reader	composition
Function	add custom headers to advanced search dialog's header dropdown (via "Customize headers...").	show custom headers in message reader with View > Headers > Normal.	add custom headers to >> extraRecipients dropdown
UI	yes (with syntax check)	no	no
Current split algorithm	.replace(/\s+/g, ""); .split(":"); (remove empty "") | .match(/[^:]+/g);	.split(" "); (ignore empty "")	.split(",") header.trim();
Current effective separator	":" (colon)	" " (space)	"," (comma)
Currently accepted separators	":" | ": "	" " (any number of spaces)	"," | ", "
Currently accepts comma in header	yes	yes	no
Proposed accepted separators (enable unified format)	":" | ": " | " " (any number of spaces)	":" | ": " | " " (any number of spaces)	":" | ": " | " " (any number of spaces) | "," | ", " (legacy compatibility)
Proposed default separator	": "	": "	": "
Proposal accepts comma in header	yes	yes	yes, when any of ":" | ": " | " " (not ", ") are found as separators

Comment 4

[Thomas D. (:thomas8)]

Alex, fyi, wrt long-term scalable solution for bug 1616514.

Comment 5

[max]

(In reply to Karsten Düsterloh from comment #1)

mail.compose.other.header is a known legacy atrocity.

What should be used instead of mail.compose.other.header if sometimes a custom header should be added to a composed message? An example is X-Debbugs-CC

https://www.debian.org/Bugs/Reporting#xcc

Another case is adjusting In-Reply-To, see the Bug #1800759 comment #9.

Comment 6

[chrizilla]

referencing related discussion in bug 353193 comment #9 by Karsten Düsterloh:

In theory, namely RFC 2822 section 3.6.8. Optional fields, header names can contain commas, so this is not a good idea (we already made that mistake for mail.compose.other.header which we should correct at some point also). You should use either a space or even better a colon as a delimiter...