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

Returning profiles for QSA queries #679

Closed
kamhayfung opened this issue Jan 22, 2019 · 5 comments

Comments

3 participants
@kamhayfung
Copy link

commented Jan 22, 2019

In 7.1.3 (https://www.w3.org/TR/dx-prof-conneg/#listprofilestokenshttp), if the QSA approach is aimed at reducing the use of HTTP headers for humans, in what shape and form (e.g. media type) would a list of profiles be returned for a QSA based query instead of using HTTP headers? Should there be a convention?

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

(as discussed in the Profiles Negotiation sprint 2019-02-28)

The server will return a canonical list of profiles in the response's Link headers, however the server may also supply response content like this:

text/uri-list - fallback, unordered list of profile URIs
application/ld+json (any RDF format) - serialization of the Profiles Vocabulary
text/html - some human-readable version of the Profiles Vocabulary

@kamhayfung

This comment has been minimized.

Copy link
Author

commented Mar 4, 2019

@nicholascar , the content suggestions look fine. Will they be added in the spec?

BTW, for completness can a server return both the Link header(s) and the human-readable content in the same HTTP response?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

I think it can...

NB

"The data sections of messages Error, Forward and redirection responses may be used to contain human-readable diagnostic information." [https://www.w3.org/Protocols/HTTP/HTRESP]

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

@kamhayfung: The proposal above is now in the document but there's a problem that needs to be fixed. For a HEAD request there's no body and for a GET request, the body content will necessarily be the default profile representation of the resource, so there's no room for the proposal body content above.

We'll try to resolve this ASAP.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented May 2, 2019

This Issue has been side-stepped with the removal of the possibility for a QSA (or HTTP header) for HEAD or List Profiles to return an available profiles URI list in the body. HEAD has no body and GET will return the representation of the resource in the body

@nicholascar nicholascar closed this May 9, 2019

Content Negotiation by Profile automation moved this from To do to Done May 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.