content-length transfer-encoding issue

I have observed a bug on a SilverStream (Novell) web server that I accessing
as a client using libwww.  Any help is appreciated.

What happens is that I do a POST using SSL, then I do a non-ssl POST.

The second post returns to the application via HTReader_read status =
HT_LOADED, then to HTTPEvent(HTTP.c) which returns with a HT_OK, after a
call to CLEANUP which releases the response object.

Problem is the second post still has data coming in, so I lose a bunch of
return response from the server.

I have it down to this:

1.  The server does not send back 'content-length'.  It does send back a
transfer-encoding:chunk, which ought to allow for proper detection of the
last of the body response packets.  I can see a hex encoded body length in
the response, but libwww seems to ignore that altogether.

When I debug the following lines in HTMIME.c:

	/* Check if CL at all - thanks to [email protected] (John Wei) */
	long cl = HTResponse_length(me->response);

cl comes back '0' during the failure.  It appears that the htresponse length
is not being set correctly if there is no 'content-length' header, and there
is instead a hex coded length along with a transfer-encoding:chunk header.

That seems like a scenario which should happen all the time, so perhaps the
SSL is messing something up?  Maybe not!

Any ideas appreciated.

thx
Fred Covely
BCF Technology