Image URLs are inconsistent between the games resource and the game resource

This is a weird bug. For a few games, the image list that comes back from the /games/ resource is different from what comes back from /game/ resource. It seems like the /games/ resource returns a list of .png files when in reality, the files are supposed to be .jpg files. The /game/ resource returns the correct list of .jpg files.

Here's the example to show this:

http://www.giantbomb.com/api/games/?api_key=<key>&format=json&offset=45800

Search for World of Final Fantasy (3030-50003). The image list it returns is a bunch of .png files, and when you attempt to look at them in a browser, they don't exist (http://static.giantbomb.com/uploads/scale_large/14/149021/2759194-9859344256-logo..png is one of the images)

However, if you go to http://www.giantbomb.com/api/game/3030-50003/?api_key=<key>&format=json the list of images is correct.

This is happening on more than just this game. Groove Galaxy is another example. It seems to be fairly limited, but something isn't meshing.

Just thought I'd let you guys know.

@edgework Bad image URLs in the API is something I have to deal with on a daily basis. I wish you could do something about it.

Just to follow on with this post, there are some games where the opposite is true. The /game/ detail request returns the wrong images. An example of that is everyone's favorite Bubble Witch 2 Saga. http://www.giantbomb.com/api/game/3030-46847/?api_key=<key>&format=json returns a list of JPGs, when they're actually supposed to be PNGs. It seems to be there are very few games where this is the case.

This API is still awesome, there's just some weirdness with the images. I've got workarounds for it on my site, but it would be nice if it got corrected someday.

@frobie ??

@peteace@szlifier Updated the API to return images correctly. It will no longer return the CDN url to the image which may not exist. Instead it will return a path that will resize the image if it does not exist. Note the resize job is put in a queue so it may not be instant. But, in the future, the resized image will appear for the given path.

@frobie: Very cool. Thank you very much!

@frobie: It appears that when the API is queried over HTTPS it will return image URLs that use the HTTPS protocol. Unfortunately, when attempting to access an image over HTTPS, the server responds with a status code of 200, but an empty payload. For example:

http://www.giantbomb.com/api/image/scale_large/2869787-demd.jpg

https://www.giantbomb.com/api/image/scale_large/2869787-demd.jpg

If an identical query was recently made over HTTP, it looks like a cached response will be used and HTTP URLs will be returned even to queries made over HTTPS, but tweaking the query (offset, length, etc.) will have the server sending back HTTPS URLs again.

Any chance the API could be forced to always return HTTP URLs for images or the server could be updated to serve images over HTTPS?

@frobie:I'm getting some more weird image issues with the API. I've seen this happen on a couple of games, but here's a specific example:

http://www.giantbomb.com/api/game/3030-47680/?api_key=<key>&format=json is endpoint for Super Meatboy Forever.

It returns http://www.giantbomb.com/api/image/scale_large/2676357-7827617660-tumbl.png as the URL for the super_url. However, my code can never grab anything from that URL. If you just punch it into your browser, you get this little error:

Not too sure why it's looking for a jpg when you send it a png in the URL, but I'm getting this error in a browser, and in code.

Hope this is enough info to go on!

@peteace: This one should be fixed. Most likely there are other images like this, let me know if you see any others pop up.

@soup_menu Got a fix in that will force the image paths returned to use the http protocol. Should be live Tuesday. Serving the images through https is a decision higher than my pay grade.

@frobie: Fantastic! Thank you, sir.

@frobie: Found a few more:

Brigador - http://www.giantbomb.com/api/game/3030-45310/?api_key=<key>&format=json
Orcs Must Die! Unchained - http://www.giantbomb.com/api/game/3030-46005/?api_key=<key>&format=json
Timespinner - http://www.giantbomb.com/api/game/3030-47154/?api_key=<key>&format=json
XING: The Land Beyond - http://www.giantbomb.com/api/game/3030-47452/?api_key=<key>&format=json
Let it Die - http://www.giantbomb.com/api/game/3030-46574/?api_key=<key>&format=json
Twisted Fusion - http://www.giantbomb.com/api/game/3030-45816/?api_key=<key>&format=json
Beyond Shadowgate - http://www.giantbomb.com/api/game/3030-47539/?api_key=<key>&format=json
Dreadnought - http://www.giantbomb.com/api/game/3030-46585/?api_key=<key>&format=json
Wulverblade - http://www.giantbomb.com/api/game/3030-46575/?api_key=<key>&format=json
Heroes of Infinity - http://www.giantbomb.com/api/game/3030-47971/?api_key=<key>&format=json
Viking Squad - http://www.giantbomb.com/api/game/3030-47934/?api_key=<key>&format=json
Justice Beaver - http://www.giantbomb.com/api/game/3030-47210/?api_key=<key>&format=json

All of these had png files for the list of images if that helps any.

Thanks!

@peteace Thanks for finding those. We know the cause but the programmatic fix would be to compare each image size we have stored against their image storage counterpart and then resize if it does not exist. This solution would take eons just due to the sheer enormity of images we have across all three sites. While we work on a better solution, ping me any you see and I'll fix them manually--which is kind of worse now that I see it in text.