In T349671#9283152, @Fabfur wrote:

Targeting cp4039 instance for upload.wikimedia.org seems to work fine when uploading/viewing contents.
I'll keep investigating on this...

This would seem to make sense based on https://wikitech.wikimedia.org/wiki/Varnish#Force_your_requests_through_a_specific_Varnish_frontend which says that the hash of my IP is the caching key

On further investigation, I think the cache has gone bad or something, because when I switch to wifi (same ISP, but different IPv6 addresses), it seems to work properly.

Then that would be evidence that my request never reached the Swift frontend.

I am blocked by this. I have not been able to upload for quite a few hours.

Same problem at https://commons.wikimedia.org/wiki/File:Tammy_2023_path.png (new image)

In T342574#9039360, @Umherirrender wrote:

Showing a form does not indicate if the account creation is blocked or stopped as all checks are done after the submit.

For a local ip block the form is also shown and fails after submit, so this task could be rewritten to be more generic.

I agree with Addshore: the abuse filter's performance should not be hindered by this kind of "namespace" protection. $wgNamespaceProtection is what's needed here.

Actually, it's different from that.

I oppose this, due to RhinosF1's recent sockpuppetry both on-wiki and on IRC. He is currently globally banned from all Wikimedia IRC channels.

The problem seems to have indeed gone away overnight. But see #wikimedia-tech logs from around 8-9 UTC.

If possible, I request that this feature request be withdrawn ("WONTFIX"'d) as a significant number of ISPs break this convention, especially for VPS and dedicated server providers.