[jira] [Created] (TS-2655) about traffic server clients prohibited by ip-allow policy log
skylander created TS-2655: - Summary: about traffic server clients prohibited by ip-allow policy log Key: TS-2655 URL: https://issues.apache.org/jira/browse/TS-2655 Project: Traffic Server Issue Type: Improvement Reporter: skylander 现在日志是写在了diags.log，不合理。 日志最好是能自己定义写到哪个目录，这样如果不想要这日志的，就可以写到/dev/null了。 如果实施起来很麻烦的话，也可以在日志目录下独立一个文件来存放这样的日志。如：var/log/trafficserver/ip_allow.log -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944781#comment-13944781
]
ASF subversion and git services commented on TS-2431:
-
Commit 829be64b45def63677c7d2320b3cf5f2a0a5e915 in trafficserver's branch
refs/heads/master from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=829be64 ]
Update CHANGES with TS-2431
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944797#comment-13944797 ] Yunkai Zhang commented on TS-2636: -- [~sudheerv]: Which ATS version does your patch based on? There is no *proxy/http/logging/* directory now, LogField.h is in *proxy/logging/* directory. Can you rebase your patch on ATS master branch? So that I can easy to review it. Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2636: -- Attachment: (was: ts2636.diff) Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2636: -- Attachment: ts2636.diff Corrected the patch file to reflect correct relative path Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945112#comment-13945112 ] Sudheer Vinukonda commented on TS-2636: --- Hi Yunkai Zhang, The patch is based off of apache master repo, but, I had put in an incorrect path (somehow, the diff command I use doesn't generate the correct path in the patch file and while manually editing the path, I made a mistake) My apologies for the mistake. The patch file has been corrected. Could you please review now? Regards, Sudheer Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: (was: ts2650.diff) Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Fix For: 5.0.0 Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945129#comment-13945129 ] Sudheer Vinukonda commented on TS-2650: --- Patch file updated to fix core dump issue - moved storing the origin connection hostname, scheme, port etc to before destroying origin, reset some of the old url stuff etc. Kindly review. Thanks! Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Fix For: 5.0.0 Attachments: ts2650.diff Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: ts2650.diff updated patch file..moved storing the origin connection hostname, scheme, port etc to before destroying origin, reset some of the old url stuff etc. Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Fix For: 5.0.0 Attachments: ts2650.diff Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2655) about traffic server clients prohibited by ip-allow policy log
[
https://issues.apache.org/jira/browse/TS-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945201#comment-13945201
]
James Peach commented on TS-2655:
-
I Google translated this. I believe that the issue [~skylander] is reporting is
that logging for the IP access control is done using {{diags.log}}, which is
not a good solution. These logs should use a separate log file which can
optionally be located in a separate directory. That would be consistent with
the way logging is done for other subsystems.
about traffic server clients prohibited by ip-allow policy log
--
Key: TS-2655
URL: https://issues.apache.org/jira/browse/TS-2655
Project: Traffic Server
Issue Type: Improvement
Reporter: skylander
现在日志是写在了diags.log，不合理。
日志最好是能自己定义写到哪个目录，这样如果不想要这日志的，就可以写到/dev/null了。
如果实施起来很麻烦的话，也可以在日志目录下独立一个文件来存放这样的日志。如：var/log/trafficserver/ip_allow.log
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2656) Add API to get/set the server connection scheme
Ron Barber created TS-2656:
--
Summary: Add API to get/set the server connection scheme
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to modify
the connection scheme after remapping (such as in the TS_EVENT_HTTP_OS_DNS
event) have no method to do so. I propose adding the following getter/setter
API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string, or
NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2656) Add API to get/set the server connection scheme
[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945293#comment-13945293
]
Leif Hedstrom commented on TS-2656:
---
I'm a little uneasy with this addition, perhaps because I don't understand the
use case, but my concerns include:
1. We now have a second API, that does almost exactly the same thing as the
existing API, but not quite the same. Confusion.
2. The internal state on the to URL is now not tracking the truth. I could
imagine someone logging the to URL, yet, the scheme is not correct. Confusion.
3. I can also imagine races / edge cases where things are not clear. For
example, what are the semantics if you call this API before remap ? What
happens if you call this API before the old API (TSUrlSchemeSet() )? Confusion.
Maybe if we could understand what problems are in the core, we can make
changes to it such that TSUrlSchemeSet() actually does what you expect ? Can we
defer setting sm-t_state.scheme ?
Cheers,
-- Leif
Add API to get/set the server connection scheme
---
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
Attachments: TS-2656.patch
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to
modify the connection scheme after remapping (such as in the
TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
following getter/setter API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string,
or NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2657) Eliminate TSHttpTxnSetHttpRetBody() and improve upon TSHttpTxnErrorBodySet()
[ https://issues.apache.org/jira/browse/TS-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2657: -- Attachment: TS-2657.diff Eliminate TSHttpTxnSetHttpRetBody() and improve upon TSHttpTxnErrorBodySet() Key: TS-2657 URL: https://issues.apache.org/jira/browse/TS-2657 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 Attachments: TS-2657.diff We currently have two APIs to set an “error” body. One was added at Yahoo many years ago, and it was done for the wrong reasons (premature optimization being one of them). I’ve made a patch that unifies these two APIs into one, such that you can use TSHttpTxnErrorBodySet() anywhere you could use either of those other two APIs. There are some subtle changes in how the APIs work, which I’ll describe here. 1. First, both TSHttpTxnSetHttpRetBody() and TSHttpTxnGetMaxHttpRetBodySize() are removed. I’ve patched all “core” plugins to use the TSHttpTxnErrorBodySet() API, but any non-Apache plugin would break. Hence, this change is going in for v5.0.0, which allows breaking compatibility. 2. More importantly, TSHttpTxnErrorBodySet() requires for the body to be heap allocated, whereas TSHttpTxnSetHttpRetBody() used a fixed size (2KB) array on the HttpSM. This was the primary reason why I started looking into this, since this “simple” change reduces the size of the HttpSM by 25%. 3. In order to make the TSHttpTxnErrorBodySet() API easier to use, I’ve changed the content type argument to not transfer ownership. The common (well, exclusive) pattern using this API used to be TSHttpTxnErrorBodySet(txnp, body, body_len, TSstrdup(“plain/html”)); This just seems like an overly generalized case, for a problem that doesn’t exist (clearly we can all manage some static strings ;). The new API is simply: TSHttpTxnErrorBodySet(txnp, body, body_len, “plain/html”); 4. The TSHttpTxnErrorBodySet() also imposes the body to be sent through the body factory, for log field expansion. For starters, this is incredibly inefficient , as well as imposing an 8KB size limit. This is something I intend to ameliorate soon by improvements to the body factory. However, this is an unnecessary inefficiency IMO; As part of the body factory improvements, I also plan on exposing the body factory “log field” expansion as a generic API. This would allow any plugin to decide if they want to go through the pains of body factory expansions or not (and not limited to just error pages, e.g. Header Rewrite would use this new API). So, I’d like to open this up for discussions and concerns. I think 3) and 4) are the primary candidates for concerns and objections. I’m willing to compromise either or both if there are major concerns (for example, is it worth the “cost” of changing the API in 3) ? I think it is, but I can easily be persuaded otherwise). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2657) Eliminate TSHttpTxnSetHttpRetBody() and improve upon TSHttpTxnErrorBodySet()
Leif Hedstrom created TS-2657: - Summary: Eliminate TSHttpTxnSetHttpRetBody() and improve upon TSHttpTxnErrorBodySet() Key: TS-2657 URL: https://issues.apache.org/jira/browse/TS-2657 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Leif Hedstrom We currently have two APIs to set an “error” body. One was added at Yahoo many years ago, and it was done for the wrong reasons (premature optimization being one of them). I’ve made a patch that unifies these two APIs into one, such that you can use TSHttpTxnErrorBodySet() anywhere you could use either of those other two APIs. There are some subtle changes in how the APIs work, which I’ll describe here. 1. First, both TSHttpTxnSetHttpRetBody() and TSHttpTxnGetMaxHttpRetBodySize() are removed. I’ve patched all “core” plugins to use the TSHttpTxnErrorBodySet() API, but any non-Apache plugin would break. Hence, this change is going in for v5.0.0, which allows breaking compatibility. 2. More importantly, TSHttpTxnErrorBodySet() requires for the body to be heap allocated, whereas TSHttpTxnSetHttpRetBody() used a fixed size (2KB) array on the HttpSM. This was the primary reason why I started looking into this, since this “simple” change reduces the size of the HttpSM by 25%. 3. In order to make the TSHttpTxnErrorBodySet() API easier to use, I’ve changed the content type argument to not transfer ownership. The common (well, exclusive) pattern using this API used to be TSHttpTxnErrorBodySet(txnp, body, body_len, TSstrdup(“plain/html”)); This just seems like an overly generalized case, for a problem that doesn’t exist (clearly we can all manage some static strings ;). The new API is simply: TSHttpTxnErrorBodySet(txnp, body, body_len, “plain/html”); 4. The TSHttpTxnErrorBodySet() also imposes the body to be sent through the body factory, for log field expansion. For starters, this is incredibly inefficient , as well as imposing an 8KB size limit. This is something I intend to ameliorate soon by improvements to the body factory. However, this is an unnecessary inefficiency IMO; As part of the body factory improvements, I also plan on exposing the body factory “log field” expansion as a generic API. This would allow any plugin to decide if they want to go through the pains of body factory expansions or not (and not limited to just error pages, e.g. Header Rewrite would use this new API). So, I’d like to open this up for discussions and concerns. I think 3) and 4) are the primary candidates for concerns and objections. I’m willing to compromise either or both if there are major concerns (for example, is it worth the “cost” of changing the API in 3) ? I think it is, but I can easily be persuaded otherwise). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945404#comment-13945404
]
Yunkai Zhang commented on TS-2636:
--
I like the idea of this patch, it would be helpful to protect user's privacy.
Here are my some advises:
1) There are some coding style problems, such as invalid tailling space, please
read ATS coding style:
https://cwiki.apache.org/confluence/display/TS/Coding+Style
2) write_this_entry() and toss_this_entry() share most common codes, we should
squash them. The same to __checkCondition() and _checkConditionAndWipe().
3) It seems that wipeField() only wipe URL parameters, renaming it to
wipeUrlParam() or other similar name would be better. Similarly, WIPE action
seems too general for this purpose, how about renaming it to WIPE_URL_PARAM?
4) Please don't forget to add some description in documents:
{{logs_xml.config.default}} and {{logs_xml.config.en.rst}}
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2656) Determine server connection scheme immedately before connecting.
[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945470#comment-13945470
]
Ron Barber commented on TS-2656:
Great points. After talking to Bryan, consider this instead:
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. {sm-t_state.scheme} is
evaluated immediately prior to establishing a new server connection to
determine if {sslNetProcessor.connect_re} or {netProcessor.connect_re} should
be called to setup the connection. Plugin's that desire to modify the
connection scheme after remapping (such as in the TS_EVENT_HTTP_OS_DNS event)
have no method to do so.
Rather than getter/setter functions that manipulate the scheme, modify ATS to
determine the connection scheme (based on server URL) immediately prior to
connecting. Here is the patch (needs more testing to make sure it doesn't
cause harm):
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index b314bc9..df86490 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -4653,7 +4653,15 @@ HttpSM::do_http_server_open(bool raw)
}
}
- if (t_state.scheme == URL_WKSIDX_HTTPS) {
+ int scheme_to_use;
+ if(!t_state.is_websocket) {
+// if not websocket, then get scheme from server request
+scheme_to_use =
t_state.hdr_info.server_request.url_get()-scheme_get_wksidx();
+ } else {
+// websockets set the scheme so use what was set
+scheme_to_use = t_state.scheme;
+ }
+ if (scheme_to_use == URL_WKSIDX_HTTPS) {
DebugSM(http, calling sslNetProcessor.connect_re);
connect_action_handle = sslNetProcessor.connect_re(this,// state
machine
t_state.current.server-addr.sa,// addr + port
{code}
Determine server connection scheme immedately before connecting.
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
Attachments: TS-2656.patch
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to
modify the connection scheme after remapping (such as in the
TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
following getter/setter API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string,
or NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2656) Determine server connection scheme immedately before connecting.
[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Barber updated TS-2656:
---
Summary: Determine server connection scheme immedately before connecting.
(was: Add API to get/set the server connection scheme)
Determine server connection scheme immedately before connecting.
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
Attachments: TS-2656.patch
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to
modify the connection scheme after remapping (such as in the
TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
following getter/setter API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string,
or NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2656) Determine server connection scheme immedately before connecting.
[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Barber updated TS-2656:
---
Attachment: (was: TS-2656.patch)
Determine server connection scheme immedately before connecting.
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to
modify the connection scheme after remapping (such as in the
TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
following getter/setter API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string,
or NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2656) Determine server connection scheme immedately before connecting.
[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945519#comment-13945519
]
Leif Hedstrom commented on TS-2656:
---
Nice! Yeah, I'm much more in favor of this, great job!
Determine server connection scheme immedately before connecting.
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to
modify the connection scheme after remapping (such as in the
TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
following getter/setter API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string,
or NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945546#comment-13945546 ] Leif Hedstrom commented on TS-2636: --- I'm not opposed to this, and I haven't looked at the code. But one concern is that it feels like we're trying to undo something that's been done before. To me, that ought to raise the question: Can we prevent it from doing it in the first place? For example, if the issue is to log a URL, but avoid logging the query parameters, why are there not log tags that lets you do that ? I.e. construct a log format which includes the scheme + host + URI path excluding not any query parameters. I *think* this would entail creating some new log tags, that excludes those components. Maybe this is not as generic as you want, but reading [~yunkai]'s review, it sounds like the patch only implements a wipeUrlParam feature. If that's the case, I can easily see us simply adding a new tag that is similar to the existing cquup / cqup log tags, but which eliminates the query parameters. Thoughts? Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945575#comment-13945575 ] Sudheer Vinukonda commented on TS-2636: --- Hi Yunkai Zhang and Leif, Thank you both for the feedback! Agree with all of Yunkai Zhang's comments - will update the patch accordingly and post it shortly. On Leif's feedback - Agree with the comment in general - however, the use case I am trying to address is a slightly more finer than wiping an entire part of the URL (e.g. query parameter). For instance, given the below URL, if someone wants to wipe the token parameter within this and retain and be able to view/log the rest of the query parameters https://abc.com/config/pwtoken_login?src=intellisynctoken=apachefoundationdotcom12345678910 it will turn to be something like the below: https://abc.com/config/pwtoken_login?src=intellisynctoken=yyyyZZy And needless to say, the specific parameter within the URL query will be different in each case and the enhancement aims to support a generic template to achieve this behavior. Additionally, the feature may be used as a framework and enhanced further to support other related use cases (such as, may be wiping non-query url parts). Please let me know what you think. Thanks again to both for the valuable feedback! Appreciate it much! Regards, Sudheer Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2656) Determine server connection scheme immediately before connecting.
[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Barber updated TS-2656:
---
Summary: Determine server connection scheme immediately before connecting.
(was: Determine server connection scheme immedately before connecting.)
Determine server connection scheme immediately before connecting.
-
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to
modify the connection scheme after remapping (such as in the
TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
following getter/setter API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string,
or NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2650: -- Assignee: Bryan Call Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Fix For: 5.0.0 Attachments: ts2650.diff Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945657#comment-13945657 ] Leif Hedstrom commented on TS-2650: --- Assigning to Bryan for reviews / shepherd . Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Fix For: 5.0.0 Attachments: ts2650.diff Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2656) Determine server connection scheme immediately before connecting.
[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Barber updated TS-2656:
---
Attachment: TS-2656_2.patch
Updated patch attached. I ran this for a short while, maybe 30 minutes, with
production traffic and didn't see any differences as compared to another
production server running an older version.
Determine server connection scheme immediately before connecting.
-
Key: TS-2656
URL: https://issues.apache.org/jira/browse/TS-2656
Project: Traffic Server
Issue Type: Improvement
Reporter: Ron Barber
Attachments: TS-2656_2.patch
ATS currently sets the server connection scheme (sm-t_state.scheme) after
remapping has occurred based on the server URL. Plugin's that desire to
modify the connection scheme after remapping (such as in the
TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
following getter/setter API functions:
{code}
/**
Retrieves the server connection scheme for the specified
transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
the string in the length argument. If the length is NULL then no
attempt is made to dereference it.
@note This function is useful if the server connection scheme needs to
retrieved post remapping.
@param txnp The transaction whose connection scheme to be retrieved
@param length length of the returned string.
@return The connection scheme for the server connection, as a string,
or NULL if not set.
*/
tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
/** Set the connection scheme to the server (http or https) for the
specified transaction @a txnp to the string value. If length is -1
then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
Otherwise, the length of the string value is taken to be length.
@note This function is useful if the server connection scheme needs to
change post remapping.
@param txnp The transaction whose connection scheme to be set
@param value value to set the scheme to.
@param length string stored in value.
@return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
*/
tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
const char* value,
int length);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: (was: ts2650.diff) Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Fix For: 5.0.0 Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: ts2650.diff - This patch also fixes a bug in handling a 302 redirection from http to https location. ATS had been incorrectly using the cached port when a 302 is received which results in sending a https request on a non-https port. Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Fix For: 5.0.0 Attachments: ts2650.diff Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-110) Improve regex remap to allow substitutions in path field
[ https://issues.apache.org/jira/browse/TS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-110: --- Assignee: Brian Geffon Improve regex remap to allow substitutions in path field Key: TS-110 URL: https://issues.apache.org/jira/browse/TS-110 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.0.0 Reporter: Manjesh Nilange Assignee: Brian Geffon Priority: Minor Fix For: 5.3.0 Currently, regex support covers only the host field of the remap rules. It'd be nice to extend this to allow substitutions into the path field as well. This will allow rules like: regex_map http://www.example-(.*).com/ http://real-example.com/$1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2633) 406 negative responses being cached for too long
[ https://issues.apache.org/jira/browse/TS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2633: -- Attachment: (was: ts2633.diff) 406 negative responses being cached for too long Key: TS-2633 URL: https://issues.apache.org/jira/browse/TS-2633 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2 Reporter: David Carlin Assignee: Bryan Call Fix For: 5.0.0 Settings: proxy.config.http.negative_caching_enabled = 1 proxy.config.http.negative_caching_lifetime = 500 406 response is being cached, but lifetime isn't being adhered to. They are cached for much longer, perhaps indefinitely. I have seen Age: increase to several hours. With proxy.config.http.negative_caching_enabled = 0 then 406 responses are not cached. Bryan pointed out that the docs don't list 406 as one of the cached negative responses: http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2633) 406 negative responses being cached for too long
[ https://issues.apache.org/jira/browse/TS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945806#comment-13945806 ] Sudheer Vinukonda commented on TS-2633: --- the above fix is incorrect. Will submit a new fix after more careful analysis 406 negative responses being cached for too long Key: TS-2633 URL: https://issues.apache.org/jira/browse/TS-2633 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2 Reporter: David Carlin Assignee: Bryan Call Fix For: 5.0.0 Settings: proxy.config.http.negative_caching_enabled = 1 proxy.config.http.negative_caching_lifetime = 500 406 response is being cached, but lifetime isn't being adhered to. They are cached for much longer, perhaps indefinitely. I have seen Age: increase to several hours. With proxy.config.http.negative_caching_enabled = 0 then 406 responses are not cached. Bryan pointed out that the docs don't list 406 as one of the cached negative responses: http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2658) debug logging for SSL certificates
[ https://issues.apache.org/jira/browse/TS-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2658: Priority: Minor (was: Major) Fix Version/s: 5.0.0 Assignee: James Peach debug logging for SSL certificates -- Key: TS-2658 URL: https://issues.apache.org/jira/browse/TS-2658 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 5.0.0 After debugging SSL client authentication issues recently, it would be useful to have some additional debug logging of SSL certificates that are accepted or presented at SSL handshake time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2658) debug logging for SSL certificates
James Peach created TS-2658: --- Summary: debug logging for SSL certificates Key: TS-2658 URL: https://issues.apache.org/jira/browse/TS-2658 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach After debugging SSL client authentication issues recently, it would be useful to have some additional debug logging of SSL certificates that are accepted or presented at SSL handshake time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945835#comment-13945835 ] ASF GitHub Bot commented on TS-2497: GitHub user jacksontj opened a pull request: https://github.com/apache/trafficserver/pull/66 Change default to keep_alive_post_out Keepalive post out used to cause issues, but we have since found and fixed the root cause (TS-2497) and we are now running this on in production. This entire feature should be cleaned out-- since it was created to workaround this problem that is now fixed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jacksontj/trafficserver master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/66.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #66 commit e210eb0a35452215c3da9cd32ff916128c73f80f Author: Thomas Jackson jacksontj...@gmail.com Date: 2014-03-24T23:01:21Z Keepalive post out used to cause issues, but we have since found and fixed the root cause (TS-2497) and we are now running this on in production. This entire feature should be cleaned out-- since it was created to workaround this problem that is now fixed. Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.1.3, 4.2.0 When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal (this=0x2aab38001130, b=0x2aab0c037200) at ../iocore/eventsystem/P_IOBuffer.h:946 #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:994 #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1002 #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1048 #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 #7 0x006c37bf in UnixNetVConnection::net_read_io (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at UnixNetVConnection.cc:816 #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, event=5, e=0x271d8e0) at UnixNet.cc:380 #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at UnixEThread.cc:264 #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2658) debug logging for SSL certificates
[ https://issues.apache.org/jira/browse/TS-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945855#comment-13945855 ] ASF subversion and git services commented on TS-2658: - Commit 7d3f9c82e32032540908b4413c252c58e87d128c in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7d3f9c8 ] TS-2658: additional SSL certificate logging After a successful SSL handshake, log the peer certificate to the debug log. This is useful for debugging SSL certificate authentication and other SSL connection issues. debug logging for SSL certificates -- Key: TS-2658 URL: https://issues.apache.org/jira/browse/TS-2658 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 5.0.0 After debugging SSL client authentication issues recently, it would be useful to have some additional debug logging of SSL certificates that are accepted or presented at SSL handshake time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2658) debug logging for SSL certificates
[ https://issues.apache.org/jira/browse/TS-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2658. - Resolution: Fixed debug logging for SSL certificates -- Key: TS-2658 URL: https://issues.apache.org/jira/browse/TS-2658 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 5.0.0 After debugging SSL client authentication issues recently, it would be useful to have some additional debug logging of SSL certificates that are accepted or presented at SSL handshake time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2659) rename state machine actions for consistency
James Peach created TS-2659:
---
Summary: rename state machine actions for consistency
Key: TS-2659
URL: https://issues.apache.org/jira/browse/TS-2659
Project: Traffic Server
Issue Type: Bug
Reporter: James Peach
the value
{code}
enum StateMachineAction_t
{
SM_ACTION_UNDEFINED = 0,
// SM_ACTION_AUTH_LOOKUP,
SM_ACTION_DNS_LOOKUP,
SM_ACTION_DNS_REVERSE_LOOKUP,
SM_ACTION_CACHE_LOOKUP,
SM_ACTION_CACHE_ISSUE_WRITE,
SM_ACTION_CACHE_ISSUE_WRITE_TRANSFORM,
SM_ACTION_CACHE_PREPARE_UPDATE,
SM_ACTION_CACHE_ISSUE_UPDATE,
SM_ACTION_ICP_QUERY,
SM_ACTION_ORIGIN_SERVER_OPEN,
SM_ACTION_ORIGIN_SERVER_RAW_OPEN,
SM_ACTION_ORIGIN_SERVER_RR_MARK_DOWN,
SM_ACTION_READ_PUSH_HDR,
SM_ACTION_STORE_PUSH_BODY,
SM_ACTION_INTERNAL_CACHE_DELETE,
SM_ACTION_INTERNAL_CACHE_NOOP,
SM_ACTION_INTERNAL_CACHE_UPDATE_HEADERS,
SM_ACTION_INTERNAL_CACHE_WRITE,
SM_ACTION_INTERNAL_100_RESPONSE,
SM_ACTION_INTERNAL_REQUEST,
SM_ACTION_SEND_ERROR_CACHE_NOOP,
#ifdef PROXY_DRAIN
SM_ACTION_DRAIN_REQUEST_BODY,
#endif /* PROXY_DRAIN */
SM_ACTION_SERVE_FROM_CACHE,
SM_ACTION_SERVER_READ,
SM_ACTION_SERVER_PARSE_NEXT_HDR,
SM_ACTION_TRANSFORM_READ,
SM_ACTION_SSL_TUNNEL,
SM_ACTION_CONTINUE,
SM_ACTION_API_SM_START,
SM_ACTION_API_READ_REQUEST_HDR,
SM_ACTION_API_PRE_REMAP,
SM_ACTION_API_POST_REMAP,
SM_ACTION_API_OS_DNS,
SM_ACTION_API_SEND_REQUEST_HDR,
SM_ACTION_API_READ_CACHE_HDR,
SM_ACTION_API_CACHE_LOOKUP_COMPLETE,
SM_ACTION_API_READ_RESPONSE_HDR,
SM_ACTION_API_SEND_RESPONSE_HDR,
SM_ACTION_API_SM_SHUTDOWN,
SM_ACTION_REMAP_REQUEST,
SM_ACTION_POST_REMAP_SKIP,
SM_ACTION_REDIRECT_READ
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2660) rename state machine action values
James Peach created TS-2660:
---
Summary: rename state machine action values
Key: TS-2660
URL: https://issues.apache.org/jira/browse/TS-2660
Project: Traffic Server
Issue Type: Bug
Components: Cleanup
Reporter: James Peach
The values of {{StateMachineAction_t}} do not adhere to any naming convention,
making them hard to recognize and find in code. We should apply a naming
convention and remove unused values.
The patch I have ends up with this set of values:
{code}
SM_ACTION_UNDEFINED = 0,
// SM_ACTION_AUTH_LOOKUP,
SM_ACTION_DNS_LOOKUP,
SM_ACTION_DNS_REVERSE_LOOKUP,
SM_ACTION_CACHE_LOOKUP,
SM_ACTION_CACHE_ISSUE_WRITE,
SM_ACTION_CACHE_ISSUE_WRITE_TRANSFORM,
SM_ACTION_CACHE_PREPARE_UPDATE,
SM_ACTION_CACHE_ISSUE_UPDATE,
SM_ACTION_ICP_QUERY,
SM_ACTION_ORIGIN_SERVER_OPEN,
SM_ACTION_ORIGIN_SERVER_RAW_OPEN,
SM_ACTION_ORIGIN_SERVER_RR_MARK_DOWN,
SM_ACTION_READ_PUSH_HDR,
SM_ACTION_STORE_PUSH_BODY,
SM_ACTION_INTERNAL_CACHE_DELETE,
SM_ACTION_INTERNAL_CACHE_NOOP,
SM_ACTION_INTERNAL_CACHE_UPDATE_HEADERS,
SM_ACTION_INTERNAL_CACHE_WRITE,
SM_ACTION_INTERNAL_100_RESPONSE,
SM_ACTION_INTERNAL_REQUEST,
SM_ACTION_SEND_ERROR_CACHE_NOOP,
#ifdef PROXY_DRAIN
SM_ACTION_DRAIN_REQUEST_BODY,
#endif /* PROXY_DRAIN */
SM_ACTION_SERVE_FROM_CACHE,
SM_ACTION_SERVER_READ,
SM_ACTION_SERVER_PARSE_NEXT_HDR,
SM_ACTION_TRANSFORM_READ,
SM_ACTION_SSL_TUNNEL,
SM_ACTION_CONTINUE,
SM_ACTION_API_SM_START,
SM_ACTION_API_READ_REQUEST_HDR,
SM_ACTION_API_PRE_REMAP,
SM_ACTION_API_POST_REMAP,
SM_ACTION_API_OS_DNS,
SM_ACTION_API_SEND_REQUEST_HDR,
SM_ACTION_API_READ_CACHE_HDR,
SM_ACTION_API_CACHE_LOOKUP_COMPLETE,
SM_ACTION_API_READ_RESPONSE_HDR,
SM_ACTION_API_SEND_RESPONSE_HDR,
SM_ACTION_API_SM_SHUTDOWN,
SM_ACTION_REMAP_REQUEST,
SM_ACTION_POST_REMAP_SKIP,
SM_ACTION_REDIRECT_READ
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2660) rename state machine action values
[
https://issues.apache.org/jira/browse/TS-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945900#comment-13945900
]
James Peach commented on TS-2660:
-
[~zwoop], [~amc], [~bcall] Are you all OK with this?
rename state machine action values
--
Key: TS-2660
URL: https://issues.apache.org/jira/browse/TS-2660
Project: Traffic Server
Issue Type: Bug
Components: Cleanup
Reporter: James Peach
Labels: Review
The values of {{StateMachineAction_t}} do not adhere to any naming
convention, making them hard to recognize and find in code. We should apply a
naming convention and remove unused values.
The patch I have ends up with this set of values:
{code}
SM_ACTION_UNDEFINED = 0,
// SM_ACTION_AUTH_LOOKUP,
SM_ACTION_DNS_LOOKUP,
SM_ACTION_DNS_REVERSE_LOOKUP,
SM_ACTION_CACHE_LOOKUP,
SM_ACTION_CACHE_ISSUE_WRITE,
SM_ACTION_CACHE_ISSUE_WRITE_TRANSFORM,
SM_ACTION_CACHE_PREPARE_UPDATE,
SM_ACTION_CACHE_ISSUE_UPDATE,
SM_ACTION_ICP_QUERY,
SM_ACTION_ORIGIN_SERVER_OPEN,
SM_ACTION_ORIGIN_SERVER_RAW_OPEN,
SM_ACTION_ORIGIN_SERVER_RR_MARK_DOWN,
SM_ACTION_READ_PUSH_HDR,
SM_ACTION_STORE_PUSH_BODY,
SM_ACTION_INTERNAL_CACHE_DELETE,
SM_ACTION_INTERNAL_CACHE_NOOP,
SM_ACTION_INTERNAL_CACHE_UPDATE_HEADERS,
SM_ACTION_INTERNAL_CACHE_WRITE,
SM_ACTION_INTERNAL_100_RESPONSE,
SM_ACTION_INTERNAL_REQUEST,
SM_ACTION_SEND_ERROR_CACHE_NOOP,
#ifdef PROXY_DRAIN
SM_ACTION_DRAIN_REQUEST_BODY,
#endif /* PROXY_DRAIN */
SM_ACTION_SERVE_FROM_CACHE,
SM_ACTION_SERVER_READ,
SM_ACTION_SERVER_PARSE_NEXT_HDR,
SM_ACTION_TRANSFORM_READ,
SM_ACTION_SSL_TUNNEL,
SM_ACTION_CONTINUE,
SM_ACTION_API_SM_START,
SM_ACTION_API_READ_REQUEST_HDR,
SM_ACTION_API_PRE_REMAP,
SM_ACTION_API_POST_REMAP,
SM_ACTION_API_OS_DNS,
SM_ACTION_API_SEND_REQUEST_HDR,
SM_ACTION_API_READ_CACHE_HDR,
SM_ACTION_API_CACHE_LOOKUP_COMPLETE,
SM_ACTION_API_READ_RESPONSE_HDR,
SM_ACTION_API_SEND_RESPONSE_HDR,
SM_ACTION_API_SM_SHUTDOWN,
SM_ACTION_REMAP_REQUEST,
SM_ACTION_POST_REMAP_SKIP,
SM_ACTION_REDIRECT_READ
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2660) rename state machine action values
[
https://issues.apache.org/jira/browse/TS-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2660:
Priority: Minor (was: Major)
Fix Version/s: 5.0.0
Assignee: James Peach
rename state machine action values
--
Key: TS-2660
URL: https://issues.apache.org/jira/browse/TS-2660
Project: Traffic Server
Issue Type: Bug
Components: Cleanup
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Labels: Review
Fix For: 5.0.0
The values of {{StateMachineAction_t}} do not adhere to any naming
convention, making them hard to recognize and find in code. We should apply a
naming convention and remove unused values.
The patch I have ends up with this set of values:
{code}
SM_ACTION_UNDEFINED = 0,
// SM_ACTION_AUTH_LOOKUP,
SM_ACTION_DNS_LOOKUP,
SM_ACTION_DNS_REVERSE_LOOKUP,
SM_ACTION_CACHE_LOOKUP,
SM_ACTION_CACHE_ISSUE_WRITE,
SM_ACTION_CACHE_ISSUE_WRITE_TRANSFORM,
SM_ACTION_CACHE_PREPARE_UPDATE,
SM_ACTION_CACHE_ISSUE_UPDATE,
SM_ACTION_ICP_QUERY,
SM_ACTION_ORIGIN_SERVER_OPEN,
SM_ACTION_ORIGIN_SERVER_RAW_OPEN,
SM_ACTION_ORIGIN_SERVER_RR_MARK_DOWN,
SM_ACTION_READ_PUSH_HDR,
SM_ACTION_STORE_PUSH_BODY,
SM_ACTION_INTERNAL_CACHE_DELETE,
SM_ACTION_INTERNAL_CACHE_NOOP,
SM_ACTION_INTERNAL_CACHE_UPDATE_HEADERS,
SM_ACTION_INTERNAL_CACHE_WRITE,
SM_ACTION_INTERNAL_100_RESPONSE,
SM_ACTION_INTERNAL_REQUEST,
SM_ACTION_SEND_ERROR_CACHE_NOOP,
#ifdef PROXY_DRAIN
SM_ACTION_DRAIN_REQUEST_BODY,
#endif /* PROXY_DRAIN */
SM_ACTION_SERVE_FROM_CACHE,
SM_ACTION_SERVER_READ,
SM_ACTION_SERVER_PARSE_NEXT_HDR,
SM_ACTION_TRANSFORM_READ,
SM_ACTION_SSL_TUNNEL,
SM_ACTION_CONTINUE,
SM_ACTION_API_SM_START,
SM_ACTION_API_READ_REQUEST_HDR,
SM_ACTION_API_PRE_REMAP,
SM_ACTION_API_POST_REMAP,
SM_ACTION_API_OS_DNS,
SM_ACTION_API_SEND_REQUEST_HDR,
SM_ACTION_API_READ_CACHE_HDR,
SM_ACTION_API_CACHE_LOOKUP_COMPLETE,
SM_ACTION_API_READ_RESPONSE_HDR,
SM_ACTION_API_SEND_RESPONSE_HDR,
SM_ACTION_API_SM_SHUTDOWN,
SM_ACTION_REMAP_REQUEST,
SM_ACTION_POST_REMAP_SKIP,
SM_ACTION_REDIRECT_READ
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945995#comment-13945995 ] Sudheer Vinukonda commented on TS-2650: --- Hi Leif - I've not opened a separate bug for the https--http redirect issue. I ran into that bug this morning and since the bug/fix is all around the same place and of the same type, thought of combining both issues together. Please let me know if you would like a separate jira for this issue. Will be happy to open a new one.Thanks! Support relative url in the location header in 302 redirection --- Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Fix For: 5.0.0 Attachments: ts2650.diff Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2660) rename state machine action values
[
https://issues.apache.org/jira/browse/TS-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946017#comment-13946017
]
Leif Hedstrom commented on TS-2660:
---
No objections.
rename state machine action values
--
Key: TS-2660
URL: https://issues.apache.org/jira/browse/TS-2660
Project: Traffic Server
Issue Type: Bug
Components: Cleanup
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Labels: Review
Fix For: 5.0.0
The values of {{StateMachineAction_t}} do not adhere to any naming
convention, making them hard to recognize and find in code. We should apply a
naming convention and remove unused values.
The patch I have ends up with this set of values:
{code}
SM_ACTION_UNDEFINED = 0,
// SM_ACTION_AUTH_LOOKUP,
SM_ACTION_DNS_LOOKUP,
SM_ACTION_DNS_REVERSE_LOOKUP,
SM_ACTION_CACHE_LOOKUP,
SM_ACTION_CACHE_ISSUE_WRITE,
SM_ACTION_CACHE_ISSUE_WRITE_TRANSFORM,
SM_ACTION_CACHE_PREPARE_UPDATE,
SM_ACTION_CACHE_ISSUE_UPDATE,
SM_ACTION_ICP_QUERY,
SM_ACTION_ORIGIN_SERVER_OPEN,
SM_ACTION_ORIGIN_SERVER_RAW_OPEN,
SM_ACTION_ORIGIN_SERVER_RR_MARK_DOWN,
SM_ACTION_READ_PUSH_HDR,
SM_ACTION_STORE_PUSH_BODY,
SM_ACTION_INTERNAL_CACHE_DELETE,
SM_ACTION_INTERNAL_CACHE_NOOP,
SM_ACTION_INTERNAL_CACHE_UPDATE_HEADERS,
SM_ACTION_INTERNAL_CACHE_WRITE,
SM_ACTION_INTERNAL_100_RESPONSE,
SM_ACTION_INTERNAL_REQUEST,
SM_ACTION_SEND_ERROR_CACHE_NOOP,
#ifdef PROXY_DRAIN
SM_ACTION_DRAIN_REQUEST_BODY,
#endif /* PROXY_DRAIN */
SM_ACTION_SERVE_FROM_CACHE,
SM_ACTION_SERVER_READ,
SM_ACTION_SERVER_PARSE_NEXT_HDR,
SM_ACTION_TRANSFORM_READ,
SM_ACTION_SSL_TUNNEL,
SM_ACTION_CONTINUE,
SM_ACTION_API_SM_START,
SM_ACTION_API_READ_REQUEST_HDR,
SM_ACTION_API_PRE_REMAP,
SM_ACTION_API_POST_REMAP,
SM_ACTION_API_OS_DNS,
SM_ACTION_API_SEND_REQUEST_HDR,
SM_ACTION_API_READ_CACHE_HDR,
SM_ACTION_API_CACHE_LOOKUP_COMPLETE,
SM_ACTION_API_READ_RESPONSE_HDR,
SM_ACTION_API_SEND_RESPONSE_HDR,
SM_ACTION_API_SM_SHUTDOWN,
SM_ACTION_REMAP_REQUEST,
SM_ACTION_POST_REMAP_SKIP,
SM_ACTION_REDIRECT_READ
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2660) rename state machine action values
[
https://issues.apache.org/jira/browse/TS-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946017#comment-13946017
]
Leif Hedstrom edited comment on TS-2660 at 3/25/14 1:58 AM:
No objections. You are updating the HttpDebugNames too ?
was (Author: zwoop):
No objections.
rename state machine action values
--
Key: TS-2660
URL: https://issues.apache.org/jira/browse/TS-2660
Project: Traffic Server
Issue Type: Bug
Components: Cleanup
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Labels: Review
Fix For: 5.0.0
The values of {{StateMachineAction_t}} do not adhere to any naming
convention, making them hard to recognize and find in code. We should apply a
naming convention and remove unused values.
The patch I have ends up with this set of values:
{code}
SM_ACTION_UNDEFINED = 0,
// SM_ACTION_AUTH_LOOKUP,
SM_ACTION_DNS_LOOKUP,
SM_ACTION_DNS_REVERSE_LOOKUP,
SM_ACTION_CACHE_LOOKUP,
SM_ACTION_CACHE_ISSUE_WRITE,
SM_ACTION_CACHE_ISSUE_WRITE_TRANSFORM,
SM_ACTION_CACHE_PREPARE_UPDATE,
SM_ACTION_CACHE_ISSUE_UPDATE,
SM_ACTION_ICP_QUERY,
SM_ACTION_ORIGIN_SERVER_OPEN,
SM_ACTION_ORIGIN_SERVER_RAW_OPEN,
SM_ACTION_ORIGIN_SERVER_RR_MARK_DOWN,
SM_ACTION_READ_PUSH_HDR,
SM_ACTION_STORE_PUSH_BODY,
SM_ACTION_INTERNAL_CACHE_DELETE,
SM_ACTION_INTERNAL_CACHE_NOOP,
SM_ACTION_INTERNAL_CACHE_UPDATE_HEADERS,
SM_ACTION_INTERNAL_CACHE_WRITE,
SM_ACTION_INTERNAL_100_RESPONSE,
SM_ACTION_INTERNAL_REQUEST,
SM_ACTION_SEND_ERROR_CACHE_NOOP,
#ifdef PROXY_DRAIN
SM_ACTION_DRAIN_REQUEST_BODY,
#endif /* PROXY_DRAIN */
SM_ACTION_SERVE_FROM_CACHE,
SM_ACTION_SERVER_READ,
SM_ACTION_SERVER_PARSE_NEXT_HDR,
SM_ACTION_TRANSFORM_READ,
SM_ACTION_SSL_TUNNEL,
SM_ACTION_CONTINUE,
SM_ACTION_API_SM_START,
SM_ACTION_API_READ_REQUEST_HDR,
SM_ACTION_API_PRE_REMAP,
SM_ACTION_API_POST_REMAP,
SM_ACTION_API_OS_DNS,
SM_ACTION_API_SEND_REQUEST_HDR,
SM_ACTION_API_READ_CACHE_HDR,
SM_ACTION_API_CACHE_LOOKUP_COMPLETE,
SM_ACTION_API_READ_RESPONSE_HDR,
SM_ACTION_API_SEND_RESPONSE_HDR,
SM_ACTION_API_SM_SHUTDOWN,
SM_ACTION_REMAP_REQUEST,
SM_ACTION_POST_REMAP_SKIP,
SM_ACTION_REDIRECT_READ
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946133#comment-13946133
]
Yunkai Zhang commented on TS-2636:
--
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(filed, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946133#comment-13946133
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 4:02 AM:
---
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
%WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
was (Author: yunkai):
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946133#comment-13946133
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 4:01 AM:
---
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
was (Author: yunkai):
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(filed, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
