We are updating our code to use the WWWLib 3.1 from WWWLib 3.0.  In 3.0 we
found that to get METHOD_HEAD to work we needed to set the HTImProxy global
variable to YES to keep the MIME parser from eating the header information.
With the WWWLib 3.1 we found that this no longer works, here's why and how
we fixed it.

Our goal is simple, use the WWWLib to get HTTP headers and pages off the net
and into a local file.  We created our own HTStreamClass and provide an
instance of it to request->output_stream.  The problem is the following code

/* Set up stream FROM network and corresponding read buffer */
http->isoc = HTInputSocket_new(http->sockfd);
http->target = HTImProxy ? request->output_stream : HTTPStatus_new(request,

If HTImProxy is not set the output goes to the HTTPStatus stream rather than
our output_stream.  HTTPStatus eats the header information; it never gets to
the request->output_stream.

Setting HTImProxy selects the correct output stream, but a problem in
HTTP.c:HTLoadHTTP:case HTTP_NEED_REQUEST causes an error return even though
the stream received the header correctly.  In short, the HTTPStatus stream
sets the http->next field to HTTP_GOT_DATA.  Any other stream does not know
to do this and does not have access to the http structure.  Here is how I
patched HTTP.c to fix the problem.

// mjd - when HTImProxy is set the MIME Parser does not get called so http->next
//	is always HTTP_ERROR.  This code fixes this bug

// old code begin
//	http->state = http->next; /* Jump to next state */
// old code end

// new code begin
	if ( HTImProxy && status == HT_LOADED )
        	http->state = HTTP_GOT_DATA;
		http->state = http->next;
// new code end

Note that this would be a problem anytime the HTImProxy variable is set

Is this a bug in the WWWLib 3.1 or is there a better way to use the library?

Mitch DeShields
IQ Interface
(415) 331-0304 (office)
(415) 331-9620 (fax)