W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: http-equiv and new http headers

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Thu, 20 Mar 1997 11:59:38 -0800
To: advax@triumf.ca
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <9703201159.aa04600@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2790
>In HTML, <META HTTP-EQUIV="Blah" is supposed to be equivalent to an
>HTTP header "Blah:", yes ?

Not quite.  It means that the content given has semantics equivalent
to the HTTP semantics for the header field "Blah".

>What is the position on creating new HTTP-EQUIV types (and presumeably
>equivalent HTTP headers) ?

That's backwards.  The only possibility is to create new HTTP headers,
which then could be used in HTTP-EQUIV.  Otherwise, use <META NAME="Blah">.

>In the Dublin Core metadata work a form <registry>.<name>[.<type>]
>seems to be accepted, e.g. 
><META NAME="DC.Author" CONTENT="Joe Fish">
>and perhaps
><META HTTP-EQUIV="DC.Author.email" CONTENT="jfish@pisces.org">
>and the equivalent
>DC.Author.email: jfish@pisces.org
>as an HTTP header
>which might imply that the "DC" portion should be reserved
>for the DC crowd, and registry-less names be reserved for the HTTP group.

That wouldn't make sense.  The DC. prefix is supposed to associate
semantics of the name with Dublin Core semantics, and for the exact same
reason that HTTP-EQUIV associates the name with HTTP semantics. 
If we were to reinvent HTML, then we would probably use

    <META NAME="HTTP.Expires" content="Wed, 19 Mar 1997 13:15:31 GMT">

instead of HTTP-EQUIV (or just skip the whole thing and just use LINK).

>What I don't want to see, obviously, is people generating headers like
>Expires: 4/5/99
>Location: Bournemouth

The server is fully capable of controlling what it sends.

Received on Thursday, 20 March 1997 12:35:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC