Re: WWW Form Bug Report: "only a question about HEAD response" on OTHER: (fwd)

["Roy T. Fielding" <fi...@avron.ICS.UCI.EDU>]

>   It was my understanding that HTTP-EQUIV was a client side function
>   (specifically designed for use with servers that don't support the desired
>   headers). I could be wrong.
> 
> My understanding (based on old HTML-WG traffic) is that it is specifically
> intended to direct the server to include new headers on the HTTP response.

It's a long story.  When I wrote MOMspider, I needed a way for authors
to be able to say "here is something I consider metainformation that can
be included in a HEAD request."  There are a number of ways to do this,
each described in the paper for the Geneva WWW conference, but the end
result was that I invented the META element.  However, someone else
(hmmm, actually, I seem to recall it being rst) pointed out that META
can be used in general and that not all metainformation is desirable
within a HEAD response.  That is why there is separate NAME= and
HTTP-EQUIV= attributes.

The HTML 2.0 spec says that a server *may* include the information
given by <META http-equiv="field-name" content="field-value"> as

   field-name: field-value

in response to a retrieval request on that resource.  The reason for doing
so is to support indexing or maintenance spiders which use that information
to control traversal (or just assign categories) without transferring
the full resource.  How it extracts the META data is up to the server --
when people ask, I usually suggest a batch process which creates a hash
table for each URL.

BTW, the reason for META instead of a wrapper like .asis or .mime files
is because META is useful at the client side even if the server does not
support putting it in the response headers.

> I don't believe anyone actually does this (yet), though...

WN does.  I would not recommend it for Apache until we are willing
to do a general overhaul of the URL -> filespace mapping.

.....Roy