Bug > JMAP/get > Return incorrect result when using invalid header parse form

[tlle14]

Actual Result

When using an invalid parse form of a header, it returns null instead of invalidArguments

Expected Result

Please confirm this expected result:

header:	header-field-name:	parse-form	Result
	valid	valid	valid
	valid	invalid	invalidArguments
	invalid	valid	null
	invalid	invalid	null (I guess)

Example:

1. "header:from:asAddresses" => Return the value
2. "header:from:asDate" => Return invalidArguments
3. "header:fro:asAddresses" => Return null
4. "header:fro:asBlahBlah" => Return invalidArguments or null?

If you haven't implemented this requirement yet, please update the documentation
https://github.com/linagora/james-project/blob/master/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/message.mdown

[tlle14]

If you haven't implemented this requirement yet, please update the documentation
https://github.com/linagora/james-project/blob/master/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/message.mdown

[Arsnael]

I would say:

1. "header:from:asAddresses" => Return the value
2. "header:from:asDate" => Return invalidArguments
3. "header:fro:asAddresses" => Return invalidArguments
4. "header:fro:asBlahBlah" => Return invalidArguments

The header field is an all. If the syntax of the field is incorrect, it is an error. Null is only returned if you fail to parse correctly the value of a header field. For example:

"header:from:asAddresses": "rcordier@linagora.com" => valid (valid header filed and valid value)

"header:from:asAddresses": "blabla" => should return null (valid header field but can't parse blabla as an email address)

Regarding documentation there is a task for this already planned: #3980

[chibenwa]

I (slightly) disagree.

I would say:

• 1. "header:from:asAddresses" => Return the value
• 2. "header:from:asDate" => Return invalidArguments (as from is implicitly known of being of type "asAdresses")
• 3. "header:fro:asAddresses" => Return the value (we should enable other parsing options for fields we don't know)
• 4. "header:fro:asBlahBlah" => Return invalidArguments (as BlahBlah is not a known header type)

"header:from:asAddresses": "blabla" => should return null (valid header field but can't parse blabla as an email address) => :+1:

[Arsnael]

Was not sure about point 3 but... I guess we can have custom headers too yes

[tlle14]

Was not sure about point 3 but... I guess we can have custom headers too yes

the point 3 means the header name is non-existing

[tlle14]

So I summarize as below:

the header filed parsed form = header:header-field-name:parse-form

• Either the header-filed-name or parse-form is invalid, the header filed parsed form is still invalid and returns invalidArguments because it is.
• Only return null when the value of the header field parsed form is invalid.