W3C home > Mailing lists > Public > www-tag@w3.org > February 2003

RE: Proposed issue: site metadata hook (slight variation)

From: <Patrick.Stickler@nokia.com>
Date: Wed, 12 Feb 2003 19:15:02 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B01B90B4A@trebe006.europe.nokia.com>
To: <miles@milessabin.com>, <www-tag@w3.org>

> -----Original Message-----
> From: ext Miles Sabin [mailto:miles@milessabin.com]
> Sent: 12 February, 2003 18:00
> To: www-tag@w3.org
> Subject: Re: Proposed issue: site metadata hook (slight variation)
> Jeffrey Winter wrote,
> > Miles Sabin wrote,
> > > Extension _headers_ are close to universally supported. I 
> could sit
> > > down right now and write a Java client which added a Meta: request
> > > header to requests, set up an Apache instance which used 
> mod_rewrite
> > > to respond appropriately, and expect the pair to be able to
> > > communicate through arbitrary proxies and firewalls.
> >
> > I was speaking specifically of their semantic support. Most servers
> > wouldn't understand what they meant, that's all I was trying to say.
> Well, on the assumption that a server not understanding a 
> Meta: request 
> header implies that there's no metadata, and that the absence of a 
> Meta-Location: response header informs the client of that 
> fact, then it 
> looks to me as tho' we have support for GET+Meta by default.

Fine, but as has been pointed out, it does *not* work for PUT or DELETE,
which can have catastrophic results, with a server overwriting or
deleting the *resource* rather than the *description* because it 
didn't understand what was actually meant by the Meta: tag.

As far as I'm convinced, this alone demonstrates the combination of
existing methods with header tags as untenable.

New verbs are needed to be sure that the communication between client
and server is clear and safe. Period.

Received on Wednesday, 12 February 2003 12:15:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:37 UTC