RE: Inconsistencies in Discovery methods

This solves my problem with regard to the Link header.

On Feb 06, 2009 4:41 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:

> The Link header field defines what it is about: [RFC2068]
>
>     The Link entity-header field provides a means for describing a
>     relationship between two resources, generally between the requested
>     resource and some other resource.

Isn't this a bit of a contradiction? The same spec defines entity-header as:

    Entity-header fields define optional metainformation about the
    entity-body or, if no body is present, about the resource identified
    by the request.

(which is identical to the language in the most recent draft without the word 'optional').

A 404 response can have an entity-body, which you defined as "representation of a resource on the server that describes that error". So a Link header on a 404 with no body is consistent between the Link header definition and the entity-header definition. But if a body is present, they contradict each other.

> If you think it would be helpful to distinguish the Link header
> field (resource metadata) from a Content-Link header field
> (representation metadata), then that is a separate discussion.

My use case needs a resource metadata field, so a Content-Link header would not be needed.

This does not seem to help me with the case where a 404 response includes an HTML body with a <LINK> element, and a Link header. According to the explanation above, each has a very different context URI. The subject of the Link header is the requested resource, while the subject of the HTML <LINK> element is the "resource on the server that describes that error".

So in order to keep the three methods synced (Link: header, <LINK> element, /site-meta), we would still need to restrict the HTTP status codes... this time because of <LINK> elements.

EHL

Received on Saturday, 7 February 2009 06:48:59 UTC