Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt

[Mark Nottingham <[e-mail]>]

OLD:
  The anchor parameter MUST be ignored by consuming implementations, unless its use is specified by the application in use.

NEW:
  Links with the anchor parameter MUST be ignored by consuming implementations, unless its use is specified by the application and/or relation type in use.

works?



On 05/02/2010, at 11:38 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> On 29/01/2010, at 11:45 PM, Julian Reschke wrote:
>>> Mark Nottingham wrote:
>>>> ...
>>>> If that's the case, you're saying that whether the anchor is allowed is really a property of the relation type, not the application, aren't you? ...
>>> First of all, I'd prefer to distinguish between (A) "must be processed" and (B) "may be processed, otherwise link must be rejected altogether".
>>> 
>>> I see two purposes for the anchor parameter:
>>> 
>>> 1) Making a statement about a subset of the context resource, by specifying a fragment identifier
>>> 
>>> 2) Making a statement about a different resource than the context resource, such as
>>> 
>>> 2a) because the context is anonymous (such as the response body for a 204, see <http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-07.html#rfc.section.A.1>), or
>>> 
>>> 2b) because a reverse link is exposed (anchor as workaround for missing rev parameter)
>>> 
>>> I'm still not sure why we would ever make special cases here, except for the known bugs in current implementations of the Link header where anchor is ignored (so mainly Mozilla/Opera for stylesheet links). Optimally, we just work with the vendors to get the bugs fixed.
>>> 
>>> If that's not possible, allowing an opt-out per relation type might work, as long as behavior (B) would still be allowed. Is there any relation != "stylesheet" for which this would be relevant?
>> I think most of them.
>> E.g., what happens when my weblog
>>  http://www.mnot.net/blog/
>> contains a link header
>>  Link: </blog-publish>; rel="service"; anchor="http://www.intertwingly.net/blog/"
>> ?
>> After Sam visits my blog, should his browser (assuming it supports Atompub) use my site for editing next time he wants to post something?
> 
> That's an excellent example. I do agree that - in general - we don't want <http://www.mnot.net/blog/> to be able to affect <http://www.intertwingly.net/blog/>.
> 
> So the choices here are:
> 
> a) Processing anchor, detecting the authority conflict, and ignoring the link, or
> 
> b) ignoring anchor, and pretending we have <http://www.mnot.net/blog/> --service--> <http://www.mnot.net/blog/blog-publish>
> 
> What I'm trying to say is that we never ever want b).
> 
> So I'm fine with clients ignoring the link header altogether because it contains anchor, but simply ignoring the anchor parameter, but processing the rest seems to be a very bad idea.
> 
>> Likewise, what happens after I put this link header in all of my responses?
>>  Link: <http://www.yahoo.com/>; rel="self"; anchor="http://www.google.com/"
>> ?
>> Or better yet:
>>  Link: <http://www.mybank.com.au/mnot>; rel="payment"; anchor="http://www.amazon.com/"
>> While it may be that browsers in general won't "remember" this information, that doesn't mean that we should specify things so that they're encouraged to handle these things, knowing full well that they won't. Opt-in seems much more sane that opt-out here, at least for different resources.
> 
> Well, maybe we've been agreeing all the time, and just the spec text needs tuning.
> 
> So again: a recipient MUST resolve the anchor parameter against the context IRI (*), producing a new context. It MAY ignore the link if the resulting context looks suspicious (maybe something like same-domain could be recommended here).
> 
> Best regards, Julian
> 
> (*) + handle the case where there's no context IRI


--
Mark Nottingham     http://www.mnot.net/