chasemp added a comment. In https://phabricator.wikimedia.org/T112151#1743222, @Smalyshev wrote:
> > I am looking for a use case we are trying to solve. > > > The use case is users using SPARQL query tool that only does POST. > Unfortunately, such tools exist, and in non-nelgligible numbers > > > At first glance, it seems like this means mangling all POST to GET would > > result in an incompatibility with the sparql protocol. > > > @chasemp I think you're missing an important point here - lack of SPARQL > Update support on query endpoint is **intentional**. That's the whole point > of the exercise - how we allow to send POST without allowing SPARQL Update. > We do not want to be compatible with SPARQL Update in query endpoint - in > fact, we want to explicitly forbid it, since we don't want the whole internet > to mess with our database (there's wikidata.org site for that ;) That's why > we do not want to allow anybody from outside to POST to Blazegraph. However, > we do want to allow tools that use POST to do SPARQL Query to do so. > Unfortunately, distinguishing SPARQL Query from SPARQL Update and other > update requests may be non-trivial to do from something like nginx, so it is > much safer and easier to just never send POST to Blazegraph, thus ensuring we > never produce an update. > > We could, of course, take a stance that since REST dictates retrieval queries > should go through GET, we only support GET. However, this stance sounds to me > unpractical and not user-friendly, as most users do not care about the purity > of our REST track record (in fact, most of them have only the vaguest idea of > REST and their requirements about POST/GET) and just want their SPARQL tool > (which they probably use with a dozen of other SPARQL endpoints by now) to > work with WDQS endpoint. Hey @Smalyshev sorry you were ready to roll on this and it got locked up in debate. I appreciate what you are saying here I really do. In large part it comes down to the idea of what is practical as you said. We have opposite ideas in this case. From my POV here we are trying to hide the complexity for poorly written clients on our end and we have few resources to do such things over the long term. We do make many decisions about how far down this gradient to travel in the pursuit of sane user expectations, SNI <https://en.wikipedia.org/wiki/Server_Name_Indication#Web_browsers.5B6.5D> is a good example where we are using it though we know a not insignificant amount of users are suck in XP land. I'm not saying this is a 1:1 example. I do think we are missing each other on the 'use case' bit here. I believe I understand this: > The use case is users using SPARQL query tool that only does POST. > Unfortunately, such tools exist, and in non-nelgligible numbers From this angle is every poorly written tool a use case? We don't seem we have a backlog of users who are held up trying to use POST to make queries and without specific examples to push this narrative along I am viewing this as premature complexity. We know poorly written tools exist for everything. We generally don't try to head them off at the pass. I did look through a bunch of sparql tools to get an idea and there was at least one <https://github.com/thomasfr/node-sparql-client/blob/master/lib/client.js#L10> default POSTer that I found, but it can be changed. The majority of tools I see do the sane thing: https://github.com/BorderCloud/SPARQL/blob/master/Curl.php#L244 https://github.com/RDFLib/sparqlwrapper/blob/master/SPARQLWrapper/Wrapper.py#L503 Not that this is a slam dunk argument either way. Maybe we revisit in the near future but at the moment I can't see my way to this making sense to support. If you feel strongly about this bring it up in Scrum of Scrums to get more visibility? TASK DETAIL https://phabricator.wikimedia.org/T112151 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, chasemp Cc: chasemp, JanZerebecki, BBlack, Andrew, Deskana, Joe, gerritbot, nichtich, Jneubert, Karima, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, Mbch331 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
