Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.
Sign upmandatory absolute URI for anchor #117
Comments
hvdsomp
added
the
linkset
label
Jan 30, 2019
This comment has been minimized.
This comment has been minimized.
|
it seems this one currently has been resolved to require that anchors MUST be absolute. that makes sense as explained by @hvdsomp, but introduces a processing model that should be made very explicit in the spec: for serializing into the media types, all links must be parsed, and all anchors must be resolved to absolute URIs. |
This comment has been minimized.
This comment has been minimized.
|
On 2019-01-30 14:06, Herbert Van de Sompel wrote:
I see two possible approaches:
1. Require that each link in a linkset has an anchor with a complete
(non-relative) URI
2. In serializations, require an information element similar to BASE in
HTML to express a BaseURI for link anchors
Note that (2) could be achieved in JSON, especially when following
proposal #103 <#103> by @BigBlueHat
<https://github.com/BigBlueHat>, which is the plan. But, it could not be
achieved for the application/linkset serialization since it is a direct
mapping of the Link header syntax.
i think there is a third possibility to say that links with non-absolute
anchors MUST be ignored if there is no well-defined context for the
linkset. we could remain agnostic as to how this context is established.
this would have the advantage of not creating different data models for
native and JSON, and to still allow full round-trip fidelity from link
headers to linksets and back.
|
BigBlueHat
referenced this issue
Mar 13, 2019
Open
Value of `application/linkset` vs. existing `message/http` #120
This comment has been minimized.
This comment has been minimized.
|
I was working on trying to get this "ignore relative URIs" into a new version of the I-D, and I am afraid it just does not make sense to me. I explained the reasons already in the above, but I'll repeat:
As such, the confusion introduced by allowing relative URIs as such is rather significant and definitely error prone. But additionally, by allowing relative URIs, we are basically requiring the client to do the following:
Based on the above, I am not sure what the "allow relative URIs and ignore them" adds as value. Agreed that relative URIs are meaningful when they are part of an HTTP interaction when there is no doubt about what their baseURL is. But link sets will be used outside of HTTP interactions and not providing absolute URIs leads to confusion and more work for the client. |
hvdsomp commentedJan 30, 2019
•
edited
For a link in the HTTP Link header, the following holds:
Applying the above to a linkset yields:
The current linkset I-D has explicit cautionary language with this regard, anticipating that the above behavior is most likely not what implementers would want to achieve.
In addition, contrary to a typical use of links in an HTTP header (follow your nose during an HTTP navigation session), links in a link set may be used in a standalone manner, meaning disconnected from the link set resource that - as per the above - is supposed to provide URI/baseURI for anchors. In such standalone uses, the information about the link set resources that provided the linkset may no longer be available. As such, it would be good if linksets would be self-contained, i.e. be explicit with regard to what the anchor of each link is.
The above tries to make the point that it would be beneficial to simultaneously:
I see two possible approaches:
Note that (2) could be achieved in JSON, especially when following proposal #103 by @BigBlueHat, which is the plan. But, it could not be achieved for the application/linkset serialization since it is a direct mapping of the Link header syntax.