Hi Adi,

I've noticed that as well. I don't actually have an answer for you. The weird part is that with cURL it's fine, but in browsers t's not. That's the part that I don't get.

$ curl -I -L https://api.themoviedb.org/3/movie/550?api_key=###
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=28800
Content-Length: 1338
Content-Type: application/json;charset=utf-8
Date: Mon, 09 May 2016 17:55:09 GMT
ETag: "ef78e0da547af7a65612b734b1273e03"
Server: openresty
Status: 200 OK
Vary: Accept-Encoding
X-Memc: HIT
X-Memc-Age: 19339
X-Memc-Expires: 9461
X-Memc-Key: a7a8be33582080c3e162cfcb93607b73
X-RateLimit-Limit: 40
X-RateLimit-Remaining: 39
X-RateLimit-Reset: 1462816519
Connection: keep-alive

Maybe it's an invisible character or something, I'm just not sure.

Seems to happen about 4% of the time programmatically for Person requests. e.g. ID 54769 was fine, but 4826 had the issue.

Will keep an eye on it and see if there is a pattern. Makes me wonder if it happened to a certain number of files which were updated over a short period where there was a code error.

The W/ is the more common of the two. A lot more common. The issue is replicated both in browser and programmatically.

Okay, so film 146107 is fine:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=28800
Content-Type: application/json;charset=utf-8
Date: Wed, 11 May 2016 16:34:47 GMT
Etag: "41739ebf149fba438463473554dedf4c"
Server: openresty
Status: 200 OK
X-Memc: HIT
X-Memc-Age: 1064
X-Memc-Expires: 27736
X-Memc-Key: 6029c2890a4431cbfd77d40f0b774621
X-RateLimit-Limit: 40
X-RateLimit-Remaining: 31
X-RateLimit-Reset: 1462984487
Content-Length: 968
Connection: keep-alive

146113 is not fine:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=28800
Content-Encoding: gzip
Content-Type: application/json;charset=utf-8
Date: Wed, 11 May 2016 16:29:15 GMT
Etag: W/"1ee1814e22b8a22c2a7868c7d0880bd8"
Server: openresty
Status: 200 OK
Vary: Accept-Encoding
X-Memc: HIT
X-Memc-Age: 725
X-Memc-Expires: 28075
X-Memc-Key: 456257f798a11d14260b3749dacd0394
X-RateLimit-Limit   : 40
X-RateLimit-Remaining: 28
X-RateLimit-Reset: 1462984155
Content-Length: 1202
Connection: keep-alive

This seems to be the difference between the two:

Content-Encoding: gzip
Vary: Accept-Encoding

W/ has gained those two entries in the header response.

Looks like Varnish-Cache or something similar is the culprit: https://www.varnish-cache.org/docs/trunk/users-guide/compression.html Check the heading: Compressing content if backends don't

We don't use Varnish, but I'll take a read through that and look to see why some responses are serving the Content-Encoding/Vary headers while others aren't.

P.S. I don't have time for this right now, but will try in the next few weeks.

Makes no odds to me. It was just a curiosity, so I thought I would mention it :) But the W/ seems to be a practise which is obviously adopted by more than one caching thing.