Gehel added a comment.

This raises some questions that are probably unrelated to the problem at hand, but might affect things indirectly:

  • Why is an internal service (wdqs) querying a public endpoint? It should probably use private internal endpoints like appservers.svc or api.svc, but there may be arguments about desirability of [Varnish] caching. This is something we're grappling with in general in the longer-term (trying to understand and/or eliminate private internal service<->service traffic routing through the public edge unnecessarily).

That specific request seems to be trying to bust cache nocache=1531160117052 so bypassing varnish caching is probably not an issue. In the more general context, there are probably instances where caching makes a lot of sense.

  • Why is it using webproxy to access it? It should be able to reach www.wikidata.org without any kind of proxy.

That's probably an historical mistake, no reason that I can think of.

Note that the same request directly from wdqs1009.eqiad.wmnet (curl -v 'https://www.wikidata.org/wiki/Q18289639?action="">) also gives an HTTP 200 Blocked. Same from elastic2035 (just for fun). But same request from my own desktop gives an HTTP 204 NO CONTENT.


TASK DETAIL

EMAIL PREFERENCES

To: Gehel
Cc: Mahir256, Jonas, Aklapper, BBlack, Gehel, Smalyshev, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, EBjune, merbst, LawExplorer, Zppix, Xmlizer, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, faidon, Mbch331, Jay8g, fgiunchedi
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to