#1 Posted by soup_menu (263 posts) -

For a little while now I've been running into instances where all of the image URLs returned from the API will be relative rather than absolute. Unfortunately I can't provide any sure-fire steps to reproduce because the behavior for identical queries sent some time apart can be different. For example, last night sending a request to /api/videos/ without any sorting/filtering/pagination would return relative links, but this morning, the exact same request is giving absolute links. During the period where it was returning relative links I could seemingly consistently get absolute links by adding additional parameters to the query, but my testing wasn't exhaustive.

From what I've seen, the relative links are always attempting to point at the same resource as the absolute ones:

  • /uploads/scale_large/0/2840/2643359-there-came-anecho-screenshot1-briefing-no-rating.jpg
  • http://static.giantbomb.com/uploads/scale_large/0/2840/2643359-there-came-anecho-screenshot1-briefing-no-rating.png
#2 Edited by Chaser324 (7413 posts) -

I'm actually going to move this over to the Bug Reporting forum - that tends to catch more engineer/Rorie eyes than the API forum.

#3 Posted by soup_menu (263 posts) -

Sounds like a plan. Thanks, Chase.

#4 Posted by Laika (148 posts) -

It's possible that some set of parameters is building an invalid cache, which is why you see that inconsistent behavior (and why modifying the request might change it). Next time you see it happen, can you log the first request you make?

#5 Posted by soup_menu (263 posts) -

@laika: I've actually started seeing it again just now for requests to https://www.giantbomb.com/api/videos/?api_key=<api key> I'm not sure what sort of log you're looking for, but here are all the HTTP headers involved and I'd be happy to provide anything else you'd find relevant.

  • Remote Address:
  • Request URL:https://www.giantbomb.com/api/videos/?api_key=<apikey>
  • Request Method:GET
  • Status Code:200 OK

Request Headers

  • GET /api/videos/?api_key=<apikey> HTTP/1.1
  • Host: www.giantbomb.com
  • Connection: keep-alive
  • Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
  • User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
  • DNT: 1
  • Accept-Encoding: gzip,deflate,sdch
  • Accept-Language: en-US,en;q=0.8

Response Headers

  • HTTP/1.1 200 OK
  • Server: nginx/1.2.0
  • Content-Type: application/xml; charset=utf-8
  • Transfer-Encoding: chunked
  • Connection: keep-alive
  • Vary: Accept-Encoding
  • X-Powered-By: PHP/5.4.17
  • Set-Cookie: PHPSESSID=oicn352pmhj0r3cqq4fjt3ouo6; path=/; domain=.giantbomb.com
  • Cache-Control: no-cache
  • Date: Wed, 16 Jul 2014 16:05:58 GMT
  • X-Phoenix-Cache-Expires: 07-16-2014 09:10:58
  • X-Phoenix-Cached: true
  • Set-Cookie: device_view=not_mobile; expires=Sat, 16-Aug-2014 07:00:00 GMT; path=/; httponly
  • Content-Encoding: gzip
#6 Posted by Laika (148 posts) -

Thanks for the log. I put in a fix for this and it should hopefully be out soon.

#7 Posted by soup_menu (263 posts) -

Fantastic. Thanks for looking into it.