Smalyshev added a comment.
We probably can't fix it until we migrate to Jetty that supports ALPN. On the other side, it may be possible to fix it if the server would handle non-APLN clients properly but I am not sure how to configure and test it, unfortunately... I don't have too much knowledge
Multichill added a comment.
In T195203#4664834, @Smalyshev wrote:
Tried it again with Curl and it seems to work OK. I suspect this is the same ALPN issue as in T202785: Federation request to https://ld.stadt-zuerich.ch/query fails.
Is that something we need to fix on our side or something that
Smalyshev added a comment.
Some of the endpoints there are dead (I removed them from Wiki, but I keep it in the whitelist in case they'd go back to life). Others fail for unknown reasons, I'll investigate it. Some are listed as failed - e.g. https://data.epo.org/linked-data/query - but work fine
Multichill added a comment.
If this gets stuck on debugging on our side, I could probably ask around for contact details for the people running https://data.pdok.nl/sparql . On https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Federation_report several other endpoints are also failing.
Smalyshev added a comment.
When I send data from my local laptop, everything works fine. With curl from production host I get 404. I suspect there's something to do with proxies maybe.TASK DETAILhttps://phabricator.wikimedia.org/T195203EMAIL
Esc3300 added a comment.
Noticed that as well.
Maybe it has something to do with the list of prefixes that is being sent.TASK DETAILhttps://phabricator.wikimedia.org/T195203EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Esc3300,
Lucas_Werkmeister_WMDE added a comment.
The end of the stack trace, for future reference:
Caused by: com.bigdata.rdf.sail.webapp.client.HttpException: Status Code=500, Status Line=Internal Server Error, Response=
500 Internal Server Error
Internal Server Error
The server encountered an internal
