you have my vote for that


On 19/02/2008 13:52:33, Markku Uttula - [EMAIL PROTECTED] wrote:
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
-------------------------------------------------------------------------
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

Reply via email to