Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback for "Prefer" method for embedding needed #3

Open
letmaik opened this issue Jan 31, 2016 · 0 comments
Open

Feedback for "Prefer" method for embedding needed #3

letmaik opened this issue Jan 31, 2016 · 0 comments

Comments

@letmaik
Copy link
Contributor

letmaik commented Jan 31, 2016

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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant