Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
Jena 2.10.1, Fuseki 0.2.7
-
None
Description
If I'm not mistaken, when / content type is used in Accept header, content negotiation is incorrect. For curl -X GET http://sparql.org/books/sparql?query=SELECT+*+WHERE+%7B+%3Fs+%3Fp+%3Fo+%7D+LIMIT+1 compare:
application/sparql-results+json => application/sparql-results+json application/sparql-results+json;q=0.1 => application/sparql-results+json */* => application/sparql-results+json */*;q=0.1 => application/sparql-results+json application/sparql-results+json;q=0.1, */*;q=0.9 => application/sparql-results+json application/sparql-results+json;q=0.9, */*;q=0.1 => text/csv application/sparql-results+json;q=0.9, */*;q=0.9 => text/csv
It appears to be that, if the q-value of these two content-types are compared, the output content-type is incorrect.
Here is an awkward one:
application/sparql-results+xml;q=0.1, */*;q=0.9 => application/sparql-results+json application/sparql-results+xml;q=0.9, */*;q=0.1 => application/sparql-results+json application/sparql-results+xml;q=0.9, */*;q=0.9 => application/sparql-results+json
What's going on now?
Just for completeness:
application/sparql-results+xml;q=0.1, application/sparql-results+json;q=0.9 => application/sparql-results+json application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.1 => application/sparql-results+xml application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.9 => application/sparql-results+json
That looks okay.