W3C home > Mailing lists > Public > www-tag@w3.org > October 2007

Re: Triggering 303's

From: Mikael Nilsson <mikael@nilsson.name>
Date: Thu, 11 Oct 2007 11:03:43 +0200
To: Ed Davies <edavies@nildram.co.uk>
Cc: Dan Connolly <connolly@w3.org>, www-tag <www-tag@w3.org>
Message-Id: <1192093423.6841.26.camel@daneel>


tor 2007-10-11 klockan 09:18 +0100 skrev Ed Davies:
> Mikael Nilsson wrote:
> > ...
> > It worries me slightly that we now have a mechanism for getting RDF
> > information about non-info resources, but we have no way of getting
> > similar information about information resources, such as
> > ...
> > For symmetry, WebArch would be well served if there would be a
> > well-defined way to trigger such "See Other" responses.
> > ... 
> 
> I think this is the same point I made in a message about
> ISSUE-57 [1].  The ensuing discussion, particuarly the post
> by Tim BL [2], is worth a read though, given Dan Connolly's
> response [3], I'm not convinced the point has really been
> made.

Thanks, yes, that's exactly what I was after. Though the discussion led
to a long "IR vs nonIR" later on...

I'm coming at this from a pragmatic perspective, which I know is very
different from the HttpRange-14 topic. The HttpPrange-14 is about
(AFAIU) what a web server is supposed to answer in the non-IR case.

My question comes from the other end

--
  What sequence of requests is a web *client* supposed to emit in
  order to get information *about* a resource?
--

Looking at

http://lists.w3.org/Archives/Public/www-tag/2007Aug/0106.html

it's pretty obvious that 303's is *not* the answer to this question.
Even for a non-information resource, you don't really know if you get
metadata or something else. 

So I'm after something more predictable, dependable, and with a more
precise meaning, namely: "please get me metadata for this resource".

It seems to me timbl's answer in [2] makes a lot of sense - this needs
to be carried in the HEAD response (which I also mentioned in my reply
to DanC). I personally feel the "webarch" way to do it is to link to a
*resource* carrying metadata, and where you can do content negotiation
if you want. Nothing wrong with allowing a HTML representation, as long
as there is a HTTP-defined relation between the original URI and the
linked URI, that relation needs to say "metadata" and not just
"SeeOther" / "SeeAlso".

In short, +1 for timbl's Link: rel=meta suggestion.

I'd encourage the TAG to produce a statement to the effect that using
HTTP Link: is the right way to link to metadata for a resource.

Is there a formal definition of a Link: header somewhere? I only found a
mention in RFC 2068 [M1], and a note in RFC 2616 [M2]: "The [...], Link,
[...] header fields were defined in previous versions of this
specification, but not commonly implemented. See RFC 2068".

Time to revive "Link"?

/Mikael

[M1] http://www.w3.org/Protocols/rfc2068/rfc2068
[M2] http://www.w3.org/Protocols/rfc2616/rfc2616.html

> 
> Ed Davies.
> 
> [1] http://lists.w3.org/Archives/Public/www-tag/2007Aug/0075.html
> [2] http://lists.w3.org/Archives/Public/www-tag/2007Aug/0089.html
> [3] http://lists.w3.org/Archives/Public/www-tag/2007Oct/0004.html
> 
> 
-- 
<mikael@nilsson.name>

Plus ça change, plus c'est la même chose
Received on Thursday, 11 October 2007 09:03:47 UTC

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