Internal Server Error about grlc HOT 7 CLOSED

OK, found it! :)

sparql.rq seems to be dead code, or at least not the commonly executed part.

This solved it: b09824a

It works on my own Virtoso and RDF4J SPARQL endpoints. But for some reason, it doesn't work on the default https://dbpedia.org/sparql .

That's why I didn't make a pull request yet. And maybe this should rather be triggered by an argument like endpoint-method to it can manually be set to GET and POST.

from grlc.

ps: I forgot to add that both queries work fine when directly submitted to the SPARQL endpoint.

from grlc.

Investigating a bit further, this problem could be related to URL length exceeding its limit.

This query reproduces the problem: https://github.com/knowledgepixels/grlc-test/blob/main/minimal-comments-2.rq

The query itself is minimal, but the whole query file is larger due to long comments.

Trying it on grlc.io with the standard endpoint (http://dbpedia.org/sparql), I get a 414 Request-URI Too Large error: https://grlc.knowledgepixels.com/api-git/knowledgepixels/grlc-test/#/default/post_minimal_comments_2

If I run it against my own endpoint (https://query.np.trustyuri.net/repo/meta), which I have configured to allow for long URLs, I get the error from above: 500 Internal Server Error (but the query works when issued directly to the SPARQL endpoint).

I have set method to POST, but I suppose that's only how the client is accessing the grlc server, not how grlc is accessing the SPARQL endpoint, right? If so, is there a way to configure the SPARQL endpoint requests to be POST too? I suppose that might be the problem.

from grlc.

After a bit more investigation, I am suspecting that adding

client.setMethod(SPARQLWrapper.Wrapper.POST)

around line 42 in sparql.py should solve the problem.

But I haven't figured out yet how to build it and test it on my own. When I build it through Docker it doesn't seem to pick up the updated code...

from grlc.

Hi @tkuhn -- thanks! That looks like it was a hard issue to track down, so thanks for your hard work! I am not sure if it is standard for endpoints to receive requests via GET or POST or are both possible? In which case, maybe we should do as you say and make it optional with a parameter (with the default being POST perhaps?)

from grlc.

If I understand the SPARQL protocol (https://www.w3.org/TR/sparql11-protocol/) correctly, then endpoints need to provide both, GET and POST support.

POST as default sounds reasonable to me, except possibly for backwards compatibility, if not all endpoints implement the protocol fully (as with DBpedia, it seems)?

from grlc.

This is fixed in release v1.3.9

from grlc.