Re: Upgrade of W3C Reference Library
To: firstname.lastname@example.org (Markku Savela)
Subject: Re: Upgrade of W3C Reference Library
From: Henrik Frystyk Nielsen <email@example.com>
Date: Tue, 13 Feb 1996 09:50:48 -0500
From firstname.lastname@example.org Tue Feb 13 09: 50:53 1996
Reply-To: Henrik Frystyk Nielsen <email@example.com>
X-Mailer: exmh version 1.6.2 7/18/95
Markku Savela writes:
> I updated to the library 4.0D, and again got lost with my converters.
> With 4.0B, the following set
> HTConversion_add(conv,"text/*","*/*", TextObject, 1.0,0.0,0.0);
> HTConversion_add(conv,"image/*","*/*", ImageObject, 1.0,0.0,0.0);
> HTConversion_add(conv,"text/html","*/*", HtmlObject, 1.0,0.0,0.0);
> got me a call to HtmlObject for "text/html".
> Now, the *same* code linked against the 4.0D library gives from the
> same document a call to TextObject (and when I print the
> input_format->name, it is "text/x-http"). What changed? Why this
> The new HTLine.c seems to add a new thing, what was not there before
> HTConversion_add(conv,"text/x-http","*/*",HTTPStatus_new,1.0, 0.0, 0.0);
> This is now required for my scheme to work? Because, when I added
> this, the program started to work again.
> However, I would like to know why. What should I read to get a better
> idea what happens with these conversions (something that would
> describe what the matching rules are, how the parameters of the
> HTConversion_add are actually used?)
I am sorry if that was not clear from the release notes. The new format
"text/x-http" allows me to use the stream stack for selecting the HTTP status
stream instead of hardcoding it into the HTTP module. The latter as a quite
client specific thing as it is not always that you want the response line to
be interpreted. For example, imagine that you are a proxy and you are talking
to a HTTP/1.x client (user agent) and a HTTP/1.x server (origin server). In
that case you want to be able to forward the response directly without
touching it. This is now possible as the HTTPStatus stream (in HTTP.c) now can
be set up via the stream stack.
Your observation about registering the HTTPStatus_new stream is correct and
that's why it started working again! However, if you look into the mini
server, you will see that this stream is _not_registered. In fact, it is often
a much more flexible solution if all streams has to go through the stream
stack algorithm. This gives a much more flexible stream design as all streams
can be set up at run time instead of hardcoded into the application.
Also, please note that you need to supply redirection callback function as
this is _not_ done automatically by HTTP.c. Again the reason is that in some
cases, you want to be able to return the redirection code as the final result
and not the result of the redirection. This is for example the case in a proxy
server and many robots.
Henrik Frystyk Nielsen, <firstname.lastname@example.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA