[jira] [Commented] (TS-4500) add cookie-rewrite functionality into header-rewrite plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4500:


Github user zizhong commented on the issue:

https://github.com/apache/trafficserver/pull/692
  
The original name for this operator is exactly set-cookie. However, Brain 
was worried about the name could be confusing with **set-cookie** in HTTP 
headers.


> add cookie-rewrite functionality into header-rewrite plugin
> ---
>
> Key: TS-4500
> URL: https://issues.apache.org/jira/browse/TS-4500
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Zhang Zizhong
>Assignee: Zhang Zizhong
> Fix For: 7.0.0
>
>
> add cookie-rewrite functionality into header-rewrite plugin.
> There're three cookie handling operators added, including *add-cookie*, 
> *rm-cookie* and *update-cookie*.
> *add-cookie* adds a key-value pair into Cookie. If the given key is already 
> in Cookie, do nothing.
> *rm-cookie* remove a pair with the given key from Cookie.
> *update-cookie* sets the value with the given key to the given value. If the 
> given key doesn't exist, add a new pair into Cookie. So the only difference 
> between *add-cookie* and *update-cookie* is overwriting an existing pair or 
> not.



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user shukitchan closed the pull request at:

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


> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user shukitchan commented on the issue:

https://github.com/apache/trafficserver/pull/719
  
yeah. just checked. it is only built at "make check" time. merging now


> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #719 from shukitchan/ostype

TS-4551: remove OS_TYPE restriction in gunzip and add unit test

> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/188/ for details.
 



> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/296/ for details.
 



> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
Not sure why the FreeBSD build failed, trying again. [approve ci] 


> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

Jenkins build is back to normal : docs-master #77

[jenkins]

See 

Jenkins build is back to normal : centos_7-master » gcc,centos_7,debug #1775

[jenkins]

See 

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/187/ for details.
 



> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

Build failed in Jenkins: centos_7-master » gcc,centos_7,debug #1774

[jenkins]

See 


--
[...truncated 17949 lines...]
0|0|86.110.4.0|86.110.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|1888958975128722431|0|0|1|0
0|0|116.92.7.0|116.92.7.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16631009639014254015|0|0|1|0
0|0|144.237.10.0|144.237.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|12905853032977407679|0|0|1|0
0|0|103.150.5.0|103.150.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16572297681063508287|0|0|1|0
0|0|250.74.6.0|250.74.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3435544084056601407|0|0|1|0
0|0|33.228.1.0|33.228.1.0|per_ip| |F|0|0|1970/01/01 
00:00:00|7054485740756729087|0|0|1|0
0|0|5.119.12.0|5.119.12.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14495321938049529599|0|0|1|0
0|0|176.81.0.0|176.81.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11377479059831779583|0|0|1|0
0|0|156.11.6.0|156.11.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8234706063569537663|0|0|1|0
0|0|109.134.9.0|109.134.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14050053816847377407|0|0|1|0
0|0|140.42.10.0|140.42.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8162434488007175487|0|0|1|0
0|0|114.61.13.0|114.61.13.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3945992723180975743|0|0|1|0
0|0|33.100.6.0|33.100.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6825087806830268671|0|0|1|0
0|0|83.94.9.0|83.94.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3346846807966173951|0|0|1|0
0|0|145.111.0.0|145.111.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4310273191177806975|0|0|1|0
RPRINT Congestion_CongestionDB: There are 1048576 records in the db
RPRINT Congestion_CongestionDB: After test [1] there are 1024 records in the db
RPRINT Congestion_CongestionDB: After test [2] there are 2816 records in the db
RPRINT Congestion_CongestionDB: After test [3] there are 1048576 records in the 
db
REGRESSION_RESULT Congestion_CongestionDB:  PASSED
REGRESSION TEST Congestion_FailHistory started
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 2612 , sum = 2612
RPRINT Congestion_FailHistory: bucket 1 => events 3974 , sum = 6586
RPRINT Congestion_FailHistory: bucket 2 => events 4015 , sum = 10601
RPRINT Congestion_FailHistory: bucket 3 => events 3855 , sum = 14456
RPRINT Congestion_FailHistory: bucket 4 => events 4029 , sum = 18485
RPRINT Congestion_FailHistory: bucket 5 => events 4023 , sum = 22508
RPRINT Congestion_FailHistory: bucket 6 => events 3828 , sum = 26336
RPRINT Congestion_FailHistory: bucket 7 => events 3855 , sum = 30191
RPRINT Congestion_FailHistory: bucket 8 => events 3914 , sum = 34105
RPRINT Congestion_FailHistory: bucket 9 => events 3864 , sum = 37969
RPRINT Congestion_FailHistory: bucket 10 => events 3926 , sum = 41895
RPRINT Congestion_FailHistory: bucket 11 => events 4018 , sum = 45913
RPRINT Congestion_FailHistory: bucket 12 => events 3957 , sum = 49870
RPRINT Congestion_FailHistory: bucket 13 => events 3935 , sum = 53805
RPRINT Congestion_FailHistory: bucket 14 => events 3959 , sum = 57764
RPRINT Congestion_FailHistory: bucket 15 => events 3869 , sum = 61633
RPRINT Congestion_FailHistory: bucket 16 => events 3903 , sum = 65536
Events: 65536, CurIndex: 0, LastEvent: 299, HistLen: 306, BinLen: 18, Start: 0
RPRINT Congestion_FailHistory: 233|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:03:53|0|299|65536|1|0
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 961 , sum = 961
RPRINT Congestion_FailHistory: bucket 1 => events 978 , sum = 1939
RPRINT Congestion_FailHistory: bucket 2 => events 602 , sum = 2541
RPRINT Congestion_FailHistory: bucket 3 => events 1011 , sum = 3552
RPRINT Congestion_FailHistory: bucket 4 => events 956 , sum = 4508
RPRINT Congestion_FailHistory: bucket 5 => events 1019 , sum = 5527
RPRINT Congestion_FailHistory: bucket 6 => events 992 , sum = 6519
RPRINT Congestion_FailHistory: bucket 7 => events 969 , sum = 7488
RPRINT Congestion_FailHistory: bucket 8 => events 1009 , sum = 8497
RPRINT Congestion_FailHistory: bucket 9 => events 950 , sum = 9447
RPRINT Congestion_FailHistory: bucket 10 => events 976 , sum = 10423
RPRINT Congestion_FailHistory: bucket 11 => events 974 , sum = 11397
RPRINT Congestion_FailHistory: bucket 12 => events 1007 , sum = 12404
RPRINT Congestion_FailHistory: bucket 13 => events 955 , sum = 13359
RPRINT Congestion_FailHistory: bucket 14 => events 998 , sum = 14357
RPRINT Congestion_FailHistory: bucket 15 => events 983 , sum = 15340
RPRINT Congestion_FailHistory: bucket 16 => events 1044 , sum = 16384
Events: 16384, CurIndex: 2, LastEvent: 2999, HistLen: 306, BinLen: 18, Start: 
2700
RPRINT Congestion_FailHistory: 2997|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:49:57|0|2999|16384|1|0
REGRESSION_RESULT Congestion_FailHistory:   PASSED
REGRESSION TEST Congestion_HashTable started

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/295/ for details.
 



> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Commented] (TS-4100) remove XML statistics

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4100:


Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/705
  
Ok, [TS-4119](https://issues.apache.org/jira/browse/TS-4119) is fixed. How 
do people feel about landing this? Please read my upgrade comments above :)


> remove XML statistics
> -
>
> Key: TS-4100
> URL: https://issues.apache.org/jira/browse/TS-4100
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Once TS-4099 lands, remove the XML statistics and corresponding code in the 
> {{StatsProcessor}}.



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

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/186/ for details.
 



> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/294/ for details.
 



> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Resolved] (TS-4119) LuaJIT and ASAN do not work well together

[James Peach (JIRA)]

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

James Peach resolved TS-4119.
-
Resolution: Fixed

> LuaJIT and ASAN do not work well together
> -
>
> Key: TS-4119
> URL: https://issues.apache.org/jira/browse/TS-4119
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> This is a long outstanding issue, where LuaJIT and ASAN is not cooperating 
> well. I see two options to this:
> 1) We fix LuaJIT.
> 2) We continue to make LuaJIT optional, with an option to compile with 
> regular Lua libraries.
> #2 is probably the easiest, at the price of worse performance. The downside 
> being that we don't test LuaJIT under ASAN.



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

[jira] [Commented] (TS-4119) LuaJIT and ASAN do not work well together

[ASF subversion and git services (JIRA)]

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

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

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

TS-4119: Don't apply any compiler sanitizers to LuaJIT.


> LuaJIT and ASAN do not work well together
> -
>
> Key: TS-4119
> URL: https://issues.apache.org/jira/browse/TS-4119
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> This is a long outstanding issue, where LuaJIT and ASAN is not cooperating 
> well. I see two options to this:
> 1) We fix LuaJIT.
> 2) We continue to make LuaJIT optional, with an option to compile with 
> regular Lua libraries.
> #2 is probably the easiest, at the price of worse performance. The downside 
> being that we don't test LuaJIT under ASAN.



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

[jira] [Assigned] (TS-4119) LuaJIT and ASAN do not work well together

[James Peach (JIRA)]

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

James Peach reassigned TS-4119:
---

Assignee: James Peach

> LuaJIT and ASAN do not work well together
> -
>
> Key: TS-4119
> URL: https://issues.apache.org/jira/browse/TS-4119
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> This is a long outstanding issue, where LuaJIT and ASAN is not cooperating 
> well. I see two options to this:
> 1) We fix LuaJIT.
> 2) We continue to make LuaJIT optional, with an option to compile with 
> regular Lua libraries.
> #2 is probably the easiest, at the price of worse performance. The downside 
> being that we don't test LuaJIT under ASAN.



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

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/720
  
Ping @bgaff @SolidWallOfCode 


> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Commented] (TS-4560) C++ API should not depend on ink_autoconf.h

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4560:


GitHub user jpeach opened a pull request:

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

TS-4560: Fix C++ API shared_ptr detection.

Since ink_autoconf.h is not installed, we can't use it to figure
out which shared_ptr implementation to use. Further, Traffic Server
might not have been built with the same toolchain that 3rd party
plugins are using.

Since shared_ptr is used in the C++ API headers, both Traffic Server
and the plugins need to agree on which implementation to use. The
best (but not perfect) solution is to hardcode it into the header
file during the Traffic Server build. This means that both parties
are consistent and any remaining problems could be attributed to
C++ standard library compatibility.

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

$ git pull https://github.com/jpeach/trafficserver fix/4560

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

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


commit b9c29f62db44573e390a203123c864f71fdf935f
Author: James Peach 
Date:   2016-06-16T23:51:40Z

TS-4560: Fix C++ API shared_ptr detection.

Since ink_autoconf.h is not installed, we can't use it to figure
out which shared_ptr implementation to use. Further, Traffic Server
might not have been built with the same toolchain that 3rd party
plugins are using.

Since shared_ptr is used in the C++ API headers, both Traffic Server
and the plugins need to agree on which implementation to use. The
best (but not perfect) solution is to hardcode it into the header
file during the Traffic Server build. This means that both parties
are consistent and any remaining problems could be attributed to
C++ standard library compatibility.




> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Assigned] (TS-4560) C++ API should not depend on ink_autoconf.h

[James Peach (JIRA)]

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

James Peach reassigned TS-4560:
---

Assignee: James Peach  (was: Brian Geffon)

> C++ API should not depend on ink_autoconf.h
> ---
>
> Key: TS-4560
> URL: https://issues.apache.org/jira/browse/TS-4560
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> {{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
> not installed (and must not be installed). This makes it impossible for 
> people to consume the C++ API.
> It is totally reasonable IMHO to expect to be able to build plugins with a 
> different toolchain than Traffic Server was built with. Consider installing 
> {{devtoolset-3}} and building plugins against a distribution package, or 
> building plugins with clang. 



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

[jira] [Created] (TS-4560) C++ API should not depend on ink_autoconf.h

[James Peach (JIRA)]

James Peach created TS-4560:
---

 Summary: C++ API should not depend on ink_autoconf.h
 Key: TS-4560
 URL: https://issues.apache.org/jira/browse/TS-4560
 Project: Traffic Server
  Issue Type: Bug
  Components: CPP API
Reporter: James Peach
Assignee: Brian Geffon


{{atscppapi/shared_ptr.h}} includes {{ink_autoconf.h}}. {{ink_autoconf.h}} is 
not installed (and must not be installed). This makes it impossible for people 
to consume the C++ API.

It is totally reasonable IMHO to expect to be able to build plugins with a 
different toolchain than Traffic Server was built with. Consider installing 
{{devtoolset-3}} and building plugins against a distribution package, or 
building plugins with clang. 



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

[jira] [Updated] (TS-4556) Plugin::handleSelectAlt looks implausible

[Leif Hedstrom (JIRA)]

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

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

> Plugin::handleSelectAlt looks implausible
> -
>
> Key: TS-4556
> URL: https://issues.apache.org/jira/browse/TS-4556
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Brian Geffon
> Fix For: sometime
>
>
> The {{Plugin::handleSelectAlt}} callback gets a transaction pointer but the 
> {{TS_HTTP_SELECT_ALT_HOOK}} hook gets a {{TSHttpAltInfo}} not a 
> {{TSHttpTxn}}. I didn't see any code that would handle this.:r 



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

[jira] [Updated] (TS-4539) the mutex of server_vc is not set while server_session reuse.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4539:
--
Assignee: Oknet Xu

> the mutex of server_vc is not set while server_session reuse.
> -
>
> Key: TS-4539
> URL: https://issues.apache.org/jira/browse/TS-4539
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>
> NetAccept got a client_vc and call new_ProxyMutex() to assign a mutex.
> And the HttpClientSession, HttpSM, HttpServerSession, server_vc also share 
> the same mutex.
> The HttpServerSession and server_vc will put into ServerSessionPool and may 
> assign to next new client_vc.
> The HttpSM::attach_server_session() only set the mutex of HttpServerSession 
> to the mutex of HttpSM after get a HttpServerSession from ServerSessionPool.
> But it forget to set the mutex of server_vc to the mutex of HttpSM.
>  
> {code}
> void
> HttpSM::attach_server_session(HttpServerSession *s)
> {
>   hsm_release_assert(server_session == NULL);
>   hsm_release_assert(server_entry == NULL);
>   hsm_release_assert(s->state == HSS_ACTIVE);
>   server_session = s; 
>   server_session->transact_count++;
>   // Set the mutex so that we have something to update
>   //   stats with
>   server_session->mutex = this->mutex;
> {code}
> But I can not found any issue, Is it by design?
> Or it is hard to locate the problem, due to my limited knowedge on HttpSM.



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

[jira] [Updated] (TS-4549) generate code coverage day in CI

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4549:
--
Fix Version/s: Infrastructure

> generate code coverage day in CI
> 
>
> Key: TS-4549
> URL: https://issues.apache.org/jira/browse/TS-4549
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: CI
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: Infrastructure
>
>
> Now that the {{--coverage}} build option works, it would be great to use 
> {{lcov}} to generate some coverage data in CI.
> I think that the gist go it would be something like this:
> {code}
> lcov --directory $PREFIX --zerocounters
> ... run tests or something here ...
> lcov --directory $PREFIX --capture --output-file coverage.info
> lcov --summary coverage.info
> {code}



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

[jira] [Updated] (TS-4544) Plugin can create cores with TSHttpSMCallback in stack

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4544:
--
Labels: 7  (was: )

> Plugin can create cores with TSHttpSMCallback in stack
> --
>
> Key: TS-4544
> URL: https://issues.apache.org/jira/browse/TS-4544
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Plugins
>Reporter: Susan Hinrichs
>Assignee: Alan M. Carroll
>  Labels: 7
>
> With a new plugin, we started seeing cores like the following.  The 
> TSHttpSMCallback is being called on a deleted HttpSM.  Looking at the code, 
> there is no logic to cancel the Callback when the state machine goes down.  
> {code}
> (gdb) bt
> #0  0x003bf5832625 in raise () from /lib64/libc.so.6
> #1  0x003bf5833d8d in abort () from /lib64/libc.so.6
> #2  0x2b832a17765d in ink_die_die_die () at ink_error.cc:43
> #3  0x2b832a177714 in ink_fatal_va(const char *, typedef __va_list_tag 
> __va_list_tag *) (
> fmt=0x2b832a188328 "%s:%d: failed assert `%s`", ap=0x2b8343b88a90) at 
> ink_error.cc:65
> #4  0x2b832a1777d9 in ink_fatal (message_format=0x2b832a188328 "%s:%d: 
> failed assert `%s`")
> at ink_error.cc:73
> #5  0x2b832a174ee6 in _ink_assert (expression=0x7db71e "magic == 
> HTTP_SM_MAGIC_ALIVE", 
> file=0x7db114 "HttpSM.cc", line=1385) at ink_assert.cc:37
> #6  0x005ee921 in HttpSM::state_api_callback (this=0x2b870ac2fb90, 
> event=60001, data=0x0)
> at HttpSM.cc:1385
> #7  0x005408dd in TSHttpSMCallback::event_handler 
> (this=0x2b8380065ab0) at InkAPI.cc:5618
> #8  0x00515330 in Continuation::handleEvent (this=0x2b8380065ab0, 
> event=1, data=0x2b8598013180)
> at ../iocore/eventsystem/I_Continuation.h:150
> #9  0x007a587e in EThread::process_event (this=0x2b83377ca010, 
> e=0x2b8598013180, calling_code=1)
> at UnixEThread.cc:145
> #10 0x007a5c1d in EThread::execute_regular (this=0x2b83377ca010) at 
> UnixEThread.cc:212
> #11 0x007a5ff4 in EThread::execute (this=0x2b83377ca010) at 
> UnixEThread.cc:304
> #12 0x007a4bad in spawn_thread_internal (a=0x2a99f80) at Thread.cc:85
> #13 0x2b832a3d3aa1 in start_thread () from /lib64/libpthread.so.0
> #14 0x003bf58e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Created] (TS-4559) ASAN leaks / errors in traffic_manager (on exit)

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4559:
-

 Summary: ASAN leaks / errors in traffic_manager (on exit)
 Key: TS-4559
 URL: https://issues.apache.org/jira/browse/TS-4559
 Project: Traffic Server
  Issue Type: Bug
  Components: Manager
Reporter: Leif Hedstrom


When we exit manager, ASAN trips on a few things, it'd be nice if we had a 
clean shutdown on traffic_manager.

{code}
=
==14870==ERROR: AddressSanitizer: attempting double-free on 0x61902d80 in 
thread T0 ([ET_NET 0]):
==14870==WARNING: readlink("/proc/self/exe") failed with errno 13, some stack 
frames may not be symbolized
#0 0x2ac4a4efddca  (/opt/gcc5/lib/../lib64/libasan.so.2+0x93dca)
#1 0x2ac4a8bf3e8f  (/lib64/libc.so.6+0x38e8f)
#2 0x2ac4a8bf3eb4  (/lib64/libc.so.6+0x38eb4)
#3 0x58cc0b  (/proc/self/exe+0x58cc0b)
#4 0x2ac4a7f280ff  (/lib64/libpthread.so.0+0xf0ff)
#5 0x2ac4a8cb22c2  (/lib64/libc.so.6+0xf72c2)
#6 0xc8fde6  (/proc/self/exe+0xc8fde6)
#7 0xd80203  (/proc/self/exe+0xd80203)
#8 0xd831aa  (/proc/self/exe+0xd831aa)
#9 0x49b36e  (/proc/self/exe+0x49b36e)
#10 0x2ac4a8bdcb14  (/lib64/libc.so.6+0x21b14)
#11 0x4aacc4  (/proc/self/exe+0x4aacc4)

0x61902d80 is located 0 bytes inside of 1040-byte region 
[0x61902d80,0x61903190)
freed by thread T1 here:
#0 0x2ac4a4efddca  (/opt/gcc5/lib/../lib64/libasan.so.2+0x93dca)
#1 0x2ac4a8bf3e8f  (/lib64/libc.so.6+0x38e8f)

previously allocated by thread T0 ([ET_NET 0]) here:
#0 0x2ac4a4efe1d1  (/opt/gcc5/lib/../lib64/libasan.so.2+0x941d1)
#1 0x2ac4a8bf4043  (/lib64/libc.so.6+0x39043)

Thread T1 created by T0 ([ET_NET 0]) here:
#0 0x2ac4a4ea00c4  (/opt/gcc5/lib/../lib64/libasan.so.2+0x360c4)
#1 0x498ee5  (/proc/self/exe+0x498ee5)
#2 0x2ac4a8bdcb14  (/lib64/libc.so.6+0x21b14)

SUMMARY: AddressSanitizer: double-free ??:0 ??
==14870==ABORTING
[TrafficManager] ==> signal #2

=
==14864==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8964 byte(s) in 249 object(s) allocated from:
#0 0x7faab3c7006a in __interceptor_malloc 
../../../../libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x7faab1f3281f in cap_init (/lib64/libcap.so.2+0x181f)
#2 0x7faab39a1d2e in ElevateAccess::ElevateAccess(unsigned int) 
/usr/local/src/trafficserver/lib/ts/ink_cap.cc:413
#3 0x48aa7f in Rollback::statFile(int, stat*) 
/usr/local/src/trafficserver/mgmt/Rollback.cc:267
#4 0x48ea10 in Rollback::checkForUserUpdate(RollBackCheckType) 
/usr/local/src/trafficserver/mgmt/Rollback.cc:911
#5 0x481adf in FileManager::isConfigStale() 
/usr/local/src/trafficserver/mgmt/FileManager.cc:690
#6 0x50c697 in sync_thr 
/usr/local/src/trafficserver/lib/records/RecLocal.cc:106
#7 0x7faab1449dc4 in start_thread (/lib64/libpthread.so.0+0x7dc4)

Direct leak of 6361 byte(s) in 208 object(s) allocated from:
#0 0x7faab3c7006a in __interceptor_malloc 
../../../../libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x7faab39aaaf5 in ats_malloc 
/usr/local/src/trafficserver/lib/ts/ink_memory.cc:59
#2 0x7faab39ab036 in _xstrdup 
/usr/local/src/trafficserver/lib/ts/ink_memory.cc:268
#3 0x55cf74 in lua_metrics_new(char const*, lua_State*) 
/usr/local/src/trafficserver/lib/bindings/metrics.cc:186
#4 0x55d3c6 in lua_metrics_install(lua_State*) 
/usr/local/src/trafficserver/lib/bindings/metrics.cc:230
#5 0x447576 in update_metrics_namespace 
/usr/local/src/trafficserver/cmd/traffic_manager/metrics.cc:162
#6 0x447576 in metrics_binding_evaluate(BindingInstance&) 
/usr/local/src/trafficserver/cmd/traffic_manager/metrics.cc:372
#7 0x431b48 in main 
/usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:807
#8 0x7faab061bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)

Direct leak of 842 byte(s) in 30 object(s) allocated from:
#0 0x7faab3c7006a in __interceptor_malloc 
../../../../libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x7faab39aaaf5 in ats_malloc 
/usr/local/src/trafficserver/lib/ts/ink_memory.cc:59
#2 0x7faab39ab036 in _xstrdup 
/usr/local/src/trafficserver/lib/ts/ink_memory.cc:268
#3 0x55cf74 in lua_metrics_new(char const*, lua_State*) 
/usr/local/src/trafficserver/lib/bindings/metrics.cc:186
#4 0x55d3c6 in lua_metrics_install(lua_State*) 
/usr/local/src/trafficserver/lib/bindings/metrics.cc:230
#5 0x446b12 in update_metrics_namespace 
/usr/local/src/trafficserver/cmd/traffic_manager/metrics.cc:162
#6 0x446b12 in metrics_binding_initialize(BindingInstance&) 
/usr/local/src/trafficserver/cmd/traffic_manager/metrics.cc:330
#7 0x431a00 in main 
/usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:757
#8 0x7faab061bb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)

Direct leak of 432 byte(s) in 6 object(s) 

Build failed in Jenkins: docs-master #76

[jenkins]

See 

Changes:

[jsime] TS-4377: update documentation links in default configuration files

[jsime] use shortened doc link in opening comment and remove errant character

--
[...truncated 3145 lines...]
developer-guide/api/functions/TSMgmtFloatGet.en.html
developer-guide/api/functions/TSMgmtIntGet.en.html
developer-guide/api/functions/TSMgmtStringGet.en.html
developer-guide/api/functions/TSMgmtUpdateRegister.en.html
developer-guide/api/functions/TSMimeHdrClone.en.html
developer-guide/api/functions/TSMimeHdrCopy.en.html
developer-guide/api/functions/TSMimeHdrCreate.en.html
developer-guide/api/functions/TSMimeHdrDestroy.en.html
developer-guide/api/functions/TSMimeHdrFieldAppend.en.html
developer-guide/api/functions/TSMimeHdrFieldClone.en.html
developer-guide/api/functions/TSMimeHdrFieldCopy.en.html
developer-guide/api/functions/TSMimeHdrFieldCopyValues.en.html
developer-guide/api/functions/TSMimeHdrFieldCreate.en.html
developer-guide/api/functions/TSMimeHdrFieldDestroy.en.html
developer-guide/api/functions/TSMimeHdrFieldFind.en.html
developer-guide/api/functions/TSMimeHdrFieldGet.en.html
developer-guide/api/functions/TSMimeHdrFieldLengthGet.en.html
developer-guide/api/functions/TSMimeHdrFieldNameGet.en.html
developer-guide/api/functions/TSMimeHdrFieldNameSet.en.html
developer-guide/api/functions/TSMimeHdrFieldNext.en.html
developer-guide/api/functions/TSMimeHdrFieldNextDup.en.html
developer-guide/api/functions/TSMimeHdrFieldRemove.en.html
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en.html
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en.html
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en.html
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en.html
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en.html
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en.html
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en.html
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en.html
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en.html
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en.html
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en.html
developer-guide/api/functions/TSMimeHdrFieldsClear.en.html
developer-guide/api/functions/TSMimeHdrFieldsCount.en.html
developer-guide/api/functions/TSMimeHdrLengthGet.en.html
developer-guide/api/functions/TSMimeHdrParse.en.html
developer-guide/api/functions/TSMimeHdrPrint.en.html
developer-guide/api/functions/TSMimeParserClear.en.html
developer-guide/api/functions/TSMimeParserCreate.en.html
developer-guide/api/functions/TSMimeParserDestroy.en.html
developer-guide/api/functions/TSMutexCreate.en.html
developer-guide/api/functions/TSMutexDestroy.en.html
developer-guide/api/functions/TSMutexLock.en.html
developer-guide/api/functions/TSMutexLockTry.en.html
developer-guide/api/functions/TSMutexUnlock.en.html
developer-guide/api/functions/TSNetAccept.en.html
developer-guide/api/functions/TSNetAcceptNamedProtocol.en.html
developer-guide/api/functions/TSNetConnect.en.html
developer-guide/api/functions/TSPluginInit.en.html
developer-guide/api/functions/TSRemap.en.html
developer-guide/api/functions/TSSslContextFindBy.en.html
developer-guide/api/functions/TSSslServerContextCreate.en.html
developer-guide/api/functions/TSTextLogObjectCreate.en.html
developer-guide/api/functions/TSThreadCreate.en.html
developer-guide/api/functions/TSThreadDestroy.en.html
developer-guide/api/functions/TSThreadInit.en.html
developer-guide/api/functions/TSThreadSelf.en.html
developer-guide/api/functions/TSTrafficServerVersionGet.en.html
developer-guide/api/functions/TSTransformCreate.en.html
developer-guide/api/functions/TSTransformOutputVConnGet.en.html
developer-guide/api/functions/TSTypes.en.html
developer-guide/api/functions/TSUrlCreate.en.html
developer-guide/api/functions/TSUrlDestroy.en.html
developer-guide/api/functions/TSUrlFtpTypeGet.en.html
developer-guide/api/functions/TSUrlFtpTypeSet.en.html
developer-guide/api/functions/TSUrlHostGet.en.html
developer-guide/api/functions/TSUrlHostSet.en.html
developer-guide/api/functions/TSUrlPercentEncode.en.html
developer-guide/api/functions/TSUrlStringGet.en.html
developer-guide/api/functions/TSVConnAbort.en.html
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en.html
developer-guide/api/functions/TSVConnClose.en.html
developer-guide/api/functions/TSVConnClosedGet.en.html
developer-guide/api/functions/TSVConnFdCreate.en.html
developer-guide/api/functions/TSVConnIsSsl.en.html
developer-guide/api/functions/TSVConnRead.en.html
developer-guide/api/functions/TSVConnReadVIOGet.en.html
developer-guide/api/functions/TSVConnReenable.en.html
developer-guide/api/functions/TSVConnShutdown.en.html
developer-guide/api/functions/TSVConnSslConnectionGet.en.html
developer-guide/api/functions/TSVConnTunnel.en.html

[jira] [Commented] (TS-4377) fix records.config template links

[ASF subversion and git services (JIRA)]

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

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

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

TS-4377: update documentation links in default configuration files


> fix records.config template links
> -
>
> Key: TS-4377
> URL: https://issues.apache.org/jira/browse/TS-4377
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: James Peach
>Assignee: Jon Sime
> Fix For: Docs
>
>
> The documentation links in the default {{records.config}} are stale. We 
> should update these to the current documentation layout. While we are at it, 
> each config file should have a link to its online documentation.



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

[jira] [Commented] (TS-4377) fix records.config template links

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4377:


Github user jsime closed the pull request at:

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


> fix records.config template links
> -
>
> Key: TS-4377
> URL: https://issues.apache.org/jira/browse/TS-4377
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: James Peach
>Assignee: Jon Sime
> Fix For: Docs
>
>
> The documentation links in the default {{records.config}} are stale. We 
> should update these to the current documentation layout. While we are at it, 
> each config file should have a link to its online documentation.



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

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

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-1257:
---
Assignee: Syeda Persia Aziz  (was: Alan M. Carroll)

> 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: Syeda Persia Aziz
> 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-4558) ASAN buffer overflow in traffic_manager -h

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4558:
--
Fix Version/s: 7.0.0

> ASAN buffer overflow in traffic_manager -h
> --
>
> Key: TS-4558
> URL: https://issues.apache.org/jira/browse/TS-4558
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> {code}
> [root@qa1 ats]# ./bin/traffic_manager  -h
> Usage: traffic_manager [--SWITCH [ARG]]
>   switch__type__default___description
>   --proxyOff  on   
> =
> ==14425==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x0089fd40 at pc 0x7fd0aef80b5e bp 0x7ffe0d210590 sp 0x7ffe0d210588
> READ of size 4 at 0x0089fd40 thread T0
> #0 0x7fd0aef80b5d in usage(ArgumentDescription const*, unsigned int, char 
> const*) /usr/local/src/trafficserver/lib/ts/ink_args.cc:323
> #1 0x7fd0aef7f5c7 in process_arg 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:122
> #2 0x7fd0aef80135 in process_args_ex(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:237
> #3 0x7fd0aef80bba in process_args(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**, char const*) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:166
> #4 0x4305a4 in main 
> /usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:481
> #5 0x7fd0abbfdb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #6 0x4343e4  (/opt/ats/bin/traffic_manager+0x4343e4)
> 0x0089fd41 is located 0 bytes to the right of global variable 'proxy_off' 
> defined in 'traffic_manager.cc:86:13' (0x89fd40) of size 1
>   'proxy_off' is ascii string ''
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:323 usage(ArgumentDescription 
> const*, unsigned int, char const*)
> Shadow bytes around the buggy address:
>   0x8010bf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x8010bfa0: 00 00 00 00 f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9
>   0x8010bfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Heap right redzone:  fb
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack partial redzone:   f4
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
> ==14425==ABORTING
> {code}



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

[jira] [Created] (TS-4558) ASAN buffer overflow in traffic_manager -h

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4558:
-

 Summary: ASAN buffer overflow in traffic_manager -h
 Key: TS-4558
 URL: https://issues.apache.org/jira/browse/TS-4558
 Project: Traffic Server
  Issue Type: Bug
  Components: Manager
Reporter: Leif Hedstrom


{code}
[root@qa1 ats]# ./bin/traffic_manager  -h
Usage: traffic_manager [--SWITCH [ARG]]
  switch__type__default___description
  --proxyOff  on   
=
==14425==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x0089fd40 at pc 0x7fd0aef80b5e bp 0x7ffe0d210590 sp 0x7ffe0d210588
READ of size 4 at 0x0089fd40 thread T0
#0 0x7fd0aef80b5d in usage(ArgumentDescription const*, unsigned int, char 
const*) /usr/local/src/trafficserver/lib/ts/ink_args.cc:323
#1 0x7fd0aef7f5c7 in process_arg 
/usr/local/src/trafficserver/lib/ts/ink_args.cc:122
#2 0x7fd0aef80135 in process_args_ex(AppVersionInfo const*, 
ArgumentDescription const*, unsigned int, char const**) 
/usr/local/src/trafficserver/lib/ts/ink_args.cc:237
#3 0x7fd0aef80bba in process_args(AppVersionInfo const*, 
ArgumentDescription const*, unsigned int, char const**, char const*) 
/usr/local/src/trafficserver/lib/ts/ink_args.cc:166
#4 0x4305a4 in main 
/usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:481
#5 0x7fd0abbfdb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
#6 0x4343e4  (/opt/ats/bin/traffic_manager+0x4343e4)

0x0089fd41 is located 0 bytes to the right of global variable 'proxy_off' 
defined in 'traffic_manager.cc:86:13' (0x89fd40) of size 1
  'proxy_off' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow 
/usr/local/src/trafficserver/lib/ts/ink_args.cc:323 usage(ArgumentDescription 
const*, unsigned int, char const*)
Shadow bytes around the buggy address:
  0x8010bf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bf60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bf90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x8010bfa0: 00 00 00 00 f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9
  0x8010bfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x8010bff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
==14425==ABORTING
{code}




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

[jira] [Resolved] (TS-4557) Plugin::handleSelectAlt looks implausible

[James Peach (JIRA)]

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

James Peach resolved TS-4557.
-
Resolution: Duplicate

> Plugin::handleSelectAlt looks implausible
> -
>
> Key: TS-4557
> URL: https://issues.apache.org/jira/browse/TS-4557
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Brian Geffon
>
> The {{Plugin::handleSelectAlt}} callback gets a transaction pointer but the 
> {{TS_HTTP_SELECT_ALT_HOOK}} hook gets a {{TSHttpAltInfo}} not a 
> {{TSHttpTxn}}. I didn't see any code that would handle this.:r 



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

[jira] [Created] (TS-4557) Plugin::handleSelectAlt looks implausible

[James Peach (JIRA)]

James Peach created TS-4557:
---

 Summary: Plugin::handleSelectAlt looks implausible
 Key: TS-4557
 URL: https://issues.apache.org/jira/browse/TS-4557
 Project: Traffic Server
  Issue Type: Bug
  Components: CPP API
Reporter: James Peach
Assignee: Brian Geffon


The {{Plugin::handleSelectAlt}} callback gets a transaction pointer but the 
{{TS_HTTP_SELECT_ALT_HOOK}} hook gets a {{TSHttpAltInfo}} not a {{TSHttpTxn}}. 
I didn't see any code that would handle this.:r 



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

[jira] [Updated] (TS-4555) C++ API takes a transaction argument without allocating it

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4555:
--
Fix Version/s: 7.0.0

> C++ API takes a transaction argument without allocating it
> --
>
> Key: TS-4555
> URL: https://issues.apache.org/jira/browse/TS-4555
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>
> {code}
> Transaction &
> utils::internal::getTransaction(TSHttpTxn ats_txn_handle)
> {
>   Transaction *transaction = static_cast *>(TSHttpTxnArgGet(ats_txn_handle, TRANSACTION_STORAGE_INDEX));
>   if (!transaction) {
> transaction = new Transaction(static_cast(ats_txn_handle));
> LOG_DEBUG("Created new transaction object at %p for ats pointer %p", 
> transaction, ats_txn_handle);
> TSHttpTxnArgSet(ats_txn_handle, TRANSACTION_STORAGE_INDEX, transaction);
>   }
>   return *transaction;
> }
> {code}
> {{TRANSACTION_STORAGE_INDEX}} is hardcoded constant that is not allocated by 
> {{TSHttpArgIndexReserve}}, so it is subject to collisions with other plugins.



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

[jira] [Commented] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4523:


Github user ushachar commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
[approve ci]


> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[jira] [Commented] (TS-4500) add cookie-rewrite functionality into header-rewrite plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4500:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/692
  
Looks good. One more thing, didn't think about it last time: The 
update-cookie, will that work if the cookie doesn't already exist? If so, can 
we call it set-cookie instead? This is in line with our existing set-header / 
add-header operators. update-cookie sounds like it'd only work if the cookie 
value already exist, which seems harder to use than just a set-cookie which 
will overwrite any existing value for the cookie (whereas add-cookie should add 
it regardless I think?).


> add cookie-rewrite functionality into header-rewrite plugin
> ---
>
> Key: TS-4500
> URL: https://issues.apache.org/jira/browse/TS-4500
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Zhang Zizhong
>Assignee: Zhang Zizhong
> Fix For: 7.0.0
>
>
> add cookie-rewrite functionality into header-rewrite plugin.
> There're three cookie handling operators added, including *add-cookie*, 
> *rm-cookie* and *update-cookie*.
> *add-cookie* adds a key-value pair into Cookie. If the given key is already 
> in Cookie, do nothing.
> *rm-cookie* remove a pair with the given key from Cookie.
> *update-cookie* sets the value with the given key to the given value. If the 
> given key doesn't exist, add a new pair into Cookie. So the only difference 
> between *add-cookie* and *update-cookie* is overwriting an existing pair or 
> not.



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

[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[David Ben Zakai (JIRA)]

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

David Ben Zakai updated TS-4523:

Description: 
I'd like to suggest an API change in the CPP API Transformation interface.

My own use case is that I'd like to be able to pause the transformation, handle 
what I can from the file and release the buffered content before resuming and 
releasing the rest of the data.
Basically what I'm trying to achieve:
Write data to file (up to a certain amount)
File analysis
Produce file data (and any leftovers) downstream
When the file size reaches a certain size limit I'd like to be able to pause 
the transformation and produce all of its content downstream and then resume 
the transformation.

API Changes:
TransformationPlugin.h:
/**
* Call this method if you wish to pause the transformation.
* Schedule the return value continuation to resume the transforamtion.
* If the continuation is scheduled and called after the transform is destroyed 
it will 
* won't do anything beyond cleanups.
* Note: You must schedule the continuation or destroy it (using TSContDestroy) 
yourself, 
* otherwise it will leak.
*/
TSCont pause();

Internally, the continuation wraps the "resumeCallback" static function:
static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** Resume 
callback*/

Thank you!

  was:
I'd like to suggest an API change in the transformation plugin which will 
enable us to pause/resume a transformation.

My own use case is that I'd like to write all the incoming data into a file 
(for analysis) before producing it downstream, but I don't want the file to 
reach a certain size limit (When content-length is present its not an issue of 
course). Basically what I'm trying to achieve:
-Write all data to file
-File analysis
-Produce file data downstream
When the file size reaches a certain size limit I'd like to be able to pause 
the transformation and produce all of its content downstream and then resume 
the transformation.


> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[jira] [Commented] (TS-3474) HTTP/2 Server Push support in ATS

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-3474:
--

I will try out your rough patch next week. Thanks a lot.

> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP/2
>Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>
> I've done some preliminary analysis/prototype of SPDY server push support in 
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross 
> origin resource push (which is sort of critical in the way, our CDN works). 
> Wanted to open this Jira to share this info with the community and ask for 
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy 
> layer:
>  - Origin Driven
>  - Client Driven
>  - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as 
> special headers in the response to a base page, for instance. We are 
> exploring making use of the HTTP LINK header for this purpose. The proxy 
> would basically initiate PUSH streams to the client for the resources 
> identified by the LINK headers in the base page response and at the same 
> time, fetch those resources by initiating internal SPDY requests. There are a 
> few things to consider such as whether the pushable resources should be 
> limited to only cacheable resources? Whether non-https resources can be 
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and 
> ATS building dynamically a set of associated resources for a given base page 
> request url. Once such a list is built, the rest of the mechanism is similar 
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the 
> proxy extracting/unzipping/parsing the response body and identifying pushable 
> resources and initiating the push resources similar to the other approaches 
> above.  This is performance intensive and will need some optimizations in not 
> having to parse every response, but doing it based on some sort of 
> count/frequency of the access. 
> I did some prototyping and was able to push resources, but, realized there 
> are some stumbling blocks. For example, Chrome doesn't permit cross origin 
> HTTPS resources to be pushed (even if certs were presented for both the 
> original and push domain). See below email from Chrome indicating that they 
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being 
> rejected. The central reason is that the session isn't authenticated for the 
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's 
> declared associated stream. This is true even of a SPDY session which 
> presented certs & authenticated for both the associated & push origins: you 
> still need to arrange for an associated stream on the origin for which you'd 
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it 
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though 
> there are continuing conversations about how it might be done. It'd need to 
> be done very carefully.
> "
> {code}



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

[jira] [Commented] (TS-4553) Add Brotli compression support

[Cynthia Gu (JIRA)]

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

Cynthia Gu commented on TS-4553:


[~briang], sure, I'll take a look

> Add Brotli compression support
> --
>
> Key: TS-4553
> URL: https://issues.apache.org/jira/browse/TS-4553
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Plugins
>Reporter: David Calavera
> Fix For: sometime
>
>
> I think it would be very interesting to add support for the Brotli 
> compression format: https://github.com/google/brotli
> Since I didn't see any issue opened and went ahead so people can discuss 
> about it.



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

[jira] [Commented] (TS-4554) ASAN crash (stack overflow) with H2 priorities

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4554:


As I remember the dependency tree doesn't remove nodes.  There should a be a 
count of the number of nodes in the dependency tree and start removing nodes 
when it starts to get large.

> ASAN crash (stack overflow) with H2 priorities
> --
>
> Key: TS-4554
> URL: https://issues.apache.org/jira/browse/TS-4554
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Affects Versions: 7.0.0
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I'm seeing (truncated):
> {code}
> ASAN:SIGSEGV
> =
> ==11178==ERROR: AddressSanitizer: stack-overflow on address 0x2aab63633ff0 
> (pc 0x007ddaa9 bp 0x2aab63634050 sp 0x2aab63633ff0 T6)
> #0 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134
> #1 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> .
> .
> .
> #2261 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2262 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2263 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> SUMMARY: AddressSanitizer: stack-overflow 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int)
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x2aab5b0d50c4 in __interceptor_pthread_create 
> ../../../../libsanitizer/asan/asan_interceptors.cc:179
> #1 0xcfdb99 in ink_thread_create ../../lib/ts/ink_thread.h:147
> #2 0xcfdb99 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:99
> #3 0xd0562e in EventProcessor::start(int, unsigned long) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:140
> #4 0x497b59 in main /usr/local/src/trafficserver/proxy/Main.cc:1746
> #5 0x2aab5ee11b14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> ==11178==ABORTING
> {code}



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

[jira] [Commented] (TS-4554) ASAN crash (stack overflow) with H2 priorities

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4554:
---

This is from current (today) master.

> ASAN crash (stack overflow) with H2 priorities
> --
>
> Key: TS-4554
> URL: https://issues.apache.org/jira/browse/TS-4554
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Affects Versions: 7.0.0
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I'm seeing (truncated):
> {code}
> ASAN:SIGSEGV
> =
> ==11178==ERROR: AddressSanitizer: stack-overflow on address 0x2aab63633ff0 
> (pc 0x007ddaa9 bp 0x2aab63634050 sp 0x2aab63633ff0 T6)
> #0 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134
> #1 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> .
> .
> .
> #2261 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2262 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2263 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> SUMMARY: AddressSanitizer: stack-overflow 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int)
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x2aab5b0d50c4 in __interceptor_pthread_create 
> ../../../../libsanitizer/asan/asan_interceptors.cc:179
> #1 0xcfdb99 in ink_thread_create ../../lib/ts/ink_thread.h:147
> #2 0xcfdb99 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:99
> #3 0xd0562e in EventProcessor::start(int, unsigned long) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:140
> #4 0x497b59 in main /usr/local/src/trafficserver/proxy/Main.cc:1746
> #5 0x2aab5ee11b14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> ==11178==ABORTING
> {code}



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

[jira] [Updated] (TS-4554) ASAN crash (stack overflow) with H2 priorities

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4554:
--
Fix Version/s: 7.0.0

> ASAN crash (stack overflow) with H2 priorities
> --
>
> Key: TS-4554
> URL: https://issues.apache.org/jira/browse/TS-4554
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Affects Versions: 7.0.0
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I'm seeing (truncated):
> {code}
> ASAN:SIGSEGV
> =
> ==11178==ERROR: AddressSanitizer: stack-overflow on address 0x2aab63633ff0 
> (pc 0x007ddaa9 bp 0x2aab63634050 sp 0x2aab63633ff0 T6)
> #0 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134
> #1 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> .
> .
> .
> #2261 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2262 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2263 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> SUMMARY: AddressSanitizer: stack-overflow 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int)
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x2aab5b0d50c4 in __interceptor_pthread_create 
> ../../../../libsanitizer/asan/asan_interceptors.cc:179
> #1 0xcfdb99 in ink_thread_create ../../lib/ts/ink_thread.h:147
> #2 0xcfdb99 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:99
> #3 0xd0562e in EventProcessor::start(int, unsigned long) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:140
> #4 0x497b59 in main /usr/local/src/trafficserver/proxy/Main.cc:1746
> #5 0x2aab5ee11b14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> ==11178==ABORTING
> {code}



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

[jira] [Updated] (TS-4554) ASAN crash (stack overflow) with H2 priorities

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4554:
--
Affects Version/s: 7.0.0

> ASAN crash (stack overflow) with H2 priorities
> --
>
> Key: TS-4554
> URL: https://issues.apache.org/jira/browse/TS-4554
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Affects Versions: 7.0.0
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I'm seeing (truncated):
> {code}
> ASAN:SIGSEGV
> =
> ==11178==ERROR: AddressSanitizer: stack-overflow on address 0x2aab63633ff0 
> (pc 0x007ddaa9 bp 0x2aab63634050 sp 0x2aab63633ff0 T6)
> #0 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134
> #1 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2 0x7ddaa8 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> .
> .
> .
> #2261 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2262 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> #2263 0x7ddc34 in 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int) 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
> SUMMARY: AddressSanitizer: stack-overflow 
> /usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134 
> Http2DependencyTree::_find(Http2DependencyTree::Node*,
>  unsigned int)
> Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
> #0 0x2aab5b0d50c4 in __interceptor_pthread_create 
> ../../../../libsanitizer/asan/asan_interceptors.cc:179
> #1 0xcfdb99 in ink_thread_create ../../lib/ts/ink_thread.h:147
> #2 0xcfdb99 in Thread::start(char const*, unsigned long, void* 
> (*)(void*), void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:99
> #3 0xd0562e in EventProcessor::start(int, unsigned long) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:140
> #4 0x497b59 in main /usr/local/src/trafficserver/proxy/Main.cc:1746
> #5 0x2aab5ee11b14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> ==11178==ABORTING
> {code}



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

[jira] [Created] (TS-4554) ASAN crash (stack overflow) with H2 priorities

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4554:
-

 Summary: ASAN crash (stack overflow) with H2 priorities
 Key: TS-4554
 URL: https://issues.apache.org/jira/browse/TS-4554
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP/2
Reporter: Leif Hedstrom


I'm seeing (truncated):

{code}
ASAN:SIGSEGV
=
==11178==ERROR: AddressSanitizer: stack-overflow on address 0x2aab63633ff0 (pc 
0x007ddaa9 bp 0x2aab63634050 sp 0x2aab63633ff0 T6)
#0 0x7ddaa8 in 
Http2DependencyTree::_find(Http2DependencyTree::Node*,
 unsigned int) 
/usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134
#1 0x7ddaa8 in 
Http2DependencyTree::_find(Http2DependencyTree::Node*,
 unsigned int) 
/usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
#2 0x7ddaa8 in 
Http2DependencyTree::_find(Http2DependencyTree::Node*,
 unsigned int) 
/usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
.
.
.
#2261 0x7ddc34 in 
Http2DependencyTree::_find(Http2DependencyTree::Node*,
 unsigned int) 
/usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
#2262 0x7ddc34 in 
Http2DependencyTree::_find(Http2DependencyTree::Node*,
 unsigned int) 
/usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140
#2263 0x7ddc34 in 
Http2DependencyTree::_find(Http2DependencyTree::Node*,
 unsigned int) 
/usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:140

SUMMARY: AddressSanitizer: stack-overflow 
/usr/local/src/trafficserver/proxy/http2/Http2DependencyTree.h:134 
Http2DependencyTree::_find(Http2DependencyTree::Node*,
 unsigned int)
Thread T6 ([ET_NET 5]) created by T0 ([ET_NET 0]) here:
#0 0x2aab5b0d50c4 in __interceptor_pthread_create 
../../../../libsanitizer/asan/asan_interceptors.cc:179
#1 0xcfdb99 in ink_thread_create ../../lib/ts/ink_thread.h:147
#2 0xcfdb99 in Thread::start(char const*, unsigned long, void* (*)(void*), 
void*) /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:99
#3 0xd0562e in EventProcessor::start(int, unsigned long) 
/usr/local/src/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:140
#4 0x497b59 in main /usr/local/src/trafficserver/proxy/Main.cc:1746
#5 0x2aab5ee11b14 in __libc_start_main (/lib64/libc.so.6+0x21b14)

==11178==ABORTING
{code}



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

[jira] [Commented] (TS-4553) Add Brotli compression support

[Brian Geffon (JIRA)]

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

Brian Geffon commented on TS-4553:
--

yes I wrote a plugin to do this, [~cselcik] [~cynthiagu] can you guys open 
source it? obviously removing the LI specific stuff first?

> Add Brotli compression support
> --
>
> Key: TS-4553
> URL: https://issues.apache.org/jira/browse/TS-4553
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Plugins
>Reporter: David Calavera
> Fix For: sometime
>
>
> I think it would be very interesting to add support for the Brotli 
> compression format: https://github.com/google/brotli
> Since I didn't see any issue opened and went ahead so people can discuss 
> about it.



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

[jira] [Commented] (TS-4553) Add Brotli compression support

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4553:
---

One concern here (slight) is how the core deals with Vary on this particular 
brotli value. We have some shenanigans inside the core to deal with gzip and 
all the variants of that, such that we normalize all gzip-like CE: headers.

> Add Brotli compression support
> --
>
> Key: TS-4553
> URL: https://issues.apache.org/jira/browse/TS-4553
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Plugins
>Reporter: David Calavera
> Fix For: sometime
>
>
> I think it would be very interesting to add support for the Brotli 
> compression format: https://github.com/google/brotli
> Since I didn't see any issue opened and went ahead so people can discuss 
> about it.



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

[jira] [Updated] (TS-4553) Add Brotli compression support

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4553:
--
Component/s: Plugins

> Add Brotli compression support
> --
>
> Key: TS-4553
> URL: https://issues.apache.org/jira/browse/TS-4553
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Plugins
>Reporter: David Calavera
> Fix For: sometime
>
>
> I think it would be very interesting to add support for the Brotli 
> compression format: https://github.com/google/brotli
> Since I didn't see any issue opened and went ahead so people can discuss 
> about it.



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

[jira] [Updated] (TS-4553) Add Brotli compression support

[Leif Hedstrom (JIRA)]

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

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

> Add Brotli compression support
> --
>
> Key: TS-4553
> URL: https://issues.apache.org/jira/browse/TS-4553
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Plugins
>Reporter: David Calavera
> Fix For: sometime
>
>
> I think it would be very interesting to add support for the Brotli 
> compression format: https://github.com/google/brotli
> Since I didn't see any issue opened and went ahead so people can discuss 
> about it.



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

[jira] [Commented] (TS-4553) Add Brotli compression support

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4553:
---

I believe both [~oschaaf] and [~briang] have done work in this area?

> Add Brotli compression support
> --
>
> Key: TS-4553
> URL: https://issues.apache.org/jira/browse/TS-4553
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Plugins
>Reporter: David Calavera
> Fix For: sometime
>
>
> I think it would be very interesting to add support for the Brotli 
> compression format: https://github.com/google/brotli
> Since I didn't see any issue opened and went ahead so people can discuss 
> about it.



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

[jira] [Created] (TS-4553) Add Brotli compression support

[David Calavera (JIRA)]

David Calavera created TS-4553:
--

 Summary: Add Brotli compression support
 Key: TS-4553
 URL: https://issues.apache.org/jira/browse/TS-4553
 Project: Traffic Server
  Issue Type: Wish
Reporter: David Calavera


I think it would be very interesting to add support for the Brotli compression 
format: https://github.com/google/brotli

Since I didn't see any issue opened and went ahead so people can discuss about 
it.



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

[jira] [Commented] (TS-4500) add cookie-rewrite functionality into header-rewrite plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4500:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/692
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/292/ for details.
 



> add cookie-rewrite functionality into header-rewrite plugin
> ---
>
> Key: TS-4500
> URL: https://issues.apache.org/jira/browse/TS-4500
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Zhang Zizhong
>Assignee: Zhang Zizhong
> Fix For: 7.0.0
>
>
> add cookie-rewrite functionality into header-rewrite plugin.
> There're three cookie handling operators added, including *add-cookie*, 
> *rm-cookie* and *update-cookie*.
> *add-cookie* adds a key-value pair into Cookie. If the given key is already 
> in Cookie, do nothing.
> *rm-cookie* remove a pair with the given key from Cookie.
> *update-cookie* sets the value with the given key to the given value. If the 
> given key doesn't exist, add a new pair into Cookie. So the only difference 
> between *add-cookie* and *update-cookie* is overwriting an existing pair or 
> not.



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

[jira] [Commented] (TS-4500) add cookie-rewrite functionality into header-rewrite plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4500:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/692
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/184/ for details.
 



> add cookie-rewrite functionality into header-rewrite plugin
> ---
>
> Key: TS-4500
> URL: https://issues.apache.org/jira/browse/TS-4500
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Zhang Zizhong
>Assignee: Zhang Zizhong
> Fix For: 7.0.0
>
>
> add cookie-rewrite functionality into header-rewrite plugin.
> There're three cookie handling operators added, including *add-cookie*, 
> *rm-cookie* and *update-cookie*.
> *add-cookie* adds a key-value pair into Cookie. If the given key is already 
> in Cookie, do nothing.
> *rm-cookie* remove a pair with the given key from Cookie.
> *update-cookie* sets the value with the given key to the given value. If the 
> given key doesn't exist, add a new pair into Cookie. So the only difference 
> between *add-cookie* and *update-cookie* is overwriting an existing pair or 
> not.



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/719
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/290/ for details.
 



> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/719
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/182/ for details.
 



> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4552) Lifecycle hook on cache disk state change

[James Peach (JIRA)]

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

James Peach commented on TS-4552:
-

Are there metrics for the number of healthy disks, bad disks, etc?

> Lifecycle hook on cache disk state change
> -
>
> Key: TS-4552
> URL: https://issues.apache.org/jira/browse/TS-4552
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, TS API
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Sometimes, it might be useful to change runtime behavior based on changes 
> (e.g. disk failures) to the cache. For example, lets say I have 4 disks, and 
> I know that I need 2 disks to function reasonably well. If I now lose two 
> disks, I'd want ATS to take action (plugin would implement the action), such 
> as shutting down, or going into no-accept mode etc.
> Also, on startup, the same logic would apply. If I can't satisfy my cache 
> requirements at startup, it should not let ATS pass the cache-ready lifecycle 
> hook.



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

[jira] [Commented] (TS-4500) add cookie-rewrite functionality into header-rewrite plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4500:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/692
  
Great, will take a look in a little bit, first CI build tests though 
[approve ci].


> add cookie-rewrite functionality into header-rewrite plugin
> ---
>
> Key: TS-4500
> URL: https://issues.apache.org/jira/browse/TS-4500
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Zhang Zizhong
>Assignee: Zhang Zizhong
> Fix For: 7.0.0
>
>
> add cookie-rewrite functionality into header-rewrite plugin.
> There're three cookie handling operators added, including *add-cookie*, 
> *rm-cookie* and *update-cookie*.
> *add-cookie* adds a key-value pair into Cookie. If the given key is already 
> in Cookie, do nothing.
> *rm-cookie* remove a pair with the given key from Cookie.
> *update-cookie* sets the value with the given key to the given value. If the 
> given key doesn't exist, add a new pair into Cookie. So the only difference 
> between *add-cookie* and *update-cookie* is overwriting an existing pair or 
> not.



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

[jira] [Commented] (TS-4510) ts_lua plugin - support multiple headers with the same name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4510:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/697
  
Git messed up, manual build [approve ci].


> ts_lua plugin - support multiple headers with the same name
> ---
>
> Key: TS-4510
> URL: https://issues.apache.org/jira/browse/TS-4510
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> Currently ts_lua plugin does not handle well when the request or response 
> contains multiple header with the same name. 
> We either retrieve the last value of first value of these headers and when we 
> set new value to the header, we only change the first one and leave the rest 
> there still.



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/719
  
I think it looks reasonable. Can you verify that the test programs are only 
built at "make check" time? We've had an issue with that with H2 tests, and 
want to make sure it doesn't happen here. :).


> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/719
  
Git messed up again, starting manually [approve ci].


> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Updated] (TS-4552) Lifecycle hook on cache disk state change

[Leif Hedstrom (JIRA)]

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

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

> Lifecycle hook on cache disk state change
> -
>
> Key: TS-4552
> URL: https://issues.apache.org/jira/browse/TS-4552
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, TS API
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Sometimes, it might be useful to change runtime behavior based on changes 
> (e.g. disk failures) to the cache. For example, lets say I have 4 disks, and 
> I know that I need 2 disks to function reasonably well. If I now lose two 
> disks, I'd want ATS to take action (plugin would implement the action), such 
> as shutting down, or going into no-accept mode etc.
> Also, on startup, the same logic would apply. If I can't satisfy my cache 
> requirements at startup, it should not let ATS pass the cache-ready lifecycle 
> hook.



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

[jira] [Created] (TS-4552) Lifecycle hook on cache disk state change

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4552:
-

 Summary: Lifecycle hook on cache disk state change
 Key: TS-4552
 URL: https://issues.apache.org/jira/browse/TS-4552
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cache, TS API
Reporter: Leif Hedstrom


Sometimes, it might be useful to change runtime behavior based on changes (e.g. 
disk failures) to the cache. For example, lets say I have 4 disks, and I know 
that I need 2 disks to function reasonably well. If I now lose two disks, I'd 
want ATS to take action (plugin would implement the action), such as shutting 
down, or going into no-accept mode etc.

Also, on startup, the same logic would apply. If I can't satisfy my cache 
requirements at startup, it should not let ATS pass the cache-ready lifecycle 
hook.



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

[jira] [Commented] (TS-4539) the mutex of server_vc is not set while server_session reuse.

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-4539:
--

Client_vc->mutex is alloced in NetAccept by {code}vc->mutex = 
new_ProxyMutex();{code}

and

Server_vc->mutex is set to {code}vc->mutex = cont->mutex;{code} in 
UnixNetProcessor::connect_re_internal().

the connect_re_internal() is called by NetProcessor::connect_re().

{code}
  if (scheme_to_use == URL_WKSIDX_HTTPS) {
DebugSM("http", "calling sslNetProcessor.connect_re");
int len = 0;
const char *host = t_state.hdr_info.server_request.host_get();
if (host && len > 0)
  opt.set_sni_servername(host, len);
connect_action_handle = sslNetProcessor.connect_re(this,
 // state machine
   
_state.current.server->dst_addr.sa, // addr + port
   );
  } else {
if (t_state.method != HTTP_WKSIDX_CONNECT) {
  DebugSM("http", "calling netProcessor.connect_re");
  connect_action_handle = netProcessor.connect_re(this, 
// state machine
  
_state.current.server->dst_addr.sa, // addr + port
  );
} else {
{code}

acroding the above code in HttpSM::do_http_server_open(), the cont is HttpSM.

the Server_vc->mutex is set to HttpSM->mutex.

the Server_vc->mutex is not set to EThread->mutex as your said.


> the mutex of server_vc is not set while server_session reuse.
> -
>
> Key: TS-4539
> URL: https://issues.apache.org/jira/browse/TS-4539
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Oknet Xu
>
> NetAccept got a client_vc and call new_ProxyMutex() to assign a mutex.
> And the HttpClientSession, HttpSM, HttpServerSession, server_vc also share 
> the same mutex.
> The HttpServerSession and server_vc will put into ServerSessionPool and may 
> assign to next new client_vc.
> The HttpSM::attach_server_session() only set the mutex of HttpServerSession 
> to the mutex of HttpSM after get a HttpServerSession from ServerSessionPool.
> But it forget to set the mutex of server_vc to the mutex of HttpSM.
>  
> {code}
> void
> HttpSM::attach_server_session(HttpServerSession *s)
> {
>   hsm_release_assert(server_session == NULL);
>   hsm_release_assert(server_entry == NULL);
>   hsm_release_assert(s->state == HSS_ACTIVE);
>   server_session = s; 
>   server_session->transact_count++;
>   // Set the mutex so that we have something to update
>   //   stats with
>   server_session->mutex = this->mutex;
> {code}
> But I can not found any issue, Is it by design?
> Or it is hard to locate the problem, due to my limited knowedge on HttpSM.



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/719
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/289/ for details.
 



> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/719
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/181/ for details.
 



> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4551:


GitHub user shukitchan opened a pull request:

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

TS-4551: remove OS_TYPE restriction in gunzip and add unit test

@zwoop can you please take a quick look and review? Thanks.

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

$ git pull https://github.com/shukitchan/trafficserver ostype

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

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


commit 7e02353aeaf2d1dc077a07a6f90fbf427054d44a
Author: Kit Chan 
Date:   2016-06-16T08:58:45Z

remove OS_TYPE restriction in gunzip and add unit test




> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Work started] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[Kit Chan (JIRA)]

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

Work on TS-4551 started by Kit Chan.

> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Updated] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[Kit Chan (JIRA)]

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

Kit Chan updated TS-4551:
-
Fix Version/s: 7.0.0

> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Created] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[Kit Chan (JIRA)]

Kit Chan created TS-4551:


 Summary: ESI plugin is unnecessarily checking OS_TYPE to x03 in 
gunzip of ESI includes
 Key: TS-4551
 URL: https://issues.apache.org/jira/browse/TS-4551
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: Kit Chan


ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

The check is here - 
https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133

It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the response. 



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

[jira] [Commented] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-4551:
--

patch will be available soon

> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Assigned] (TS-4551) ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes

[Kit Chan (JIRA)]

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

Kit Chan reassigned TS-4551:


Assignee: Kit Chan

> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> -
>
> Key: TS-4551
> URL: https://issues.apache.org/jira/browse/TS-4551
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ESI plugin is unnecessarily checking OS_TYPE to x03 in gunzip of ESI includes
> The check is here - 
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/lib/gzip.cc#L133
> It is unnecessary IMO. e.g. I saw some sites such as google homepage and the 
> OS_TYPE can be xff for the 10th bytes of the gzip header bytes of the 
> response. 



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

[jira] [Commented] (TS-4548) Convert custom log config file to Lua

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-4548:
--

yeah. I figure that this should be next. 
 I think another easy candidate is the ip_allow.config. But this obviously 
should be done to remove the XML related stuff in ATS

I would be interested in picking this up

> Convert custom log config file to Lua
> -
>
> Key: TS-4548
> URL: https://issues.apache.org/jira/browse/TS-4548
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> Custom logs {{logs_xml.config}} is a good candidate to convert to Lua 
> bindings. I'm thinking that we bind fairly directly to the internal logging 
> objects so that conceptually it is the same but instead of using XML to 
> construct objects, you use Lua. We would just construct Lua states on the fly 
> to evaluate the file.
> This is the last usage of XML and would let us nuke {{proxy/shared/InkXml.*}} 
> as well as our dependencies on expat+libxml2.



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

[jira] [Commented] (TS-4510) ts_lua plugin - support multiple headers with the same name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4510:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/697
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/288/ for details.
 



> ts_lua plugin - support multiple headers with the same name
> ---
>
> Key: TS-4510
> URL: https://issues.apache.org/jira/browse/TS-4510
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> Currently ts_lua plugin does not handle well when the request or response 
> contains multiple header with the same name. 
> We either retrieve the last value of first value of these headers and when we 
> set new value to the header, we only change the first one and leave the rest 
> there still.



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

[jira] [Commented] (TS-4510) ts_lua plugin - support multiple headers with the same name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4510:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/697
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/180/ for details.
 



> ts_lua plugin - support multiple headers with the same name
> ---
>
> Key: TS-4510
> URL: https://issues.apache.org/jira/browse/TS-4510
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> Currently ts_lua plugin does not handle well when the request or response 
> contains multiple header with the same name. 
> We either retrieve the last value of first value of these headers and when we 
> set new value to the header, we only change the first one and leave the rest 
> there still.



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

[jira] [Commented] (TS-4510) ts_lua plugin - support multiple headers with the same name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4510:


Github user shukitchan commented on the issue:

https://github.com/apache/trafficserver/pull/697
  
@jpeach , I just updated according to your comments. pls take a look.
once i get a thumbs up, will definitely squash the commits before merge


> ts_lua plugin - support multiple headers with the same name
> ---
>
> Key: TS-4510
> URL: https://issues.apache.org/jira/browse/TS-4510
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> Currently ts_lua plugin does not handle well when the request or response 
> contains multiple header with the same name. 
> We either retrieve the last value of first value of these headers and when we 
> set new value to the header, we only change the first one and leave the rest 
> there still.



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

[jira] [Commented] (TS-4500) add cookie-rewrite functionality into header-rewrite plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4500:


Github user zizhong commented on the issue:

https://github.com/apache/trafficserver/pull/692
  
Thanks for the instructive comments. I've fixed most of them. For the 
namespace, I would keep it as it makes code clearer.
About supporting **Set-Cookie**, let me address it with another ticket.


> add cookie-rewrite functionality into header-rewrite plugin
> ---
>
> Key: TS-4500
> URL: https://issues.apache.org/jira/browse/TS-4500
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Zhang Zizhong
>Assignee: Zhang Zizhong
> Fix For: 7.0.0
>
>
> add cookie-rewrite functionality into header-rewrite plugin.
> There're three cookie handling operators added, including *add-cookie*, 
> *rm-cookie* and *update-cookie*.
> *add-cookie* adds a key-value pair into Cookie. If the given key is already 
> in Cookie, do nothing.
> *rm-cookie* remove a pair with the given key from Cookie.
> *update-cookie* sets the value with the given key to the given value. If the 
> given key doesn't exist, add a new pair into Cookie. So the only difference 
> between *add-cookie* and *update-cookie* is overwriting an existing pair or 
> not.



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