Re: header_get_value() field concat bug - anybody relying on this?

[Alain Magloire]

> 
> Bon soir,
> 

8-) that .. is usually one word,

> In the process of getting the smtp mailer_t working (not leaking
> bcc values, among other things) I've run into a problem Alain and
> I discussed a long while back.
> 
> If multiple fields with a given value exist in a message
> header, header_get_value() concatenates all the values and
> returns them. This is never right.
> 
> RFC822 says:
> 
>   This specification permits multiple  occurrences  of  most
>   fields.   Except  as  noted,  their  interpretation is not
>   specified here, and their use is discouraged.
> 
> A few fields, such as received:, do have defined meanings for
> multiple occurences, but are not parseable when all concatenated
> together.
> 
> Multiple to: fields are arguably meaningless, so possibly a bug in the
> message writer. However, like most (all?) structured fields, concatenating
> two fields results in syntactically invalid fields:
> 
> to: address@hidden
> to: address@hidden
> 
> header_get_value() gives me:
> 
> "address@hidden address@hidden"
> 
> This is an invalid address list.
> 
> Possible fixes:
> 
> 1 - return the first field
> 
>   If you want fields like Received: you will be using
>   header_get_field_value() looking at each one.
> 
> 2 - add an index to header_get_value()
>   
>   so you ask for the 1st "received" field, or the 2nd, etc.
> 
>   this would have the nice side effect of allowing the replacement of
>   header_get_value() and header_get_field_value() with a single function:
> 
>   header_get_value(header_t,
>       const char *name, size_t index,
>       char *value, size_t insz, size_t* outsz)
> 
>   a name of 0 could mean "any name", identical to the current
>   header_get_field_value().
> 
> 3 - make header_get_value() return an array of pointers to the values
> 
> ===
> 
> I want to do 1 now, and 2 when I have the time (there are other things
> to fix first).
> 
> Before I commit it, is imap, or something, relying on this odd
> concatenation side-effect?

The only way to answer this question, is to contact an IMAP server on port 
149(?)
and issue a FETCH of some specific headers.  You will find that
it does return the duplications, IIRC.

As usual in the RFC of IMAP there is no clear guidelines on this.
And think most servers will do the prudent thing and return any duplication:
To: fo\r\n
To: bar\r\n
xx FETCH OK.

But in any case, I agree we got it wrong, and the real solution is (2)
and (1) is just a particular case with index = 0;

If you find time to do (2) virtual beer on me, unless you drive through Ottawa 
8-).

Later, I'm off working on my IDE.