Multichill added a comment.
In T199146#4409514, @Smalyshev wrote:
Yeah looks like ipblocks table for wikidata has block on 2620:0:862:101:0:0:0:0/96 by user "Merlissimo" with comment 'Toolserver Range - no anon edits' but this doesn't seem to match wdq9. So probably not this one.
Toolserver?
gerritbot added a comment.
Change 444736 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Set requiresUnblock to false for CheckConstraintsRdf
https://gerrit.wikimedia.org/r/444736TASK DETAILhttps://phabricator.wikimedia.org/T199146EMAIL
gerritbot added a comment.
Change 444736 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[mediawiki/extensions/WikibaseQualityConstraints@master] Set requiresUnblock to false for CheckConstraintsRdf
https://gerrit.wikimedia.org/r/444736TASK
Smalyshev added a comment.
Looks like we don't need to change blocks - instead, 'constraintsrdf' should be marked as read action not requiring blocks check.TASK DETAILhttps://phabricator.wikimedia.org/T199146EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Smalyshev added a comment.
This block seems to be driven by $wgSoftBlockRanges setting in CommonSettings.php, which includes $wgSquidServersNoPurge, which includes private WMF IPs.
// Addresses used by WMF, people should log in to edit from them directly.
$wgSquidServersNoPurge
Now we need to
Gehel added a comment.
In T199146#4409514, @Smalyshev wrote:
Yeah looks like ipblocks table for wikidata has block on 2620:0:862:101:0:0:0:0/96 by user "Merlissimo" with comment 'Toolserver Range - no anon edits'.
That block goes from 2620::0862:0101:::: to
Smalyshev added a comment.
Yeah looks like ipblocks table for wikidata has block on 2620:0:862:101:0:0:0:0/96 by user "Merlissimo" with comment 'Toolserver Range - no anon edits'.TASK DETAILhttps://phabricator.wikimedia.org/T199146EMAIL
Smalyshev added a comment.
For the record, 204 NO CONTENT or 200 with RDF output is the right answer. For most items, it's 204 no content.TASK DETAILhttps://phabricator.wikimedia.org/T199146EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc:
Gehel added a comment.
In T199146#4409455, @BBlack wrote:
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
Smalyshev added a comment.
Yes, I verified, I get the same block with curl --noproxy \*. Just different IP in the error message.TASK DETAILhttps://phabricator.wikimedia.org/T199146EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Mahir256, Jonas,
Smalyshev added a comment.
Why is an internal service (wdqs) querying a public endpoint?
It needs to load Wikidata data, and I don't know any other way to do it.
It should probably use private internal endpoints like appservers.svc or api.svc, but there may be arguments about desirability of
BBlack 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
Jonas added a comment.
My IP is also blocked
F23514678: image.pngTASK DETAILhttps://phabricator.wikimedia.org/T199146EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: Jonas, Aklapper, BBlack, Gehel, Smalyshev, AndyTan, Davinaclare77, Qtn1293, Lahi,
Smalyshev added a comment.
Additionally, the blocking page returns 200 status code, which is also wrong as it pretends it to be correct result and not error page (which could be properly handled by the client then).TASK DETAILhttps://phabricator.wikimedia.org/T199146EMAIL
14 matches
Mail list logo
