Accept header with multiple options does not return the supported format

[white-gecko]

Apparently for request with multiple formats in the Accept header, qlever does not look for the first actually supported field, but returns an exception if a known but unsupported format is listed:

$ curl 'https://qlever.cs.uni-freiburg.de/api/dnb' -X POST -H "Accept: application/sparql-results+json, text/turtle, application/trix, application/n-quads, application/sparql-results+json, application/n-triples, application/rdf+xml, application/ld+json, text/n3" -H "Content-type: application/sparql-query" --data "construct { ?s ?p ?o } where { ?s ?p ?o } limit 10"
{
    "exception": "SPARQL-compliant JSON format is only supported for SELECT queries. In file \"/local/data/qlever/qlever-code/src/engine/ExportQueryExecutionTrees.cpp \" at line 726",
    "query": "construct { ?s ?p ?o } where { ?s ?p ?o } limit 10",
    "resultsize": 0,
    "runtimeInformation": {
        "cache_status": "computed",
        "children": [],
        "column_names": [],
        "description": "",
        "details": null,
        "estimated_column_multiplicities": [],
        "estimated_operation_cost": 0,
        "estimated_size": 0,
        "estimated_total_cost": 0,
        "operation_time": 0,
        "original_operation_time": 0,
        "original_total_time": 0,
        "result_cols": 0,
        "result_rows": 0,
        "status": "not started",
        "total_time": 0
    },
    "status": "ERROR",
    "time": {
        "computeResult": 0,
        "total": 0
    }
}

while

$ curl 'https://qlever.cs.uni-freiburg.de/api/dnb' -X POST -H "Accept: text/turtle, application/trix, application/n-quads, application/sparql-results+json, application/n-triples, application/rdf+xml, application/ld+json, text/n3" -H "Content-type: application/sparql-query" --data "construct { ?s ?p ?o } where { ?s ?p ?o } limit 10" 
_:bn39602389 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602390 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602391 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602392 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602394 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602395 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602396 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602397 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn40067157 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn40067158 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .

works.

[joka921]

Thanks for pointing this out. Our parsing of the GET and POS requests is still rather rudimentary (the bug you discovered is not the only one, and not even the only one we know of).
Thanks for reporting this, it is on our list, do you have a way of working around this issue in your application for now?