You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several things in section 6.1 ("Prefer header method for embedding data") where it is not clear that this is the best solution.
http://coverageapi.org/ns#canInclude is used to advertise supported URIs for the include parameter. However, is this scalable? Is it too simple? What URIs should those really be? It seems that http://coveragejson.org/def#Domain is a bad example and should be replaced by a format-independent concept URI, but there doesn't seem to be any.
There is the issue with cross domain requests and the section includes a longer text on that, but the details of it are not fully thought through:
Recommendation: Browser clients that access cross-domain coverage data should only send a Prefer header after they have confirmed that the server understands it. The client should assume that this is the case if a Link header with rel="http://coverageapi.org/ns#canInclude" is included or the Vary header includes Prefer. Furthermore, the client should assume that any related coverage data resource on the same domain has the same support. The reason for confirming support before-hand is that not all servers implement CORS "preflight" requests which would mean that in those cases the request would simply fail, but in fact would succeed if the Prefer header had not been included.
Is using Prefer a good idea anyway?
Should a server simply redirect to a non-Prefer URL (section 6.2) with additional parameters like ?include=domain? Otherwise there is the problem that there is no URL for that specific response. (Similar issue with conneg with/without redirect to file extension URL)
The text was updated successfully, but these errors were encountered:
There are several things in section 6.1 ("Prefer header method for embedding data") where it is not clear that this is the best solution.
http://coverageapi.org/ns#canInclude
is used to advertise supported URIs for the include parameter. However, is this scalable? Is it too simple? What URIs should those really be? It seems thathttp://coveragejson.org/def#Domain
is a bad example and should be replaced by a format-independent concept URI, but there doesn't seem to be any.Prefer
a good idea anyway??include=domain
? Otherwise there is the problem that there is no URL for that specific response. (Similar issue with conneg with/without redirect to file extension URL)The text was updated successfully, but these errors were encountered: