On 22.9.2011, at 1.59, Andrew Richards wrote:
I'm seeing a strange problem with some attachment filenames that are UTF-8 encoded. The problem seems to be related to spaces and/or unusual characters in filenames, like accented characters (or perhaps just to filenames if UTF-8 encoded; I've not explored that fully).
The problem is that the client sends it wrong:
Content-Type: application/octet-stream; name==?UTF-8?B?dGhpc19mYWlscy50eHQ=?= Content-Disposition: attachment; filename==?UTF-8?B?dGhpc19mYWlscy50eHQ=?=
These are both wrong. First of all they are illegal because they have = and ? characters, from RFC 2045:
parameter := attribute "=" value value := token / quoted-string token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials> tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values
Also from RFC 2047 (encoded-word is the =?UTF-8?...?= thing):
- An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'.
The proper way to do this would be to use RFC 2184, which looks something like this:
Content-Disposition: attachment; filename*=iso-8859-1''p%E4%E4
Looks like Apple Mail also sends:
Content-Type: application/octet-stream; name="=?iso-8859-1?Q?p=E4=E4?="
That is inside a quoted-string, so it's not broken, but clients aren't really supposed to decode that string in there either.
Anyway .. I'll check tomorrow if I can easily add code to workaround your problem. If it's just a minor change I'll do it.