[ 
https://issues.apache.org/jira/browse/TS-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-3432:
----------------------------
    Fix Version/s:     (was: 6.0.0)
                   sometime

> 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
>    Affects Versions: 5.2.0
>            Reporter: Nick Muerdter
>            Priority: Trivial
>             Fix For: sometime
>
>
> 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)

Reply via email to