nasty little HTMIME bug (in 4.0D)

Got a winner for you. In HTMIME_put_block, you sequentially store
lines of the header. If you reach the end of the header, great, parse
it, otherwise keep going. 

HOWEVER, the buffer doesn't contain all of the header, i.e. some of it
is still in transit over the socket or something (i.e. they stuck in a
huge cookie value... grrr...), then most likely a header value is
incomplete. 

HTMIME_put_block will happily drop the incomplete header on the
floor. It will then put the remainder of the header in the buffer,
which will promptly get chucked by the parser (as it won't look like
any header it's seen!).

My current fix is to add the following:

HTMIME_put_block(...) {
...

if (!me->transparent) {
    ...
} else { 
    /* Added 3/25/97 by Erik Selberg <selberg@cs.washington.edu>
       If the buffer ends in the middle of a header field, it's dropped.
       Bummer. So be sure and stick whatever's left onto the buffer.
     */
  if (end-start) {
    HTChunk_putb(me->buffer, start, end-start);
    if (STREAM_TRACE)
      TTYPrint(TDEST,"MIMEPutBlock Chopped Header info, appending anyway `%s\'\n", start);
  }
}

I don't know if this is also the case in 5.0a, as I haven't fully
converted yet. However, from my brief scan it looks like this may be
the case.

-Erik

-- 
				Erik Selberg
"I get by with a little help	selberg@cs.washington.edu
 from my friends."		http://www.cs.washington.edu/homes/selberg

Received on Tuesday, 25 March 1997 20:54:31 UTC