Re: Triggering 303's

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

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"?



> Ed Davies.
> [1]
> [2]
> [3]

Plus ça change, plus c'est la même chose

Received on Thursday, 11 October 2007 09:03:47 UTC