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:

	HTSetTraceMessageMask("sop");

as described at

	http://www.w3.org/Library/src/HTHome.html#Trace
 
> 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

	http://www.w3.org/Library/User/Using/HTML.html

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:

	http://www.w3.org/Library/src/HTHInit.html

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();
        HTMLInit(converters);
    }
 
> 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.

Henrik
Received on Monday, 21 December 1998 13:23:23 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 17:59:26 EDT