XF 1.5 Are these XF image proxy related URLs?

[XenBurger]

We have a few image related proxy 500 errors showing in Console so i wanted to ask if these are related to the image proxy option setting in the XF admin, or unrelated?

https://www.hairlosstalk.com/intera...oads/2008/12/kelly-slater-20061112-178330.jpg

https://www.hairlosstalk.com/intera...Premiere+Screen+Gems+Wedding+0L9MN9UTMTKl.jpg

https://www.hairlosstalk.com/interact/proxy.php?image\u003dhttp://i.imgur.com/Yb6hO.jpg
https://www.hairlosstalk.com/interact/proxy.php?image\u003dhttp://i.imgur.com/zPng6Ev.jpg
https://www.hairlosstalk.com/interact/proxy.php?image\u003dhttp://i.imgur.com/jpnXW.jpg

https://www.hairlosstalk.com/interact/proxy.php?image\u003dhttp://i48.tinypic.com/np4eg2.jpg

https://www.hairlosstalk.com/intera...ttp://s19.postimage.org/t5toqrlg3/top_wet.jpg

All returning 500 server errors.

Any suggestions on fixing these errors?

 

[Mr Lucky]

Change the image URLs to the actual ones, not the redirects.


See here: https://xenforo.com/community/threa...e-image-proxy-to-follow-301-redirects.120346/

e.g.

 

[Mike]

These aren't valid URLs, in that they have multiple levels of encoding (and aren't URLs XF would generate). Because they aren't valid, they can't even be detected as image proxy URLs.

 

[XenBurger]

@Mike -

One quick question: what if I change the key in the admin?

"Image and Link Proxy Secret Key - If you find that links are being accessed via third-party sites, you can change this secret key to expire these links. All links stored on the forum will be automatically updated to use the new secret key."

Here's why I think maybe these are not originating at my forum, but are being accessed from a third party site:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Mike]

Changing that value won't help here as the code isn't even getting there.

I'm changing the response code in this case to 400 (for the next release), which indicates a bad request and that the server can't respond due to a client error (in this case, a logic/malformed syntax error). This may still be listed in webmaster tools, but the alternative is returning a 200 which would indicate that the page is valid, which is clearly not correct.

 

[XenBurger]

I'm changing the response code in this case to 400 (for the next release), which indicates a bad request and that the server can't respond due to a client error

Great idea. I appreciate you thinking of doing this. The real question is whether 400's are also counted against the site ranking-wise, like 500's can sometimes be. If 400's are safe then its fine to return that. But if they're exactly like 500's in googles eyes it might make no difference. Should I ask around?

 

[XenBurger]

Okay so apparently 400 errors are a referred to as "400 level" errors and are part of a group of errors, among which are 400, 410 and 404.

All of which are considered somewhat inert to Google, rankingwise.

I hope that is correct. I just googled a bit.

 

[XenBurger]

Initially i thought if we deleted the broken images on our forums, this would fix the problem.

But:

Actually this has nothing to do with them being broken or not. The external link which is pointing to these images on our site, is malformed.

So broken or not, the problem is the external link. This means that the best we can do in the short term is to delete the image.

This means when google goes to look for it, its going to serve a 404 instead of a 500 most likely. Im hoping.

----------------------------

EDIT 2: When I deleted the image from our forums, it still serves the 500 on our forum and says malformed proxy ...........................

So there's literally nothing we can do.

Am I understanding this correctly @Mike ?

 

[Mike]

These are malformed links. There's nothing you can do within XF to prevent the code from responding this way. If you are desperate to block them, you'll need to do it at the web server level.

 

[XenBurger]

I'm changing the response code in this case to 400 (for the next release)

Just wanted to follow up on this.

All the 500's dropped off the "Server Error" tab in Google Console and now it says "0".

So the change you made worked!