src/smblib smbtxt.c 1.36 1.37
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/home/rswindell/sbbs/src/smblib

Modified Files:
smbtxt.c
Log Message:
Ammendment to previous commit: "Content-type:" is already removed from
the string being passed around.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/smblib smbtxt.c 1.38 1.39
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/tmp/cvs-serv9792

Modified Files:
smbtxt.c
Log Message:
Fix off-by-one stack corruption introduced in rev 1.35.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/smblib smbtxt.c 1.39 1.40
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/tmp/cvs-serv15459

Modified Files:
smbtxt.c
Log Message:
smb_countattachments() now works - needed a filename buffer even though we don't care about filenames.
smb/mime_getattachment() now supports filenames with spaces in them. If we need to strip or convert to short filenames, do that in the application/script code, not in smblib.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/smblib smbtxt.c 1.40 1.41
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/tmp/cvs-serv2655

Modified Files:
smbtxt.c
Log Message:
Correctly detect a "last boundary delimeter":
--<boundary>--

Without this change, some attachment (e.g. from gmail) would not be correctly decoded because gmail would not insert any blank lines between the end of the nested multipart/alternative part and the beginning of the attachment part: --000000000000d75a0f058779bbb2--
--000000000000d75a12058779bbb4
Content-Type: image/jpeg;
name="29571163_1640947089321419_3376478908098884084_n.jpg" Content-Disposition: attachment;
filename="29571163_1640947089321419_3376478908098884084_n.jpg" Content-Transfer-Encoding: base64

It looks (from RFC2046) like boundary delimeters should actually be: "\r\n--<boundary>", but I'll look into that later.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/smblib smbtxt.c 1.43 1.44
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/tmp/cvs-serv21721

Modified Files:
smbtxt.c
Log Message:
Constify mime_getcontent() - don't modify the text buffer as that stops subsequent parsing (e.g. fall-back to html) to fail.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/smblib smbtxt.c 1.44 1.45
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/tmp/cvs-serv26237

Modified Files:
smbtxt.c
Log Message:
Support multipart/report MIME content-type, from RFC3462:
The syntax of Multipart/Report is identical to the Multipart/Mixed content type


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/smblib smbtxt.c 1.45 1.46
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/home/rswindell/sbbs/src/smblib

Modified Files:
smbtxt.c
Log Message:
Added NULL pointer (strdup failure) check for good measure.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/smblib smbtxt.c 1.46 1.47
Update of /cvsroot/sbbs/src/smblib
In directory cvs:/tmp/cvs-serv17219

Modified Files:
smbtxt.c
Log Message:
MIME header fields are case-insensitive. <sigh>
So replace some strstr() calls with either (new local function) strStartWith_i()
or strcasestr(), depending.
strStartWith_i() return length of the matched word, so no need to sprinkle about magic numeric constants everywhere. The extra calls to strlen() are worth the code clarity / reliability, methinks.
TODO: find out if there's a way to calculate the length of string-constants at compile-time (?).


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net