Steps to replicate the issue (include links if applicable):
- webservice shell
- curl -v -o flickr.jpg "https://live.staticflickr.com/65535/54265555549_3e41dca85a_o_d.jpg"
What happens?:
<html><body><h1>403 Forbidden</h1> Request forbidden by administrative rules. </body></html>
originally, now
<html><body><h1>429 Too Many Requests</h1> You have sent too many requests in a given amount of time. </body></html>
tools.anticompositetest@shell-1737548902:~$ curl -v -o flickr.jpg "https://live.staticflickr.com/65535/54265555549_3e41dca85a_o_d.jpg"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 3.171.59.65:443...
* Connected to live.staticflickr.com (3.171.59.65) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3851 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=static.flickr.com
* start date: Oct 12 00:00:00 2024 GMT
* expire date: Nov 9 23:59:59 2025 GMT
* subjectAltName: host "live.staticflickr.com" matched cert's "*.staticflickr.com"
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x557247e2d200)
} [5 bytes data]
> GET /65535/54265555549_3e41dca85a_o_d.jpg HTTP/2
> Host: live.staticflickr.com
> user-agent: curl/7.74.0
> accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [157 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
} [5 bytes data]
< HTTP/2 429
< content-type: text/html
< content-length: 117
< date: Wed, 22 Jan 2025 12:29:10 GMT
< cache-control: no-cache
< x-cache: Error from cloudfront
< via: 1.1 308930dd559485ab2bf680b9ef6cf01c.cloudfront.net (CloudFront)
< x-amz-cf-pop: IAD61-P8
< x-amz-cf-id: Rm5gpz5_InSWGvf2CHJSXxKD8mWNgZuhYVIkkPBKKEiAam7Sf79qsA==
<
{ [117 bytes data]
100 117 100 117 0 0 3342 0 --:--:-- --:--:-- --:--:-- 3342
* Connection #0 to host live.staticflickr.com left intactWhat should have happened instead?:
200 OK
Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
Other information (browser name/version, screenshots, etc.):
This is affecting flickr2commons (though it appears to be intermittent, with some files occasionally getting through), @Don-vip's https://commons.wikimedia.org/wiki/User:OptimusPrimeBot, and https://commons.wikimedia.org/wiki/User:FlickreviewR_2 . Other unidentified tools are also likely affected. Previous discussion has been on https://commons.wikimedia.org/wiki/User_talk:Zhuyifei1999#FlickreviewR_2_getting_403'd_by_Flickr where @Sannita was going to contact the person who was keeping in contact with the Flickypedia (Flickr Foundation) folks.
It seems like the primary contact method for Flickr.com is through https://www.flickrhelp.com/hc/en-us/requests/new. The Flickr Foundation, which does not run the site but might be able to advocate on our behalf, is at hello@flickr.org. I have not attempted either and feel that outreach from WMCS staff would be more useful since it's affecting multiple tools on the shared hosting.