On 9 Sep 2013, at 09:31, Richard Frith-Macdonald <[email protected]> wrote:
> > On 8 Sep 2013, at 23:30, Pirmin Braun <[email protected]> wrote: > >> Am Sun, 8 Sep 2013 21:36:31 +0100 >> schrieb Richard Frith-Macdonald <[email protected]> : >> >>> 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. > > Sounds like there is something else going on ... if we are tryihng latin1 the > character conversion should never fail: since latin1 is an 8bit characterset > with all 256 available codepoints used, any data should represent a valid > string, so I guess the error message must be about something other than the > encoding. But ... checking the code I see no other way to get that 'Bad header ... illegal characters in %@' message. Can you provide example code to reproduce the problem? I'd like to try running it under gdb to see what's going on. _______________________________________________ Bug-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnustep
