[jira] [Commented] (TS-3960) traffic_line -x doesn't reload SSL certs content

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058270#comment-15058270
 ] 

ASF subversion and git services commented on TS-3960:
-

Commit c9b2241c4faf4dbb2a706cf7d7e169252b14a3ed in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c9b2241 ]

TS-3960: fix a couple of merge errors


> traffic_line -x doesn't reload SSL certs content
> 
>
> Key: TS-3960
> URL: https://issues.apache.org/jira/browse/TS-3960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Zhang Zizhong
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> traffic_line -x doesn't reload  when SSL certs change file contents without 
> changing the file names.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3960) traffic_line -x doesn't reload SSL certs content

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058271#comment-15058271
 ] 

ASF GitHub Bot commented on TS-3960:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/301#issuecomment-164817652
  
Thanks @zizhong 


> traffic_line -x doesn't reload SSL certs content
> 
>
> Key: TS-3960
> URL: https://issues.apache.org/jira/browse/TS-3960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Zhang Zizhong
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> traffic_line -x doesn't reload  when SSL certs change file contents without 
> changing the file names.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4078) CID 1343334: Uninitialized members in Rollback.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4078:
--
Fix Version/s: 6.1.0

> CID 1343334:  Uninitialized members in Rollback.cc
> --
>
> Key: TS-4078
> URL: https://issues.apache.org/jira/browse/TS-4078
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {code}
> ** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 
> *** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 95 
> 96   // If we are not doing backups, bail early.
> 97   if ((numberBackups <= 0) || (flags & CONFIG_FLAG_UNVERSIONED)) {
> 98 currentVersion = 0;
> 99 setLastModifiedTime();
> 100 numberBackups = 0;
>CID 1343334:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "numVersions" is not initialized in this 
> constructor nor in any functions that it calls.
> 101 return;
> 102   }
> 103 
> 104   currentVersion = 0; // Prevent UMR with stat file
> 105   highestSeen = findVersions_ml(versionQ);
> 106 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4078) CID 1343334: Uninitialized members in Rollback.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4078:
--
Assignee: Zhang Zizhong

> CID 1343334:  Uninitialized members in Rollback.cc
> --
>
> Key: TS-4078
> URL: https://issues.apache.org/jira/browse/TS-4078
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Zhang Zizhong
> Fix For: 6.1.0
>
>
> {code}
> ** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 
> *** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 95 
> 96   // If we are not doing backups, bail early.
> 97   if ((numberBackups <= 0) || (flags & CONFIG_FLAG_UNVERSIONED)) {
> 98 currentVersion = 0;
> 99 setLastModifiedTime();
> 100 numberBackups = 0;
>CID 1343334:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "numVersions" is not initialized in this 
> constructor nor in any functions that it calls.
> 101 return;
> 102   }
> 103 
> 104   currentVersion = 0; // Prevent UMR with stat file
> 105   highestSeen = findVersions_ml(versionQ);
> 106 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058683#comment-15058683
 ] 

ASF subversion and git services commented on TS-4030:
-

Commit bf04f7fe5aefe570f60e8de3a054fd49bd4f117c in trafficserver's branch 
refs/heads/master from John J. Rushford
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bf04f7f ]

TS-4030: Fixed a regression test failure

In FindParent(), ParentResult::start_parent was not initialized properly.


> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4078) CID 1343334: Uninitialized members in Rollback.cc

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058693#comment-15058693
 ] 

Leif Hedstrom commented on TS-4078:
---

[~zhangzizhong] Can you take a look at this please? I think this is related to 
TS-3960.

Thanks!

-- leif


> CID 1343334:  Uninitialized members in Rollback.cc
> --
>
> Key: TS-4078
> URL: https://issues.apache.org/jira/browse/TS-4078
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Zhang Zizhong
> Fix For: 6.1.0
>
>
> {code}
> ** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 
> *** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 95 
> 96   // If we are not doing backups, bail early.
> 97   if ((numberBackups <= 0) || (flags & CONFIG_FLAG_UNVERSIONED)) {
> 98 currentVersion = 0;
> 99 setLastModifiedTime();
> 100 numberBackups = 0;
>CID 1343334:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "numVersions" is not initialized in this 
> constructor nor in any functions that it calls.
> 101 return;
> 102   }
> 103 
> 104   currentVersion = 0; // Prevent UMR with stat file
> 105   highestSeen = findVersions_ml(versionQ);
> 106 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4078) CID 1343334: Uninitialized members in Rollback.cc

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4078:
-

 Summary: CID 1343334:  Uninitialized members in Rollback.cc
 Key: TS-4078
 URL: https://issues.apache.org/jira/browse/TS-4078
 Project: Traffic Server
  Issue Type: Bug
  Components: Management API
Reporter: Leif Hedstrom


{code}
** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
/mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
unsigned int)()



*** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
/mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
unsigned int)()
95 
96   // If we are not doing backups, bail early.
97   if ((numberBackups <= 0) || (flags & CONFIG_FLAG_UNVERSIONED)) {
98 currentVersion = 0;
99 setLastModifiedTime();
100 numberBackups = 0;
   CID 1343334:  Uninitialized members  (UNINIT_CTOR)
   Non-static class member "numVersions" is not initialized in this constructor 
nor in any functions that it calls.
101 return;
102   }
103 
104   currentVersion = 0; // Prevent UMR with stat file
105   highestSeen = findVersions_ml(versionQ);
106 

{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058661#comment-15058661
 ] 

ASF GitHub Bot commented on TS-4030:


GitHub user jrushf1239k opened a pull request:

https://github.com/apache/trafficserver/pull/377

TS-4030: Fixed a regression test failure.  

Fix a bug found with regression tests.  ParentResult::start_parent was not 
initialized in FindParent() when  using strict round robin in a parent 
configuration.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jrushf1239k/trafficserver ts4030

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/377.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 #377


commit 4e4f35d4fc579e3b9e75177e9deef37def3f1fd7
Author: John J. Rushford 
Date:   2015-12-15T19:49:36Z

TS-4030: Fixed a regression test failure.  In FindParent(), 
ParentResult::start_parent was not initialized properly.




> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058742#comment-15058742
 ] 

ASF GitHub Bot commented on TS-4030:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/377#issuecomment-164888496
  
+1


> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4080) Lua Ability return parent proxy

[Faysal Banna (JIRA)]

Faysal Banna created TS-4080:


 Summary: Lua Ability return parent proxy 
 Key: TS-4080
 URL: https://issues.apache.org/jira/browse/TS-4080
 Project: Traffic Server
  Issue Type: Wish
  Components: Lua, Parent Proxy
Reporter: Faysal Banna


Good day sir.
is it possible add a functionality to lua extension so that the request be 
supplied to parent proxy ; add a directive to explicitly service the request 
being examined in lua script to go through a parent proxy whenever possible ? 

something like ts_parent_proxy="x.y.z.c:8080" 

much regards 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4079) Support for arbitrary esi vars through HTTP request headers

[Sandeep Davu (JIRA)]

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

Sandeep Davu updated TS-4079:
-
   Priority: Minor  (was: Major)
Description: 
Variables in ESI have to be predefined. This feature extends the variables to 
be any on the request headers. Stored as a dictionary.

Variables may be accessed  $(HTTP_HEADER{HDR_NAME}) .


  was:
Variables in ESI have to be predefined. This feature extends the variables to 
be any on the request headers. Stored as a dictionary.

Variables may be accessed $(HTTP_HEADER{HDR_NAME}).


Component/s: Plugins

> Support for arbitrary esi vars through HTTP request headers
> ---
>
> Key: TS-4079
> URL: https://issues.apache.org/jira/browse/TS-4079
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Sandeep Davu
>Priority: Minor
>
> Variables in ESI have to be predefined. This feature extends the variables to 
> be any on the request headers. Stored as a dictionary.
> Variables may be accessed  $(HTTP_HEADER{HDR_NAME}) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4080) Lua Ability return parent proxy

[Kit Chan (JIRA)]

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

Kit Chan reassigned TS-4080:


Assignee: Kit Chan

> Lua Ability return parent proxy 
> 
>
> Key: TS-4080
> URL: https://issues.apache.org/jira/browse/TS-4080
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Lua, Parent Proxy
>Reporter: Faysal Banna
>Assignee: Kit Chan
>
> Good day sir.
> is it possible add a functionality to lua extension so that the request be 
> supplied to parent proxy ; add a directive to explicitly service the request 
> being examined in lua script to go through a parent proxy whenever possible ? 
> something like ts_parent_proxy="x.y.z.c:8080" 
> much regards 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3941) Make DUMP_HEADER be a TXN debug as enabled with TSHttpTxnDebugSet()

[Uri Shachar (JIRA)]

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

Uri Shachar updated TS-3941:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Make DUMP_HEADER be a TXN debug as enabled with TSHttpTxnDebugSet()
> ---
>
> Key: TS-3941
> URL: https://issues.apache.org/jira/browse/TS-3941
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Uri Shachar
> Fix For: 6.2.0
>
>
> Today, we use DUMP_HEADER (a macro) to dump out very useful information out 
> of transactions. However, DUMP_HEADER uses printf(), which is, hem, 
> unorthodox. It'd be better if we could change this such that it uses 
> DebugTxn(). The only concern here is that it still has to retain the same 
> performance characteristics (in particular, it can not be slower in the case 
> where diagnostics are not enabled).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3609) Upstream cert validation error triggers connection retry

[Uri Shachar (JIRA)]

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

Uri Shachar updated TS-3609:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Upstream cert validation error triggers connection retry
> 
>
> Key: TS-3609
> URL: https://issues.apache.org/jira/browse/TS-3609
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 6.2.0
>
>
> When we fail the validation of upstream SSL certificate we treat it as a 
> regular connection failure and retry with the same SSL parameters -- even 
> though there's no reason to.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4079) Support for arbitrary esi vars through HTTP request headers

[Kit Chan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058896#comment-15058896
 ] 

Kit Chan commented on TS-4079:
--

Please submit a PR on github and I will help to review and merge accordingly.

> Support for arbitrary esi vars through HTTP request headers
> ---
>
> Key: TS-4079
> URL: https://issues.apache.org/jira/browse/TS-4079
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Sandeep Davu
>Assignee: Kit Chan
>Priority: Minor
> Fix For: 6.1.0
>
>
> Variables in ESI have to be predefined. This feature extends the variables to 
> be any on the request headers. Stored as a dictionary.
> Variables may be accessed  $(HTTP_HEADER{HDR_NAME}) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4079) Support for arbitrary esi vars through HTTP request headers

[Sandeep Davu (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058978#comment-15058978
 ] 

Sandeep Davu commented on TS-4079:
--

PR submitted https://github.com/apache/trafficserver/pull/378

> Support for arbitrary esi vars through HTTP request headers
> ---
>
> Key: TS-4079
> URL: https://issues.apache.org/jira/browse/TS-4079
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Sandeep Davu
>Assignee: Kit Chan
>Priority: Minor
> Fix For: 6.2.0
>
>
> Variables in ESI have to be predefined. This feature extends the variables to 
> be any on the request headers. Stored as a dictionary.
> Variables may be accessed  $(HTTP_HEADER{HDR_NAME}) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4079) Support for arbitrary esi vars through HTTP request headers

[Kit Chan (JIRA)]

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

Kit Chan reassigned TS-4079:


Assignee: Kit Chan

> Support for arbitrary esi vars through HTTP request headers
> ---
>
> Key: TS-4079
> URL: https://issues.apache.org/jira/browse/TS-4079
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Sandeep Davu
>Assignee: Kit Chan
>Priority: Minor
> Fix For: 6.1.0
>
>
> Variables in ESI have to be predefined. This feature extends the variables to 
> be any on the request headers. Stored as a dictionary.
> Variables may be accessed  $(HTTP_HEADER{HDR_NAME}) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4079) Support for arbitrary esi vars through HTTP request headers

[Kit Chan (JIRA)]

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

Kit Chan updated TS-4079:
-
Fix Version/s: 6.1.0

> Support for arbitrary esi vars through HTTP request headers
> ---
>
> Key: TS-4079
> URL: https://issues.apache.org/jira/browse/TS-4079
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Sandeep Davu
>Assignee: Kit Chan
>Priority: Minor
> Fix For: 6.1.0
>
>
> Variables in ESI have to be predefined. This feature extends the variables to 
> be any on the request headers. Stored as a dictionary.
> Variables may be accessed  $(HTTP_HEADER{HDR_NAME}) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4030) Add option to remove query string from URL hashing in consistent hash parent selection method.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058812#comment-15058812
 ] 

ASF GitHub Bot commented on TS-4030:


Github user jrushf1239k closed the pull request at:

https://github.com/apache/trafficserver/pull/377


> Add option to remove query string from URL hashing in consistent hash parent 
> selection method.
> --
>
> Key: TS-4030
> URL: https://issues.apache.org/jira/browse/TS-4030
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A
> Fix For: 6.1.0
>
>
> You most likely will not want to hash on the query string, so we should have 
> an option to remove it from consideration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4080) Lua Ability return parent proxy

[Kit Chan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059033#comment-15059033
 ] 

Kit Chan commented on TS-4080:
--

Can you add more info with a more elaborate example? e.g. 

Client -> proxy 1 -> origin

and you want the lua script in proxy 1 to allow you to change it to 

Client -> proxy 1 -> proxy 2 -> origin

Is that what you mean? In that case. you can do a 
ts.client_request.set_url_host(). You can follow the example here 
https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/ts_lua.en.html#ts-client-request-set-url-host


> Lua Ability return parent proxy 
> 
>
> Key: TS-4080
> URL: https://issues.apache.org/jira/browse/TS-4080
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Lua, Parent Proxy
>Reporter: Faysal Banna
>Assignee: Kit Chan
>
> Good day sir.
> is it possible add a functionality to lua extension so that the request be 
> supplied to parent proxy ; add a directive to explicitly service the request 
> being examined in lua script to go through a parent proxy whenever possible ? 
> something like ts_parent_proxy="x.y.z.c:8080" 
> much regards 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4069) proxy.config.diags.show_location doesn't work for plugins

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4069:
--
Fix Version/s: 6.2.0

> proxy.config.diags.show_location doesn't work for plugins
> -
>
> Key: TS-4069
> URL: https://issues.apache.org/jira/browse/TS-4069
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 5.3.0
>Reporter: David Carlin
>  Labels: 5.3.x, yahoo
> Fix For: 6.2.0
>
>
> enabling proxy.config.diags.show_location doesn't provide any additional 
> debug info for plugins.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4075) segmentation fault due to reenable in SNI Hook for a closed ssl connection

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4075:
--
Component/s: SSL
 Plugins

> segmentation fault due to reenable in SNI Hook for a closed ssl connection
> --
>
> Key: TS-4075
> URL: https://issues.apache.org/jira/browse/TS-4075
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, SSL
>Reporter: Oknet Xu
> Fix For: 6.2.0
>
>
> I'm writing a ssl hook to look up a cert from mysql database.
> the SNI Hook stall at fetch cert from mysql database due to a database dump 
> lock every mid night.
> the SSL Client got timeout and closing the connection before SNI Hook 
> reenable the connection.
> Segmentation fault due to the TSVConnSSLConnectionGet() can not get a SSLVC 
> during reenable the SSLVC.
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [(nil)])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x2b90c9955b22]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b90cc1ea8d0]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(__dynamic_cast+0x60)[0x2b90cc9c3020]
> /usr/bin/traffic_server(TSVConnSSLConnectionGet+0x1e)[0x2b90c997832e]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::reenable()+0x8c)[0x2b90d5fe29dc]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::destroy()+0xe5)[0x2b90d5fe2b85]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_content(tsapi_vio*)+0x29b)[0x2b90d5fe34db]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_read(TSEvent,
>  tsapi_vio*)+0x36)[0x2b90d5fe3526]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::dispatch(tsapi_cont*,
>  TSEvent, void*)+0x95)[0x2b90d5fe35e5]
> /usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x366)[0x2b90c998b0a6]
> /usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x5a9)[0x2b90c998ba49]
> /usr/bin/traffic_server(PluginVC::main_handler(int, 
> void*)+0x371)[0x2b90c998e1c1]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x2b90c9bc8620]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x2b90c9bc922f]
> /usr/bin/traffic_server(+0x369a1a)[0x2b90c9bc7a1a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b90cc1e30a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b90cd26704d]
> traffic_server: using root directory '/usr'
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4080) Lua Ability return parent proxy

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4080:
--
Fix Version/s: sometime

> Lua Ability return parent proxy 
> 
>
> Key: TS-4080
> URL: https://issues.apache.org/jira/browse/TS-4080
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Lua, Parent Proxy
>Reporter: Faysal Banna
>Assignee: Kit Chan
> Fix For: sometime
>
>
> Good day sir.
> is it possible add a functionality to lua extension so that the request be 
> supplied to parent proxy ; add a directive to explicitly service the request 
> being examined in lua script to go through a parent proxy whenever possible ? 
> something like ts_parent_proxy="x.y.z.c:8080" 
> much regards 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4077) Clean up doc build warnings

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4077:
--
Fix Version/s: Docs

> Clean up doc build warnings
> ---
>
> Key: TS-4077
> URL: https://issues.apache.org/jira/browse/TS-4077
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Miles Libbey
>Assignee: Jon Sime
> Fix For: Docs
>
>
> When building the documentation, there are a bunch of warnings about options, 
> invalid syntax etc.  We should clean these up.
> From a clean git repo:
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:160: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:176: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:195: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:281: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:305: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:360: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:413: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:457: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:483: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:520: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:541: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:568: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:584: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:612: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:640: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/cache-basics.en.rst:672: WARNING: 
> Malformed :option: u'traffic_ctl config reload', does not contain option 
> marker - or -- or /
> trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:18: 
> SEVERE: Problems with "include" directive path:
> InputError: [Errno 2] No such file or directory: 'admin-guide/common.defs'.
> trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:173: 
> WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/hierachical-caching.en.rst:221: 
> WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:265:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:276:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:297:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> trafficserver/doc/admin-guide/configuration/redirecting-http-requests.en.rst:321:
>  WARNING: Malformed :option: u'traffic_ctl config reload', does not contain 
> option marker - or -- or /
> 

[jira] [Updated] (TS-3636) Parent Proxy Forward mode ts-full

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3636:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Parent Proxy Forward mode ts-full
> -
>
> Key: TS-3636
> URL: https://issues.apache.org/jira/browse/TS-3636
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy, TProxy
>Reporter: Faysal Banna
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> Hello Guys.
> today i stumbled upon an issue with parent proxy, and let me describe what is 
> going on.
> i have my cache working in forward proxy mode tr-full
> proxy.config.reverse_proxy.enabled 0
> proxy.config.url_remap.remap_required 0
> proxy.config.http.server_ports 8080:tr-full:tr-pass 8099
> and in parent.config i have 
> url_regex=".*distrowatch" parent="77.75.92.61:8080"
> now if i do 
> export http_proxy=127.0.0.1:8099
> wget 'http://distrowatch.com'  --delete-after 
> i can see that the request was proxied to the parent cache in squid.log as 
> shown below:
> 1432569647.049 823 127.0.0.1 TCP_REFRESH_MISS/200 157668 GET 
> http://distrowatch.com/ - PARENT_HIT/77.75.92.61 text/html
> yet if i go as a client forwarded to the server from my laptop 
> i issue 
> wget --delete-after 'http://distrowatch.com'
> i get in squid.log
> 1432570157.718 62805 77.75.88.82 TCP_REFRESH_MISS/200 157598 GET 
> http://distrowatch.com/ - DIRECT/distrowatch.com text/html
> i checked tcpdump on the interface between both caches and i had a result 
> that ATS was sending parent proxies with origin ip addresses same as the 
> client ip addresses .
> so i did a source-nat (SNAT) via iptables firewall on the interface itself 
> and originated traffic as if originated from ATS itself 
> in diags.log i could always see
> http parent proxy 77.75.92.61:8080 marked down
> in my believe parent proxy should not get client address unless asked for. 
> since it should always reply to the ATS server so it should get ATS ip 
> address and not client ip address regardless of being TProxied or not.
> unless someone can create some variable to enable disable such feature when 
> contacting parent proxies.
> Regards 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3996) CID 1338133: Control flow issues (DEADCODE) /cmd/traffic_manager/traffic_manager.cc

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3996:

Fix Version/s: (was: 6.1.0)
   6.2.0

> CID 1338133:  Control flow issues  (DEADCODE) 
> /cmd/traffic_manager/traffic_manager.cc
> -
>
> Key: TS-3996
> URL: https://issues.apache.org/jira/browse/TS-3996
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> {code}
> Hi,
> Please find the latest report on new defect(s) introduced to Apache Traffic 
> Server found with Coverity Scan.
> 1 new defect(s) introduced to Apache Traffic Server found with Coverity Scan.
> 6 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
> recent build analyzed by Coverity Scan.
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of 1 defect(s)
> ** CID 1338133:  Control flow issues  (DEADCODE)
> /cmd/traffic_manager/traffic_manager.cc: 569 in main()
> 
> *** CID 1338133:  Control flow issues  (DEADCODE)
> /cmd/traffic_manager/traffic_manager.cc: 569 in main()
> 563 int facility_int;
> 564 
> 565 facility_str = REC_readString(sys_var, );
> 566 ink_assert(found);
> 567 
> 568 if (!found) {
>CID 1338133:  Control flow issues  (DEADCODE)
>Execution cannot reach this statement: "mgmt_elog(0, "Could not rea...".
> 569   mgmt_elog(0, "Could not read %s.  Defaulting to LOG_DAEMON\n", 
> sys_var);
> 570   facility_int = LOG_DAEMON;
> 571 } else {
> 572   facility_int = facility_string_to_int(facility_str);
> 573   ats_free(facility_str);
> 574   if (facility_int < 0) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3758) Elimiate std::map from logging code

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3758:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Elimiate std::map from logging code
> ---
>
> Key: TS-3758
> URL: https://issues.apache.org/jira/browse/TS-3758
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> We introduce std::map in the logging code with TS-2150. We should replace 
> this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3736) AMC will replace std::map in the core

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3736:

Fix Version/s: (was: 6.1.0)
   6.2.0

> AMC will replace std::map in the core
> -
>
> Key: TS-3736
> URL: https://issues.apache.org/jira/browse/TS-3736
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4071) unused mutex Diags::rotate_lock

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059083#comment-15059083
 ] 

Leif Hedstrom commented on TS-4071:
---

Lets try to get this in ASAP for 6.1.0.

> unused mutex Diags::rotate_lock
> ---
>
> Key: TS-4071
> URL: https://issues.apache.org/jira/browse/TS-4071
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 6.1.0
>
>
> {{ Diags::rotate_lock}} was introduced in TS-306. It is initialized but never 
> used. Is it needed? If not, let's remove it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4075) segmentation fault due to reenable in SNI Hook for a closed ssl connection

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4075:
--
Fix Version/s: 6.2.0

> segmentation fault due to reenable in SNI Hook for a closed ssl connection
> --
>
> Key: TS-4075
> URL: https://issues.apache.org/jira/browse/TS-4075
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Oknet Xu
> Fix For: 6.2.0
>
>
> I'm writing a ssl hook to look up a cert from mysql database.
> the SNI Hook stall at fetch cert from mysql database due to a database dump 
> lock every mid night.
> the SSL Client got timeout and closing the connection before SNI Hook 
> reenable the connection.
> Segmentation fault due to the TSVConnSSLConnectionGet() can not get a SSLVC 
> during reenable the SSLVC.
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [(nil)])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x2b90c9955b22]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b90cc1ea8d0]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(__dynamic_cast+0x60)[0x2b90cc9c3020]
> /usr/bin/traffic_server(TSVConnSSLConnectionGet+0x1e)[0x2b90c997832e]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::reenable()+0x8c)[0x2b90d5fe29dc]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::destroy()+0xe5)[0x2b90d5fe2b85]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_content(tsapi_vio*)+0x29b)[0x2b90d5fe34db]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::handler_read(TSEvent,
>  tsapi_vio*)+0x36)[0x2b90d5fe3526]
> /usr/lib/trafficserver/modules/test-ssl.so(CertRequestContext::dispatch(tsapi_cont*,
>  TSEvent, void*)+0x95)[0x2b90d5fe35e5]
> /usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x366)[0x2b90c998b0a6]
> /usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x5a9)[0x2b90c998ba49]
> /usr/bin/traffic_server(PluginVC::main_handler(int, 
> void*)+0x371)[0x2b90c998e1c1]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x2b90c9bc8620]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x2b90c9bc922f]
> /usr/bin/traffic_server(+0x369a1a)[0x2b90c9bc7a1a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b90cc1e30a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b90cd26704d]
> traffic_server: using root directory '/usr'
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4074) build_* variables need to be escaped

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4074:
--
Assignee: Masakazu Kitajo

> build_* variables need to be escaped
> 
>
> Key: TS-4074
> URL: https://issues.apache.org/jira/browse/TS-4074
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> BUILD_PERSON, BUILD_GROUP and BUILD_MACHINE need to be escaped.
> {noformat}
> traffic_layout.cc:79:32: error: unknown escape sequence '\D' 
> [-Werror,-Wunknown-escape-sequence]
>   print_feature("BUILD_GROUP", BUILD_GROUP, json);
>^
> ../../lib/ts/ink_config.h:49:46: note: expanded from macro 'BUILD_GROUP'
> #define BUILD_GROUP"XXX\Domain Users"
> {noformat}
> Current configure.ac
> {code}
> build_person="`id -nu`"
> build_group="`id -ng`"
> build_machine="`uname -n`"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4074) build_* variables need to be escaped

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4074:
--
Fix Version/s: 6.2.0

> build_* variables need to be escaped
> 
>
> Key: TS-4074
> URL: https://issues.apache.org/jira/browse/TS-4074
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> BUILD_PERSON, BUILD_GROUP and BUILD_MACHINE need to be escaped.
> {noformat}
> traffic_layout.cc:79:32: error: unknown escape sequence '\D' 
> [-Werror,-Wunknown-escape-sequence]
>   print_feature("BUILD_GROUP", BUILD_GROUP, json);
>^
> ../../lib/ts/ink_config.h:49:46: note: expanded from macro 'BUILD_GROUP'
> #define BUILD_GROUP"XXX\Domain Users"
> {noformat}
> Current configure.ac
> {code}
> build_person="`id -nu`"
> build_group="`id -ng`"
> build_machine="`uname -n`"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4081:
-

Assignee: Leif Hedstrom

> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4081:
-

 Summary: Allow escalate plugin to use the pristine URL when 
retrying
 Key: TS-4081
 URL: https://issues.apache.org/jira/browse/TS-4081
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Leif Hedstrom


We have a use case where the remap rules must modify the path for the primary 
origin, but when escalating (using escalate.so) it must use the original 
(pristine) URL. I have a patch which adds a --pristine option to the plugin, 
telling it to base the escalated request on the pristine URL and not the 
remapped URL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4081:
--
Fix Version/s: 6.1.0

> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4081:
--
Labels: A  (was: )

> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4071) unused mutex Diags::rotate_lock

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4071:
--
Fix Version/s: 6.1.0

> unused mutex Diags::rotate_lock
> ---
>
> Key: TS-4071
> URL: https://issues.apache.org/jira/browse/TS-4071
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 6.1.0
>
>
> {{ Diags::rotate_lock}} was introduced in TS-306. It is initialized but never 
> used. Is it needed? If not, let's remove it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4069) proxy.config.diags.show_location doesn't work for plugins

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4069:
--
Labels: yahoo  (was: 5.3.x yahoo)

> proxy.config.diags.show_location doesn't work for plugins
> -
>
> Key: TS-4069
> URL: https://issues.apache.org/jira/browse/TS-4069
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 5.3.0
>Reporter: David Carlin
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> enabling proxy.config.diags.show_location doesn't provide any additional 
> debug info for plugins.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4072) diagnostic log rolling races

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4072:
--
Fix Version/s: 6.2.0

> diagnostic log rolling races
> 
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 6.2.0
>
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced 
> with a new log object. Since the global {{diags}} points to a a single 
> {{Diags}} object there is nothing to prevent a different thread logging 
> through this object at the time it is deleted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3927) Open Write retries not working and make the setting overridable.

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda resolved TS-3927.
---
Resolution: Fixed

> Open Write retries not working and make the setting overridable.
> 
>
> Key: TS-3927
> URL: https://issues.apache.org/jira/browse/TS-3927
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> The setting *proxy.config.http.cache.max_open_write_retries* is expected to 
> retry a cache open write upon the configured number of times, upon a open 
> write failure. However, the setting doesn't work currently. Opening this jira 
> to fix the setting and to make the setting overridable as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3881) new TS API TSHttpTxnInfoIntGet.

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda resolved TS-3881.
---
Resolution: Fixed

> new TS API TSHttpTxnInfoIntGet.
> ---
>
> Key: TS-3881
> URL: https://issues.apache.org/jira/browse/TS-3881
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: TS API
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> I started off trying to write a TSHttpTxnCacheStateGet API to return cache 
> lookup specific details, but, based on feed back on the IRC and dev@, 
> changing the API to a more generic interface TSHttpTxnInfoIntGet to return 
> any arbitrary info. The idea is to be able to use this API in the long term 
> to support any arbitrary information related to a Txn (which can be used as 
> the underlying piece for a framework to return txn info using custom log 
> tags).
> Below's the proposal with the info I'd like the new API return along with the 
> API signature.
> Please provide comments/suggestions.
> {code}
> +typedef enum {
> +  TS_TXN_INFO_CACHE_HIT_RAM,
> +  TS_TXN_INFO_COMPRESSED_IN_RAM,
> +  TS_TXN_INFO_CACHE_HIT_RWW, // READ_WHILE_WRITE
> +  TS_TXN_INFO_CACHE_OPEN_READ_TRIES,
> +  TS_TXN_INFO_CACHE_OPEN_WRITE_TRIES,
> +  TS_TXN_INFO_CACHE_VOLUME,
> +  TS_TXN_INFO_LAST_ENTRY
> +} TSHttpTxnInfoKey;
> +
> +/* Get Arbitrary Txn info such as cache lookup details etc as defined in 
> TSHttpTxnInfoKey */
> +/**
> +   Return the particular txn info requested.
> +
> +   @param txnp the transaction pointer
> +   @param key the requested txn info.
> +   @param TSMgmtInt a pointer to a integer where the return value is stored
> +
> +   @return @c TS_SUCCESS if the requested info is supported, TS_ERROR 
> otherwise
> +
> +*/
> +tsapi TSReturnCode TSHttpTxnInfoIntGet(TSHttpTxn txnp, TSHttpTxnInfoKey key, 
> TSMgmtInt *value);
> +
> {code}
> +



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4023) cachekey plugin

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059217#comment-15059217
 ] 

ASF subversion and git services commented on TS-4023:
-

Commit d2140cf0128c6f89ce843dbcf8816e979de7c8c7 in trafficserver's branch 
refs/heads/master from [~gancho]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d2140cf ]

TS-4023 Adds a new cachekey plugin

This plugin allows some common cache key manipulations based on various HTTP 
request elements. It can
- sort query parameters so reordering can be a cache hit
- ignore specific query parameters from the cache key by name or regular 
expression
- ignore all query parameters from the cache key
- only use specific query parameters in the cache key by name or regular 
expression
- include headers or cookies by name
- capture values from the User-Agent header.
- classify request using User-Agent and a list of regular expressions

This closes #371


> cachekey plugin
> ---
>
> Key: TS-4023
> URL: https://issues.apache.org/jira/browse/TS-4023
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 6.1.0
>
>
> This plugin allows some common cache key normalizations of the URI.  It can
> - sort query parameters so reordering can be a cache hit
> - ignore specific query parameters from the cache key by name or regular 
> expression
> - ignore all query parameters from the cache key
> - only use specific query parameters in the cache key by name or regular 
> expression
> - include headers or cookies by name
> - capture / replace values from the User-Agent header.
> - classify request using User-Agent and a list of regular expressions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3235) PluginVC crashed with unrecognized event

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3235:

Fix Version/s: (was: 6.1.0)
   6.2.0

> PluginVC crashed with unrecognized event
> 
>
> Key: TS-3235
> URL: https://issues.apache.org/jira/browse/TS-3235
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API, HTTP, Plugins
>Reporter: kang li
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
> Attachments: pluginvc-crash.diff
>
>
> We are using atscppapi to create Intercept plugin.
>  
> From the coredump , that seems Continuation of the InterceptPlugin was 
> already been destroyed. 
> {code}
> #0  0x00375ac32925 in raise () from /lib64/libc.so.6
> #1  0x00375ac34105 in abort () from /lib64/libc.so.6
> #2  0x2b21eeae3458 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3  0x2b21eeae3525 in ink_fatal_va(int, const char *, typedef 
> __va_list_tag __va_list_tag *) (return_code=1, 
> message_format=0x2b21eeaf08d8 "%s:%d: failed assert `%s`", 
> ap=0x2b21f4913ad0) at ink_error.cc:65
> #4  0x2b21eeae35ee in ink_fatal (return_code=1, 
> message_format=0x2b21eeaf08d8 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5  0x2b21eeae2160 in _ink_assert (expression=0x76ddb8 "call_event == 
> core_lock_retry_event", file=0x76dd04 "PluginVC.cc", line=203)
> at ink_assert.cc:37
> #6  0x00530217 in PluginVC::main_handler (this=0x2b24ef007cb8, 
> event=1, data=0xe0f5b80) at PluginVC.cc:203
> #7  0x004f5854 in Continuation::handleEvent (this=0x2b24ef007cb8, 
> event=1, data=0xe0f5b80) at ../iocore/eventsystem/I_Continuation.h:146
> #8  0x00755d26 in EThread::process_event (this=0x309b250, 
> e=0xe0f5b80, calling_code=1) at UnixEThread.cc:145
> #9  0x0075610a in EThread::execute (this=0x309b250) at 
> UnixEThread.cc:239
> #10 0x00755284 in spawn_thread_internal (a=0x2849330) at Thread.cc:88
> #11 0x2b21ef05f9d1 in start_thread () from /lib64/libpthread.so.0
> #12 0x00375ace8b7d in clone () from /lib64/libc.so.6
> (gdb) p sm_lock_retry_event
> $13 = (Event *) 0x2b2496146e90
> (gdb) p core_lock_retry_event
> $14 = (Event *) 0x0
> (gdb) p active_event
> $15 = (Event *) 0x0
> (gdb) p inactive_event
> $16 = (Event *) 0x0
> (gdb) p *(INKContInternal*)this->core_obj->connect_to
> Cannot access memory at address 0x2b269cd46c10
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4032) Provide command line messaging for plugins

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-4032:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Provide command line messaging for plugins
> --
>
> Key: TS-4032
> URL: https://issues.apache.org/jira/browse/TS-4032
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Labels: Review
> Fix For: 6.2.0
>
>
> Add another event  to the lifecycle hook, ALERT. This will be sent only from 
> an external API, e.g. {{traffic_ctl}}. Any plugin that wants to be alertable 
> from the command line can attach to this hook and watch for the event 
> {{TS_EVENT_LIFECYCLE_ALERT}}. The data for the event wil be a string that is 
> provided by the external agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-3535) Add priority feature to the HTTP/2 implementation

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba reassigned TS-3535:
---

Assignee: Masaori Koshiba

> Add priority feature to the HTTP/2 implementation
> -
>
> Key: TS-3535
> URL: https://issues.apache.org/jira/browse/TS-3535
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
> Fix For: 6.1.0
>
>
> Prioritizes the responses back to the client based on the priority level 
> specified by the HTTP/2 protocol.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-974) TS should have a mode to hold partial objects in cache

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-974:
---
Fix Version/s: (was: 6.1.0)
   7.0.0

> TS should have a mode to hold partial objects in cache
> --
>
> Key: TS-974
> URL: https://issues.apache.org/jira/browse/TS-974
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Affects Versions: 3.0.1
>Reporter: William Bardwell
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.0.0
>
>
> For ATS to do an excelent job caching large files like video it would need to 
> be able to hold partial objects for a large file.  This could be done in a 
> plugin or in the core.  This would need to be integrated with the Range 
> handling code to serve requests out of the partial objects and to get more 
> parts of a file to satisfy a Range request.
> An intermediate step (also do-able in the core or in a plugin) would be to 
> have some settings to let the Range handling code be able to trigger a full 
> file download either asynchronously when a Range response indicates that the 
> file isn't larger than some threshold, or synchronously when a Range request 
> could reasonably be answered quickly from a full request.  (Right now Range 
> requests are tunneled if there is not full cached content as far as I can 
> tell.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2918) collapsed_connection Plugin Errors

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-2918:

Fix Version/s: (was: 6.1.0)
   6.2.0

> collapsed_connection Plugin Errors 
> ---
>
> Key: TS-2918
> URL: https://issues.apache.org/jira/browse/TS-2918
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Performance, Plugins
>Reporter: Faysal Banna
>Assignee: Alan M. Carroll
>  Labels: crash, newbie
> Fix For: 6.2.0
>
>
> Hi Guys.
> I been using trafficserver for over a year with all the good stuff it holds 
> still there are bugs that are yet not fixed 
> one of the common bug in a plugin experimental called collapsed_connection 
> and here's the output 
> FATAL: InkAPI.cc:989: failed assert `!"Plugin tries to use a continuation 
> which is deleted"`
> /usr/local/bin/traffic_server - STACK TRACE: 
> /usr/local/lib/libtsutil.so.5(+0x1e897)[0x2b587580c897]
> /usr/local/lib/libtsutil.so.5(+0x1d84f)[0x2b587580b84f]
> /usr/local/bin/traffic_server[0x4b73b3]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, 
> void*)+0x102)[0x5ae762]
> /usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int, 
> void*)+0x170)[0x5af510]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x5b319d]
> /usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, 
> void*)+0x156)[0x5910c6]
> /usr/local/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, 
> HTTPHdr*, CacheLookupHttpConfig*, CacheFragType, char*, int)+0x642)[0x6dfd12]
> /usr/local/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, 
> bool, HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x9b)[0x6beecb]
> /usr/local/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, 
> CacheLookupHttpConfig*, long)+0x81)[0x591381]
> /usr/local/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x5a163b]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x7aa)[0x5b3c2a]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, 
> void*)+0x2c0)[0x5ae920]
> /usr/local/bin/traffic_server(HttpSM::state_api_callback(int, 
> void*)+0x82)[0x5b3382]
> /usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4c9c34]
> /usr/local/libexec/trafficserver/collapsed_connection.so(+0x2edf)[0x2b587b651edf]
> /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4714)[0x2b587b653714]
> /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4b90)[0x2b587b653b90]
> /usr/local/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x170)[0x73e030]
> /usr/local/bin/traffic_server(EThread::execute()+0x7e1)[0x73ec51]
> /usr/local/bin/traffic_server[0x73d94a]
> each time this happens the server is being restarted 
> much regards 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3347) make ink_assert a no-op in release builds

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3347:

Fix Version/s: (was: 6.1.0)
   6.2.0

> make ink_assert a no-op in release builds
> -
>
> Key: TS-3347
> URL: https://issues.apache.org/jira/browse/TS-3347
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> ink_assert() is expected to be enabled only in DEBUG builds. However, the 
> current definition of ink_assert() for non-DEBUG (release) builds, still 
> evaluates the expression passed to it, which seems totally unnecessary. 
> Opening this jira to make ink_assert() a complete no-op for non-DEBUG release 
> builds. Along with the change of definition, need to scan the entire TS code 
> to fix the code that relies on the expression evaluated in the ink_assert() 
> accordingly. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-1033) Add some "missing" WKS's to HdrToken.

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-1033:

Fix Version/s: (was: 6.1.0)
   7.0.0

> Add some "missing" WKS's to HdrToken.
> -
>
> Key: TS-1033
> URL: https://issues.apache.org/jira/browse/TS-1033
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> And of course various other places (including InkAPI).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3960) traffic_line -x doesn't reload SSL certs content

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058689#comment-15058689
 ] 

ASF subversion and git services commented on TS-3960:
-

Commit 4c6f15ea997aef1d6062df3b23cad7ebec9deab0 in trafficserver's branch 
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4c6f15e ]

TS-3960: clang-format


> traffic_line -x doesn't reload SSL certs content
> 
>
> Key: TS-3960
> URL: https://issues.apache.org/jira/browse/TS-3960
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Zhang Zizhong
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> traffic_line -x doesn't reload  when SSL certs change file contents without 
> changing the file names.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4079) Support for arbitrary esi vars through HTTP request headers

[Sandeep Davu (JIRA)]

Sandeep Davu created TS-4079:


 Summary: Support for arbitrary esi vars through HTTP request 
headers
 Key: TS-4079
 URL: https://issues.apache.org/jira/browse/TS-4079
 Project: Traffic Server
  Issue Type: New Feature
Reporter: Sandeep Davu


Variables in ESI have to be predefined. This feature extends the variables to 
be any on the request headers. Stored as a dictionary.

Variables may be accessed $(HTTP_HEADER{HDR_NAME}).




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4079) Support for arbitrary esi vars through HTTP request headers

[Kit Chan (JIRA)]

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

Kit Chan updated TS-4079:
-
Fix Version/s: (was: 6.1.0)
   6.2.0

> Support for arbitrary esi vars through HTTP request headers
> ---
>
> Key: TS-4079
> URL: https://issues.apache.org/jira/browse/TS-4079
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Sandeep Davu
>Assignee: Kit Chan
>Priority: Minor
> Fix For: 6.2.0
>
>
> Variables in ESI have to be predefined. This feature extends the variables to 
> be any on the request headers. Stored as a dictionary.
> Variables may be accessed  $(HTTP_HEADER{HDR_NAME}) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4062) CID 1341764, 1341763 Control flow issues and resource leak in H2

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba resolved TS-4062.
-
Resolution: Fixed

> CID 1341764, 1341763 Control flow issues and resource leak in H2
> 
>
> Key: TS-4062
> URL: https://issues.apache.org/jira/browse/TS-4062
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Masaori Koshiba
>Priority: Critical
>  Labels: coverity
> Fix For: 6.1.0
>
>
> {code}
> New defect(s) Reported-by: Coverity Scan
> Showing 2 of 2 defect(s)
> ** CID 1341764:  Possible Control flow issues  (DEADCODE)
> /proxy/http2/HPACK.cc: 347 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 
> *** CID 1341764:  Possible Control flow issues  (DEADCODE)
> /proxy/http2/HPACK.cc: 347 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 341   if (use_huffman) {
> 342 data = static_cast(ats_malloc(value_len * 4));
> 343 if (data == NULL)
> 344   return -1;
> 345 data_len = huffman_encode(reinterpret_cast(data), 
> reinterpret_cast(value), value_len);
> 346   } else {
>CID 1341764:  Possible Control flow issues  (DEADCODE)
>Execution cannot reach this statement: "data = (char *)value;".
> 347 data = const_cast(value);
> 348 data_len = value_len;
> 349   }
> 350 
> 351   // Length
> 352   const int64_t len = encode_integer(p, buf_end, data_len, 7);
> ** CID 1341763:(RESOURCE_LEAK)
> /proxy/http2/HPACK.cc: 354 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> /proxy/http2/HPACK.cc: 360 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 
> *** CID 1341763:(RESOURCE_LEAK)
> /proxy/http2/HPACK.cc: 354 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 348 data_len = value_len;
> 349   }
> 350 
> 351   // Length
> 352   const int64_t len = encode_integer(p, buf_end, data_len, 7);
> 353   if (len == -1)
>CID 1341763:(RESOURCE_LEAK)
>Variable "data" going out of scope leaks the storage it points to.
> 354 return -1;
> 355   if (use_huffman) {
> 356 *p |= 0x80;
> 357   }
> 358   p += len;
> 359   if (buf_end < p || buf_end - p < data_len)
> /proxy/http2/HPACK.cc: 360 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 354 return -1;
> 355   if (use_huffman) {
> 356 *p |= 0x80;
> 357   }
> 358   p += len;
> 359   if (buf_end < p || buf_end - p < data_len)
>CID 1341763:(RESOURCE_LEAK)
>Variable "data" going out of scope leaks the storage it points to.
> 360 return -1;
> 361 
> 362   // Value
> 363   memcpy(p, data, data_len);
> 364   p += data_len;
> 365 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3535) Add priority feature to the HTTP/2 implementation

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-3535:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Add priority feature to the HTTP/2 implementation
> -
>
> Key: TS-3535
> URL: https://issues.apache.org/jira/browse/TS-3535
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
> Fix For: 6.2.0
>
>
> Prioritizes the responses back to the client based on the priority level 
> specified by the HTTP/2 protocol.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4074) build_* variables need to be escaped

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059319#comment-15059319
 ] 

ASF GitHub Bot commented on TS-4074:


GitHub user maskit opened a pull request:

https://github.com/apache/trafficserver/pull/379

TS-4074: Escape backslashes in user/group/machine name

https://issues.apache.org/jira/browse/TS-4074

The patch just replace one backslash with two backslashes.
Is there more general way, like AC_FOO?

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/maskit/trafficserver ts4074

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/379.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 #379


commit ac7c624309359de6a04835fd47a579cbf93a5354
Author: Masakazu Kitajo 
Date:   2015-12-14T08:29:25Z

TS-4074: Escape backslashes in user/group/machine name




> build_* variables need to be escaped
> 
>
> Key: TS-4074
> URL: https://issues.apache.org/jira/browse/TS-4074
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> BUILD_PERSON, BUILD_GROUP and BUILD_MACHINE need to be escaped.
> {noformat}
> traffic_layout.cc:79:32: error: unknown escape sequence '\D' 
> [-Werror,-Wunknown-escape-sequence]
>   print_feature("BUILD_GROUP", BUILD_GROUP, json);
>^
> ../../lib/ts/ink_config.h:49:46: note: expanded from macro 'BUILD_GROUP'
> #define BUILD_GROUP"XXX\Domain Users"
> {noformat}
> Current configure.ac
> {code}
> build_person="`id -nu`"
> build_group="`id -ng`"
> build_machine="`uname -n`"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-1775) Cleanup of ink_hrtime.{cc,h}

[Alan M. Carroll (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059380#comment-15059380
 ] 

Alan M. Carroll commented on TS-1775:
-

I ended up doing most of this for the event loop issue so I'll keep this around 
and attach it to that bug when I file it.

> Cleanup of ink_hrtime.{cc,h}
> 
>
> Key: TS-1775
> URL: https://issues.apache.org/jira/browse/TS-1775
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
>  Labels: newbie
> Fix For: 6.2.0
>
>
> A few things comes to mind:
> 1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell, 
> and I can't imagine there's a reason to not have it on (it'd completely break 
> like everything, in fact it would fail to compile since gethrtime() doesn't 
> exist?).
> 2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code 
> that implements our own TSC code. Modern Unix flavors implements this already 
> in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space 
> implementation).
> 3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the 
> optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or 
> CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for 
> gettimeofday() on linux.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-1809) remove HTTP_CACHE build option

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-1809:

Fix Version/s: (was: 6.1.0)
   7.0.0

> remove HTTP_CACHE build option
> --
>
> Key: TS-1809
> URL: https://issues.apache.org/jira/browse/TS-1809
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> The HTTP_CACHE build option is probably not useful anymore. It's almost 
> certainly broken and clutters up a lot of code. Let's remove it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TS-4062) CID 1341764, 1341763 Control flow issues and resource leak in H2

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba closed TS-4062.
---
Resolution: Fixed

> CID 1341764, 1341763 Control flow issues and resource leak in H2
> 
>
> Key: TS-4062
> URL: https://issues.apache.org/jira/browse/TS-4062
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Masaori Koshiba
>Priority: Critical
>  Labels: coverity
> Fix For: 6.1.0
>
>
> {code}
> New defect(s) Reported-by: Coverity Scan
> Showing 2 of 2 defect(s)
> ** CID 1341764:  Possible Control flow issues  (DEADCODE)
> /proxy/http2/HPACK.cc: 347 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 
> *** CID 1341764:  Possible Control flow issues  (DEADCODE)
> /proxy/http2/HPACK.cc: 347 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 341   if (use_huffman) {
> 342 data = static_cast(ats_malloc(value_len * 4));
> 343 if (data == NULL)
> 344   return -1;
> 345 data_len = huffman_encode(reinterpret_cast(data), 
> reinterpret_cast(value), value_len);
> 346   } else {
>CID 1341764:  Possible Control flow issues  (DEADCODE)
>Execution cannot reach this statement: "data = (char *)value;".
> 347 data = const_cast(value);
> 348 data_len = value_len;
> 349   }
> 350 
> 351   // Length
> 352   const int64_t len = encode_integer(p, buf_end, data_len, 7);
> ** CID 1341763:(RESOURCE_LEAK)
> /proxy/http2/HPACK.cc: 354 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> /proxy/http2/HPACK.cc: 360 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 
> *** CID 1341763:(RESOURCE_LEAK)
> /proxy/http2/HPACK.cc: 354 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 348 data_len = value_len;
> 349   }
> 350 
> 351   // Length
> 352   const int64_t len = encode_integer(p, buf_end, data_len, 7);
> 353   if (len == -1)
>CID 1341763:(RESOURCE_LEAK)
>Variable "data" going out of scope leaks the storage it points to.
> 354 return -1;
> 355   if (use_huffman) {
> 356 *p |= 0x80;
> 357   }
> 358   p += len;
> 359   if (buf_end < p || buf_end - p < data_len)
> /proxy/http2/HPACK.cc: 360 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 354 return -1;
> 355   if (use_huffman) {
> 356 *p |= 0x80;
> 357   }
> 358   p += len;
> 359   if (buf_end < p || buf_end - p < data_len)
>CID 1341763:(RESOURCE_LEAK)
>Variable "data" going out of scope leaks the storage it points to.
> 360 return -1;
> 361 
> 362   // Value
> 363   memcpy(p, data, data_len);
> 364   p += data_len;
> 365 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4014) Update HTTP/2 dynamic table size smartly

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4014:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Update HTTP/2 dynamic table size smartly
> 
>
> Key: TS-4014
> URL: https://issues.apache.org/jira/browse/TS-4014
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> We don't need to update dynamic table size per every updates.
> {quote}
> Multiple updates to the maximum table size can occur between the
> transmission of two header blocks.  In the case that this size is
> changed more than once in this interval, the smallest maximum table
> size that occurs in that interval MUST be signaled in a dynamic table
> size update.  The final maximum size is always signaled, resulting in
> at most two dynamic table size updates.  This ensures that the
> decoder is able to perform eviction based on reductions in dynamic
> table size (see Section 4.3).
> {quote}
> https://tools.ietf.org/html/rfc7541#section-4.2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4002) Optimize HPACK Decoder

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4002:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Optimize HPACK Decoder
> --
>
> Key: TS-4002
> URL: https://issues.apache.org/jira/browse/TS-4002
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masaori Koshiba
> Fix For: 6.2.0
>
>
> As Kazu pointed out at H2 + ATS Meetup, current implementation of HPACK 
> Decoder could be optimized.
> His analysis of HPACK is below.
> [Implementation and Analysis of HPACK 
> 05|http://d.hatena.ne.jp/kazu-yamamoto/20140129/1391057824]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3269) Remove remnants of CACHE_RTSP_TYPE and mixt/MIXT.

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3269:

Fix Version/s: (was: 6.1.0)
   7.0.0

> Remove remnants of CACHE_RTSP_TYPE and mixt/MIXT.
> -
>
> Key: TS-3269
> URL: https://issues.apache.org/jira/browse/TS-3269
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> There are some remnants of CACHE_RTSP_TYPE, which I think we should 
> eliminate. This include parsing of cache hosting which deals with e.g. "mixt" 
> content, which is not supported in any way.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3252) Don't chunk response body if transform_response_cl is valid

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3252:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Don't chunk response body if transform_response_cl is valid
> ---
>
> Key: TS-3252
> URL: https://issues.apache.org/jira/browse/TS-3252
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: portl4t
>Assignee: Alan M. Carroll
>  Labels: Review
> Fix For: 6.2.0
>
> Attachments: 
> 0001-TS-3252-Don-t-chunk-response-body-if-transform_respo.patch
>
>
> The way as I see, the client will get chunked response from ATS if the origin 
> server issues a chunked response to ATS.
> I am wondering whether this can be changed if there is a transfrom plugin 
> exists and the transform can insure transform_response_cl is valid. This can 
> be done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform 
> handler.
> Here is an example, I want to response "abcdefg" in transform handler, no 
> matter what is received from upstream, and I can write code like this in 
> plugin:
> {code}
> static int transform_handler(...)
> {
>   ...
>   output.buffer = TSIOBufferCreate();
>   output.reader = TSIOBufferReaderAlloc(output.buffer);
>   output.vio = TSVConnWrite(output_conn, contp, output.reader, 
> sizeof("abcdefg")-1);
>   TSIOBufferWrite(output.buffer, "abcdefg", sizeof("abcdefg")-1);
>   TSVIOReenable(output.vio);
>   ...
> }
> {code}
> However, the response body to the client will be chunked if ATS got chunked 
> response from origin server. Maybe we can change this by refining the 
> function HttpTransact::handle_response_keep_alive_headers(...)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4078) CID 1343334: Uninitialized members in Rollback.cc

[Brian Geffon (JIRA)]

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

Brian Geffon reassigned TS-4078:


Assignee: Brian Geffon  (was: Zhang Zizhong)

> CID 1343334:  Uninitialized members in Rollback.cc
> --
>
> Key: TS-4078
> URL: https://issues.apache.org/jira/browse/TS-4078
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> {code}
> ** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 
> *** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 95 
> 96   // If we are not doing backups, bail early.
> 97   if ((numberBackups <= 0) || (flags & CONFIG_FLAG_UNVERSIONED)) {
> 98 currentVersion = 0;
> 99 setLastModifiedTime();
> 100 numberBackups = 0;
>CID 1343334:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "numVersions" is not initialized in this 
> constructor nor in any functions that it calls.
> 101 return;
> 102   }
> 103 
> 104   currentVersion = 0; // Prevent UMR with stat file
> 105   highestSeen = findVersions_ml(versionQ);
> 106 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (TS-4062) CID 1341764, 1341763 Control flow issues and resource leak in H2

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba reopened TS-4062:
-

> CID 1341764, 1341763 Control flow issues and resource leak in H2
> 
>
> Key: TS-4062
> URL: https://issues.apache.org/jira/browse/TS-4062
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Masaori Koshiba
>Priority: Critical
>  Labels: coverity
> Fix For: 6.1.0
>
>
> {code}
> New defect(s) Reported-by: Coverity Scan
> Showing 2 of 2 defect(s)
> ** CID 1341764:  Possible Control flow issues  (DEADCODE)
> /proxy/http2/HPACK.cc: 347 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 
> *** CID 1341764:  Possible Control flow issues  (DEADCODE)
> /proxy/http2/HPACK.cc: 347 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 341   if (use_huffman) {
> 342 data = static_cast(ats_malloc(value_len * 4));
> 343 if (data == NULL)
> 344   return -1;
> 345 data_len = huffman_encode(reinterpret_cast(data), 
> reinterpret_cast(value), value_len);
> 346   } else {
>CID 1341764:  Possible Control flow issues  (DEADCODE)
>Execution cannot reach this statement: "data = (char *)value;".
> 347 data = const_cast(value);
> 348 data_len = value_len;
> 349   }
> 350 
> 351   // Length
> 352   const int64_t len = encode_integer(p, buf_end, data_len, 7);
> ** CID 1341763:(RESOURCE_LEAK)
> /proxy/http2/HPACK.cc: 354 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> /proxy/http2/HPACK.cc: 360 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 
> *** CID 1341763:(RESOURCE_LEAK)
> /proxy/http2/HPACK.cc: 354 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 348 data_len = value_len;
> 349   }
> 350 
> 351   // Length
> 352   const int64_t len = encode_integer(p, buf_end, data_len, 7);
> 353   if (len == -1)
>CID 1341763:(RESOURCE_LEAK)
>Variable "data" going out of scope leaks the storage it points to.
> 354 return -1;
> 355   if (use_huffman) {
> 356 *p |= 0x80;
> 357   }
> 358   p += len;
> 359   if (buf_end < p || buf_end - p < data_len)
> /proxy/http2/HPACK.cc: 360 in encode_string(unsigned char *, const unsigned 
> char *, const char *, unsigned long)()
> 354 return -1;
> 355   if (use_huffman) {
> 356 *p |= 0x80;
> 357   }
> 358   p += len;
> 359   if (buf_end < p || buf_end - p < data_len)
>CID 1341763:(RESOURCE_LEAK)
>Variable "data" going out of scope leaks the storage it points to.
> 360 return -1;
> 361 
> 362   // Value
> 363   memcpy(p, data, data_len);
> 364   p += data_len;
> 365 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3426) Consolidate the multiple API for disabling cache

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3426:

Fix Version/s: (was: 6.1.0)
   7.0.0

> Consolidate the multiple API for disabling cache
> 
>
> Key: TS-3426
> URL: https://issues.apache.org/jira/browse/TS-3426
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.0.0
>
>
> There are currently multiple API (see below) that can be used by a plugin to 
> disable cache for a given transaction. 
> {{TSHttpTxnServerRespNoStoreSet}}, {{TSHttpTxnReqCacheableSet}}, 
> {{TSHttpTxnRespCacheableSet}}
> Opening this jira to analyze whether these are redundant and consolidate if 
> necessary. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-658:
---
Fix Version/s: (was: 6.1.0)
   7.0.0

> HTTP SM holds the cache write lock for too long
> ---
>
> Key: TS-658
> URL: https://issues.apache.org/jira/browse/TS-658
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.0.0
>
>
> It seems we open the cache for write very early on in the HTTP SM, which can 
> have very bad effect on performance if the object is not cacheable. It's not 
> totally clear as to why this is done this way, but we should examine this for 
> v3.1, and try to minimize how long we hold the lock. It's possible this is 
> related to read_while_writer, but then it should be modified IMO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-1257) Replace Tcl_Hash* with lib/ts/Map

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-1257:

Fix Version/s: (was: 6.1.0)
   7.0.0

> Replace Tcl_Hash* with lib/ts/Map
> -
>
> Key: TS-1257
> URL: https://issues.apache.org/jira/browse/TS-1257
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: Igor Galić
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> We have our own implementation of maps that we use in most new code. We have 
> already discussed looking into removing the old Tcl cruft by replacing it 
> with {{Map}}, but have neither followed up on the ML nor Jira - or in the 
> code ;)
> This ticket is a reminder that this task exists and wants to be done!
> As to whether we simply replace the Tcl Implementation underneath, or visibly 
> to all developers, replace {{InkHashTable}} with {{Map}}, remains to be 
> discussed/decided/evaluated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-966:
---
Fix Version/s: (was: 6.1.0)
   7.0.0

> cache.config dest_domain= dest_hostname= dest_ip= do not match anything
> ---
>
> Key: TS-966
> URL: https://issues.apache.org/jira/browse/TS-966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 3.1.0, 3.0.1
>Reporter: Igor Galić
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.0.0
>
>
> Caching policies are not applied when using these options to match targets.
> It is also not very clear *what* dest_domain= vs dest_hostname= can match.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-1775) Cleanup of ink_hrtime.{cc,h}

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-1775:

Fix Version/s: (was: 6.1.0)
   6.2.0

> Cleanup of ink_hrtime.{cc,h}
> 
>
> Key: TS-1775
> URL: https://issues.apache.org/jira/browse/TS-1775
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
>  Labels: newbie
> Fix For: 6.2.0
>
>
> A few things comes to mind:
> 1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell, 
> and I can't imagine there's a reason to not have it on (it'd completely break 
> like everything, in fact it would fail to compile since gethrtime() doesn't 
> exist?).
> 2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code 
> that implements our own TSC code. Modern Unix flavors implements this already 
> in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space 
> implementation).
> 3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the 
> optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or 
> CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for 
> gettimeofday() on linux.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4078) CID 1343334: Uninitialized members in Rollback.cc

[Brian Geffon (JIRA)]

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

Brian Geffon resolved TS-4078.
--
Resolution: Fixed

This was fixed by [~jamespeach] in c9b2241c4faf4dbb2a706cf7d7e169252b14a3ed

> CID 1343334:  Uninitialized members in Rollback.cc
> --
>
> Key: TS-4078
> URL: https://issues.apache.org/jira/browse/TS-4078
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> {code}
> ** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 
> *** CID 1343334:  Uninitialized members  (UNINIT_CTOR)
> /mgmt/Rollback.cc: 101 in Rollback::Rollback(const char *, bool, Rollback*, 
> unsigned int)()
> 95 
> 96   // If we are not doing backups, bail early.
> 97   if ((numberBackups <= 0) || (flags & CONFIG_FLAG_UNVERSIONED)) {
> 98 currentVersion = 0;
> 99 setLastModifiedTime();
> 100 numberBackups = 0;
>CID 1343334:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "numVersions" is not initialized in this 
> constructor nor in any functions that it calls.
> 101 return;
> 102   }
> 103 
> 104   currentVersion = 0; // Prevent UMR with stat file
> 105   highestSeen = findVersions_ml(versionQ);
> 106 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3639) Add GeoIP info to header_rewrite plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3639:
--
Labels: A  (was: )

> Add GeoIP info to header_rewrite plugin
> ---
>
> Key: TS-3639
> URL: https://issues.apache.org/jira/browse/TS-3639
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> It'd be generally useful to incorporate some of the features from geo_acl's 
> into header_rewrite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3204) Crash when body_factory file is empty

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3204:
--
Fix Version/s: (was: 6.1.0)
   sometime

> Crash when body_factory file is empty
> -
>
> Key: TS-3204
> URL: https://issues.apache.org/jira/browse/TS-3204
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Leif Hedstrom
> Fix For: sometime
>
>
> Reproducible on 5.0.x
> If you have a body factory page that is completely empty, after some time I 
> start getting very obscure crashes all over the place (ssl, remap, etc.). If 
> I add a single whitespace it works fine, seems that something in there 
> doesn't like empty files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3904) Add basic access control to the xdebug plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3904:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> Add basic access control to the xdebug plugin
> -
>
> Key: TS-3904
> URL: https://issues.apache.org/jira/browse/TS-3904
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> It'd be useful to limit access to XDebug information based on client IP. E.g.
> {code}
>--allow=69/8 --allow=10/8 --allow=192.168/16
> {code}
> As an alternative, we could add this to header_rewrite, such that if the 
> X-Debug header is in the client request, we deny the request based on the IP. 
>  The configuration for this could get complex though (maybe header_rewrite 
> needs an ACL operator).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2914) LogField cquuh does not work for TSSkipRemappingSet

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2914:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> LogField cquuh does not work for TSSkipRemappingSet
> ---
>
> Key: TS-2914
> URL: https://issues.apache.org/jira/browse/TS-2914
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging, TS API
>Reporter: xiongzongtao
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: Review
> Fix For: 6.2.0
>
> Attachments: quickfix.diff
>
>
> if cquuh is set in logs_xml.config and  TSSkipRemappingSet called in plugin
>   log entry related to that plugin is not correct and not readable



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3204) Crash when body_factory file is empty

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3204:
--
Assignee: (was: Leif Hedstrom)

> Crash when body_factory file is empty
> -
>
> Key: TS-3204
> URL: https://issues.apache.org/jira/browse/TS-3204
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
> Fix For: sometime
>
>
> Reproducible on 5.0.x
> If you have a body factory page that is completely empty, after some time I 
> start getting very obscure crashes all over the place (ssl, remap, etc.). If 
> I add a single whitespace it works fine, seems that something in there 
> doesn't like empty files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3123) Make proxy.config.http.transaction_active_timeout_in overridable

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3123:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> Make proxy.config.http.transaction_active_timeout_in overridable
> 
>
> Key: TS-3123
> URL: https://issues.apache.org/jira/browse/TS-3123
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.2.0
>
>
> This also requires moving the setup to a slightly later state in the HttpSM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-777) Increasing logbuffer size makes us "drop" log entries

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-777:
-
Fix Version/s: (was: 6.1.0)
   6.2.0

> Increasing logbuffer size makes us "drop" log entries
> -
>
> Key: TS-777
> URL: https://issues.apache.org/jira/browse/TS-777
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 2.1.8
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.2.0
>
>
> Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB 
> makes us start losing log entries. This is bad, since increasing this setting 
> could be a way to increase performance for busy systems. I've for now set the 
> defaults to 16KB, which seems to be stable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2888) Fix build_error_response() to not take a vararg and perhaps not even a format

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2888:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> Fix build_error_response() to not take a vararg and perhaps not even a format
> -
>
> Key: TS-2888
> URL: https://issues.apache.org/jira/browse/TS-2888
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> As the body factory is now required, build_error_response() has a legacy 
> option which generally is not used (except one case which I'm hoping to fix 
> as well). I've already fixed most usage as part of TS-2886, those additional 
> format strings would never have been used after we made body factory 
> mandatory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-946) Scheduling a continuation on all threads of a specific type

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-946:
-
Fix Version/s: (was: 6.1.0)
   7.0.0

> Scheduling a continuation on all threads of a specific type
> ---
>
> Key: TS-946
> URL: https://issues.apache.org/jira/browse/TS-946
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 3.0.0
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> It would be incredibly useful, both in the core and in plugin APIs, to be 
> able to schedule a continuation to run on all threads of a specific type. 
> E.g. in a plugin, something like
> TSAction TSContScheduleOnThreads(TSCont cont, TSThreadPool tp);
> This would be useful for e.g. setting up per-thread specifics from a plugin, 
> but quite possibly also from the core.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2968) Make proxy.config.http.doc_in_cache_skip_dns overridable

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2968:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> Make proxy.config.http.doc_in_cache_skip_dns overridable
> 
>
> Key: TS-2968
> URL: https://issues.apache.org/jira/browse/TS-2968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.2.0
>
>
> Make this overridable per remap rule / plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4020) Cache_promote plugin LRU should use cachekey instead of url

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059638#comment-15059638
 ] 

Leif Hedstrom commented on TS-4020:
---

I hope to have this done, with a new set of plugin APIs as well, for 6.1.0.

> Cache_promote plugin LRU should use cachekey instead of url
> ---
>
> Key: TS-4020
> URL: https://issues.apache.org/jira/browse/TS-4020
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Miles Libbey
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> The Cache_promote plugin currently uses the URL when using the LRU policy.  
> It would be better to use the cachekey, as that is actually going to be the 
> index later.  
> This would make any cachekey modifications also work for the promotion 
> algorithm. For instance, if a domain has a (randomish) query string that gets 
> removed for the cachekey, using the URL in the LRU would effectively never 
> allow it to be promoted to cache, whereas the cachekey would.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4043) Prevent bogus FQDN characters in host header

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4043:
--
Assignee: Alan M. Carroll  (was: Leif Hedstrom)

> Prevent bogus FQDN characters in host header
> 
>
> Key: TS-4043
> URL: https://issues.apache.org/jira/browse/TS-4043
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Security
>Reporter: Daniel Xu
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> Currently ATS isn't checking if a character is valid before letting it in as 
> a hostname. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3737) Document and describe the Jira Labels we expect people to use

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3737:
--
Fix Version/s: (was: 6.1.0)
   Docs

> Document and describe the Jira Labels we expect people to use
> -
>
> Key: TS-3737
> URL: https://issues.apache.org/jira/browse/TS-3737
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Web site
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>
> We should document the Labels in Jira that we expect people to use. Some 
> coming to mind are:
> newbie
> compatibility
> regression
> crasher



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3737) Document and describe the Jira Labels we expect people to use

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-3737.
---
Resolution: Fixed

> Document and describe the Jira Labels we expect people to use
> -
>
> Key: TS-3737
> URL: https://issues.apache.org/jira/browse/TS-3737
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Web site
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>
> We should document the Labels in Jira that we expect people to use. Some 
> coming to mind are:
> newbie
> compatibility
> regression
> crasher



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3494) Expose the "name" (e.g. [ET_NET 0]) in the Thread class

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3494:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> Expose the "name" (e.g. [ET_NET 0]) in the Thread class
> ---
>
> Key: TS-3494
> URL: https://issues.apache.org/jira/browse/TS-3494
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> This would allow our code to e.g. produce Debug() and other info with details 
> on what type of thread, and its # (to match up with e.g. top output). I think 
> this is a trivial addition, e.g.
> const char* Thread::get_name() const { return name; };



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3639) Add GeoIP info to header_rewrite plugin

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059633#comment-15059633
 ] 

Leif Hedstrom commented on TS-3639:
---

I'd like to try to land this for 6.1.0, but the patch still needs some work.

> Add GeoIP info to header_rewrite plugin
> ---
>
> Key: TS-3639
> URL: https://issues.apache.org/jira/browse/TS-3639
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> It'd be generally useful to incorporate some of the features from geo_acl's 
> into header_rewrite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3771) Cleanup ink_platform.h

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3771:
--
Fix Version/s: (was: 6.1.0)
   7.0.0

> Cleanup ink_platform.h
> --
>
> Key: TS-3771
> URL: https://issues.apache.org/jira/browse/TS-3771
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> There's a number of stuff that's unnecessary in this file, and similarly, 
> there are places that *should* use it, but instead do the platform dependent 
> includes directly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4043) Prevent bogus FQDN characters in host header

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4043:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> Prevent bogus FQDN characters in host header
> 
>
> Key: TS-4043
> URL: https://issues.apache.org/jira/browse/TS-4043
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Security
>Reporter: Daniel Xu
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> Currently ATS isn't checking if a character is valid before letting it in as 
> a hostname. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)