multi-value Accept header

[eroux]

the request

curl http://purl.bdrc.io/resource/P1583 -H "Accept: audio/mpeg, text/turle"

should return the turtle version, it currently returns a 406 error

[MarcAgate]

Fixed as of commit 8daa228 The returned mime corresponds to the first acceptable mime type found in Accept header string.

[eroux]

Thanks! I think there are a few more complex cases that could be handled (see examples in https://tools.ietf.org/html/rfc7231#section-5.3.2 ), but that's good enough for the demo!

[eroux]

a caveat with the current implementation is for instance

 curl -I http://purl.bdrc.io/resource/P1583 -H "Accept: text/*"

that should return something (turtle probably), but it doesn't matter now, we can see that later

[MarcAgate]

text/html and application/xhtml+xml are the only valid and not Jena content-type. Therefore, text/* and text/invalid are non acceptable for /resource/xxx endpoint and it makes sense to return a 406 response with: 1) full alternates and TCN:List headers 2) a html page with links to alternatives 3) A Content-type text/html 4) A Content-Location indicating the url of the html page described in 2)

Implemented as of commit 98de184

[MarcAgate]

An alternative to the previous implementation would be to allow text/* as a valid content-type, associated and equivalent to text/turtle

[eroux]

I think the only additional contents we could handle are text/* and application/* (we could map it to json-ld). Maybe we could also test more convoluted stuff... In fact, after a little bit of research, we should use the functions that are made exactly for that purpose, like javax.ws.rs.core.Request.selectVariant(), that would be the most solid solution. can you give it a try?

[MarcAgate]

Actually, javax.ws.rs.core.Request.selectVariant() cannot bring much to our context: selectVariant() - using our supported mime types- returns "text/trig" when accept is "text/" and "application/rdf+thrift" when Accept is "application/." We would need to override select variant to meet our requirement. I derived a very simple solution from the existing implementation that meets our needs perfectly.

[eroux]

I bet it just chooses the last it can in the list, can you try changing the list order?

[MarcAgate]

well, as far as I can tell it doesn't depend upon the list order, but it doesn't matter since the first implementation does the job. I dont see how to use selectVariant reliably without overriding it or creating our own (from the HttpHearders).

[eroux]

well, then if the order of the list doesn't matter (which would surprise me), ok to have text/trig for text/* and application/rdf+thrift for application/*

[MarcAgate]

This issue has been adressed using variants for both endpoints /resource and /graph GET and POST method