Kostik <[email protected]> ha escrit:
> Yes, but if filename*0*="a", filename*1*="b", filename*3*="c".
> get_attachment_name should return fname="ab" (excluding "Ó"), is not
> it?
No, it should not. There is a gap in sequence (0, 1, -- missing 2 --, 3),
which is expressly prohibited by rfc 2231, so MU does right when
returning error in this case.
> Well, try to use it, I'll tell the result later.
OK
> -- ordinary mime header, but if "Content-Disposition" has "name" param
> instead "filename", get_attachment_name return NULL.
There is no such parameter in Content-Disposition header. Says RFC
2183, section 2:
disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)
disposition-type := "inline"
/ "attachment"
/ extension-token
disposition-parm := filename-parm
....
filename-parm := "filename" "=" value
You see, it is "filename" not "name", that has special meaning.
> -- 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"("="))
In my opinion, that's right. I may be too purist about reading the RFCs,
but neither RFC 2045 nor 2183 seem to indicate that any whitespace
characters are allowed around the '='. Let me know if you find any
evidence for the contrary.
Regards,
Sergey
_______________________________________________
Bug-mailutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-mailutils
