[jira] [Work started] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-2954 started by Susan Hinrichs. cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Assignee: Susan Hinrichs Priority: Critical Fix For: 5.1.0 Attachments: ts-2954.patch Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082223#comment-14082223 ] Susan Hinrichs commented on TS-2954: Spent yesterday tracing through code. Finally see how this could happen. Need to reproduce it in my environment to verify. Not clear how much time I'll have to work on it today, but should have an updated patch available by Monday morning. cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Assignee: Susan Hinrichs Priority: Critical Fix For: 5.1.0 Attachments: ts-2954.patch Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082223#comment-14082223 ] Susan Hinrichs edited comment on TS-2954 at 8/1/14 1:22 PM: Spent yesterday tracing through code. Finally see how this could happen. Indeed it is on the code path for updating a modified cache entry. Need to reproduce it in my environment to verify and fix. Not clear how much time I'll have to work on it today, but should have an updated patch available by Monday morning. was (Author: shinrich): Spent yesterday tracing through code. Finally see how this could happen. Need to reproduce it in my environment to verify. Not clear how much time I'll have to work on it today, but should have an updated patch available by Monday morning. cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Assignee: Susan Hinrichs Priority: Critical Fix For: 5.1.0 Attachments: ts-2954.patch Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2802) Add SNI support for origin servers
[
https://issues.apache.org/jira/browse/TS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082262#comment-14082262
]
Alan M. Carroll edited comment on TS-2802 at 8/1/14 2:07 PM:
-
The ts::Buffer changes break WCCP, lib/tsconfig specifically.
was (Author: amc):
The ts::Buffer changes break WCCP.
Add SNI support for origin servers
--
Key: TS-2802
URL: https://issues.apache.org/jira/browse/TS-2802
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Bryan Call
Assignee: James Peach
Labels: Review
Fix For: 5.1.0
Attachments: TS-2802.diff, TS-2802_without_changing_interface.diff
test to an origin that requires SNI
{code}
[bcall@cat ~]$ tail -1 /usr/local/etc/trafficserver/remap.config
map http://foo.yahoo.com
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
[bcall@cat ~]$ curl -H 'Host: foo.yahoo.com' http://localhost:8080/; echo
TLS SNI Required.
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2802) Add SNI support for origin servers
[
https://issues.apache.org/jira/browse/TS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082262#comment-14082262
]
Alan M. Carroll commented on TS-2802:
-
The ts::Buffer changes break WCCP.
Add SNI support for origin servers
--
Key: TS-2802
URL: https://issues.apache.org/jira/browse/TS-2802
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Bryan Call
Assignee: James Peach
Labels: Review
Fix For: 5.1.0
Attachments: TS-2802.diff, TS-2802_without_changing_interface.diff
test to an origin that requires SNI
{code}
[bcall@cat ~]$ tail -1 /usr/local/etc/trafficserver/remap.config
map http://foo.yahoo.com
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
[bcall@cat ~]$ curl -H 'Host: foo.yahoo.com' http://localhost:8080/; echo
TLS SNI Required.
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2802) Add SNI support for origin servers
[
https://issues.apache.org/jira/browse/TS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082276#comment-14082276
]
ASF subversion and git services commented on TS-2802:
-
Commit 426879358105f80785ceeb4ca375581b0c7cf79a in trafficserver's branch
refs/heads/master from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4268793 ]
TS-2802: SNI support for origin servers - fix WCCP compile errors.
Add SNI support for origin servers
--
Key: TS-2802
URL: https://issues.apache.org/jira/browse/TS-2802
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Bryan Call
Assignee: James Peach
Labels: Review
Fix For: 5.1.0
Attachments: TS-2802.diff, TS-2802_without_changing_interface.diff
test to an origin that requires SNI
{code}
[bcall@cat ~]$ tail -1 /usr/local/etc/trafficserver/remap.config
map http://foo.yahoo.com
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
[bcall@cat ~]$ curl -H 'Host: foo.yahoo.com' http://localhost:8080/; echo
TLS SNI Required.
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2964) Generalize URL hashing implementation
[ https://issues.apache.org/jira/browse/TS-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082287#comment-14082287 ] ASF subversion and git services commented on TS-2964: - Commit 2ac12c4a2770600743d12964f4b998ba38b05116 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2ac12c4 ] TS-2964: Make URL hash run time selectable. Generalize URL hashing implementation - Key: TS-2964 URL: https://issues.apache.org/jira/browse/TS-2964 Project: Traffic Server Issue Type: Improvement Components: Cache, Core Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 5.1.0 Attachments: ts-2964.diff Currently URL hashing is hardwired. It needs to be generalized so that different hashes can be selected at run time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2362: Attachment: (was: ts-2362.diff) Backwards cache compatibility for 4.X (read 3.2) Key: TS-2362 URL: https://issues.apache.org/jira/browse/TS-2362 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: Review Fix For: 5.1.0 Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2362: Attachment: ts-2362.diff Backwards cache compatibility for 4.X (read 3.2) Key: TS-2362 URL: https://issues.apache.org/jira/browse/TS-2362 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: Review Fix For: 5.1.0 Attachments: ts-2362.diff Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082381#comment-14082381 ] Alan M. Carroll commented on TS-2362: - Updated patch for master. Testing locally. Backwards cache compatibility for 4.X (read 3.2) Key: TS-2362 URL: https://issues.apache.org/jira/browse/TS-2362 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: Review Fix For: 5.1.0 Attachments: ts-2362.diff Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2979) move scheduled updates feature to a plugin
James Peach created TS-2979:
---
Summary: move scheduled updates feature to a plugin
Key: TS-2979
URL: https://issues.apache.org/jira/browse/TS-2979
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Reporter: James Peach
The scheduled update feature is basically doing what {{TSHttpConnect}} and
{{TSFetchURL}} already do. We should move this feature into a plugin and
implement it in terms of those APIs. That would make it more robust since it
would be using well-used and tested APIs.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082408#comment-14082408 ] Nikolai Gorchilov commented on TS-2954: --- OK. In case you need some more context during assert (i.e. some debug print) you can provide me with a patch that will do so and I can run in once again in order to collect the information. cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Assignee: Susan Hinrichs Priority: Critical Fix For: 5.1.0 Attachments: ts-2954.patch Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2043) Setup CI builds, RAT reports etc. for v3.4 branch
[ https://issues.apache.org/jira/browse/TS-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2043. --- Resolution: Invalid No longer needed. Setup CI builds, RAT reports etc. for v3.4 branch - Key: TS-2043 URL: https://issues.apache.org/jira/browse/TS-2043 Project: Traffic Server Issue Type: Improvement Components: Quality Reporter: Leif Hedstrom Assignee: Daniel Gruno Fix For: Infrastructure -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2980) Fix RAT report for 4.2.x
Phil Sorber created TS-2980: --- Summary: Fix RAT report for 4.2.x Key: TS-2980 URL: https://issues.apache.org/jira/browse/TS-2980 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Fix RAT report exceptions for 4.2.x branch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2964) Generalize URL hashing implementation
[ https://issues.apache.org/jira/browse/TS-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082419#comment-14082419 ] ASF subversion and git services commented on TS-2964: - Commit c0e5dc6f17a814ae9126d0106995983b3351873a in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c0e5dc6 ] TS-2964: Fix searchreplace error in CachePagesInternal.cc Generalize URL hashing implementation - Key: TS-2964 URL: https://issues.apache.org/jira/browse/TS-2964 Project: Traffic Server Issue Type: Improvement Components: Cache, Core Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 5.1.0 Attachments: ts-2964.diff Currently URL hashing is hardwired. It needs to be generalized so that different hashes can be selected at run time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2980) Fix RAT report for 4.2.x
[ https://issues.apache.org/jira/browse/TS-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082514#comment-14082514 ] ASF subversion and git services commented on TS-2980: - Commit 92d152f61a5fb82bb471f3904dc624decc6499ce in trafficserver's branch refs/heads/4.2.x from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=92d152f ] TS-2980: Fix RAT report exceptions. Fix RAT report for 4.2.x Key: TS-2980 URL: https://issues.apache.org/jira/browse/TS-2980 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Fix RAT report exceptions for 4.2.x branch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082623#comment-14082623 ] ASF subversion and git services commented on TS-2367: - Commit 562179c50eae3422ac9b4fe50a1b41ea09712ad1 in trafficserver's branch refs/heads/master from [~ffcai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=562179c ] TS-2367: Add OCSP (Online Certificate Status Protocol) Stapling Support Add OCSP (Online Certificate Status Protocol) Stapling Support --- Key: TS-2367 URL: https://issues.apache.org/jira/browse/TS-2367 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Bryan Call Assignee: Bryan Call Labels: review Fix For: 5.1.0 Attachments: TS-2367.diff, TS-2367.diff RFC: http://tools.ietf.org/html/rfc6066 Overview: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling http://en.wikipedia.org/wiki/OCSP_stapling There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082629#comment-14082629 ] ASF subversion and git services commented on TS-2367: - Commit 2621e676c2b3880c5f3d822bf6e0e5cf30c021fc in trafficserver's branch refs/heads/master from [~ffcai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2621e67 ] TS-2367: Add OCSP (Online Certificate Status Protocol) Stapling Support Add OCSP (Online Certificate Status Protocol) Stapling Support --- Key: TS-2367 URL: https://issues.apache.org/jira/browse/TS-2367 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Bryan Call Assignee: Bryan Call Labels: review Fix For: 5.1.0 Attachments: TS-2367.diff, TS-2367.diff RFC: http://tools.ietf.org/html/rfc6066 Overview: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling http://en.wikipedia.org/wiki/OCSP_stapling There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1475) static analysis: clean up all clang and coverity reports
[ https://issues.apache.org/jira/browse/TS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082661#comment-14082661 ] ASF subversion and git services commented on TS-1475: - Commit bd4fa47753983f5bef2f15ac7a0765881cc871b2 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bd4fa47 ] TS-2957 TS-1475 Remove unused initialization, make clang-analyzer happy static analysis: clean up all clang and coverity reports Key: TS-1475 URL: https://issues.apache.org/jira/browse/TS-1475 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 3.3.0 Reporter: Zhao Yongming Fix For: sometime the new report is in https://ci.trafficserver.apache.org/files/clang-analyzer/latest/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2957) sslheaders plugin
[ https://issues.apache.org/jira/browse/TS-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082660#comment-14082660 ] ASF subversion and git services commented on TS-2957: - Commit bd4fa47753983f5bef2f15ac7a0765881cc871b2 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bd4fa47 ] TS-2957 TS-1475 Remove unused initialization, make clang-analyzer happy sslheaders plugin - Key: TS-2957 URL: https://issues.apache.org/jira/browse/TS-2957 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: James Peach Assignee: James Peach Fix For: 5.1.0 The sslheaders plugin injects information about the SSL session into the client request, the server request or both. It can be used to transmit client SSL informatin (eg, SSL certificate, certificate subject, etc) to origin servers. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082695#comment-14082695 ] ASF subversion and git services commented on TS-2367: - Commit 17ae8069acb908fece508e323c791e52a8c91a3c in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=17ae806 ] TS-2367: Couple fixes to make builds happy Add OCSP (Online Certificate Status Protocol) Stapling Support --- Key: TS-2367 URL: https://issues.apache.org/jira/browse/TS-2367 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Bryan Call Assignee: Bryan Call Labels: review Fix For: 5.1.0 Attachments: TS-2367.diff, TS-2367.diff RFC: http://tools.ietf.org/html/rfc6066 Overview: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling http://en.wikipedia.org/wiki/OCSP_stapling There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082733#comment-14082733 ] ASF subversion and git services commented on TS-2367: - Commit 8bed36eed7819912723a583d2ceeef7cd19ea4b7 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8bed36e ] TS-2367: A better way to declare an argument as unused Add OCSP (Online Certificate Status Protocol) Stapling Support --- Key: TS-2367 URL: https://issues.apache.org/jira/browse/TS-2367 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Bryan Call Assignee: Bryan Call Labels: review Fix For: 5.1.0 Attachments: TS-2367.diff, TS-2367.diff RFC: http://tools.ietf.org/html/rfc6066 Overview: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling http://en.wikipedia.org/wiki/OCSP_stapling There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2964) Generalize URL hashing implementation
[ https://issues.apache.org/jira/browse/TS-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082791#comment-14082791 ] ASF subversion and git services commented on TS-2964: - Commit de6bac77d013c0d7774d7e9641f519d56d0cc8d4 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=de6bac7 ] TS-2964: Make hash runtime selectable - fix gcc issues. Generalize URL hashing implementation - Key: TS-2964 URL: https://issues.apache.org/jira/browse/TS-2964 Project: Traffic Server Issue Type: Improvement Components: Cache, Core Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 5.1.0 Attachments: ts-2964.diff Currently URL hashing is hardwired. It needs to be generalized so that different hashes can be selected at run time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082866#comment-14082866 ] ASF subversion and git services commented on TS-2367: - Commit f5a3d5a2ff8ada63015748532f6904d6d94ed48e in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f5a3d5a ] TS-2367: Don't define OCSPContinuation if there is no OCSP support Add OCSP (Online Certificate Status Protocol) Stapling Support --- Key: TS-2367 URL: https://issues.apache.org/jira/browse/TS-2367 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Bryan Call Assignee: Bryan Call Labels: review Fix For: 5.1.0 Attachments: TS-2367.diff, TS-2367.diff RFC: http://tools.ietf.org/html/rfc6066 Overview: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling http://en.wikipedia.org/wiki/OCSP_stapling There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2980) Fix RAT report for 4.2.x
[ https://issues.apache.org/jira/browse/TS-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2980: -- Fix Version/s: 4.2.2 Fix RAT report for 4.2.x Key: TS-2980 URL: https://issues.apache.org/jira/browse/TS-2980 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Fix For: 4.2.2 Fix RAT report exceptions for 4.2.x branch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2980) Fix RAT report for 4.2.x
[ https://issues.apache.org/jira/browse/TS-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2980: -- Assignee: Phil Sorber Fix RAT report for 4.2.x Key: TS-2980 URL: https://issues.apache.org/jira/browse/TS-2980 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 4.2.2 Fix RAT report exceptions for 4.2.x branch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2980) Fix RAT report for 4.2.x
[ https://issues.apache.org/jira/browse/TS-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2980. --- Resolution: Fixed Fix RAT report for 4.2.x Key: TS-2980 URL: https://issues.apache.org/jira/browse/TS-2980 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 4.2.2 Fix RAT report exceptions for 4.2.x branch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2969) setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421
[ https://issues.apache.org/jira/browse/TS-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2969. --- Resolution: Incomplete No details on this, closing. setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421 Key: TS-2969 URL: https://issues.apache.org/jira/browse/TS-2969 Project: Traffic Server Issue Type: Task Components: DNS, ICP, Management API Reporter: Angelo Lomonaco Assignee: Leif Hedstrom setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2967:
--
Fix Version/s: 5.1.0
failed assert if ssl_multicert.config doesn't exist
---
Key: TS-2967
URL: https://issues.apache.org/jira/browse/TS-2967
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Fix For: 5.1.0
If an ssl_multicert.config file doesn't exist then
SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
and SSLCertificateConfig::reconfigure() doesn't initialize configid
(SSLConfig.cc line 333)
Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
(SSLUtils.cc line 502)
it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
(configid !=0)
Another way might be if SSLCertificateConfig::reconfigure() initialized
configid with configProcessor.set(configid, NULL) if
SSLParseCertificateConfiguration() returns false?
Or SSLParseCertificateConfiguration() could treat a nonexistent
ssl_multicert.config the same as it treats a blank file? ({{touch
ssl_multicert.config}} makes the failed assert go away.)
Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2981) Add HTTP session id to all HTTP debug log messages
[ https://issues.apache.org/jira/browse/TS-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2981: -- Fix Version/s: sometime Add HTTP session id to all HTTP debug log messages -- Key: TS-2981 URL: https://issues.apache.org/jira/browse/TS-2981 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Bryan Call Fix For: sometime Trying to debug an event system with interleaved debugging messages can make you crazy... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2965) Support RFC7238: 308 status code
[ https://issues.apache.org/jira/browse/TS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2965: -- Fix Version/s: sometime Support RFC7238: 308 status code Key: TS-2965 URL: https://issues.apache.org/jira/browse/TS-2965 Project: Traffic Server Issue Type: New Feature Components: HTTP Reporter: Leif Hedstrom Fix For: sometime I think the primary feature addition here is that 308's are cacheable, unless explicitly stated otherwise. So, we should at a minimum add 308's to allowed status code for caching (without requiring negative caching). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2967:
--
Assignee: Jack Bates
failed assert if ssl_multicert.config doesn't exist
---
Key: TS-2967
URL: https://issues.apache.org/jira/browse/TS-2967
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Assignee: Jack Bates
Fix For: 5.1.0
If an ssl_multicert.config file doesn't exist then
SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
and SSLCertificateConfig::reconfigure() doesn't initialize configid
(SSLConfig.cc line 333)
Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
(SSLUtils.cc line 502)
it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
(configid !=0)
Another way might be if SSLCertificateConfig::reconfigure() initialized
configid with configProcessor.set(configid, NULL) if
SSLParseCertificateConfiguration() returns false?
Or SSLParseCertificateConfiguration() could treat a nonexistent
ssl_multicert.config the same as it treats a blank file? ({{touch
ssl_multicert.config}} makes the failed assert go away.)
Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2962) header_rewrite default exists matcher not working
[
https://issues.apache.org/jira/browse/TS-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2962:
-
Assignee: Leif Hedstrom
header_rewrite default exists matcher not working
---
Key: TS-2962
URL: https://issues.apache.org/jira/browse/TS-2962
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 5.0.1
Reporter: Nick Muerdter
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.1.0
The
[documentation|https://docs.trafficserver.apache.org/en/latest/reference/plugins/header_rewrite.en.html#operands-to-conditions]
for the header_rewrite plugin indicates that if you don't specify a matcher
on a condition, then the matcher checks if a value exists. However, if I'm
understanding the intended behavior correctly, this is not the behavior I'm
seeing. If I don't specify an explicit matcher on the condition, then the
condition never seems to match (at least for http headers).
Here's a simplified example in a stock 5.0.1 installation that should add a
{{X-Testing}} header to the response if the {{Surrogate-Control}} header
exists on the response:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control}
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:43 GMT
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
But as you can see from this response, no such header is added.
If I change the condition to a regex match for one or more characters, then
the header gets added as I expect:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control} /.+/
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:12 GMT
X-Testing: Hello
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
The regex based approach works fine, but it took me a while to realize what
was going on and figure this out (the primary example in the documentation
also seems to be utilizing this exists logic so that also doesn't work for
me).
So if the condition without an explicit matcher should check for a variable's
existence, that doesn't seem to be working. Alternatively, if the current
behavior is working as intended, then I think the documentation and examples
might need to be updated (and if that's the case, I'd be happy to take a stab
at that).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2979) move scheduled updates feature to a plugin
[
https://issues.apache.org/jira/browse/TS-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2979:
--
Fix Version/s: sometime
move scheduled updates feature to a plugin
--
Key: TS-2979
URL: https://issues.apache.org/jira/browse/TS-2979
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Reporter: James Peach
Fix For: sometime
The scheduled update feature is basically doing what {{TSHttpConnect}} and
{{TSFetchURL}} already do. We should move this feature into a plugin and
implement it in terms of those APIs. That would make it more robust since it
would be using well-used and tested APIs.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2950) Import libck to libts for atomics and concurrent data structures
[ https://issues.apache.org/jira/browse/TS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2950: Description: We want to import libck to replace our atomics and concurrent data structures. We would preferably like to build against an OS supplied version, but will import ourselves until it is more ubiquitous. https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers was: We want to import libck to replace our atomics and concurrent data structures. We would preferably like to build against an OS supplied version, but will import ourselves until it is more ubiquitous. Import libck to libts for atomics and concurrent data structures Key: TS-2950 URL: https://issues.apache.org/jira/browse/TS-2950 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.1.0 We want to import libck to replace our atomics and concurrent data structures. We would preferably like to build against an OS supplied version, but will import ourselves until it is more ubiquitous. https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2962) header_rewrite default exists matcher not working
[
https://issues.apache.org/jira/browse/TS-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2962:
--
Fix Version/s: 5.1.0
header_rewrite default exists matcher not working
---
Key: TS-2962
URL: https://issues.apache.org/jira/browse/TS-2962
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 5.0.1
Reporter: Nick Muerdter
Priority: Minor
Fix For: 5.1.0
The
[documentation|https://docs.trafficserver.apache.org/en/latest/reference/plugins/header_rewrite.en.html#operands-to-conditions]
for the header_rewrite plugin indicates that if you don't specify a matcher
on a condition, then the matcher checks if a value exists. However, if I'm
understanding the intended behavior correctly, this is not the behavior I'm
seeing. If I don't specify an explicit matcher on the condition, then the
condition never seems to match (at least for http headers).
Here's a simplified example in a stock 5.0.1 installation that should add a
{{X-Testing}} header to the response if the {{Surrogate-Control}} header
exists on the response:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control}
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:43 GMT
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
But as you can see from this response, no such header is added.
If I change the condition to a regex match for one or more characters, then
the header gets added as I expect:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control} /.+/
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:12 GMT
X-Testing: Hello
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
The regex based approach works fine, but it took me a while to realize what
was going on and figure this out (the primary example in the documentation
also seems to be utilizing this exists logic so that also doesn't work for
me).
So if the condition without an explicit matcher should check for a variable's
existence, that doesn't seem to be working. Alternatively, if the current
behavior is working as intended, then I think the documentation and examples
might need to be updated (and if that's the case, I'd be happy to take a stab
at that).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2950) Import libck to libts for atomics and concurrent data structures
[ https://issues.apache.org/jira/browse/TS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082931#comment-14082931 ] ASF subversion and git services commented on TS-2950: - Commit f098175e9620743ab632f0fa23104f6498d45d44 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f098175 ] TS-2950: Initial commit of libck. Import libck to libts for atomics and concurrent data structures Key: TS-2950 URL: https://issues.apache.org/jira/browse/TS-2950 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.1.0 We want to import libck to replace our atomics and concurrent data structures. We would preferably like to build against an OS supplied version, but will import ourselves until it is more ubiquitous. https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1187: Fix Version/s: (was: 5.1.0) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Assignee: Bryan Call Labels: api-change TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-727) Do we need support for streams partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-727: --- Fix Version/s: (was: 5.1.0) 6.0.0 Do we need support for streams partitions? Key: TS-727 URL: https://issues.apache.org/jira/browse/TS-727 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 6.0.0 There's code in the cache related to MIXT streams volumes (caches). Since we don't support streams, I'm thinking this code could be removed? Or alternatively, we should expose APIs so that someone writing a plugin and wish to store a different protocol (e.g. QT) can register this media type with the API and core. The idea being that the core only contains protocols that are in the core, but expose the cache core so that plugins can take advantage of it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1033) Add some missing WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1033: Fix Version/s: (was: 5.1.0) 5.2.0 Add some missing WKS's to HdrToken. - Key: TS-1033 URL: https://issues.apache.org/jira/browse/TS-1033 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.2.0 And of course various other places (including InkAPI). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-1187. --- Resolution: Cannot Reproduce TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Assignee: Bryan Call Labels: api-change TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1381: Fix Version/s: (was: 5.2.0) 6.0.0 Performance of server intercept without Content-Length is poor -- Key: TS-1381 URL: https://issues.apache.org/jira/browse/TS-1381 Project: Traffic Server Issue Type: Improvement Components: HTTP, Performance Reporter: Leif Hedstrom Fix For: 6.0.0 When using a server intercept plugin, if the plugin is unable (for whatever reason) to inject a Content-Length header, we perform chunked encoding on the body. This turns out to be pretty slow, I'm seeing at least 5-8x slowdown doing this chunking, vs simply setting a CL: header. The reason I'm filing this is because for certain server intercept plugins, such as an fcgi plugin, this could be bad for performance. I can see that there would be some overhead doing the chunking, but 800% seems very steep. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1381: Fix Version/s: (was: 5.1.0) 5.2.0 Performance of server intercept without Content-Length is poor -- Key: TS-1381 URL: https://issues.apache.org/jira/browse/TS-1381 Project: Traffic Server Issue Type: Improvement Components: HTTP, Performance Reporter: Leif Hedstrom Fix For: 6.0.0 When using a server intercept plugin, if the plugin is unable (for whatever reason) to inject a Content-Length header, we perform chunked encoding on the body. This turns out to be pretty slow, I'm seeing at least 5-8x slowdown doing this chunking, vs simply setting a CL: header. The reason I'm filing this is because for certain server intercept plugins, such as an fcgi plugin, this could be bad for performance. I can see that there would be some overhead doing the chunking, but 800% seems very steep. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1666) Plugins, clustering and core crashes when share_server_sessions=2
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1666:
Fix Version/s: (was: 5.1.0)
6.0.0
Plugins, clustering and core crashes when share_server_sessions=2
-
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Assignee: Leif Hedstrom
Priority: Critical
Labels: Crash
Fix For: 6.0.0
ibrezac dumped this trace on irc:
{noformat}
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
{noformat}
configuration used:
{noformat}
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
{noformat}
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
{noformat}
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1590) use_remap_processor crashes if share_server_sessions = 2
[
https://issues.apache.org/jira/browse/TS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1590:
Fix Version/s: (was: 5.1.0)
6.0.0
use_remap_processor crashes if share_server_sessions = 2
Key: TS-1590
URL: https://issues.apache.org/jira/browse/TS-1590
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.0
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
Labels: Crash
Fix For: 6.0.0
easy to reproduce:
{code}
CONFIG proxy.config.remap.use_remap_processor INT 1 (default is 0)
CONFIG proxy.config.http.share_server_sessions INT 2 (0, 1 will be ok)
{code}
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1210
[Switching to process 8927 thread 0x1a03]
0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
(gdb) bt
#0 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
#1 0x0001000eb366 in HttpSessionManager::acquire_session
(this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19
127.0.0.1, ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
#2 0x000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0,
raw=false) at HttpSM.cc:4384
..
(gdb) p this_ethread()-l1_hash
$2 = (SessionBucket *) 0x0
(gdb) p this_ethread()-event_types
$3 = 2 (ET_REMAP)
{code}
Using separate remap processor is a hidden option, and I enable it by
accident.. (Does anyone use it in prod?)
I noticed HttpSM::do_http_server_open is always executed by the remap
processer ethread (because of
action.continuation-handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if
wrong). While the remap thread was not initialized as ET_NET and has no
l1_hash, server session lookup in this ET_REMAP thread will crash.
I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on
ET_NET. So a fast workaround would be falling back to global server
connection when use_remap_processor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1757:
Fix Version/s: (was: 5.1.0)
5.2.0
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: Yunkai Zhang
Labels: A, crash, review
Fix For: 5.2.0
Attachments: 0001-TS-1757-workaround-to-fix-core-at-escapify_url.patch
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1835) Restore ink_resource.{cc,h} functionality
[
https://issues.apache.org/jira/browse/TS-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1835:
Fix Version/s: (was: 5.1.0)
6.0.0
Restore ink_resource.{cc,h} functionality
-
Key: TS-1835
URL: https://issues.apache.org/jira/browse/TS-1835
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 6.0.0
I think we should eliminate the ink_resource memory tracking code. We already
have support for this when linking in with tcmalloc or jemalloc, rolling our
own seems pointless with these tools being available.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-1917:
---
Assignee: Alan M. Carroll (was: James Peach)
It seems that one of assert in HttpTransact::handle_content_length_header()
is unnecessary
---
Key: TS-1917
URL: https://issues.apache.org/jira/browse/TS-1917
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Alan M. Carroll
Labels: review
Fix For: 6.0.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`,
ap=0x2b34979073a0) at ink_error.cc:65
#4 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
OK) at HttpTransact.cc:7731
#8 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
By analyzing the code, it seems that this assertion is unnecessary:
When client sends a request to ATS, and the content hits in cache, but if the
cache is STALE, ATS will sent a request to Original-Server.
In this case, the t_sate.source will be updated to
SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
HttpTransact::handle_cache_operation_on_forward_server_response()
= s-state_machine-do_range_setup_if_necessary(), the s-range_setup could
be
[jira] [Updated] (TS-1883) SSL origin connections do not support connection timeouts
[
https://issues.apache.org/jira/browse/TS-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1883:
Fix Version/s: (was: 5.1.0)
6.0.0
SSL origin connections do not support connection timeouts
-
Key: TS-1883
URL: https://issues.apache.org/jira/browse/TS-1883
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: James Peach
Fix For: 6.0.0
In {{proxy/http/HttpSM.cc}}, we can see that origin connections do not
support timeouts if the scheme is HTTPS:
{code}
void
HttpSM::do_http_server_open(bool raw)
{
...
if (t_state.scheme == URL_WKSIDX_HTTPS) {
DebugSM(http, calling sslNetProcessor.connect_re);
connect_action_handle = sslNetProcessor.connect_re(this,// state
machine
t_state.current.server-addr.sa,// addr + port
opt);
} else {
...
// Setup the timeouts
// Set the inactivity timeout to the connect timeout so that we
// we fail this server if it doesn't start sending the response
// header
MgmtInt connect_timeout;
if (t_state.method == HTTP_WKSIDX_POST || t_state.method ==
HTTP_WKSIDX_PUT) {
connect_timeout = t_state.txn_conf-post_connect_attempts_timeout;
} else if (t_state.current.server == t_state.parent_info) {
connect_timeout = t_state.http_config_param-parent_connect_timeout;
} else {
if (t_state.pCongestionEntry != NULL)
connect_timeout = t_state.pCongestionEntry-connect_timeout();
else
connect_timeout = t_state.txn_conf-connect_attempts_timeout;
}
DebugSM(http, calling netProcessor.connect_s);
connect_action_handle = netProcessor.connect_s(this, // state
machine
t_state.current.server-addr.sa,// addr + port
connect_timeout, opt);
...
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1917:
Fix Version/s: (was: 5.1.0)
6.0.0
It seems that one of assert in HttpTransact::handle_content_length_header()
is unnecessary
---
Key: TS-1917
URL: https://issues.apache.org/jira/browse/TS-1917
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Yunkai Zhang
Assignee: James Peach
Labels: review
Fix For: 6.0.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`,
ap=0x2b34979073a0) at ink_error.cc:65
#4 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
OK) at HttpTransact.cc:7731
#8 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
By analyzing the code, it seems that this assertion is unnecessary:
When client sends a request to ATS, and the content hits in cache, but if the
cache is STALE, ATS will sent a request to Original-Server.
In this case, the t_sate.source will be updated to
SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
HttpTransact::handle_cache_operation_on_forward_server_response()
= s-state_machine-do_range_setup_if_necessary(), the s-range_setup could
be
[jira] [Updated] (TS-1979) Investigate body factory and its use of malloc()
[ https://issues.apache.org/jira/browse/TS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1979: Fix Version/s: (was: 5.1.0) sometime Investigate body factory and its use of malloc() Key: TS-1979 URL: https://issues.apache.org/jira/browse/TS-1979 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: sometime It might be a nice optimization to make it use heap allocation (that is, put the body factory on the freelist) for small bodies. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1967) create max accept handler function
[ https://issues.apache.org/jira/browse/TS-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1967: Fix Version/s: (was: 5.1.0) 6.0.0 create max accept handler function --- Key: TS-1967 URL: https://issues.apache.org/jira/browse/TS-1967 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.2.4 Reporter: Bin Chen Assignee: Bin Chen Labels: review Fix For: 6.0.0 Attachments: TS-1967.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1992) examine mgmt/RecordsConfig.cc, add validation where it makes sense
[
https://issues.apache.org/jira/browse/TS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1992:
Fix Version/s: (was: 5.1.0)
6.0.0
examine mgmt/RecordsConfig.cc, add validation where it makes sense
--
Key: TS-1992
URL: https://issues.apache.org/jira/browse/TS-1992
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Fix For: 6.0.0
example:
{code}
{RECT_CONFIG, proxy.config.http.cache.required_headers, RECD_INT, 2,
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{code}
We should change this to
{code}
{RECT_CONFIG, proxy.config.http.cache.required_headers, RECD_INT, 2,
RECU_DYNAMIC, RR_NULL, RECC_NULL, [0-2], RECA_NULL}
{code}
which are the valid values for this config.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1996) Remove TSHttpTxnNewCacheLookupDo API
[ https://issues.apache.org/jira/browse/TS-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1996: Fix Version/s: (was: 5.1.0) 6.0.0 Remove TSHttpTxnNewCacheLookupDo API Key: TS-1996 URL: https://issues.apache.org/jira/browse/TS-1996 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2056) When proxy.config.http.negative_caching_enabled = 1 we cache errors even if Cache-Control: no-cache is sent from the origin
[
https://issues.apache.org/jira/browse/TS-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2056:
Fix Version/s: (was: 5.1.0)
sometime
When proxy.config.http.negative_caching_enabled = 1 we cache errors even if
Cache-Control: no-cache is sent from the origin
---
Key: TS-2056
URL: https://issues.apache.org/jira/browse/TS-2056
Project: Traffic Server
Issue Type: Bug
Reporter: Phil Sorber
Labels: C
Fix For: sometime
{noformat}
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Cache-Control: no-cache
Date: Sun, 21 Jul 2013 17:20:00 GMT
Expires: Sun, 21 Jul 2013 17:50:00 GMT
Age: 38
Content-Length: 40
Connection: keep-alive
Via: http/1.1 XX (ApacheTrafficServer/3.3.5-dev [uScHs f p eN:t cCHi
p s ])
Server: ATS/3.3.5-dev
{noformat}
While this is a grey area since we are already breaking the spec by negative
caching, I think we should still not cache this when explicitly told not to
by the origin and [~zwoop] agrees!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2110) Cleanup ts/experimental.h
[ https://issues.apache.org/jira/browse/TS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2110: Fix Version/s: (was: 5.1.0) 6.0.0 Cleanup ts/experimental.h - Key: TS-2110 URL: https://issues.apache.org/jira/browse/TS-2110 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Kit Chan Labels: api-change Fix For: 6.0.0 We should go through the APIs in experimental.h, and do one of 1. Remove 2. Move to ts/ts.h.in 3. Leave as is, assuming it's still considered experimental. I know there are arguments for and against having an experimental.h include file. I guess I don't have a strong opinion, another solution is to simply keep everything in ts.h.in, but mark APIs that are experimental as such. I do believe having APIs in an experimental state has benefits (such as we can modify such APIs as we see fit, there is no ABI/API compatibility promise). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2087) Reimplement / refactor / fix the SSD code
[ https://issues.apache.org/jira/browse/TS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2087: Fix Version/s: (was: 5.1.0) sometime Reimplement / refactor / fix the SSD code - Key: TS-2087 URL: https://issues.apache.org/jira/browse/TS-2087 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Yunkai Zhang Fix For: sometime This is in relation to TS-745, see that for some of the comments that's been added re: the code that was landed. I really feel we ought to clean up a lot of this, and address all the concerns that was brought up. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2134) SRV lookup does not handle failover correctly
[ https://issues.apache.org/jira/browse/TS-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2134: Fix Version/s: (was: 5.1.0) 5.2.0 SRV lookup does not handle failover correctly - Key: TS-2134 URL: https://issues.apache.org/jira/browse/TS-2134 Project: Traffic Server Issue Type: Bug Components: DNS, HTTP Reporter: Thach Tran Labels: review Fix For: 5.2.0 Attachments: ats.log, ts2134.patch I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail over to alternative origins once the first choice is marked as down. To reproduce this, I'm running dnsmasq as a local resolver to serve up the test SRV records. My configuration is as follows. h4. records.config CONFIG proxy.config.dns.nameservers STRING 127.0.0.1 CONFIG proxy.config.dns.resolv_conf STRING NULL CONFIG proxy.config.srv_enabled INT 1 h4. remap.config regex_remap http://.*:8080/ https://noexample.com/ h4. dnsmasq.conf (srv records config) srv-host=_http._tcp.noexample.com,abc.com,443,0,100 srv-host=_http._tcp.noexample.com,google.com,443,1,100 The intention is since the srv lookup for _http._tcp.noexample.com returns abc.com:443 and google.com:443 with abc.com:443 being the one with higher priority, the proxy should try that first and once the connection to abc.com:443 is marked as down (up to 6 retries by default), google.com:443 should be tried next and the connection should succeed then. However, testing with the following curl command multiple times still gives back 502. $ curl -v http://localhost:8080/ Debug log seems to suggest it always attempts abc.com:443. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2231) header_rewrite uses boost regexes, we should switch to PCRE
[ https://issues.apache.org/jira/browse/TS-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2231: Fix Version/s: (was: 5.1.0) 6.0.0 header_rewrite uses boost regexes, we should switch to PCRE --- Key: TS-2231 URL: https://issues.apache.org/jira/browse/TS-2231 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 It makes no sense to have another regex format, lets unify everything on PCRE. Also, while we're at it, lets get rid of BOOST entirely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2153) traffic_manager -tsArgs without -M is fatal error
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083002#comment-14083002
]
Alan M. Carroll commented on TS-2153:
-
Jack - land this next week or we'll have to move it out to 5.2.0.
traffic_manager -tsArgs without -M is fatal error
-
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Adam Twardowski
Assignee: Jack Bates
Fix For: 5.1.0
traffic_manager -tsArgs -T 'log.*'
Running the above command on the 4.0.0 branch commit
c8931df15e33924bb459d40859a0b49331a6dbaf
resulted in no running traffic_server and the following ps output
nobody 16807 0.1 0.9 410884 18272 pts/0Sl+ 16:58 0:00
traffic_manager -tsArgs -T log.*
nobody 16816 0.0 0.0 0 0 pts/0Z+ 16:58 0:00
[traffic_manager] defunct
root 16818 0.0 0.0 103240 864 pts/1S+ 16:59 0:00 grep tr
manger.log output
--
[Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server
Args: ' -T log.*'
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup
complete
[Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE:
[LocalManager::startProxy] Launching ts process
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:
[LocalManager::startProxy] ts options must contain -M
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: (last system error 0:
Success)
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager
[ https://issues.apache.org/jira/browse/TS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2268: Fix Version/s: (was: 5.1.0) sometime Add support for opening protocol traffic sockets through the traffic_manager Key: TS-2268 URL: https://issues.apache.org/jira/browse/TS-2268 Project: Traffic Server Issue Type: Improvement Components: Plugins, TS API Reporter: Uri Shachar Assignee: Uri Shachar Labels: api-addition Fix For: sometime Add a TSNetAcceptNamedDescriptor(contp, char *) function to allow a protocol plugin to set a callback for accepting new connections on a socket opened by the traffic_manager (that's defined like 2345:plugin:name=myname in the server_ports configuration). This has three advantages on opening a socket using TSNetAccept: 1) If the traffic_server crashes and restarts, new connections won't be rejected while we recover - This is the main selling point of the new API. 2) Support for all port configuration flags (Which also exists when using TSPortDescriptorAccept) 3) Allow for a single point of configuration for all ATS ports -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2237) URL encoding wrong in squid.blog
[ https://issues.apache.org/jira/browse/TS-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2237: Fix Version/s: (was: 5.1.0) 5.2.0 URL encoding wrong in squid.blog Key: TS-2237 URL: https://issues.apache.org/jira/browse/TS-2237 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: David Carlin Priority: Minor Fix For: 5.2.0 Attachments: TS-2237.diff I was replaying URLs captured from squid.blog and I noticed I was getting 404's for some of them when squid.blog showed a 200 for that request. Turns out there is an issue with URL encoding. For example: Requesting file 'duck%20sports%20authority.gif' via curl will put this in the logs: duck%2520sports%2520authority.gif The % from %20 (space) in the request is being converted to %25 resulting in %2520 I tested both the %cquc and %cquuc log fields - same thing happens. I tested on ATS 3.2.0 and 3.3.5 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2258) Verify that all fields are correct in RecordsConfig.cc
[ https://issues.apache.org/jira/browse/TS-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2258: Fix Version/s: (was: 5.1.0) 6.0.0 Verify that all fields are correct in RecordsConfig.cc -- Key: TS-2258 URL: https://issues.apache.org/jira/browse/TS-2258 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Fix For: 6.0.0 We should go through every configuration in RecordsConfig.cc, and assure that fields such as if it's dynamically reloadable or not, validation regexes etc. are all set 100% correct. Once this file is accurate, and will be the one true authoritative source for everything configuration; it can be used for command line help (e.g. traffic_line can say if a config is reloadable), and we can even use it as a source for the Sphinx documentation. A bonus would be to add a one-line helper line for each configuration in RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new type of tools to help managing configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2282) Allow ATS to run with empty config
[ https://issues.apache.org/jira/browse/TS-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2282: Fix Version/s: (was: 5.1.0) 5.2.0 Allow ATS to run with empty config -- Key: TS-2282 URL: https://issues.apache.org/jira/browse/TS-2282 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.2.0 Traffic server should start and run with empty config files using the defaults. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2284) Run with no configs
[ https://issues.apache.org/jira/browse/TS-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2284: Fix Version/s: (was: 5.1.0) 5.2.0 Run with no configs --- Key: TS-2284 URL: https://issues.apache.org/jira/browse/TS-2284 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.2.0 In addition to running with empty configs (TS-2282), we should be able to run with no configs and not write them out (TS-2283). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2289) Only support AIO_MODE_THREAD and AIO_MODE_NATIVE
[ https://issues.apache.org/jira/browse/TS-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2289: Fix Version/s: (was: 5.1.0) 6.0.0 Only support AIO_MODE_THREAD and AIO_MODE_NATIVE Key: TS-2289 URL: https://issues.apache.org/jira/browse/TS-2289 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 As discussed, we'd like to simplify this code, and only keep our own AIO and the linux native AIO implementations. That would leave AIO_MODE_THREAD and AIO_MODE_NATIVE. Also, I think it's pretty unfortunate that AIO_MODE_NATIVE has to escape encapsulation and have custom code in e.g. Cache.cc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2299:
Fix Version/s: (was: 5.1.0)
5.2.0
ATS seg faults in MIMEScanner::mime_scanner_get
---
Key: TS-2299
URL: https://issues.apache.org/jira/browse/TS-2299
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, MIME
Affects Versions: 4.0.1
Environment: RHEL 5.9
Reporter: John Paul Vasicek
Labels: Crash
Fix For: 5.2.0
I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2aafe810683d]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
(demangled)
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/lib64/libpthread.so.0[0x2ba86e67aca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x39f)[0x4d37cf]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8Plu
ginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x238)[0x6cb258]
/usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2ba86e67283d]
/usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x46e)[0x4d389e]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2403) Segfault when HostDB full
[
https://issues.apache.org/jira/browse/TS-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2403:
Fix Version/s: (was: 5.1.0)
6.0.0
Segfault when HostDB full
-
Key: TS-2403
URL: https://issues.apache.org/jira/browse/TS-2403
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 4.0.1
Reporter: David Carlin
Labels: Crash
Fix For: 6.0.0
diags.log leading up to crash:
{noformat}
[Nov 25 10:50:23.346] Server {0x2b06c4302700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.379] Server {0x2b06c4100700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.449] Server {0x2b06c4a09700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.462] Server {0x2b06c4403700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.494] Server {0x2b06bed1f540} WARNING: out of room in hostdb
for reverse DNS data
[Nov 25 10:54:46.919] {0x2baa2d65b540} STATUS: opened
/home/y/logs/trafficserver/diags.log
[Nov 25 10:54:46.927] {0x2baa2d65b540} NOTE: updated diags config
[Nov 25 10:54:46.961] Server {0x2baa2d65b540} NOTE: cache clustering disabled
[Nov 25 10:54:46.995] Server {0x2baa2d65b540} NOTE: ip_allow.config updated,
reloading
[Nov 25 10:54:47.059] Server {0x2baa2d65b540} NOTE: cache clustering disabled
[Nov 25 10:54:47.072] Server {0x2baa2d65b540} NOTE: logging initialized[15],
logging_mode = 3
[Nov 25 10:54:47.103] Server {0x2baa2d65b540} NOTE: loading plugin
'/home/y/libexec64/trafficserver/quick_filter.so'
[Nov 25 10:54:47.326] Server {0x2baa2d65b540} NOTE: loading plugin
'/home/y/libexec64/trafficserver/header_filter.so'
[Nov 25 10:54:49.395] Server {0x2baa2d65b540} NOTE: traffic server running
{noformat}
From traffic.out:
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3d07c0f500)[0x2b06be27a500]
/home/y/bin/traffic_server(_Z14ats_ip_addr_eqPK8sockaddrS1_+0x3)[0x5e0323]
/home/y/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x2389)[0x5df3b9]
/home/y/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f9cd4]
/home/y/bin/traffic_server[0x5fbd17]
/home/y/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x8d0)[0x5fd5c0]
/home/y/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x12)[0x5fe642]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a321f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a3c03]
/home/y/bin/traffic_server(main+0xb14)[0x4c5314]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3d0781ecdd]
/home/y/bin/traffic_server[0x485a19]
{noformat}
Backtrace:
{noformat}
#0 ats_ip_addr_cmp (lhs=0x7fffdf15e778, rhs=0x8) at
../../lib/ts/ink_inet.h:669
#1 ats_ip_addr_eq (lhs=0x7fffdf15e778, rhs=0x8) at
../../lib/ts/ink_inet.h:721
#2 0x005df3b9 in restore_info (this=value optimized out,
event=value optimized out, e=value optimized out) at HostDB.cc:1375
#3 HostDBContinuation::dnsEvent (this=value optimized out, event=value
optimized out, e=value optimized out) at HostDB.cc:1604
#4 0x005f9cd4 in handleEvent (this=0x2b06f40a2120) at
../../iocore/eventsystem/I_Continuation.h:146
#5 DNSEntry::postEvent (this=0x2b06f40a2120) at DNS.cc:1278
#6 0x005fbd17 in dns_result (h=0x1778380, e=0x2b06f40a2120,
ent=0x1913820, retry=value optimized out) at DNS.cc:1230
#7 0x005fd5c0 in dns_process (this=0x1778380) at DNS.cc:1599
#8 DNSHandler::recv_dns (this=0x1778380) at DNS.cc:790
#9 0x005fe642 in DNSHandler::mainEvent (this=0x1778380, event=value
optimized out, e=value optimized out) at DNS.cc:802
#10 0x006a321f in handleEvent (this=0x2b06bf2d0010, e=0x2b06d8092740,
calling_code=5) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b06bf2d0010, e=0x2b06d8092740,
calling_code=5) at UnixEThread.cc:141
#12 0x006a3c03 in EThread::execute (this=0x2b06bf2d0010) at
UnixEThread.cc:265
#13 0x004c5314 in main (argv=value optimized out) at Main.cc:1690
{noformat}
HostDB settings:
CONFIG proxy.config.hostdb.size INT 20
CONFIG proxy.config.hostdb.storage_size INT 50331648
CONFIG proxy.config.hostdb.ttl_mode INT 0
CONFIG proxy.config.hostdb.timeout INT 1440
CONFIG proxy.config.hostdb.strict_round_robin INT 0
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2375) Error when using ascii logging format: There are more field markers than fields
[
https://issues.apache.org/jira/browse/TS-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2375:
Fix Version/s: (was: 5.1.0)
sometime
Error when using ascii logging format: There are more field markers than
fields
---
Key: TS-2375
URL: https://issues.apache.org/jira/browse/TS-2375
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 4.0.2, 4.1.2
Reporter: David Carlin
Assignee: Bryan Call
Fix For: sometime
I noticed the following on an ats 4.0.2 host in diags.log:
{noformat}[Nov 20 15:08:29.627] Server {0x2b732fe9c700} NOTE: There are more
field markers than fields; cannot process log entry{noformat}
It only happens about every fifth time you start ATS. That message will fill
diags.log and nothing is written to squid.log
I then upgraded to 4.1.1 as a test, and the same thing happened except there
was additional error information:
{noformat}[Nov 20 15:40:53.656] Server {0x2b568aac8700} NOTE: There are more
field markers than fields; cannot process log entry
[Nov 20 15:40:53.656] Server {0x2b568aac8700} ERROR: Failed to convert
LogBuffer to ascii, have dropped (232) bytes.{noformat}
The convert to ascii message tipped me off that this could be the source of
the problem. Up until now we've been using the binary log format, so perhaps
this is why I didn't run into this in the past. I then changed the log
format back to binary, and I was unable to reproduce the issue - so it seems
related to ascii logging.
Here is our logs_xml.config:
{noformat}
LogFormat
Name = ats_generic_config/
Format = %cqtq %ttms %chi %crc %pssc %psql %cqhm %cquc
%caun %phr/%pqsn %psct %cquuc f1 f2 f3 f4/
/LogFormat
LogObject
Format = ats_generic_config/
Filename = squid/
Mode = ascii/
/LogObject
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2407) we should add API TSUrlStringGetBuf in ts.h
[
https://issues.apache.org/jira/browse/TS-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2407:
Assignee: (was: Leif Hedstrom)
we should add API TSUrlStringGetBuf in ts.h
---
Key: TS-2407
URL: https://issues.apache.org/jira/browse/TS-2407
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Yu Qing
Labels: api-addition, review
Fix For: sometime
Attachments: 0001-TS-2407-add-API-TSUrlStringGetBuf.patch
the existing API TSUrlStringGet call ats_malloc to malloc buffer for the url
string. the caller should call ats_free to free the buffer. the API prototype
is:
tsapi char* TSUrlStringGet(TSMBuffer bufp, TSMLoc offset, int* length);
call this API is expensive because dynamic memory alloc and free.
we wish the buffer can be passed in. the new API prototype is:
tsapi char* TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc offset, char *buff, int
buf_size, int* length);
the implements as:
char *
TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc obj, char *buff, int buf_size, int*
length)
{
sdk_assert(sdk_sanity_check_mbuffer(bufp) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_url_handle(obj) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)buff) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)length) == TS_SUCCESS);
URLImpl *url_impl = (URLImpl *) obj;
return url_string_get_buf(url_impl, buff, buf_size, length);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2411) TS Http byte get functions does not return the true number, for server response body byte get
[ https://issues.apache.org/jira/browse/TS-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2411: Fix Version/s: (was: 5.1.0) 5.2.0 TS Http byte get functions does not return the true number, for server response body byte get - Key: TS-2411 URL: https://issues.apache.org/jira/browse/TS-2411 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Roee Gil Assignee: Brian Geffon Labels: api-change Fix For: 5.2.0 When using the example of null-transform, adding TS_EVENT_HTTP_TXN_CLOSE to hooks, and counting byte number, I get: // server - proxy TSHttpTxnServerRespHdrBytesGet(txnDB); TSHttpTxnServerRespBodyBytesGet(txnDB); // proxy - client TSHttpTxnClientRespHdrBytesGet(txnDB); TSHttpTxnClientRespBodyBytesGet(txnDB); 1. server side response body = 0 2. client side response body = (payload size) when inspecting this issue, it seems that VConnection is downloading the content but, this does not count in server response byte get -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2417) forward secrecy for non-EC key types
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2417: Assignee: Leif Hedstrom (was: James Peach) forward secrecy for non-EC key types Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, SSL Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: sometime mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2417) forward secrecy for non-EC key types
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2417: -- Component/s: (was: Security) forward secrecy for non-EC key types Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, SSL Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: sometime mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2417) forward secrecy for non-EC key types
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2417: Fix Version/s: (was: 5.1.0) sometime forward secrecy for non-EC key types Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, SSL Reporter: Bryan Call Assignee: James Peach Fix For: sometime mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2417) forward secrecy for non-EC key types
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2417: -- Assignee: (was: Leif Hedstrom) forward secrecy for non-EC key types Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, SSL Reporter: Bryan Call Fix For: sometime mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2442) Validation strings in RecordsConfig.cc are ignored (or not correctly handled)
[ https://issues.apache.org/jira/browse/TS-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-2442: --- Assignee: Alan M. Carroll Validation strings in RecordsConfig.cc are ignored (or not correctly handled) - Key: TS-2442 URL: https://issues.apache.org/jira/browse/TS-2442 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.2.0 We have all these nice validation strings / regexes / ranges in RecordsConfig.cc, but it seems we take little or no action on failures on them. We should fix that. Also see TS-1992. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2442) Validation strings in RecordsConfig.cc are ignored (or not correctly handled)
[ https://issues.apache.org/jira/browse/TS-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2442: Fix Version/s: (was: 5.1.0) 5.2.0 Validation strings in RecordsConfig.cc are ignored (or not correctly handled) - Key: TS-2442 URL: https://issues.apache.org/jira/browse/TS-2442 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.2.0 We have all these nice validation strings / regexes / ranges in RecordsConfig.cc, but it seems we take little or no action on failures on them. We should fix that. Also see TS-1992. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2443) cache.config isn't suitable for forward caching
[ https://issues.apache.org/jira/browse/TS-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2443: Fix Version/s: (was: 5.1.0) 5.2.0 cache.config isn't suitable for forward caching --- Key: TS-2443 URL: https://issues.apache.org/jira/browse/TS-2443 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: zhiyuanfu Assignee: James Peach Fix For: 5.2.0 Use ats for forward caching. Many objects' header have not cache control information. So I use ttl-in-cache to forced to control cache,but ttl-in-cache will cause many problems when using forward cacheing. Like range object will be cached as a intact object for next time request. Our cache control plugin: https://github.com/acache/stateam_trafficserver/tree/master -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2447) Cache fails to load / initialize, seems stuck on directory entry cleanup
[
https://issues.apache.org/jira/browse/TS-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2447:
Fix Version/s: (was: 5.1.0)
5.2.0
Cache fails to load / initialize, seems stuck on directory entry cleanup
Key: TS-2447
URL: https://issues.apache.org/jira/browse/TS-2447
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 5.2.0
We had an issue where a number of machines would not startup properly. They
get stuck on reading / initializing the cache. It initializes the caches with
{code}
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 0:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 1:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 2:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 3:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 4:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 5:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 6:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 65536
[Dec 20 16:45:40.198] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.201] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.204] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.208] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.213] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.219] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.224] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
{code}
After this, it enters a stage where it’s doing a *lot* of dir_clean events:
{code}
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f028 tag 0 boffset 0 b 0x7f3edcd6f028 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f050 tag 0 boffset 0 b 0x7f3edcd6f050 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f078 tag 0 boffset 0 b 0x7f3edcd6f078 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0a0 tag 0 boffset 0 b 0x7f3edcd6f0a0 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0c8 tag 0 boffset 0
[jira] [Updated] (TS-2449) I find INKUDPRecvFrom can not work .
[ https://issues.apache.org/jira/browse/TS-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2449: -- Labels: review (was: ) I find INKUDPRecvFrom can not work . - Key: TS-2449 URL: https://issues.apache.org/jira/browse/TS-2449 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.1.2 Reporter: xinyuziran Labels: review Fix For: 5.1.0 Attachments: iocore.patch, main.patch, udp_patch.txt I find INKUDPBind can bind udp port, but INKUDPRecvFrom can't recive udp data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2470) PCT type metrics seems out of whack
[
https://issues.apache.org/jira/browse/TS-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2470:
Fix Version/s: (was: 5.1.0)
5.2.0
PCT type metrics seems out of whack
---
Key: TS-2470
URL: https://issues.apache.org/jira/browse/TS-2470
Project: Traffic Server
Issue Type: Bug
Components: Metrics
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.2.0
From my latest master build:
{code}
proxy.node.bandwidth_hit_ratio_int_pct=429227680
proxy.node.hostdb.hit_ratio_int_pct=1116599040
proxy.node.cache_hit_ratio_int_pct=419143744
proxy.node.bandwidth_hit_ratio_avg_10s_int_pct=362055712
proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct=50927432
proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct=50927432
proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct=1018548608
proxy.node.cache.percent_free_int_pct=1077459456
{code}
Neither of these seem particularly reasonable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2480: Fix Version/s: (was: 5.1.0) 5.2.0 Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Wei Sun Assignee: Bryan Call Labels: review Fix For: 5.2.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2480: Assignee: James Peach (was: Bryan Call) Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Wei Sun Assignee: James Peach Labels: review Fix For: 5.2.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2561) remove app-template from examples
[ https://issues.apache.org/jira/browse/TS-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2561: Fix Version/s: (was: 5.1.0) 5.2.0 remove app-template from examples - Key: TS-2561 URL: https://issues.apache.org/jira/browse/TS-2561 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 5.0.0 Reporter: Zhao Yongming Assignee: Leif Hedstrom Fix For: 5.2.0 due to the STANDALONE IOCORE is removed, the app-template example should not be there. and most of the app-template STANDALONE IOCORE design purpose is able to satisfied with the protocol plugin. let us remove it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2506) active request timeout leaves client hanging
[
https://issues.apache.org/jira/browse/TS-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2506:
Fix Version/s: (was: 5.1.0)
5.2.0
active request timeout leaves client hanging
Key: TS-2506
URL: https://issues.apache.org/jira/browse/TS-2506
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: James Peach
Assignee: James Peach
Fix For: 5.2.0
If you set {{proxy.config.http.transaction_active_timeout_out}} and the
origin response takes too long, the origin end of the HTTP tunnel will get
shut down, but the user agent will never get notified. The user agent just
keeps waiting for a response that will never come.
The HTTP debug log looks like this:
{code}
+ Proxy's Response 2 +
-- State Machine Id: 1
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Thu, 16 Jan 2014 01:06:06 GMT
Age: 0
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/4.2.0
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:6769
(call_transact_and_set_next_state) (http) [1] State Transition:
ORIGIN_SERVER_OPEN - SERVER_READ
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:7278
(do_redirect) (http_redirect) [HttpSM::do_redirect]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:1583
(deallocate_redirect_postdata_buffers) (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:584
(add_producer) (http_tunnel) [1] adding producer 'http server'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:640
(add_consumer) (http_tunnel) [1] adding consumer 'user agent'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpSM.cc:5345
(perform_cache_write_action) (http) [1] perform_cache_write_action
CACHE_DO_NO_ACTION
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:686
(tunnel_run) (http_tunnel) tunnel_run started, p_arg is NULL
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:253
(do_io_write) (http_cs) tcp_init_cwnd_set 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:265
(set_tcp_init_cwnd) (http_cs) desired TCP congestion window is 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:905
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.chunked_reader-read_avail() = 184
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:909
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.skip_bytes = 161
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:142
(read_size) (http_chunk) read chunk size of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:217
(read_chunk) (http_chunk) completed read of chunk of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 100
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1240
(consumer_handler) (http_tunnel) [1] consumer_handler [user agent
VC_EVENT_WRITE_READY]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 106
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:2791
(tunnel_handler_server) (http) [1] [HttpSM::tunnel_handler_server,
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpTunnel.cc:1240
(consumer_handler) (http_tunnel) [1] consumer_handler [user agent
VC_EVENT_WRITE_COMPLETE]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:3029
(tunnel_handler_ua) (http) [1] [HttpSM::tunnel_handler_ua,
VC_EVENT_WRITE_COMPLETE]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpClientSession.cc:592
(release) (http_cs) [1] session released by sm [1]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpClientSession.cc:618
(release) (http_cs) [1]
[jira] [Resolved] (TS-2506) active request timeout leaves client hanging
[
https://issues.apache.org/jira/browse/TS-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2506.
-
Resolution: Duplicate
active request timeout leaves client hanging
Key: TS-2506
URL: https://issues.apache.org/jira/browse/TS-2506
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: James Peach
Assignee: James Peach
Fix For: 5.2.0
If you set {{proxy.config.http.transaction_active_timeout_out}} and the
origin response takes too long, the origin end of the HTTP tunnel will get
shut down, but the user agent will never get notified. The user agent just
keeps waiting for a response that will never come.
The HTTP debug log looks like this:
{code}
+ Proxy's Response 2 +
-- State Machine Id: 1
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Thu, 16 Jan 2014 01:06:06 GMT
Age: 0
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/4.2.0
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:6769
(call_transact_and_set_next_state) (http) [1] State Transition:
ORIGIN_SERVER_OPEN - SERVER_READ
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:7278
(do_redirect) (http_redirect) [HttpSM::do_redirect]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:1583
(deallocate_redirect_postdata_buffers) (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:584
(add_producer) (http_tunnel) [1] adding producer 'http server'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:640
(add_consumer) (http_tunnel) [1] adding consumer 'user agent'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpSM.cc:5345
(perform_cache_write_action) (http) [1] perform_cache_write_action
CACHE_DO_NO_ACTION
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:686
(tunnel_run) (http_tunnel) tunnel_run started, p_arg is NULL
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:253
(do_io_write) (http_cs) tcp_init_cwnd_set 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:265
(set_tcp_init_cwnd) (http_cs) desired TCP congestion window is 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:905
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.chunked_reader-read_avail() = 184
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:909
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.skip_bytes = 161
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:142
(read_size) (http_chunk) read chunk size of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:217
(read_chunk) (http_chunk) completed read of chunk of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 100
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1240
(consumer_handler) (http_tunnel) [1] consumer_handler [user agent
VC_EVENT_WRITE_READY]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 106
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:2791
(tunnel_handler_server) (http) [1] [HttpSM::tunnel_handler_server,
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpTunnel.cc:1240
(consumer_handler) (http_tunnel) [1] consumer_handler [user agent
VC_EVENT_WRITE_COMPLETE]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:3029
(tunnel_handler_ua) (http) [1] [HttpSM::tunnel_handler_ua,
VC_EVENT_WRITE_COMPLETE]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpClientSession.cc:592
(release) (http_cs) [1] session released by sm [1]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpClientSession.cc:618
(release) (http_cs) [1] initiating io for next header
[Jan 15
[jira] [Updated] (TS-2581) Add / modify APIs to allow easy freelist allocation of iobuffer's from C/C++ plugins
[ https://issues.apache.org/jira/browse/TS-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2581: Fix Version/s: (was: 5.1.0) sometime Add / modify APIs to allow easy freelist allocation of iobuffer's from C/C++ plugins Key: TS-2581 URL: https://issues.apache.org/jira/browse/TS-2581 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: api-addition Fix For: sometime This would allow for efficient allocations in plugins, such that they can do an in-place new() on a chunk of memory (iobuffer). The API / features should make it easy and possible to asks for an iobuffer of at least size x. It can return a bigger one, at which point, you'd waste some. But this allows us to reuse / repurpose the existing iobuffer allocation. Phil points out that there are existing iobuffer allocation APIs, so maybe something in conjunction with that is appropriate. I would like for this to be easy on the plugin user though, such that it's as simple as malloc/free chains. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2574) Sharing server sessions per thread doesn't work when doing https to http
[ https://issues.apache.org/jira/browse/TS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083024#comment-14083024 ] Alan M. Carroll commented on TS-2574: - Brian; If you fixed this, resolve the bug. Sharing server sessions per thread doesn't work when doing https to http Key: TS-2574 URL: https://issues.apache.org/jira/browse/TS-2574 Project: Traffic Server Issue Type: Bug Components: HTTP, SSL Reporter: Bryan Call Assignee: Brian Geffon Fix For: 5.1.0 Attachments: TS-2574.patch When running a reverse proxy with incoming https scheme and outgoing http, the share server sessions value of 2 doesn't work. Since the https and http thread pools are separate after using the http connection it will be released to the http thread. When a new https request comes in it will look in the https threads servers session pool to make a request to the origin even though it is a http request. Of course it will fail the lookup since the ports wont match. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2602) Support continuation lines in regex_remap configs
[
https://issues.apache.org/jira/browse/TS-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2602:
Fix Version/s: (was: 5.1.0)
sometime
Support continuation lines in regex_remap configs
-
Key: TS-2602
URL: https://issues.apache.org/jira/browse/TS-2602
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: sometime
With the introduction of overridable configurations (TS-2585), regex_remap
rules can now be fairly long. It'd be swell to support continuation lines,
e.g.
{code}
. http://www.ogre.com/ \
@proxy.config.http.insert_response_via_str=1 \
@proxy.config.http.background_fill_completed_threshold=0.75
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2591: Fix Version/s: (was: 5.1.0) 5.2.0 Cache does not invalidate variant/alternate content types on PUT or POST - Key: TS-2591 URL: https://issues.apache.org/jira/browse/TS-2591 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Norm Paxton Assignee: Leif Hedstrom Fix For: 5.2.0 Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are: PUT, DELETE, POST. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 (This doesn't explicitly address variant content types, I read it as implied.) The current caching implementation only invalidates the Request URI, and not variant/alternate URI's. Example: A REST service provides both xml and json documents. A client app requests in both content-types (perhaps two different components, one expects xml, the other json). Assume both documents (xml and json) are in the cache. If the app PUTs a modification to the object in XML (ie, changes a User object's email address), it should then be able to retrieve the correct object data via a GET in json. In order to do so, the json object in the cache would need to be invalidated, so that the cache server forwards the request on to the REST service. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2609) Header rewrite plugin ORIGIN-HOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2609: Fix Version/s: (was: 5.1.0) sometime Header rewrite plugin ORIGIN-HOST condition --- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Assignee: Leif Hedstrom Priority: Minor Labels: review Fix For: sometime Enhance header rewrite plugin to support ORIGIN-HOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2633) 406 negative responses being cached for too long
[ https://issues.apache.org/jira/browse/TS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2633: Fix Version/s: (was: 5.1.0) 5.2.0 406 negative responses being cached for too long Key: TS-2633 URL: https://issues.apache.org/jira/browse/TS-2633 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2 Reporter: David Carlin Assignee: Bryan Call Labels: yahoo Fix For: 5.2.0 Settings: proxy.config.http.negative_caching_enabled = 1 proxy.config.http.negative_caching_lifetime = 500 406 response is being cached, but lifetime isn't being adhered to. They are cached for much longer, perhaps indefinitely. I have seen Age: increase to several hours. With proxy.config.http.negative_caching_enabled = 0 then 406 responses are not cached. Bryan pointed out that the docs don't list 406 as one of the cached negative responses: http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2629) Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
[
https://issues.apache.org/jira/browse/TS-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2629:
Fix Version/s: (was: 5.1.0)
sometime
Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
---
Key: TS-2629
URL: https://issues.apache.org/jira/browse/TS-2629
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: sometime
It seems even with the default configuration:
{code}
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
{code}
ATS can create much larger orphaned logs, e.g.
{code}
$ du -h log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
442M log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2644) TOS (DSCP)
[ https://issues.apache.org/jira/browse/TS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2644: --- Assignee: Phil Sorber (was: Leif Hedstrom) TOS (DSCP) --- Key: TS-2644 URL: https://issues.apache.org/jira/browse/TS-2644 Project: Traffic Server Issue Type: New Feature Components: Cache, Network Reporter: Faysal Banna Assignee: Phil Sorber Labels: review Fix For: 5.2.0 Attachments: domain_tos.cc Hi Guys I wonder if it would be possible to have a plugin that we can assign TOS/DSCP bits to the objects that are being a cache HIT or maybe object type of video/audio. such a plugin would give us better performance and control on how to distribute the output of the cache towards clients. example : suppose i set traffic to clients each of different bandwidth. on a router on a link somewhere on some roof top building i can say this client can get miss object traffic of 512Kbit/s and 1Mbit/s of Hits from the cache. this way if this client is getting a cached object he would get it in 1Mbit/s while his non cached requests would be of 512Kbit/s hope whoever does this patch plugin takes into consideration the mime type or url of the object being retrieved maybe i want to set audio/video being cached or not to have 768Kbit/s while windows updates and android/iphone apps should take no more than 512kbit/s bear in mind that this has nothing to do with Origin servers throttling feature request. this is just client side feature set. much regards Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2645) Crash in HttpTunnel
[ https://issues.apache.org/jira/browse/TS-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2645: Fix Version/s: (was: 5.1.0) 5.2.0 Crash in HttpTunnel --- Key: TS-2645 URL: https://issues.apache.org/jira/browse/TS-2645 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Peter Walsh Fix For: 5.2.0 Occasionally we are seeing crashes after the event TS_EVENT_HTTP_SEND_RESPONSE_HDR. We are working on trying to reproduce this, however because it happens only every couple days we have so far not identified the cause. I will update this ticket as I gather more information. /usr/local/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x3f8380eca0] /usr/local/bin/traffic_server(HttpTunnel::producer_run(HttpTunnelProducer*)+0x630)[0x573fb0] /usr/local/bin/traffic_server(HttpTunnel::tunnel_run(HttpTunnelProducer*)+0xd6)[0x574b96] /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x90)[0x52e020] /usr/local/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x9e)[0x5311ae] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2640) Does _TSAssert() really have to return an int (always 0) ?
[
https://issues.apache.org/jira/browse/TS-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll closed TS-2640.
---
Resolution: Won't Fix
Behavior is required by standard assert mechanisms.
Does _TSAssert() really have to return an int (always 0) ?
--
Key: TS-2640
URL: https://issues.apache.org/jira/browse/TS-2640
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Labels: api-change
I don't know why, but we have
{code}
_TSAssert(const char *text, const char *file, int line)
{
_ink_assert(text, file, line);
return 0;
}
{code}
Why the return 0 ?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2640) Does _TSAssert() really have to return an int (always 0) ?
[
https://issues.apache.org/jira/browse/TS-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2640:
Fix Version/s: (was: 5.1.0)
Does _TSAssert() really have to return an int (always 0) ?
--
Key: TS-2640
URL: https://issues.apache.org/jira/browse/TS-2640
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Labels: api-change
I don't know why, but we have
{code}
_TSAssert(const char *text, const char *file, int line)
{
_ink_assert(text, file, line);
return 0;
}
{code}
Why the return 0 ?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2644) TOS (DSCP)
[ https://issues.apache.org/jira/browse/TS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2644: Fix Version/s: (was: 5.1.0) 5.2.0 TOS (DSCP) --- Key: TS-2644 URL: https://issues.apache.org/jira/browse/TS-2644 Project: Traffic Server Issue Type: New Feature Components: Cache, Network Reporter: Faysal Banna Assignee: Leif Hedstrom Labels: review Fix For: 5.2.0 Attachments: domain_tos.cc Hi Guys I wonder if it would be possible to have a plugin that we can assign TOS/DSCP bits to the objects that are being a cache HIT or maybe object type of video/audio. such a plugin would give us better performance and control on how to distribute the output of the cache towards clients. example : suppose i set traffic to clients each of different bandwidth. on a router on a link somewhere on some roof top building i can say this client can get miss object traffic of 512Kbit/s and 1Mbit/s of Hits from the cache. this way if this client is getting a cached object he would get it in 1Mbit/s while his non cached requests would be of 512Kbit/s hope whoever does this patch plugin takes into consideration the mime type or url of the object being retrieved maybe i want to set audio/video being cached or not to have 768Kbit/s while windows updates and android/iphone apps should take no more than 512kbit/s bear in mind that this has nothing to do with Origin servers throttling feature request. this is just client side feature set. much regards Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2682) Add per remap configuration / activation to background_fetch
[ https://issues.apache.org/jira/browse/TS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2682: Fix Version/s: (was: 5.1.0) 6.0.0 Add per remap configuration / activation to background_fetch Key: TS-2682 URL: https://issues.apache.org/jira/browse/TS-2682 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2696) Add / move memory barrier defines from plugins to ink_atomic.h
[ https://issues.apache.org/jira/browse/TS-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-2696. --- Resolution: Won't Fix We will use Concurrency Kit to do this. Add / move memory barrier defines from plugins to ink_atomic.h -- Key: TS-2696 URL: https://issues.apache.org/jira/browse/TS-2696 Project: Traffic Server Issue Type: Improvement Components: Core, Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.1.0 A couple of plugins are using memory barrier defines. We should move these into one place, ink_atomic.h. -- This message was sent by Atlassian JIRA (v6.2#6252)
