W3C home > Mailing lists > Public > www-lib@w3.org > October to December 2002

content-length transfer-encoding issue

From: Fred Covely <fcovely@bcftech.com>
Date: Thu, 19 Dec 2002 23:43:07 -0800
To: <www-lib@w3.org>
Message-ID: <NDBBIGEEOLAKIPFCDMLNOEODIPAA.fcovely@bcftech.com>

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 jwei@hal.com (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
Received on Friday, 20 December 2002 02:43:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:43 GMT