Sergey Poznyakoff wrote:
>> But does not work, if filename*0*, filename*1*, filename*3*
>> (filename*2* is missing).
>
> That's intended. It really should not. Quoth RFC 2231, section 3:
>
Yes, but if filename*0*="a", filename*1*="b", filename*3*="c".
get_attachment_name should return fname="ab" (excluding "с"), is not it?
But now return NULL.
> Nope. I've forgotten to inform you (or, better said, supposed
> you to have paid attention to the ChangeLog, alias git log. It's a rule
> of thumb now, that you've cloned the repo): use
> mu_message_aget_decoded_attachment_name, which does all the dirty
> work for you. E.g.:
Well, try to use it, I'll tell the result later.
>> Does not work but really existing attachements:
>> -- Content-Disposition: attachment; filename = "111.doc"
>> -- Content-Disposition: attachment; name = "111.doc"
>> -- Content-Disposition: attachment; name="111.doc"
>
> Hmm, give more details please, would you?
-- ordinary mime header, but if "Content-Disposition" has "name" param
instead "filename", get_attachment_name return NULL.
-- ordinary mime header, but if "filename"("name") separated from "equal
sign"("=") by space, get_attachment_name return NULL.
Example:
---- filename="111.doc" - works well.
---- filename = "111.doc" - does not work (space before and after "equal
sign"("="))
=kostik
_______________________________________________
Bug-mailutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-mailutils
