Problem
There's the new image hosting system and Super User (my main "playground") is trialling it.
My problem is I cannot see images hosted on i.sstatic.net. This is how it looks like:
This particular screenshot is from the following question: USB-C Splitter for external SSD enclosure. The link to the image is https://i.sstatic.net/KnVuyq7G.jpg and when I click it I see:
wget 'https://i.sstatic.net/KnVuyq7G.jpg' gives me:
--2024-04-10 10:12:58-- https://i.sstatic.net/KnVuyq7G.jpg
Resolving i.sstatic.net (i.sstatic.net)... 104.18.41.33, 172.64.146.223
Connecting to i.sstatic.net (i.sstatic.net)|104.18.41.33|:443... connected.
HTTP request sent, awaiting response... 400 Bad Request
2024-04-10 10:12:59 ERROR 400: Bad Request.
curl -o result 'https://i.sstatic.net/KnVuyq7G.jpg' gives me the following content in the result file:
<!DOCTYPE html> <html> <head> <link rel='stylesheet' href='https://fonts.googleapis.com/css?family=Arimo'> <style> body { font-family: 'Arimo', sans-serif; text-align: center; font-size: .9em; background-color: white; color: gray } .container { display: flex; flex-direction: column; align-items: center; justify-content: center; height: 100vh; } img { max-width: 100%; height: auto; } </style>
</head> <body> <div class='container'> <img src='https://i.sstatic.net/wiC8UD6Y.png'> <p>oh no, that request didn't look right<br>RayID: 872149dd09dabfc6</br></p> </div> </body> </html>
The above describes how the situation looks at my home, let's call it Location A. I have SSH access to a remote computer, Location B (details below). There I can also do wget 'https://i.sstatic.net/KnVuyq7G.jpg' and the result is:
Downloading 'https://i.sstatic.net/KnVuyq7G.jpg'
Connecting to 172.64.146.223:443
Writing to 'KnVuyq7G.jpg'
KnVuyq7G.jpg 100% |*******************************| 202k 0:00:00 ETA
Download completed (207108 bytes)
Then file KnVuyq7G.jpg reports:
KnVuyq7G.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 1200x1600, components 3
so from B the link works fine.
Now the crazy part: once the link is accessed from B, it starts working when accessed from A! Now I can refresh the linked question in my browser and the image is there. I can wget on A, there is no longer 400 Bad Request; and I can curl on A, there is no longer oh no, that request didn't look right. Each method shows or downloads the proper .jpg file.
So the action on B fixed the problem with this particular image on A. This makes me believe the problem is not on my computer(s) in the Location A. I suspect there is something wrong with the content delivery network or so.
Can you fix this globally, so I can simply (without tricks) see images posted on Stack Exchange? Or is the problem nevertheless on my side? Or the ISP's? I'm posting few RayIDs down below, hopefully they will help.
I'm also curious about the mechanism that allows actions of B affect abilities of A to access resources. If it's really a problem with the content delivery network and some developer briefly explains what happened then this will be a nice bonus.
Details
Location A is not a single computer. I have tested from few computers. Location A consists of:
my home with
- a home router with Debian 12 implementing NAT
- a laptop with Kubuntu 23.10 with Vivaldi browser behind the NAT
my workplace where I also tested on
- a virtual machine with Debian 12 behind (another) NAT
My home and my workplace share an ISP. Each uses a separate IPv4 address in the
213.5.145.0/24range. The addresses are globally routable.Location B is a home router I can access via SSH, it runs some version of OpenWRT. It's in a different town than A, it uses a different ISP than A. It's behind CGNAT and the public IP address is
185.138.239.xxx.Location A and Location B are in Poland.
To be clear: fixing links for A involves no tunneling nor proxying via B. The sole act of accessing a link from B magically fixes it for A.
There is virtually no delay: a link does not work on A, I run
wgeton B, in few seconds I refresh it on A and it suddenly works.I have fixed several links this way. The method worked each time exactly as stated. For now it's my only firm way to deal with the problem.
I have observed few images that started showing on A "by themselves". I suspect in this case some random user(s) of the Internet had done the job of B for me.
The example link was posted on Super User, but I have also observed the problem on Ask Ubuntu (e.g. here).
I'm using my laptop in the Location A to ask this very question. I was afraid I wouldn't be able to add images, but the site still uses Imgur and there was no problem. As a test I started writing a question on Super User, uploaded an image and encountered
oh no, that request didn't look rightfromi.sstatic.net. In other words I couldn't see the file I have uploaded… until I accessed it from B which again fixed it for A. This means the act of uploading from A went well.In my tests
i.sstatic.netresolved either to172.64.146.223or to104.18.41.33. It seems it doesn't matter which IP address is used at which stage, the problem and my method of dealing with it behave consistently.RayIDs of my unsuccessful tries to access https://i.sstatic.net/KnVuyq7G.jpg from A:
872140670bf8772e,872149dd09dabfc6. This is one of the images I have already fixed by accessing from B.RayIDs of my unsuccessful tries to access another image uploaded by me:
8721e856df81353a,8721e999fe58353a. I have not fixed this image by accessing its link from B; I'm not going to. I deliberately do not post the link, so hopefully nobody inadvertently fixes it before the right person or team starts investigating.
Hypothesis
One scenario that (I think) makes sense is:
Initial requests from A do not find the resource (image) on CDN nodes in geographical proximity. The requests ultimately go to a distant server that refuses serving to the IP addresses of A for some reason.
A request from B ultimately goes to the same or to another server that serves the resource to the IP address of B successfully.
The resource gets copied to a node (or cache) closer to B automatically.
It so happens this node (or cache) is the best choice when A requests the resource again.
It so happens this node (or cache) has no problem with serving to the IP addresses of A.
With this hypothesis the "crazy part" is no longer that crazy.
Workaround
As a workaround I have set up a SOCKS proxy in B and I use it from A only to access i.sstatic.net. The actual setup is more convoluted, it involves VPN and SSH connections I had been using even before the problem started.
Still I'm hoping for a fix that will make the things just work. The question stands.
Update
I've been asked to post more recent RayIDs, here they are (from 2024-05-02, around 19:30 UTC):
87da5fd72dbd357e,87da606e9963357e.The resource is https://i.sstatic.net/KnVuyq7G.jpg , accessed from A. This is one of the images I had fixed by accessing from B, but I have just discovered it is unavailable to A again. So I have just fixed it again by accessing from B. Nothing has changed; accessing from B fixed it for A, but now I strongly suspect this is a temporary fix that needs to be renewed.
87da6ced4f7d357e,87da6e511844357eThe resource is the already mentioned image uploaded by me, accessed from A; the one I was not going and I'm not going to fix by accessing from B.
To be clear: I have disabled my workaround (the SOCKS proxy) in order to obtain the above RayIDs.
