According to RFC 2045, it's not legal syntax, because a
(non-quoted) token cannot contain spaces:
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
I don't know of a good way to get mhshow to handle it. If
you want to hack the source, it looks like line 789 of
uip/mhparse.c is the place:
for (cp = dp, dp = vp; istoken (*cp); cp++, dp++)
I don't see how allowing spaces in the token could hurt, if
we want to consider a permanent hack.
David
Paul writes:
can someone tell me whether this is legal syntax for
a Content-Type field?
> --Apple-Mail-21--97781285
> Content-Transfer-Encoding: base64
> Content-Type: application/pdf;
> x-unix-mode=0644;
> name=Low Cost Laptop.pdf
> Content-Disposition: inline;
> filename="Low Cost Laptop.pdf"
>
the issue, unsurprisingly, is the lack of quotes on the "name="
field. i have the following rule in .mh_profile, which catches
otherwise unhandled application types and lets me save the file:
mhshow-show-application: fallback_save '%f' '%a'
when invoked, the fallback_save script is getting the string:
'x-unix-mode="0644" name="Low"'
(without the single quotes) as its second argument.
so -- who's at fault, and if it's apple mail, is there a way
to make mhshow handle this better?
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers