Re: patch suggestion for GSMime.m

[Pirmin Braun]

reverted and set a breakpoint on the line with the error message and got this:
#0  -[GSMimeParser(Private) _decodeHeader] (self=0xa9cbbf0, _cmd=0xb7fd6f48) at 
GSMime.m:2948
#1  0xb7dd7089 in -[GSMimeParser parseHeaders:remaining:] (self=0xa9cbbf0, 
_cmd=0xb7fd6f70, d=0xa5108b8, body=0xbfffd898) at GSMime.m:1582
#2  0xb7dd6916 in -[GSMimeParser parse:] (self=0xa9cbbf0, _cmd=0xb7fd6ee0, 
d=0xa5108b8) at GSMime.m:1459
#3  0xb7ddaa01 in -[GSMimeParser(Private) _decodeBody:] (self=0xd9660c8, 
_cmd=0xb7fd6f78, d=0x8825730) at GSMime.m:2763
#4  0xb7dd6987 in -[GSMimeParser parse:] (self=0xd9660c8, _cmd=0xb7b42140, 
d=0x8825730) at GSMime.m:1472
#5  0xb7b308ae in -[WebServerConnection _didData:] (self=0x8ef5938, 
_cmd=0xb7b421a0, d=0x84073e0) at WebServerConnection.m:1479
#6  0xb7b31875 in -[WebServerConnection _didRead:] (self=0x8ef5938, 
_cmd=0xb7b42090, notification=0xa299b00) at WebServerConnection.m:1626

(gdb) p beg
$2 = (
    const unsigned char *) 0xa632410 "Content-Disposition: form-data; 
name=\"parmDict.uploadData\"; filename=\"▒a.PDF\"\r\nContent-Type: 
application/pdf\r\n\r\n\004"
(gdb) p flags.isHttp
$3 = 0

so somehow the isHttp is not set to YES in this case; gonna find out, how this 
happens

Am Mon, 9 Sep 2013 09:35:41 +0100
schrieb Richard Frith-Macdonald <richardfrithmacdonald@gmail.com> :

> 
> On 9 Sep 2013, at 09:31, Richard Frith-Macdonald 
> <richardfrithmacdonald@gmail.com> wrote:
> 
> > 
> > On 8 Sep 2013, at 23:30, Pirmin Braun <pb@intars.de> wrote:
> > 
> >> Am Sun, 8 Sep 2013 21:36:31 +0100
> >> schrieb Richard Frith-Macdonald <richardfrithmacdonald@gmail.com> :
> >> 
> >>> 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.


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