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

GET requests on receivers with no Accept header #31

Closed
acoburn opened this issue Sep 7, 2016 · 2 comments
Closed

GET requests on receivers with no Accept header #31

acoburn opened this issue Sep 7, 2016 · 2 comments

Comments

@acoburn
Copy link
Member

acoburn commented Sep 7, 2016

In the context of receivers making an inbox accessible to consumers, the draft LDN specification states in section 3.4.2 that:

If the GET request has no Accept header, the results must be returned as JSON-LD; otherwise the receiver should return the results in the serialization requested, or a 415 Unsupported Media Type error if the requested serialization is not available.

I was planning to use an LDP server implementation as an LDN receiver, but the LDP specification (i.e. section 4.3.2.2) states that:

LDP servers should respond with a text/turtle representation of the requested LDP-RS whenever the Accept request header is absent

So in the case where the GET request has no Accept header, these two specs are pointing to different serializations. Would it be possible to get some clarification about that difference?

@csarven
Copy link
Member

csarven commented Sep 7, 2016

@acoburn Good catch! Thank you for raising this.

I think LDN should stick close to expected LDP behaviour.

How about the following: 95eb604 .

Consumers SHOULD use an Accept header. If the Accept header is not specified, the behaviour is default RFC 7231 Accept:

A request without any Accept header field implies that the user agent will accept any media type in response.

and receivers SHOULD return JSON-LD or Turtle in absence of the Accept header.

This should keep existing LDP implementations (receivers) happy.

What do you think?

@acoburn
Copy link
Member Author

acoburn commented Sep 7, 2016

@csarven your change looks great. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants