CDN and Image Styles

1. Please update from 3.0-rc1 to 3.0.
2. Please export your cdn.settings and paste it here.

My solution of this issue: lets check file existence for images that using Image Styles. The patch is attached.

Is site.domain.net a CDN or reverse proxy? Or is it just a CNAME record pointing to domain.net?

The D7 version of the CDN module did something like that. But it was removed in the D8 version (see #2708787-18: Port Far Future expiration to 8.x-3.x), because it was too brittle/unreliable, it caused NUMEROUS bug reports.

So I want to avoid adding something like that. Also, I'm not at all convinced it's necessary.

You have

farfuture:
  status: false

So you're not using the far future functionality, which is the only functionality that truly needs those files to already exist.

If it's an actual CDN or reverse proxy, then any request to the CDN:

http://site.domain.net/sites/default/files/styles/thumbnail/public/2017-01/test.png?itok=bF91EIdy

is received by the CDN/reverse proxy and relayed to the origin:

http://origin.domain.net/sites/default/files/styles/thumbnail/public/2017-01/test.png?itok=bF91EIdy

And then it would generate the image, the CDN would receive that, and everything would be working.

There are only two possible explanations:

1. You're not using a CDN/reverse proxy. You said in #6 that you are using a CDN.
2. You have your CDN/reverse proxy configured to strip query strings, which means the itok query string is not passed on to origin, which means that origin will refuse to generate this image.

I'm betting it's that second explanation then.

Also: please post a screenshot showing the network inspector on the failed image style request in Chrome. That will give me some additional information, and hopefully confirmation of my theory in #8.

I used patch from post #4 and it works for me. Thanks!

I'm re-opening this as we do have the same issue and also some more details.

This always happens when a new images requires a new image derivate which has not yet been created and then only the first time this is being requested. The CDN responds with a 416 status code which is specified as

The HTTP 416 Range Not Satisfiable error response code indicates that a server cannot serve the requested ranges. The most likely reason is that the document doesn't contain such ranges, or that the Range header value, though syntactically correct, doesn't make sense.

The next time the same resource is being requested through the CDN, everything is fine, response code is 200 and the image style properly get delivered and displayed.

The requests to the Drupal server do contain the query parameters, so that can't be the problem, that the CDN were mis-configured.

I guess that this is "simply" a timing issue where the CDN expects the result to be available completely and immediately where in this scenario Drupal responds with the 416 saying that not the full range is present yet but will be in a few milliseconds. So if the CDN were to retry or something similar, that problem may well be gone.

Having said that, I'm uncertain if that behavior is CDN provider specific or a general problem. My client who is seeing this problem is about to switch to a different provider and I will be able to report back if the problem will be gone with the new one.

But maybe in the meantime, someone around here can make more sense out of what I've just reported.

Which CDN is this? It's peculiar that the CDN is doing range requests. Perhaps they're trying to sniff some image metadata to determine how to process/optimize it. That's why it'd be interesting to see which CDN you are seeing this with.

My client who is seeing this problem is about to switch to a different provider and I will be able to report back if the problem will be gone with the new one.

That will be super valuable information! Thanks for following up on this so meticulously! ❤️ That's a great contribution too :) (Crediting you already.)

The CDN is StackPath (https://www.stackpath.com) and the client is going to switch over to AWS CloudFront. We've setup the test stage to run with AWS CF where the error is gone! We then switched back to StackPath and the error is showing up again.

So this is reproducable with StackPath and it's wixed with AWS CF. Whether we can do anything about this in the CDN module, I'm not sure.

Thanks a lot @Wim Leers for being so responsive to this issue. Let's hope we get this to the next level. If you need any more details, please let me know and I'll try to find out for you.

Thanks for isolating it to the https://www.stackpath.com/ CDN! I'm inclined to say this is a bug in the CDN provider then honestly, and not thisD Drupal module. I'm not sure how I could possibly solve this, because the CDN Drupal module doesn't change anything about image style handling.

If we're going to fix this, it'd need to happen in Drupal core's image module. We'd need to determine the exact cause. I strongly suspect that StackPath is doing some initial "scanning" request that uses a Range request header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range.

Agreed. At least the cause of it is now documented here for folks com ing across the same issue and then they can approach their cdn provider.

I pinged StackPath on Twitter: https://twitter.com/wimleers/status/906181654070341632 + https://twitter.com/wimleers/status/906181759531966464.

If they reply, then I'll open an issue against Drupal core's image module, and link it here :)

For now, closing this again.

Good job, @jurgenhaas! 🖐👊

thanks a lot

I have the same problem, and #4 fixed it for me. Drupal 8.9.0
maybe reopen this issue?