4.1b1 *NULL, MIME parse bug

> Hi -

        Here are diffs for a couple of relatively 
minor problems with 4.1b1,
compiled on Solaris 2.x.  If your OS/compiler 
allows for NULL pointer
dereferencing, ignore at your peril.

        In HTMIME.c:_dispatchParsers(), an empty 
line (ie. "\r\n") in
the stream, results in a NULL token being returned 
HTChunk_data().  If STREAM_TRACE is enabled and 
token is NULL, a
segmentation violation will occur.

	A similar problem exists in
HTMIMPRS.c:HTMIMEParseSet_dispatch(), but this time 
it happens
regardless of tracing.  If the token parameter is 
NULL (see above),
then the subsequent call to HTMIMParseSet_hash() 
will fail.
	The _dispatchParsers() function is called 
HTMIME_put_block()/HTMIME_free() and in turn calls
HTMIMEParseSet_dispatch().  It may be that checking 
for a NULL token
in _dispatchParsers(), and not calling 
HTMIMEParseSet_dispatch() in
that case is the best solution.

	The empty line ("\r\n") shows up after 
MiniServ parses the
HTTP Request-Line and begins looking at the 
Headers.  The Request-Line
parsing apparently does not gobble the "\r\n".  
This should probably
be fixed, but as there are other changes in this 
function in
forthcoming versions of the library, I've held off 
pursuing the matter


<     if (STREAM_TRACE) HTTrace("checking MIME 
header %s: %s\n", token, value);
> ---
>     if (STREAM_TRACE) HTTrace("checking MIME header %s: %s\n", token ? token : "(null)", value);
<     if (STREAM_TRACE) HTTrace("Ignoring MIME 
header: %s: %s.\n", token, value);
>     if (STREAM_TRACE) HTTrace("Ignoring MIME header: %s: %s.\n", token ? token : "(null)", 

> #if 1
>     if (token != NULL) {
> #endif184a188,190
> #if 1
>     }
> #endif

Bill Rizzi	rizzi@softserv.com			
Software Services
    Z		http://www.softserv.com/~rizzi		
Santa Barbara, CA