[jira] [Commented] (TS-3432) XDebug X-Cache header erroneously reports "hit-fresh" for mismatched HTTP methods
[
https://issues.apache.org/jira/browse/TS-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584180#comment-14584180
]
Bryan Call commented on TS-3432:
What is proxy.config.http.cache.post_method set to?
> 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 (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 (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)
[jira] [Commented] (TS-3432) XDebug X-Cache header erroneously reports "hit-fresh" for mismatched HTTP methods
[
https://issues.apache.org/jira/browse/TS-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354221#comment-14354221
]
James Peach commented on TS-3432:
-
The {{xdebug}} plugin gets this value from {{TSHttpTxnCacheLookupStatusGet}}.
So in this case, it's telling us that the cache lookup was a hit, though
subsequently the cache value must have been invalidated due to the {{POST}}. I
agree that this is misleading. The notion of "cache hit" needs to be a bit more
sophisticated to deal with this.
> 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: 6.0.0
>
>
> 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 (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 (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)
[jira] [Commented] (TS-3432) XDebug X-Cache header erroneously reports "hit-fresh" for mismatched HTTP methods
[
https://issues.apache.org/jira/browse/TS-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352367#comment-14352367
]
Leif Hedstrom commented on TS-3432:
---
This is likely not so much an issue with X-Debug plugin itself, as how this is
exposed inside the core.
> 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: 6.0.0
>
>
> 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 (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 (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)
