This is very weird, but I have a cache entry where the request is for http://api.themoviedb.org/3/person/229533, but the response is movie info, I believe what should be the return from http://api.themoviedb.org/3/movie/37861

Based on the date of the response, the request was made around Date: Wed, 08 May 2013 18:22:47 GMT

Is there any chance this is a known TMDB error? I rather dread trying to track it on my side. :/ I've made the squid cache file available here: http://ruka.org/~toast/tmdb_wrong_response.bin this is reasonably legible (the format is not well documented, and I can provide more details if you want, but on the first line, the requested url is between the last two nulls; after the last null is the HTTP response (the response body is gzipped). (I zeroed out my api key).

My stack is php -> squid3 -> erlang HTTP proxy (yaws + custom logic for rate limiting and tweaking cache headers) -> api.themoviedb.org. HTTP Keep alive is enabled between all the layers.

To be clear, the erlang layer is adding the Last-Modified header, may be forcing gzip encoding, and is also making the header names lower case; I believe squid is adding (or overwriting) the Age header, and is normalizing many of the header names back to the cases we know and love (I believe it also adds the X-Cache header).

I also have a daily process that goes through the squid cache to build a sitemap; it's been crashing because that response doesn't look like a normal /person/ response.

Squid logs related to the movie for May 8th:

1368039816.581 1457 127.0.0.1 TCP_REFRESH_MODIFIED/200 2027 GET http://api.themoviedb.org/3/movie/37861/casts?api_key= "low" FIRST_UP_PARENT/127.0.0.1 application/json 1368041894.073 0 127.0.0.1 TCP_MEM_HIT/200 2029 GET http://api.themoviedb.org/3/movie/37861/casts?api_key= "-" NONE/- application/json 1368041894.455 388 127.0.0.1 TCP_REFRESH_MODIFIED/200 1581 GET http://api.themoviedb.org/3/movie/37861?api_key= "-" FIRST_UP_PARENT/127.0.0.1 application/json

And squid logs for the person for May 8th:

1368037367.365 109 127.0.0.1 TCP_REFRESH_MODIFIED/200 1579 GET http://api.themoviedb.org/3/person/229533?api_key="-" FIRST_UP_PARENT/127.0.0.1 application/json 1368037367.783 520 127.0.0.1 TCP_REFRESH_FAIL/200 1074 GET http://api.themoviedb.org/3/person/229533/credits?api_key="-" FIRST_UP_PARENT/127.0.0.1 application/json 1368037368.599 0 127.0.0.1 TCP_MEM_HIT/200 1578 GET http://api.themoviedb.org/3/person/229533?api_key="-" NONE/- application/json 1368037368.897 297 127.0.0.1 TCP_REFRESH_FAIL/200 1074 GET http://api.themoviedb.org/3/person/229533/credits?api_key="-" FIRST_UP_PARENT/127.0.0.1 application/json

I also have yaws logs for the movie (times in PDT):

127.0.0.1 - - [08/May/2013:12:03:34 -0700] "GET /3/movie/37861/casts?api_key= HTTP/1.1" 200 1336 "-" "-" 127.0.0.1 - - [08/May/2013:12:38:14 -0700] "GET /3/movie/37861?api_key= HTTP/1.1" 200 896 "-" "-"

And the person:

127.0.0.1 - - [08/May/2013:11:22:45 -0700] "GET /3/person/229533?api_key= HTTP/1.1" 200 896 "-" "-" 127.0.0.1 - - [08/May/2013:11:22:45 -0700] "GET /3/person/229533/credits?api_key= HTTP/1.1" 500 0 "-" "-" 127.0.0.1 - - [08/May/2013:11:22:48 -0700] "GET /3/person/229533/credits?api_key= HTTP/1.1" 500 0 "-" "-"

I don't have any details on the HTTP 500 for /3/person/229533/credits; my erlang proxy will proxy through an HTTP 500 from tmdb, but it can also generate them. If the proxy generates an HTTP 500, it should be accompanied by an error log, and there aren't any during that time frame.

Sorry for the length of the post, but I wanted to make sure I had all the relevant info, in case it's helpful.