Hi, I have come across a strange ATS behavior that I'm hoping someone can help with.
My setup is as follows: I have an origin server that exposes an end point that returns streaming JSON data, the size of the data that is returned by this end point is unknown at the point of receiving the HTTP request so the origin server returns back the following headers (captured from a wget): HTTP request sent, awaiting response... HTTP/1.1 200 OK Vary: Accept-Encoding Cache-Control: max-age=345600 Expires: Mon, 01 Aug 2016 14:21:10 GMT Date: Thu, 28 Jul 2016 14:21:10 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD Content-Type: text/plain; charset=iso-8859-1 Server: Jetty(6.1.26) Length: unspecified [text/plain] I have placed ATS (configured in reverse proxy mode, in a cluster config of 6 nodes) in front of my origin servers. The reason for doing this is the json response from the origin server is immutable and cache-able and allows me to offload a lot of pressure on my origin server/data store. When I query the same request via ATS I see the below headers: HTTP request sent, awaiting response... HTTP/1.0 200 OK Vary: Accept-Encoding Cache-Control: max-age=345600 Expires: Mon, 01 Aug 2016 14:24:58 GMT Date: Thu, 28 Jul 2016 14:24:58 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD Content-Type: text/plain; charset=iso-8859-1 Server: ATS/5.3.2 Age: 0 Connection: close Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSfWpSeN:t cCMi p sS]) Length: unspecified [text/plain] My problem is as follows: Due to the size of the response that is returned it can take several seconds for the complete response to be sent back to the client. I have been able to recreate the issue easily using wget in two separate terminal sessions. In the first terminal session (Terminal 1), I do a wget (without setting any accept-encoding request headers), I wait for the headers to come back and as soon as they do, I do the same wget in the second terminal window (Terminal 2). After a few seconds, in the first terminal I get the full response back from the wget call, below are the headers sent back to the client: >From Terminal 1: HTTP request sent, awaiting response... HTTP/1.0 200 OK Vary: Accept-Encoding Cache-Control: max-age=259200 Expires: Sat, 30 Jul 2016 12:20:08 GMT Date: Wed, 27 Jul 2016 12:20:08 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD Content-Type: text/plain; charset=iso-8859-1 Server: ATS/5.3.2 Age: 0 Connection: close Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSfWpSeN:t cCMi p sS]) Length: unspecified [text/plain] >From Terminal 2 however, I never get the full response back, the call ultimately times out after 10mins: Below are the headers from the call in Terminal 2: HTTP request sent, awaiting response... HTTP/1.0 200 OK Vary: Accept-Encoding Cache-Control: max-age=259200 Expires: Sat, 30 Jul 2016 12:20:08 GMT Date: Wed, 27 Jul 2016 12:20:08 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD Content-Type: text/plain; charset=iso-8859-1 Server: ATS/5.3.2 Age: 1 Connection: close Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScHs f p eN:t cCHi p s ]) Length: unspecified [text/plain] The interesting thing to highlight here is that the response I get back from the call in Terminal 1 is a cache miss (as expected) however, the response I get back from Terminal 2 is a cache hit. However, ATS has not completed stored the entire object in its cache since its still streaming it back to the client. Another interesting thing to point out is if I do the same experiment but explicitly specifying "accept-encoding: gzip" in the wget call I am able to get the full response back from both calls with no timeout issues at all. Why does ATS behave differently in this scenario when a client requests gzip encoding vs no encoding at all? Below are the headers I get back from Terminal 1 when sending "accept-encoding: gzip": HTTP request sent, awaiting response... HTTP/1.0 200 OK Vary: Accept-Encoding Cache-Control: max-age=259200 Expires: Sun, 31 Jul 2016 14:39:06 GMT Date: Thu, 28 Jul 2016 14:39:06 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD Content-Type: text/plain Content-Encoding: gzip Server: ATS/5.3.2 Age: 2 Connection: close Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSfWpSeN:t cCMi p sS]) Length: unspecified [text/plain] Below are the headers I get back from Terminal 2 when sending "accept-encoding: gzip": HTTP request sent, awaiting response... HTTP/1.0 200 OK Vary: Accept-Encoding Cache-Control: max-age=259200 Expires: Sun, 31 Jul 2016 14:39:09 GMT Date: Thu, 28 Jul 2016 14:39:09 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD Content-Type: text/plain Content-Encoding: gzip Server: ATS/5.3.2 Age: 0 Connection: close Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSf pSeN:t cCMi p sS]) Length: unspecified [text/plain] Can someone please shed some light on this issue? Thanks. -- View this message in context: http://apache-traffic-server.24303.n7.nabble.com/ATS-returning-cache-hit-on-partially-cached-response-tp2554.html Sent from the Apache Traffic Server mailing list archive at Nabble.com.
