ssl=1 error 400

I can see all of those with and without the ssl. Are you still having trouble?

Yes the problem persists. It happens with all browsers and with different internet connections. Even a collaborator who lives in a different city has the same problem with the same images.

Watch this please: https://reccloud.com/en/u/fbeuzs3

Thanks

Thanks, could you link to the page that is failing to display the images?

For example, this is the “tag” page: https://sbamcomics.it/blog/tag/new-mutants/

I don’t see the image of the first article (it’s the same linked above). But I see the image of the second one.

The same thing happens in the category archive, in the “search” and of course on the article page. It also happens on the administrator side in the “media” control panel.

I tried to install the “Regenerate thumbnail” plugin. I can see the image if I go to regenerate the miniatures because they are loaded locally. But after having regenerated them, nothing changes, I still don’t see the image on the website pages.

Thanks

Do the images re-appear if you switch off just “Speed up image load times” or “Enable Lazy Loading for images” at Jetpack > Settings > Performance in your site’s Dashboard?

Lazy loading on or off has nothing to do, I just tried.

It is not a problem related to wordpress or hosting. The url on i2.wp.com that should return the image returns an error 400 instead, that’s the problem.

The “&ssl=1” parameter in the url is the key. It’s not an encoding problem with “&” because if I add “&xxx=1” it works.

It’s not related with my internet connection because I can reproduce the issue with 2 different ADSL provider and with my mobile conn.

Okay, I got one thing.

I just tried to access the image with a VPN (a simple test on hide.me).

Try it yourself.

Select “Germany” = error 400
Select “Netherlands” = error 400
Select “USA” = it works!

I am in Italy. It seems that this url (with “&ssl=1”) is not accessible from all over Europe:

https://i2.wp.com/sbamcomics.it/wp-content/uploads/2020/01/new-mutants-fotogramma.jpg?resize=600%2C382&ssl=1

I am in Italy. It seems that this url (with “&ssl=1”) is not accessible from all over Europe:

Okay. This is because no matter where you are in Europe, the image will be served from the same data center over there. If you’re in the US, the image will instead be served from one of our data centers in the US.

So this indicates that the image is not cached at our EU data center.

I see you’re using the SG Optimizer plugin, and that plugin comes with its own CDN and lazy loading built in. To rule that out as a cause here, can you please disable that plugin, then re-upload that featured image with a slightly different filename, and replace it on that post, and see if that makes any difference?

If it doesn’t, then the problem is most likely that the image takes too long to cache to our CDN servers, causing the process to time out. This could be because your host is rate-limiting the connections we can make, or it could just be due to low data transfer speeds between your server and our CDN’s.

Hi, how was this resolved? I see it is marked “resolved”, but no solution provided.

I am experiencing the exact same issue on images in my shop.

Where:
https://i1.wp.com/shopnall.co.za/wp-content/uploads/2020/04/silo-MIN_197493001_EAA_large.jpeg?fit=694%2C636&ssl=1
gave an error:
We cannot complete this request, remote server returned an unexpected status code (400)
while
https://i1.wp.com/shopnall.co.za/wp-content/uploads/2020/04/silo-MIN_197493001_EAA_large.jpeg?fit=694%2C636
loads fine.
This was an image that had been working and then stopped without any modification by me. Editing the images helps, but I can’t be checking and re-editing my product images every day and this looks bad to my customers!

I disabled SG Optimizer to no effect. Then I disabled JetPack and the images magically reappeared. Unfortunately I need the Jetpack connection for my WooCommerce store management app, so I re-enabled it. The problem appeared again. So finally under JetPack->Settings->Performance I disabled “Speed up image load times” and that restores the images.

There is clearly something wrong with the Jetpack image caching, so it would be nice if that could be addressed.

Only solution is re-upload the broken images or use another CDN.

@lucamc Reloading doesn’t help in the long term coz previously working images break randomly

@lucamc Agree with @urshadow. Re-uploading is not a satisfactory solution.

It is not a satisfactory solution but at the moment it is the ONLY solution.

The images exist on the server because if you remove the parameter “ssl=1” the images appear. So it is clearly an internal server bug. There is no user-side solution in my opinion.

We probably have to insist, the more people report the bug the more chances there are that they decide to do something.

We are seing the same issue on the page:
https://forum.astronomisk.dk/forums/reply/316881/
Exactly the same problem.
Trying to load this URL:
https://i2.wp.com/forum.astronomisk.dk/wp-content/uploads/2018/03/tube2_surface.jpg?ssl=1
results in this error:
“We cannot complete this request, remote server returned an unexpected status code (400)”
(I’m also seeing this error: “Error 0005. The type of image you are trying to process is not allowed.”)
If you remove the “ssl=1” parameter the original cached image will load:
https://i2.wp.com/forum.astronomisk.dk/wp-content/uploads/2018/03/tube2_surface.jpg
So it seems there must be something fishy going on on the image caching server.
I reoploaded the same image again without any problems.

FWIW: I don’t know how the software (formerly known as Photon) does its trick on its own server, but we have had SG Cache activated on this server at the time when the upload took place. Also the page in question had 4 big images (about 1MB each) uploaded at once, so perhaps there has been some timeout going on in the webserver-to-photon-server-process that could have interfered with the preparation work of the SG Cache?! Maybe something that led to an timeout or some unexpected behaviour like the original webserver image being altered in the middle of the photon-caching process? Obviously, I’m just guessing.

But please be aware that the original version still seems to be available from:
https://i2.wp.com/forum.astronomisk.dk/wp-content/uploads/2018/03/tube2_surface.jpg

I have similar problem

• This reply was modified 4 years, 5 months ago by nafidurmus.