[jira] [Commented] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15485582#comment-15485582
]
Quinn Lertratanakul commented on TS-4098:
-
Fixed: https://github.com/apache/trafficserver/pull/1010
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15453224#comment-15453224
]
Quinn Lertratanakul edited comment on TS-4098 at 8/31/16 8:26 PM:
--
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
While stepping through gdb for a nonstandard method, {{match}} is true under
{{PerformACLFiltering}} in {{UrlRewrite.cc}} and the request is not blocked.
was (Author: kawaiirice):
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
While stepping through gdb for a nonstandard method, {example}match{example} is
true under PerformACLFiltering in UrlRewrite.cc and the request is not blocked.
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15453224#comment-15453224
]
Quinn Lertratanakul edited comment on TS-4098 at 8/31/16 8:24 PM:
--
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
While stepping through gdb for a nonstandard method, {example}match{example} is
true under PerformACLFiltering in UrlRewrite.cc and the request is not blocked.
was (Author: kawaiirice):
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
While stepping through gdb for a nonstandard method,
{inlinecode}match{inlinecode} is true under PerformACLFiltering in
UrlRewrite.cc and the request is not blocked.
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15453224#comment-15453224
]
Quinn Lertratanakul edited comment on TS-4098 at 8/31/16 8:23 PM:
--
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
While stepping through gdb for a nonstandard method,
{inlinecode}match{inlinecode} is true under PerformACLFiltering in
UrlRewrite.cc and the request is not blocked.
was (Author: kawaiirice):
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
While stepping through gdb for a nonstandard method, match is true under
PerformACLFiltering in UrlRewrite.cc and the request is not blocked.
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15453224#comment-15453224
]
Quinn Lertratanakul edited comment on TS-4098 at 8/31/16 8:21 PM:
--
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
While stepping through gdb for a nonstandard method, match is true under
PerformACLFiltering in UrlRewrite.cc and the request is not blocked.
was (Author: kawaiirice):
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15453224#comment-15453224
]
Quinn Lertratanakul edited comment on TS-4098 at 8/31/16 8:18 PM:
--
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @action=allow
@method=GET{code} returns 400 for a nonstandard method and 403 for a standard
method (ie HEAD).
was (Author: kawaiirice):
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @allow {code}
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15453224#comment-15453224
]
Quinn Lertratanakul edited comment on TS-4098 at 8/31/16 8:15 PM:
--
Under attachments is the current remaps being applied and tested on
functionality (remap.config).
>From testing by hand, the ACL filters are not behaving in the expected LIFO
>manner. For example, when we have 3 embedded filters where the GET method is
>allowed and then denied and then allowed again, a curl command requesting GET
>returns a 403.
In addressing the behavior of allow on methods, doing {code} @allow {code}
was (Author: kawaiirice):
current remaps being applied and tested on functionality by hand
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quinn Lertratanakul updated TS-4098:
Attachment: remap.config
current remaps being applied and tested on functionality by hand
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4740) Produce a warning if old metrics config is still in place
[
https://issues.apache.org/jira/browse/TS-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435154#comment-15435154
]
Quinn Lertratanakul commented on TS-4740:
-
Do we check for stats.config.xml in the sysconfdir?
> Produce a warning if old metrics config is still in place
> -
>
> Key: TS-4740
> URL: https://issues.apache.org/jira/browse/TS-4740
> Project: Traffic Server
> Issue Type: Improvement
> Components: Metrics
>Reporter: Leif Hedstrom
>Assignee: Quinn Lertratanakul
> Labels: newbie
> Fix For: 7.0.0
>
>
> As of v7.0.0, the metrics config is migrated from XML to Lua. It might be
> nice that upon loading the Lua file, if it also sees the old XML file, it'd
> produce a warning. Something like
> {code}
> if (exists(stats.config.xml)) { /* Pseudo code, obviously do it right */
> Warning("Ignoring the old stats.config.xml configuration, loading
> metrics.config instead");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4740) Produce a warning if old metrics config is still in place
[
https://issues.apache.org/jira/browse/TS-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15421580#comment-15421580
]
Quinn Lertratanakul commented on TS-4740:
-
Can someone direct me to where these checks should be made?
> Produce a warning if old metrics config is still in place
> -
>
> Key: TS-4740
> URL: https://issues.apache.org/jira/browse/TS-4740
> Project: Traffic Server
> Issue Type: Improvement
> Components: Metrics
>Reporter: Leif Hedstrom
> Labels: newbie
> Fix For: 7.0.0
>
>
> As of v7.0.0, the metrics config is migrated from XML to Lua. It might be
> nice that upon loading the Lua file, if it also sees the old XML file, it'd
> produce a warning. Something like
> {code}
> if (exists(stats.config.xml)) { /* Pseudo code, obviously do it right */
> Warning("Ignoring the old stats.config.xml configuration, loading
> metrics.config instead");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357225#comment-15357225 ] Quinn Lertratanakul commented on TS-4593: - Edited doc/admin-guide/files/ip_allow.config.en.rst to describe the added features. You can view it in this pull request: https://github.com/apache/trafficserver/pull/769. > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Assignee: Quinn Lertratanakul >Priority: Minor > Fix For: sometime > > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-4593 started by Quinn Lertratanakul. --- > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Assignee: Quinn Lertratanakul >Priority: Minor > Fix For: sometime > > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Lertratanakul updated TS-4593: Comment: was deleted (was: Assign to me please) > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Assignee: Quinn Lertratanakul >Priority: Minor > Fix For: sometime > > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Lertratanakul updated TS-4593: Assignee: Quinn Lertratanakul > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Assignee: Quinn Lertratanakul >Priority: Minor > Fix For: sometime > > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15351687#comment-15351687 ] Quinn Lertratanakul commented on TS-4593: - Assign to me please > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Priority: Minor > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Lertratanakul updated TS-4593: Issue Type: Improvement (was: Bug) > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Priority: Minor > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Lertratanakul updated TS-4593: Priority: Minor (was: Major) > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Quinn Lertratanakul >Priority: Minor > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4593) Extend ip_allow.config to filter destination IPs
Quinn Lertratanakul created TS-4593: --- Summary: Extend ip_allow.config to filter destination IPs Key: TS-4593 URL: https://issues.apache.org/jira/browse/TS-4593 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Quinn Lertratanakul We want to be able to block requests to IP ranges via ip_allow.config . For example, prevent ATS from remapping to origins with rfc1918 ips like 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
