Re: patch suggestion for GSMime.m

[Richard Frith-Macdonald]

On 7 Sep 2013, at 18:41, Pirmin Braun <pb@intars.de> wrote:

> Am Sat, 07 Sep 2013 18:13:04 +0200
> schrieb Fred Kiefer <fredkiefer@gmx.de> :
> 
>> On 06.09.2013 20:42, Pirmin Braun wrote:
>>> this was a bug for serveral years. Upload of Files with Umlaute in the 
>>> filename didn't work.
>>> With this modification it works.
>> 
>> Hi Pirmin,
>> 
>> could you please give an example of a text wrongly decoded by the old
>> code and correctly handled by yours? By looking at the patch I don't see
>> how this would result in a better decoding.
>> There definitely is one problem with your code. After decoding with
>> NSISOLatin1StringEncoding failed this is no use to try
>> NSASCIIStringEncoding which is a strict subset.
> 
> http://pirmin.de/GSWeb/Aprica3000230.woa/?pw=root&loginname=Administrator
> type "upload" in the "gehe zu.." Field and click "upload".
> take a "aä.pdf" file and try to upload  with Chrome or Firefox in a Web App 
> using GSWeb, i.e. IntarS:
> it won't work.
> rename the file to "a.pdf" and try again, it will work.
> This is in a very old Rev. of GNUstep.
> 
> In the Head Revision the behaviour was still the same until I changed the 
> GSMime.m according to the patch.
> The order of trying the encodings might be wrong but at least now every 
> encoding is tried.
> 
>> 
>> This means the main change of your code is that you always use
>> NSISOLatin1StringEncoding first, where the old code only did this for
>> flags.isHttp == 1. The second difference is that you don't try the
>> _defaultEncoding. Which of these should make the difference?
>> 
>> Fred
> 
> 
> -- 
> Pirmin Braun - IntarS Unternehmenssoftware GmbH - Am Hofbräuhaus 1 - 96450 
> Coburg
> +49 2642 40526292 +49 174 9747584 - skype:pirminb www.intars.de  pb@intars.de
> Geschäftsführer: Pirmin Braun, Ralf Engelhardt Registergericht: Amtsgericht 
> Coburg HRB3136

I guess the bug here is in the application using GSMime, rather than in GSMIme 
itsself.

Judging by the suggestion above, the intention here is to upload a file (whose 
name contains an umlaut) using a web browser.
Now, web browsers won't upload files by producing valid MIME documents.  So 
what's uploaded will probably not be a valid MIME document, so GSMime should 
reject it.
But ... GSMime is also intended to support HTTP stuff and has two options to 
support that:
1. setting the parser to tell it that it's supporting HTTP will get it to use 
latin1 rather than ascii ... since web stuff historically uses latin1 in places 
where the MIME specifications demand strict ascii only.
2. setting the parser to use a default characterset can be used to parse 
headers encoded using another characterset (so you can use whatever 
characterset the browser has been told to use when uploading a file) and falls 
back to utf-8 (which modern browsers tend to use when they haven't been told 
what to do bu the server.

It seems to me that the suggested patch just breaks all this and uses latin1 
all the time ... which would parse invalid documents without any warning/error, 
producing a header value with garbage values in it for any case where the 
header actually contained non-latin1 data.
This would of course appear to work perfectly for all uploads where header 
lines contained latin1 data.

I would have thought the correct fix would be for the calling application to 
use the existing methods to set the mime parser to be expecting http and/or a 
different characterset, since this application should know  the context (ie 
what is being parsed and what form the browser has been told to upload the data 
in).