Steps to Reproduce:
- Visit https://query.wikidata.org/bigdata/ldf, observe broken page render. Observe 404 errors for JS and CSS resources.
Actual Results:
Refer screenshot
Expected Results:
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Fix WDQS LDF URI routing | operations/puppet | production | +1 -1 |
Related Objects
Related Objects
Event Timeline
Comment Actions
Cannot reproduce on https://query.wikidata.org/bigdata/ldf . All four items (page; style.css; logo.svg; favicon.ico) load correctly.
Comment Actions
@Aklapper Thanks for the more precise issue title. Attached is a screenshot of 404 errors for minimised js etc. https://query.wikidata.org/bigdata/ldf Behaviour is the same across Firefox, Safari, Chrome. Requests are being responded to by cache (server: envoy)
Comment Actions
I think @Ratso56’s original title was more accurate. The core issue isn’t that some JS/CSS is failing to load – as far as I can tell, the server is sending the completely wrong HTML to begin with. It’s sending the same HTML as for https://query.wikidata.org (main Wikidata Query Service UI), whereas this is supposed to be a different service.
$ curl -s https://query.wikidata.org/bigdata/ldf | sha256sum 343fb7b2a2ef08da29f21dbde5621efdb2ba834371573571715f5da94271e83d - $ curl -s https://query.wikidata.org/ | sha256sum 343fb7b2a2ef08da29f21dbde5621efdb2ba834371573571715f5da94271e83d -
It’s also sending this same HTML regardless of Accept headers:
$ curl -s -H 'Accept: text/turtle' 'https://query.wikidata.org/bigdata/ldf?subject=http%3A%2F%2Fwww.wikidata.org%2Fentity%2FQ146' | tee >(file -) >(sha256sum) > /dev/null 343fb7b2a2ef08da29f21dbde5621efdb2ba834371573571715f5da94271e83d - /dev/stdin: HTML document, ASCII text, with very long lines, with no line terminators
Is the LDF server just gone? What happened here?
Comment Actions
Per T232006, the LDF service was still up (though sometimes sending the wrong cached responses) in early September at least.
Comment Actions
After some experimentation, I found that this query fails while this query works. The only difference is the order of the URL parameters (in the first, the empty subject is at the beginning, while in the second, it's at the end). No idea what would cause that to matter, though.
Comment Actions
For me they look exactly the same – I suspect the first URL is still in your browser cache.
Comment Actions
from inside any of the WDQS machines ( 'wdqs1004.eqiad.wmnet','wdqs1005.eqiad.wmnet', 'wdqs1006.eqiad.wmnet','wdqs1007.eqiad.wmnet')
the following curls return the correct data
curl localhost:80/bigdata/ldf -> direct to nginx server on host
curl localhost:9999/bigdata/ldf -> direct to query service on host
but curl https://query.wikidata.org/bigdata/ldf is not working indicating some problem with routing traffic.
This could be the recent switch from varnish to apache.
Comment Actions
for clarification the correct response will contain a list that looks like this
@prefix schema: <http://schema.org/> . @prefix pq: <http://www.wikidata.org/prop/qualifier/> . @prefix pr: <http://www.wikidata.org/prop/reference/> . @prefix ps: <http://www.wikidata.org/prop/statement/> .
and the incorrect response is HTML that looks similar to
<!DOCTYPE html><html lang="en" dir="ltr"><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width,initial-scale=1,user-scalable=yes"><link rel="stylesheet" href="css/style.min.6c0e4865f687302c4d99.css"><link id="favicon" rel="shortcut icon"><script src="js/shim.min.6d0a3b4d4b50e4f73d3e.js"></script><style id="MJX-CHTML-styles">/* placeholder for MathJax */</style></head><body><div class="wikibase-queryservice container-fluid">
Comment Actions
Change 563281 had a related patch set uploaded (by BBlack; owner: BBlack):
[operations/puppet@production] Fix WDQS LDF URI routing
Comment Actions
Change 563281 merged by BBlack:
[operations/puppet@production] Fix WDQS LDF URI routing