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

Reply via email to