Am Sun, 8 Sep 2013 21:36:31 +0100 schrieb Richard Frith-Macdonald <richardfrithmacdon...@gmail.com> :
> > On 7 Sep 2013, at 18:41, Pirmin Braun <p...@intars.de> wrote: > > > Am Sat, 07 Sep 2013 18:13:04 +0200 > > schrieb Fred Kiefer <fredkie...@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 > > p...@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 p...@intars.de Geschäftsführer: Pirmin Braun, Ralf Engelhardt Registergericht: Amtsgericht Coburg HRB3136 _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep