m-mohr
commented
3 years ago The official RFC (see https://www.rfc-editor.org/rfc/rfc6596.html) for this relation type just says it's the "preferred" version of a link:
The canonical link relation specifies the preferred IRI from resources with duplicative content. Common implementations of the canonical link relation are to specify the preferred version of an IRI from duplicate pages created with the addition of IRI parameters (e.g., session IDs)"
In our case we have usually two cases:
- URL only accessible to authenticated users with a short-lived Bearer token (this is what they call session ID in the quote above, usual expiry time e.g. 15mins, this is not really permanent)
- URL publicly accessible to all users with a token in the signed URL (usual expiry time is some hours up to multiple years)
Thus, usually, the signed URLs live longer than the Bearer Tokens and that's why it is the preferred URL for (public) access. So looking at the full requests, I don't see a conflict here. Sure the endpoint is permanently available, but to get a useful result you need something short-lived.
https://github.com/Open-EO/openeo-api/blob/9d958225c7e33fbc5942808c951ce8b5a99b6643/openapi.yaml#L4289-L4297
In my head there is a bit of conflict related to the usage of "canonical" here. In general I associate "canonical" with the official/master/main version of or pointer to something. The description above also uses the word "permanent" which gives it great responsibility as well.
In openEO we use "canonical" links for things that are less durable: for example signed urls for job results. It's not uncommon for signed urls to be revoked/bumped, so it's a bit strange to call the "short term" signed url the canonical one, while it's possible to define a more durable URL for the same thing (e.g.
/jobs/{job_id}/results/{asset_id}, which would indeed require auth headers, but at least it is permanent).(related to #405 )