Page MenuHomePhabricator

Image fails to load with CORS violation
Closed, DuplicatePublic

Description

When I try to load https://en.wikipedia.org/wiki/24_Hours_of_Le_Mans#/media/File:Circuit_de_la_Sarthe_track_map.svg (by clicking the thumbnail at https://en.wikipedia.org/wiki/24_Hours_of_Le_Mans#Circuit), I get an error message (in the form of an image, attached).

In my browser console, I've got:

Access to XMLHttpRequest at 'https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/Circuit_de_la_Sarthe_track_map.svg/2880px-Circuit_de_la_Sarthe_track_map.svg.png' from origin 'https://en.wikipedia.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Failed to load resource: net::ERR_FAILED

Access to image at 'https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/Circuit_de_la_Sarthe_track_map.svg/2880px-Circuit_de_la_Sarthe_track_map.svg.png' from origin 'https://en.wikipedia.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Failed to load resource: net::ERR_FAILED

Refused to get unsafe header "X-Varnish"
PL.populateStatsFromXhr @ load.php?lang=en&modules=mmv&skin=vector&version=3h1nr:7

Event Timeline

Majavah added a subscriber: Majavah.

added hopefully right project tags, please correct if I'm wrong

I get an error message

I don't, being logged in, on Firefox 84. Which browser and browser version is this about?

I'm still getting it. I can reproduce on any of:

Chrome Version 87.0.4280.88 (Official Build) (x86_64) (same result in both a regular or an incognito window)
Safari Version 14.0.2 (16610.3.7.1.9)
Firefox 79.0 (64-bit)

MacOS Big Sur

The interesting thing is first I get low-res version of the image, then it hangs for a while, then that's replaced by the error image. I think that was happening yesterday, but the delay was short enough that I wasn't sure. Now the delay is longer so it's more obvious that's happening.

RLazarus added a subscriber: RLazarus.

I can't repro the CORS issue exactly, but I am getting a 503 from Varnish for https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/Circuit_de_la_Sarthe_track_map.svg/2880px-Circuit_de_la_Sarthe_track_map.svg.png ... but only on the 2880px- URL -- the smaller ones work fine. I suspect that's why @Aklapper couldn't immediately repro: my browser didn't try to fetch the 2880px edition until I resized the window big enough.

Digging a little more into this (and re-adding Traffic) but I'm more likely to route it to an expert, once I figure out a little more about what's going on here, than solve it myself.

only on the 2880px- URL -- the smaller ones work fine.

Meant to add -- that's also the reason for this:

first I get low-res version of the image, then it hangs for a while, then that's replaced by the error image.

Yeah, I can repro that here. On the command line:

curl -v https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/Circuit_de_la_Sarthe_track_map.svg/2560px-Circuit_de_la_Sarthe_track_map.svg.png

the headers I get back are:

HTTP/2 429
date: Fri, 18 Dec 2020 20:19:42 GMT
server: Varnish
x-cache: cp1082 int
x-cache-status: int-front
server-timing: cache;desc="int-front"
strict-transport-security: max-age=106384710; includeSubDomains; preload
report-to: { "group": "wm_nel", "max_age": 86400, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
nel: { "report_to": "wm_nel", "max_age": 86400, "failure_fraction": 0.05, "success_fraction": 0.0}
set-cookie: WMF-Last-Access=18-Dec-2020;Path=/;HttpOnly;secure;Expires=Tue, 19 Jan 2021 12:00:00 GMT
x-client-ip: 172.16.3.190
content-type: text/html; charset=utf-8
content-length: 1820
RLazarus added a subscriber: CDanis.

Thanks to @CDanis for digging into this with me. There are a couple of different things going on.

  1. The thumbor service has a lot of trouble producing a 2880-pixel version of that SVG -- probably because the SVG is itself large and expensive, or something along those lines. When I fetched it directly, the request hung for a minute or so before coming back as a 503, likely because of a timeout somewhere in the stack.
  2. After Chris and I tried that a few times in the course of investigating, the slow 503 became a quick 429, because we rate-limit these fairly aggressively. That part is working as intended. (Hence the 429 in your latest, @RoySmith -- and thanks for that data, btw!)
  3. The Varnish error page, for both the 503 and the 429, doesn't set an Access-Control-Allow-Origin header (which the actual image response does include). So I think that's why your browser gave you a CORS policy error, but it's not why the image didn't load: the response was already a 503, so the CORS message is a red herring.

We should address those problems a few different ways, so I'm splitting this into a few tasks.

  • I suspect this might turn out to be a known limitation on huge SVGs, but serviceops should dig into the root Thumbor problem with this image, so I'm repurposing this task for that (and spinning the revolving door on Traffic once more).
  • Maybe those Varnish error pages should set CORS headers. It's not obvious that's the right thing to do, since nobody is running around cross-requesting an error page on purpose, but it would avoid the confusing browser error in cases like this. I'll refer that question to Traffic in another task.
  • On getting the 503, maybe the viewer should have left up the initial low-res version of the image, rather than replace it with the error -- or even try requesting a smaller size like 1440px, after a suitable backoff. But that definitely might not be the right idea, and I'll refer it to the folks who work on the viewer, in a separate task.

When I fetched it directly, the request hung for a minute or so before coming back as a 503, likely because of a timeout somewhere in the stack.

Yup, Thumbor gives librsvg 59 seconds to process the file before giving up. Testing locally, rsvg-convert version 2.40.21 wasn't finished in 2 minutes (when I got tired of waiting). This is a known issue for large thumbnails of SVGs using feGaussianBlur (T200866) and should be fixed in T193352: Update librsvg to ≥2.42.3 (2.44.10).

Ah, cheers @AntiCompositeNumber, I thought it sounded familiar. So it sounds like this will get better with T216815, which I think I've heard mutterings about doing Soon™.

So, since the root cause here is a known issue, I'm duping this ticket over to the SVG rendering issue, but thanks @RoySmith for filing -- the subtasks are still open and will hopefully yield distinct improvements here.