Smalyshev added a comment.
POST can be used with any queries, same as GET, though I'm not sure how it would be cached, so I'd recommend using POST only for big queries now, unless you don't have a choice (e.g. the tool only supports POST). I'll update about caching once I know it.TASK
gerritbot added a comment.
Change 243883 merged by Gehel:
Allow SPARQL endpoint to be queried via POST
https://gerrit.wikimedia.org/r/243883TASK DETAILhttps://phabricator.wikimedia.org/T112151EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev,
Smalyshev added a comment.
Java/Blazegraph seems to have URL length limit around 8K. So we may have to support real POST on Blazegraph side anyway.TASK DETAILhttps://phabricator.wikimedia.org/T112151EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc:
Jneubert added a comment.
Examples for the federated query use case see at https://github.com/zbw/sparql-queries/tree/master/wikidata#power-queries (queries with econ_pers or ebds in name). The intermediate set fed into Wikidata was about 450,000 GND IDs. Currently, that requieres setting up a
JanZerebecki added a comment.
Yes. But: 1) This ticket is only about compatibility with existing clients we
didn't create and don't control. Those clients are conforming implementations
of SPARQL 1.1 2) Option 2 and 3 in
https://phabricator.wikimedia.org/T112151#1818392 are not defined in the
Smalyshev added a comment.
> Primarily it's that we can't cache them in Varnish like we should be able to
Caching SPARQL results via Varnish is not a good idea in most cases. For two
reasons:
1. Usually the same query is not repeated very often (unless somebody has a
buggy script, etc.).
BBlack added a comment.
In https://phabricator.wikimedia.org/T112151#1739918, @Smalyshev wrote:
> > As Andrew said above, why not support this directly in WQDS if you have to
> > support it at all?
>
>
> Because in Blazegraph, allowing POST means allowing write requests. This is
> not good for
JanZerebecki added a comment.
In https://phabricator.wikimedia.org/T112151#1742574, @chasemp wrote:
> At first glance, it seems like this means mangling all POST to GET would
> result in an incompatibility with the sparql protocol.
I didn't suggest that. I suggested to apply GET semantics to
JanZerebecki added a comment.
The first sentence in the task is the use case I looked at while coming up with
my suggestion. To explain why these tools would use POST I came up with the
Request-URI length. But another workable explanation is that the tool just
doesn't bother to differentiate
chasemp added a subscriber: chasemp.
chasemp added a comment.
Yesterday in IRC it seemed like there was consensus we don't have any actual
(quantifiable) concerns regarding query length at the moment.
SMalyshev: chasemp: I'm not worried too much about query length
The 2008
chasemp added a comment.
In https://phabricator.wikimedia.org/T112151#1742627, @JanZerebecki wrote:
> In https://phabricator.wikimedia.org/T112151#1742574, @chasemp wrote:
>
> > At first glance, it seems like this means mangling all POST to GET would
> > result in an incompatibility with the
Smalyshev added a comment.
> 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
>
JanZerebecki added a comment.
Short: Because IE is broken.
Long: The problem here is that while
https://tools.ietf.org/html/rfc2616#section-3.2.1 says "The HTTP protocol does
not place any a priori limit on the length of a URI." this reality doesn't
conform. On the server side our caching
Andrew added a subscriber: Andrew.
Andrew added a comment.
WDQS is in internal tool, so if its API doesn't conform to clients'
expectations then this is a bug in WDQS, yes? Would it not be better to fix
that rather than adding mysterious middleware obfuscation?
TASK DETAIL
BBlack added a subscriber: BBlack.
BBlack added a comment.
I'm not a fan of this on a few levels:
1. As Andrew said above, why not support this directly in WQDS if you have to
support it at all? as in, let the POSTs come through the rest of the stack
unmolested, and deal with it inside WQDS,
Smalyshev added a comment.
> As Andrew said above, why not support this directly in WQDS if you have to
> support it at all?
Because in Blazegraph, allowing POST means allowing write requests. This is not
good for security.
> let the POSTs come through the rest of the stack unmolested, and
Smalyshev added a comment.
I've tested it in labs and it seems OK, would like somebody from ops to review
if it's OK for production.
TASK DETAIL
https://phabricator.wikimedia.org/T112151
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev
Karima added a comment.
You can test your endpoint with this tool (View->Show endpoint bar and write
the url of your endpoint).
http://openuplabs.tso.co.uk/demos/sparqleditor
Try to respect the standard. (there is again a problem with the content
negociation)
gerritbot added a subscriber: gerritbot.
gerritbot added a comment.
Change 243883 had a related patch set uploaded (by Smalyshev):
Allow SPARQL endpoint to be queries via POST
https://gerrit.wikimedia.org/r/243883
TASK DETAIL
https://phabricator.wikimedia.org/T112151
EMAIL PREFERENCES
Jneubert added a subscriber: Jneubert.
Jneubert added a comment.
Another argument for enabling POST requests is, that GET requests / URLs are
limited in length. The exact limit depends (see
http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers),
20 matches
Mail list logo
