You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #304 some of our users have begun to use the .csv extension on the request URLs to directly access the results in CSV format.
We are using Amazon Neptune and today observe that these requests suddenly start returning JSON results after upgrading the cluster to the new version 1.0.4.2 engine. On closer inspection it transpires that grlc makes those requests with header Accept: text/csv; q=1.0, */*; q=0.1 and the new Neptune version gives a JSON response for those.
To help avoid such nasty surprises, it would appear wise to be more specific in the accept headers that are sent in sparql protocol requests. My suggestion is to modify mimetypes as follows to be much more specific in the media types and extend support for additional (standard) formats:
Format
Accept
csv
text/csv; charset=utf-8
tsv
text/tab-separated-values; charset=utf-8
json
application/sparql-results+json
srj
application/sparql-results+json
xml
application/sparql-results+xml; charset=utf-8
srx
application/sparql-results+xml; charset=utf-8
ttl
text/turtle
nt
application/n-triples
rdf
application/rdf+xml; charset=utf-8
jsonld
application/ld+json
html
text/html
Note the use of charset parameter on those media types where the character set is not implied by the media type.
The text was updated successfully, but these errors were encountered:
Related to #304 some of our users have begun to use the
.csv
extension on the request URLs to directly access the results in CSV format.We are using Amazon Neptune and today observe that these requests suddenly start returning JSON results after upgrading the cluster to the new version 1.0.4.2 engine. On closer inspection it transpires that grlc makes those requests with header
Accept: text/csv; q=1.0, */*; q=0.1
and the new Neptune version gives a JSON response for those.To help avoid such nasty surprises, it would appear wise to be more specific in the accept headers that are sent in sparql protocol requests. My suggestion is to modify
mimetypes
as follows to be much more specific in the media types and extend support for additional (standard) formats:text/csv; charset=utf-8
text/tab-separated-values; charset=utf-8
application/sparql-results+json
application/sparql-results+json
application/sparql-results+xml; charset=utf-8
application/sparql-results+xml; charset=utf-8
text/turtle
application/n-triples
application/rdf+xml; charset=utf-8
application/ld+json
text/html
Note the use of charset parameter on those media types where the character set is not implied by the media type.
The text was updated successfully, but these errors were encountered: