DZ-Jay wrote: > On Jun 2, 2005, at 06:04, Arno Garrels wrote: > >> [snip a lot] >> > [snip some more!] >>> In essence, what that means is that the second <CRLF> that you see >>> belongs to the boundary itself and should have been removed by >>> MimeDec. >> >> Thanks DZ and Michael, >> >> After a brief look at MimeDec.pas I gave it up (too complicated for me >> today), >> I fixed it on the application level :( > > Arno, > > Have you had a chance to look into this?
No I haven't, I decided to not touch MimeDec.pas and fixed it on the application level (2 lines in my code). However it would be nice to get this fixed in the component. I wonder if Francois has noticed this thread? May be the subject should be changed to "BUG in MimeDec" ;-) May be he's currently more interested in HTTP and SSL stuff? Unfortunately I can't say more. Arno Garrels > I tried to study MimeDec.pas a > few days ago, but found it (like you) too complicated for the moment > (its been a while since I touched TWSocket code specifically and Delphi > in general). But the immediate problem that I saw is that the decoded > string is being written to the output buffer "live", as it is being > decoded, line by line, including the blank lines which come before > boundaries and should be removed. > > Since these blanks belong to the boundary itself, I only see potential > 3 solutions: > > 1. Change the boundary detection to look for "#10#13--<boundary>#10#13" > instead of just "--<boundary>#10#13". But this might be hard, because > as far as I understood MimeDec, it already has the stream split into > lines before testing for boundaries, and so it is not looking for > "--<boundary>#10#13", but for "--<boundary>" in the next string, which > happens to be a line; in this case, it would need to combine with #2 > below. > > 2. Implement a look-ahead system when writing the buffer (or detecting > boundaries) to remove blank lines belonging to the boundaries (or > ignore them when detecting). > > 3. Remove the blank lines from the output buffer ex post facto, i.e. > once we detect a boundary, we are guaranteed to have found a blank line > before (a boundary must have a #10#13 before it -- or else this is not > a valid MIME encapsulation!), which has already been written into the > output buffer, and so we go back and remove it. This is fine if the > output buffer is in fact a buffer, but I'm not sure if it is, or could > be, a file stream, in which case removing a written line is not > trivial. > > These are only very high-level ideas, because I didn't spend more than > 30 minutes studying MimeDec, and so they could be way off the mark. > What do you guys think? > > dZ. > > -- > Trying to teach good programming habits in VB6 is like trying to teach > proper hygiene in a sewer. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be