Re: HTTP HEAD not HTML <HEAD>...</HEAD>

> If Al is right (and he usually is),


He is, HEAD is just for HTTP header less the body. I was told this
morning by one of our HTTP guru that these headers should in theory
include "metadata" information for things that are found under <META>
HTTP-EQUIV in the HTML doc, but that this is not implemented (and
things like TITLE or DESC and just not here).

> then there could be an argument for a
> modification to HTTP that would facilitate the extraction of titles from
> HTML head elements, text fields from PNG images, etc.

Indeed, this part of HTTP could be clarified and extended and Javier
is on the hook to produce a requirement document for that, that we
will submit to the W3C HTTP working group.

> I have not had time
> to read through the HTTP specification (I am still working through the
> HTML 4.0 draft in my spare moments), but one solution that comes to mind
> is a pattern matching scheme. The server would read the file until a
> pattern supplied by the client was matched, and then transmit all of the
> data up to and including the octets that matched the pattern. This
> approach would eliminate the need for the server software to be able to
> interpret each particular file format (HTML, PNG, audio file formats,
> etc.), since the pattern matching request would be provided by the client
> (E.G. "</title>").

This is assuming that the client knows more about the document format
that the server. For HTML, this is true, but for image format, this is
probably not true. In fact, the client might not even know which
format is going to be returned (it can give preferences: PNG first,
then GIF and the server decides).

Received on Friday, 11 July 1997 05:26:23 UTC