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

Re: -902

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 21 Dec 1998 13:23:18 -0500
To: www-lib@w3.org
Message-ID: <367E9216.12345586@w3.org>
To: Jim_Ravan@avid.com

Jim_Ravan@avid.com wrote:
> So basically, HTReader_read, the socket stream, read the socket, and got
> the data above. That routine then passed the data downstream to
> HTTPStatus_put_block, who then passed the data downstream to
> HTMIME_put_block. The MIME header parser then started parsing the header,
> and came to the <CR><LF><CR><LF> body separator. Upon encountering that,
> the remaining body data was passed downstream to (as I suspected by this
> time) THE GENERIC ERROR STREAM. The error stream HTErrorStream_write,
> simply replies HT_ERROR (-1, Generic failure). That eventually cascades
> back and causes the request to generate an HTEvent_Close event, which tears
> everything down and causes the PUT request to return -902.

Well done! I know that it takes a little while before getting into the
libwww stream model. However, I have not found another model that is
more flexible nor works better with Web based applications. It could,
however, be more evident though that this is what happened - especially
with PUT where it is more often the server that causes trouble.

I will add some code to the MIME parser that adds an error to the error
stack so that the application easier can see what is going on. In the
meantime, a good tip is to turn on the protocol trace, core trace, and
stream trace like this:


as described at

> So, now I know what the *real* problem is. I just have to understand why
> there isn't anyone downstream of the MIME header parser to handle the body.
> I suspect I might not have a content translator installed that I need (but
> ... "text/html"? That's pretty basic stuff. It's hard for me to understand
> why I didn't get a "text/html" decoder by default from
> HTProfile_newNoCacheClient()) But progress is being made.

The reason is that the HTML parser stream requires that the application
provides an implementation of the HText interface, see


If you are interested in only the HTML parser but not any output (or
just a limited output like for example the robot has) then you can setup
the HTML parser as described in:


You can also see an example in the line mode browser, for example:

    /* Add the default HTML parser to the set of converters */
        HTList * converters = HTFormat_conversion();
> regards and thanks Henrik and Olga,
> P.S. and if anyone wants to pipe up and explain why there was an error
> stream, instead of, say, a black hole, downstream of the MIME header
> parser, I'd be very happy.

At some point it was but the problem with this solution is that you may
waste a lot of bandwidth/time if you are downloading a big object and
just pump it into a black hole - especially if you are on a dialup link.
The error stream stops the transfer immediately.

Received on Monday, 21 December 1998 13:23:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:48 UTC