Nick Muerdter created TS-3432:
---------------------------------
Summary: XDebug X-Cache header erroneously reports "hit-fresh" for
mismatched HTTP methods
Key: TS-3432
URL: https://issues.apache.org/jira/browse/TS-3432
Project: Traffic Server
Issue Type: Bug
Reporter: Nick Muerdter
I noticed the XDebug experimental plugin can sometimes give what appears to be
incorrect responses to POST requests if there is a cached GET response at the
same URL endpoint. If a GET response is cached at a specific URL, and then a
POST request is made to the same URL, the XDebug plugin reports that it's a
cache hit according to the "X-Cache: hit-fresh" header. However, TrafficServer
is correctly not serving up the cached GET request in response to the POST, so
the issue appears to simply be XDebug's "X-Cache" header returning incorrect
information.
Here's a some example scripts that demonstrate the issue. First here's a simple
nodejs backend server that will respond to both GET and POST requests:
{code}
var http = require("http");
http.createServer(function(request, response) {
if(request.method == 'GET') {
response.writeHead(200, { 'Cache-Control': 'max-age=300' });
} else {
response.writeHead(200);
}
response.write('example response');
response.end();
}).listen(3000);
{code}
Here's the response to the initial GET request:
{code}
$ curl -v -H "X-Debug: X-Cache" "http://127.0.0.1:8080/test";
* About to connect() to 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /test HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
> Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 127.0.0.1:8080
> Accept: */*
> X-Debug: X-Cache
>
< HTTP/1.1 200 OK
< Cache-Control: max-age=300
< Date: Sun, 08 Mar 2015 22:12:07 GMT
< Age: 0
< Transfer-Encoding: chunked
< Connection: keep-alive
< Via: http/1.1 <proxy_name> (ApacheTrafficServer/5.2.0 [uScMsSfWpSeN:t cCMi p
sS])
< Server: ATS/5.2.0
< X-Cache: miss
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
example response - HTTP method: GET
{code}
Here's the response to a subsequent POST request. Note the "X-Cache: hit-fresh"
response header despite the fact that it's not delivering a cached response.
{code}
$ curl --data "foo=bar" -H "X-Debug: X-Cache" -v "http://127.0.0.1:8080/test";
* About to connect() to 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> POST /test HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
> Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 127.0.0.1:8080
> Accept: */*
> X-Debug: X-Cache
> Content-Length: 7
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Date: Sun, 08 Mar 2015 22:12:32 GMT
< Age: 0
< Transfer-Encoding: chunked
< Connection: keep-alive
< Via: http/1.1 <proxy_name> (ApacheTrafficServer/5.2.0 [uScSsSfDpSeN:t cCDi p
sS])
< Server: ATS/5.2.0
< X-Cache: hit-fresh
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
example response - HTTP method: POST
{code}
In this case, I have the detailed Via response headers turned on, and according
to the cache-lookup value in there, the POST response is "in cache, stale (a
cache “MISS”)" ("cS" code).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
