amos wrote:
> Content-Type: application/x-zip-compressed; name=UNKNOWN_PARAMETER_VALUE
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="=?utf-8?q?my=20UI=20Proposal.zip?="
[Code removed]
> is this a bug, or again, yahoo is to blame?
> mayb to overcome this issue, FFilename should get the fn value anyway?
> please advice
This is interestingly "a shortcoming of distinct RFCs", not a bug per se. The
problem is that RFC's 2183, 2045 and 1049 all address the issues that are
causing you trouble; the headers Content-Type and Content-Disposition. The
problem lies in the fact that the RFC's simply don't tell what to do when the
information in the distinct headers is conflicts with each other.
I'd put emphasis on this matter to RFC2183 as it is the latest one of the trio
and states:
a) that Filename parameter is a suggestion of the filename to use for
attachment disposition type and
b) that Content-Disposition parameters are valid for all dispositions (in
contrast to MIME Content-Type parameters, which are defined on a
per-content-type basis) - even the unknown ones.
Therefore, I'd suggest that it would propably be a good idea to change the code
to reflect this; ie. that if there is a Content-Disposition filename-parameter
present, it should be used instead of a name-parameter from another header.
Thus, changing the code:
if FFileName = '' then
FFileName := fn;
...into...
if fn <> '' then
FFileName := fn;
...should work. Comments?
--
Markku Uttula
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
synalist-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synalist-public
