Re: What is the content type of the document being loaded?

> 	I'm experiencing some troubles with the library of common code
> and this is my firt message to this list. Please disregard my bad
> english :-)

Oh, I think they are getting used to it ;-)
 
> 	I'm willing to load some documents, pass them through some
> structured or unstructured streams then write them to disk.
> 
> 	The exact streams used for a given document is dependent of
> the content type of this document.
> 
> 	Now I'm loading the documents using theses steps:
> 
> 	I create a request structure containing a GET nethod, a
> WWW_SOURCE output format, no converters or presenters, and a given
> output stream wich eventaly ends in a file.
> 
> 	I call the HTLoadAbsolute to perform the loading operations
> and all goes well.

This is all good and sound!

> 	My trouble is that I can't predict the content type of the
> loaded document and must use this or this output stream to postprocess
> it. Note that theses postprocessing streams are linked in a tree form
> (two branchs then stacks). The exact organisation of the "stream
> stacks" depends of the content type of the document.
> 
> 	This would be easy to write the the HTStreamStack function
> could generate an elaborated stack from a given list of convertes
> (more than 1 level deep). I dreamed that this freature would be
> corrected for the 3.1 release. It was not. So I need another solution.

What you need is not a list of the actual conversions but the original media 
type (content type) when the data object arrives from the network. Your 
problem is in fact solved in version 3.1 of the Library. There the anchor 
object has been extended to include all metainformation about the object such 
as the media type, content length etc. This information is for example 
obtained in the header parser (HTMIME.c)

Also remember, that you can define how you want to set up the stream stack by 
modifying the HTInit.c module. The Library is shipped with a default set of 
conversions but this can ((and will often) be overriden by applications.


-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Thursday, 28 September 1995 09:31:45 UTC