Mailing List Archive

>
>
> I was tempted to just say "no", but thought I'd check.
>
> If the answer is indeed "no", please Cc the submitter.
>
>
> Forwarded message:
> > From nobody@hyperreal.com Fri Oct 6 06:47:24 1995
> > Message-Id: <199510061347.GAA00390@taz.hyperreal.com>
> > From: davidmsl@anti.tesi.dsi.unimi.it
> > To: apache-bugs%apache.org@organic.com
> > Date: Fri Oct 6 6:47:04 1995
> > Subject: WWW Form Bug Report: "only a question about HEAD response" on OTHER:
> >
> > Submitter: davidmsl@anti.tesi.dsi.unimi.it
> > Operating system: OTHER:, version:
> > Extra Modules used:
> > URL exhibiting problem:
> >
> > Symptoms:
> > --
> > Sorry, but I didn't know the right address to use to write to someone of the Apache team... I'd like to know if your server handle (but I haven't found anything in the documentation) or will handle the HTTP-EQUIV meta tag. Davide Musella davidmsl@anti.tesi.dsi.unimi.it
> > --
> >
> > Backtrace:
> > --
> >
> > --
> >
>

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.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

Sorry; we don't handle <meta http-equiv> right now. It would be possible
to do this as a drop-in module, but we have no *immediate* plans to do so.

rst

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.

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

[.FYI, I just sent mail explaining this cc:ed to the original requester].

rst

>
> 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.

Yep, you're right - just checked the spec (HTML 3.0).


--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

> 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