Re: patch suggestion for GSMime.m

[Pirmin Braun]

Am Sun, 8 Sep 2013 21:36:31 +0100
schrieb Richard Frith-Macdonald <richardfrithmacdonald@gmail.com> :

> 
> 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).
> 
> 
> 

the application using GSMime is the webserver-Library; in WebServerConnection.m 
it says:
          parser = [GSMimeParser new];
          [parser setIsHttp];
so GSMimeParser will try NSISOLatin1StringEncoding, which obviously fails. 
Since _defaultEncoding is left unchanged at NSASCIIStringEncoding, no further 
attempts are made and it ends up with the NSLog(@"Bad header ... illegal 
characters in %@"

so I thought, lets try all encodings. I think, the header is encoded in UTF-8. 
But will look at it with gdb now to be sure.


-- 
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