This solves my problem with regard to the Link header.
On Feb 06, 2009 4:41 PM, "Roy T. Fielding" <field...@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
