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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot logged work on TS-3474:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 07:24
Start Date: 09/Sep/16 07:24
Worklog Time Spent: 10m 
  Work Description: Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
It doesn't work correctly after the rebasing. I'm working on it.


Issue Time Tracking
---

Worklog Id: (was: 28572)
Time Spent: 5h 10m  (was: 5h)

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



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

[GitHub] trafficserver issue #833: TS-3474: HTTP/2 Server Push support

[maskit]

Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
It doesn't work correctly after the rebasing. I'm working on it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Comment Edited] (TS-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

[David Brodin (JIRA)]

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

David Brodin edited comment on TS-4816 at 9/9/16 7:32 AM:
--

Hi [~zwoop] and [~jamespeach], {{traffic_server}} just crashed, I got some 
output from gdbs {{bt}} and {{info locals}}. I'm attaching the output in the 
file {{gdb-traffic_server-160909.txt}}.


was (Author: durd):
Hi [-zwoop] and [-jamespeach], {{traffic_server}} just crashed, I got some 
output from gdbs {{bt}} and {{info locals}}. I'm attaching the output in the 
file {{gdb-traffic_server-160909.txt}}.

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, ats_manager-gdb-160906.txt, 
> crash-2016-09-05-075309.log, est_socks-ats_6.2.0.png, 
> gdb-traffic_server-160909.txt
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm not sure if I'm leaving some of 
> the stacktr

[jira] [Updated] (TS-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

[David Brodin (JIRA)]

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

David Brodin updated TS-4816:
-
Attachment: gdb-traffic_server-160909.txt

Hi [-zwoop] and [-jamespeach], {{traffic_server}} just crashed, I got some 
output from gdbs {{bt}} and {{info locals}}. I'm attaching the output in the 
file {{gdb-traffic_server-160909.txt}}.

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, ats_manager-gdb-160906.txt, 
> crash-2016-09-05-075309.log, est_socks-ats_6.2.0.png, 
> gdb-traffic_server-160909.txt
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm not sure if I'm leaving some of 
> the stacktrace out:
> {noformat}
> traffic_server[TrafficManager] ==> Cleaning up and reissuing signal #15
> : Terminated
> traffic_server: Terminatedtraffic_servertraffic_servertraffic_server: 
> Segmentation fault
> traffic_server - STACK TRACE:
> 0x4af409 <_Z19crash_logger_invokeiP

[jira] [Comment Edited] (TS-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

[David Brodin (JIRA)]

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

David Brodin edited comment on TS-4816 at 9/9/16 7:32 AM:
--

Hi [~zwoop] and [~jamespeach], {{traffic_server}} just crashed, I got some 
output from gdbs {{bt}} and {{info locals}}. I'm attaching the output in the 
file {{gdb-traffic_server-160909.txt}}.
Hope there's something there for you guys :s


was (Author: durd):
Hi [~zwoop] and [~jamespeach], {{traffic_server}} just crashed, I got some 
output from gdbs {{bt}} and {{info locals}}. I'm attaching the output in the 
file {{gdb-traffic_server-160909.txt}}.

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, ats_manager-gdb-160906.txt, 
> crash-2016-09-05-075309.log, est_socks-ats_6.2.0.png, 
> gdb-traffic_server-160909.txt
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm n

[jira] [Comment Edited] (TS-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

[David Brodin (JIRA)]

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

David Brodin edited comment on TS-4816 at 9/9/16 7:33 AM:
--

Hi [~zwoop] and [~jamespeach], {{traffic_server}} just crashed, I got some 
output from gdbs {{bt}} and {{info locals}}. I'm attaching the output in the 
file {{gdb-traffic_server-160909.txt}}.
Hope there's something there for you guys :s

Edit: this was running the downloaded source from ATS-web, not installed from 
FreeBSD ports.


was (Author: durd):
Hi [~zwoop] and [~jamespeach], {{traffic_server}} just crashed, I got some 
output from gdbs {{bt}} and {{info locals}}. I'm attaching the output in the 
file {{gdb-traffic_server-160909.txt}}.
Hope there's something there for you guys :s

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, ats_manager-gdb-160906.txt, 
> crash-2016-09-05-075309.log, est_socks-ats_6.2.0.png, 
> gdb-traffic_server-160909.txt
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.

[GitHub] trafficserver pull request #999: TS-4759: Fix stream states management

[masaori335]

GitHub user masaori335 opened a pull request:

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

TS-4759: Fix stream states management

Below is the situation when this failure is happen.

1. h2spec sends a HEADERS frame with END_HEADERS flag and without 
END_STREAM flag.
2. TS returns a HEADERS frame and two DATA frames immediately. And TS set 
server side stream state `closed`.
3. h2spec sends RST_STREAM with a length other than 4 cotets.
4. TS ignores RST_STREAM to closed stream. 

There are two problems.

- h2spec assumes server side stream state is open. ( This is fixed by 
h2spec v1.5.0 )
- At #2, TS should change server side stream state to `half-close (local)`.
   And send RST_STREAM frame to client and make state `closed`.

To fix this

- Change stream state to `half-close (local)` from `idle` or `open` when 
send a frame w/ END_STREAM flag
- Make send_a_data_frame to return HTTP2_SEND_A_DATA_FRAME_DONE when send 
DATA frame w/ END_STREAM flag
- Set stream state CLOSED when error is happen

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

$ git pull https://github.com/masaori335/trafficserver ts-4759

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

https://github.com/apache/trafficserver/pull/999.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #999


commit a907e554efcfd4789ad13e7bf3df32ed2de273ea
Author: Masaori Koshiba 
Date:   2016-08-29T06:19:00Z

TS-4759: Fix stream states management

- Change stream state from IDLE or OPEN to HALF_CLOSED_LOCAL when send a 
frame w/ END_STREAM
- Make send_a_data_frame to return HTTP2_SEND_A_DATA_FRAME_DONE when send 
DATA frame w/ END_STREAM
- Set stream state CLOSED when error is happen




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4759) Intermittent HTTP/2 failure with h2spec (6.4.)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4759?focusedWorklogId=28573&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28573
 ]

ASF GitHub Bot logged work on TS-4759:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 07:43
Start Date: 09/Sep/16 07:43
Worklog Time Spent: 10m 
  Work Description: GitHub user masaori335 opened a pull request:

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

TS-4759: Fix stream states management

Below is the situation when this failure is happen.

1. h2spec sends a HEADERS frame with END_HEADERS flag and without 
END_STREAM flag.
2. TS returns a HEADERS frame and two DATA frames immediately. And TS set 
server side stream state `closed`.
3. h2spec sends RST_STREAM with a length other than 4 cotets.
4. TS ignores RST_STREAM to closed stream. 

There are two problems.

- h2spec assumes server side stream state is open. ( This is fixed by 
h2spec v1.5.0 )
- At #2, TS should change server side stream state to `half-close (local)`.
   And send RST_STREAM frame to client and make state `closed`.

To fix this

- Change stream state to `half-close (local)` from `idle` or `open` when 
send a frame w/ END_STREAM flag
- Make send_a_data_frame to return HTTP2_SEND_A_DATA_FRAME_DONE when send 
DATA frame w/ END_STREAM flag
- Set stream state CLOSED when error is happen

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

$ git pull https://github.com/masaori335/trafficserver ts-4759

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

https://github.com/apache/trafficserver/pull/999.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #999


commit a907e554efcfd4789ad13e7bf3df32ed2de273ea
Author: Masaori Koshiba 
Date:   2016-08-29T06:19:00Z

TS-4759: Fix stream states management

- Change stream state from IDLE or OPEN to HALF_CLOSED_LOCAL when send a 
frame w/ END_STREAM
- Make send_a_data_frame to return HTTP2_SEND_A_DATA_FRAME_DONE when send 
DATA frame w/ END_STREAM
- Set stream state CLOSED when error is happen




Issue Time Tracking
---

Worklog Id: (was: 28573)
Time Spent: 10m
Remaining Estimate: 0h

> Intermittent HTTP/2 failure with h2spec (6.4.)
> --
>
> Key: TS-4759
> URL: https://issues.apache.org/jira/browse/TS-4759
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
>   6.4. RST_STREAM
> × Sends a RST_STREAM frame with a length other than 4 octets
>   - The endpoint MUST respond with a connection error of type 
> FRAME_SIZE_ERROR.
> Expected: GOAWAY frame (ErrorCode: FRAME_SIZE_ERROR)
>   Connection close
>   Actual: DATA frame (Length: 0, Flags: 1)
> {noformat}
> ( h2spec v1.4.2 )



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

[jira] [Updated] (TS-4759) Intermittent HTTP/2 failure with h2spec (6.4.)

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4759:

Fix Version/s: (was: 7.1.0)
   7.0.0

> Intermittent HTTP/2 failure with h2spec (6.4.)
> --
>
> Key: TS-4759
> URL: https://issues.apache.org/jira/browse/TS-4759
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
>   6.4. RST_STREAM
> × Sends a RST_STREAM frame with a length other than 4 octets
>   - The endpoint MUST respond with a connection error of type 
> FRAME_SIZE_ERROR.
> Expected: GOAWAY frame (ErrorCode: FRAME_SIZE_ERROR)
>   Connection close
>   Actual: DATA frame (Length: 0, Flags: 1)
> {noformat}
> ( h2spec v1.4.2 )



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

[jira] [Closed] (TS-4218) Intermittent HTTP/2 failure with h2spec (8.1.)

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba closed TS-4218.
---
Resolution: Duplicate

I thought this is related to TS-3812 at first, but this looks same problems to 
TS-4759.

> Intermittent HTTP/2 failure with h2spec (8.1.)
> --
>
> Key: TS-4218
> URL: https://issues.apache.org/jira/browse/TS-4218
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>
> Sometimes I see a test for {{8.1. HTTP Request/Response Exchange}} in h2spec 
> is failed.
> - h2spec : v1.3.1
> - ATS master (9c707a89d58f0b635cc3c2070025ba08161beec0)
> {noformat}
>   8.1. HTTP Request/Response Exchange
> × Sends a second HEADERS frame without the END_STREAM flag
>   - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
> Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
>   RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
>   Connection close
>   Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: 
> STREAM_CLOSED)
> {noformat}



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

[jira] [Work logged] (TS-4759) Intermittent HTTP/2 failure with h2spec (6.4.)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4759?focusedWorklogId=28574&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28574
 ]

ASF GitHub Bot logged work on TS-4759:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 07:56
Start Date: 09/Sep/16 07:56
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28574)
Time Spent: 20m  (was: 10m)

> Intermittent HTTP/2 failure with h2spec (6.4.)
> --
>
> Key: TS-4759
> URL: https://issues.apache.org/jira/browse/TS-4759
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {noformat}
>   6.4. RST_STREAM
> × Sends a RST_STREAM frame with a length other than 4 octets
>   - The endpoint MUST respond with a connection error of type 
> FRAME_SIZE_ERROR.
> Expected: GOAWAY frame (ErrorCode: FRAME_SIZE_ERROR)
>   Connection close
>   Actual: DATA frame (Length: 0, Flags: 1)
> {noformat}
> ( h2spec v1.4.2 )



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

[GitHub] trafficserver issue #999: TS-4759: Fix stream states management

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #999: TS-4759: Fix stream states management

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4759) Intermittent HTTP/2 failure with h2spec (6.4.)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4759?focusedWorklogId=28575&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28575
 ]

ASF GitHub Bot logged work on TS-4759:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 07:59
Start Date: 09/Sep/16 07:59
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28575)
Time Spent: 0.5h  (was: 20m)

> Intermittent HTTP/2 failure with h2spec (6.4.)
> --
>
> Key: TS-4759
> URL: https://issues.apache.org/jira/browse/TS-4759
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
>   6.4. RST_STREAM
> × Sends a RST_STREAM frame with a length other than 4 octets
>   - The endpoint MUST respond with a connection error of type 
> FRAME_SIZE_ERROR.
> Expected: GOAWAY frame (ErrorCode: FRAME_SIZE_ERROR)
>   Connection close
>   Actual: DATA frame (Length: 0, Flags: 1)
> {noformat}
> ( h2spec v1.4.2 )



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

[GitHub] trafficserver issue #833: TS-3474: HTTP/2 Server Push support

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot logged work on TS-3474:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 09:36
Start Date: 09/Sep/16 09:36
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28576)
Time Spent: 5h 20m  (was: 5h 10m)

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



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

[GitHub] trafficserver issue #833: TS-3474: HTTP/2 Server Push support

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot logged work on TS-3474:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 09:39
Start Date: 09/Sep/16 09:39
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28577)
Time Spent: 5.5h  (was: 5h 20m)

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



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

[GitHub] trafficserver issue #833: TS-3474: HTTP/2 Server Push support

[maskit]

Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
It works now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot logged work on TS-3474:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 09:41
Start Date: 09/Sep/16 09:41
Worklog Time Spent: 10m 
  Work Description: Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
It works now.


Issue Time Tracking
---

Worklog Id: (was: 28578)
Time Spent: 5h 40m  (was: 5.5h)

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



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

[GitHub] trafficserver issue #990: TS-3216: Add HPKP Support

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3216?focusedWorklogId=28579&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28579
 ]

ASF GitHub Bot logged work on TS-3216:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 10:08
Start Date: 09/Sep/16 10:08
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28579)
Time Spent: 40m  (was: 0.5h)

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[GitHub] trafficserver issue #990: TS-3216: Add HPKP Support

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3216?focusedWorklogId=28580&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28580
 ]

ASF GitHub Bot logged work on TS-3216:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 10:09
Start Date: 09/Sep/16 10:09
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28580)
Time Spent: 50m  (was: 40m)

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[jira] [Commented] (TS-4503) MachineFatal should shutdown without cleanup

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4503:


Persia is working on this (PR 991).  Don't know why her PR activity isn't 
adding comments. here.

> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[jira] [Created] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

[Dimitry Andric (JIRA)]

Dimitry Andric created TS-4838:
--

 Summary: After TS-3612 restructuring, very slow SSL sessions and 
HttpSM::state_raw_http_server_open errors
 Key: TS-4838
 URL: https://issues.apache.org/jira/browse/TS-4838
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, SSL
Reporter: Dimitry Andric


We have been using TrafficServer 5.3.2 for quite some time now, for forward 
proxying of a number of different HTML5 applications, one of the most important 
ones being YouTube's TV interface, e.g. https://youtube.com/tv.  This is all 
hosted on CentOS 7.2 x86_64 machines.

We recently upgraded to 6.2.0, and then started having problems with the 
CONNECT requests for port 443 which are generated by the YouTube app.  It seems 
like these connections are "stalled" somehow, sometimes for >10 seconds.  
Meanwhile, {{diags.log}} is getting spammed lots of the following:
{noformat}
[Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
[HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
server_entry: (nil)
{noformat}

Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
{noformat}
1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
DIRECT/i9.ytimg.com -
1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ - 
DIRECT/csi.gstatic.com -
1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT www.youtube.com:443/ 
- DIRECT/www.youtube.com -
1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
r17---sn-5hnednl7.googlevideo.com:443/ - 
DIRECT/r17---sn-5hnednl7.googlevideo.com -
{noformat}

As part of figuring out how to diagnose this, I tried a downgrade to 
TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
the branch point of 6.2, and I ended up at [commit 
af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
{quote}
Author: Susan Hinrichs 
Date:   Wed Apr 13 19:57:39 2016 +

TS-3612: Restructure client session and transaction processing. This closes 
#570.
{quote}

Unfortunately, this is a quite big refactoring commit, so it is not possible to 
revert it individually to see whether it improves things.

I read TS-3612 and #570, and I saw there were also a number of follow-up 
commits to fix various problems with it, but this particular problem of stalled 
SSL connections is still occurring with master as of today, 2016-09-09.

I realize that this report is still missing reproduction details, since it is 
tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
itself is pretty easy to try out, I think.




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

[jira] [Updated] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

[Dimitry Andric (JIRA)]

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

Dimitry Andric updated TS-4838:
---
Affects Version/s: 7.0.0
   6.2.0
  Environment: CentOS/RHEL 7.2, x86_64

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



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

[GitHub] trafficserver issue #996: TS-4834 Expose bad disk and disk access failures

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/996
  
My comments from [TS-4834](https://issues.apache.org/jira/browse/TS-4834) ..

>I think the nomenclature should mirror the existing metrics which 
typically don't include "count" in the names. Especially since the count of bad 
disks (gauge) does not have the same semantics as the count of disk errors 
(counter).

Looking at the code I think the bad disk metric is a counter not a gauge.

> Is "disk" the right nomenclature, or would "span" be more accurate?
How feasible is it to have separate metrics for read and write errors? Does 
it make sense to also have metrics for disk read and write operations, or are 
system tools sufficient for that?
If you have a count of bad disks, does it make sense to have other disk 
counts? ie. good disks, offline disks, etc.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4834) Expose bad disk and disk access failures

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4834?focusedWorklogId=28581&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28581
 ]

ASF GitHub Bot logged work on TS-4834:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:04
Start Date: 09/Sep/16 15:04
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/996
  
My comments from [TS-4834](https://issues.apache.org/jira/browse/TS-4834) ..

>I think the nomenclature should mirror the existing metrics which 
typically don't include "count" in the names. Especially since the count of bad 
disks (gauge) does not have the same semantics as the count of disk errors 
(counter).

Looking at the code I think the bad disk metric is a counter not a gauge.

> Is "disk" the right nomenclature, or would "span" be more accurate?
How feasible is it to have separate metrics for read and write errors? Does 
it make sense to also have metrics for disk read and write operations, or are 
system tools sufficient for that?
If you have a count of bad disks, does it make sense to have other disk 
counts? ie. good disks, offline disks, etc.


Issue Time Tracking
---

Worklog Id: (was: 28581)
Time Spent: 40m  (was: 0.5h)

> Expose bad disk and disk access failures
> 
>
> Key: TS-4834
> URL: https://issues.apache.org/jira/browse/TS-4834
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We would like to monitor low-level disk access failures and disks marked by 
> ATS as bad.
> I have a patch that exposes that information through
> {code}
> proxy.process.cache.disk_error_count 10
> proxy.process.cache.disk_bad_count 5
> {code}
> and the following tests/shows how it would work...
> Start ATS with 2 disks and tail {{diags.log}}
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ tail -f var/log/trafficserver/diags.log
> [Sep  8 12:18:48.149] Server {0x2b5f43db54c0} NOTE: traffic server running
> [Sep  8 12:18:48.198] Server {0x2b5f44654700} NOTE: cache enabled
> {code}
> Check related metrics and observe all 0s
> {code}
> $ ./bin/traffic_ctl metric match "proxy.process.cache*.disk.*" 
> "proxy.process.cache.*(read|write).failure" 
> "proxy.process.http.cache_(read|write)_errors"
> proxy.process.cache.disk_error_count 0
> proxy.process.cache.disk_bad_count 0
> proxy.process.cache.read.failure 0
> proxy.process.cache.write.failure 0
> proxy.process.cache.volume_0.read.failure 0
> proxy.process.cache.volume_0.write.failure 0
> proxy.process.http.cache_write_errors 0
> proxy.process.http.cache_read_errors 0
> {code}
> Now using your favorite hard disk failure injection tool inject 10 failures, 
> by setting both disks used by this setup {{/dev/sdb}} and {{/dev/sdc}} to 
> fail all reads. And shoot 5 requests causing 10 failed reads.
> {code}
> $ for i in 1 2 3 4 5; do curl -x 127.0.0.1:80 http://example.com/1 -o 
> /dev/null -s; done
> $ tail -f var/log/trafficserver/diags.log
> [Sep  8 12:19:09.758] Server {0x2aaab4302700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.759] Server {0x2aaac0100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.764] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [1/10]
> [Sep  8 12:19:09.769] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [2/10]
> [Sep  8 12:19:09.785] Server {0x2aaac0100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.786] Server {0x2aaab4302700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.791] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [3/10]
> [Sep  8 12:19:09.796] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [4/10]
> [Sep  8 12:19:09.812] Server {0x2aaab4100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.813] Server {0x2aaacc100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.817] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [5/10]
> [Sep  8 12:19:09.823] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [6/10]
> [Sep  8 12:19:09.843] Server {0x2aaacc302700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.844] Server {0x2aaad8100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.847] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [7/10]
> [Sep  8 12:19:09.854] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [8/10]
> [Sep  8 12

[jira] [Work logged] (TS-4731) Change return type for TSHttpTxnIsInternal and TSHttpSsnIsInternal

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4731?focusedWorklogId=28583&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28583
 ]

ASF GitHub Bot logged work on TS-4731:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:12
Start Date: 09/Sep/16 15:12
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/995#discussion_r78197044
  
--- Diff: doc/developer-guide/api/functions/TSHttpTxnIsInternal.en.rst ---
@@ -41,8 +41,8 @@ was originated within Traffic Server.
 Return Values
 =
 
-Both these APIs returns a :type:`TSReturnCode`, indicating whether the
-object was internal (:data:`TS_SUCCESS`) or not (:data:`TS_ERROR`).
+Both these APIs returns a :type:`int`, indicating whether the
+object was internal (:data:`1`) or not (:data:`0`).
--- End diff --

s/object/transaction/


Issue Time Tracking
---

Worklog Id: (was: 28583)
Time Spent: 1h  (was: 50m)

> Change return type for TSHttpTxnIsInternal and TSHttpSsnIsInternal
> --
>
> Key: TS-4731
> URL: https://issues.apache.org/jira/browse/TS-4731
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> I'd like to propose that we modify these two APIs from:
> {code}
> tsapi TSReturnCode TSHttpTxnIsInternal(TSHttpTxn txnp);
> tsapi TSReturnCode TSHttpSsnIsInternal(TSHttpSsn snap);
> {code}
> to be
> {code}
> tsapi int TSHttpTxnIsInternal(TSHttpTxn txnp);
> tsapi int TSHttpSsnIsInternal(TSHttpSsn snap);
> {code}
> This is more inline with our current standards of using "int" as a boolean 
> type. This is for example the prototype in TSVConnIsSsl() as well as in e.g. 
> TSHttpTxnDebugSet(TSHttpTxn txnp, int on).
> This is an incompatible change though.



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

[GitHub] trafficserver issue #995: TS-4731: Changes return codes for IsInternal APIs

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/995
  
👍 

Consider a heads-up email to dev@ since this change is likely to break 3rd 
party plugins.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4731) Change return type for TSHttpTxnIsInternal and TSHttpSsnIsInternal

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4731?focusedWorklogId=28584&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28584
 ]

ASF GitHub Bot logged work on TS-4731:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:14
Start Date: 09/Sep/16 15:14
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/995
  
👍 

Consider a heads-up email to dev@ since this change is likely to break 3rd 
party plugins.


Issue Time Tracking
---

Worklog Id: (was: 28584)
Time Spent: 1h 10m  (was: 1h)

> Change return type for TSHttpTxnIsInternal and TSHttpSsnIsInternal
> --
>
> Key: TS-4731
> URL: https://issues.apache.org/jira/browse/TS-4731
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> I'd like to propose that we modify these two APIs from:
> {code}
> tsapi TSReturnCode TSHttpTxnIsInternal(TSHttpTxn txnp);
> tsapi TSReturnCode TSHttpSsnIsInternal(TSHttpSsn snap);
> {code}
> to be
> {code}
> tsapi int TSHttpTxnIsInternal(TSHttpTxn txnp);
> tsapi int TSHttpSsnIsInternal(TSHttpSsn snap);
> {code}
> This is more inline with our current standards of using "int" as a boolean 
> type. This is for example the prototype in TSVConnIsSsl() as well as in e.g. 
> TSHttpTxnDebugSet(TSHttpTxn txnp, int on).
> This is an incompatible change though.



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

[GitHub] trafficserver pull request #991: TS-4503: Remove the class ErrorClass and al...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/991#discussion_r78197657
  
--- Diff: proxy/logging/LogBuffer.h ---
@@ -25,6 +25,7 @@
 #define LOG_BUFFER_H
 
 #include "ts/ink_platform.h"
+#include "ts/Diags.h"
--- End diff --

Is this change necessary?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4503) MachineFatal should shutdown without cleanup

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4503?focusedWorklogId=28586&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28586
 ]

ASF GitHub Bot logged work on TS-4503:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:17
Start Date: 09/Sep/16 15:17
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/991
  
This looks good, I have 1 small comment.

@persiaAziz can you update the commit message to have a shorter summary and 
a better description of this change, see the commit message 
[guidelines](https://cwiki.apache.org/confluence/display/TS/CommitPolicies). 
Thanks.


Issue Time Tracking
---

Worklog Id: (was: 28586)
Time Spent: 2.5h  (was: 2h 20m)

> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[GitHub] trafficserver pull request #995: TS-4731: Changes return codes for IsInterna...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/995#discussion_r78197044
  
--- Diff: doc/developer-guide/api/functions/TSHttpTxnIsInternal.en.rst ---
@@ -41,8 +41,8 @@ was originated within Traffic Server.
 Return Values
 =
 
-Both these APIs returns a :type:`TSReturnCode`, indicating whether the
-object was internal (:data:`TS_SUCCESS`) or not (:data:`TS_ERROR`).
+Both these APIs returns a :type:`int`, indicating whether the
+object was internal (:data:`1`) or not (:data:`0`).
--- End diff --

s/object/transaction/


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4316:
-

Yes. This is why I would recommend as a next step enhancing Petar's header 
counter, which will be used to get commonality data for updating the WKS list. 
I don't think it would be much work to have it do a histogram on the number of 
headers also. if it's rare for a request to have 14 headers then this isn't a 
problem. If 14 or more is common we could do a bit of math to see how likely it 
is for a WKS to in an unknown slot.  There is likely to be more data we could 
gather this way.

> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
>  Issue Type: Bug
>  Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards 
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an 
> accelerator, and it causes slower search. Although there is no critical 
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply 
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of 
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change 
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change 
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891



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

[jira] [Work logged] (TS-4731) Change return type for TSHttpTxnIsInternal and TSHttpSsnIsInternal

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4731?focusedWorklogId=28582&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28582
 ]

ASF GitHub Bot logged work on TS-4731:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:11
Start Date: 09/Sep/16 15:11
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/995#discussion_r78196913
  
--- Diff: doc/developer-guide/api/functions/TSHttpTxnIsInternal.en.rst ---
@@ -41,8 +41,8 @@ was originated within Traffic Server.
 Return Values
 =
 
-Both these APIs returns a :type:`TSReturnCode`, indicating whether the
-object was internal (:data:`TS_SUCCESS`) or not (:data:`TS_ERROR`).
+Both these APIs returns a :type:`int`, indicating whether the
--- End diff --

s/returns/return/


Issue Time Tracking
---

Worklog Id: (was: 28582)
Time Spent: 50m  (was: 40m)

> Change return type for TSHttpTxnIsInternal and TSHttpSsnIsInternal
> --
>
> Key: TS-4731
> URL: https://issues.apache.org/jira/browse/TS-4731
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I'd like to propose that we modify these two APIs from:
> {code}
> tsapi TSReturnCode TSHttpTxnIsInternal(TSHttpTxn txnp);
> tsapi TSReturnCode TSHttpSsnIsInternal(TSHttpSsn snap);
> {code}
> to be
> {code}
> tsapi int TSHttpTxnIsInternal(TSHttpTxn txnp);
> tsapi int TSHttpSsnIsInternal(TSHttpSsn snap);
> {code}
> This is more inline with our current standards of using "int" as a boolean 
> type. This is for example the prototype in TSVConnIsSsl() as well as in e.g. 
> TSHttpTxnDebugSet(TSHttpTxn txnp, int on).
> This is an incompatible change though.



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

[GitHub] trafficserver pull request #1000: TS-4468: http.server_session_sharing.match...

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4468: http.server_session_sharing.match check SNI

Started with patch proposed by Jered Floyd on the bug.  Tested the basic 
case of SNI name match/mismatch and reuse seem to work as expected.

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

$ git pull https://github.com/shinrich/trafficserver ts-4468

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

https://github.com/apache/trafficserver/pull/1000.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1000


commit 262707c9ae1eb929fd1b91821569ff7aa9297f0e
Author: Susan Hinrichs 
Date:   2016-09-09T15:14:18Z

TS-4468: http.server_session_sharing.match check SNI




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4468?focusedWorklogId=28587&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28587
 ]

ASF GitHub Bot logged work on TS-4468:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:19
Start Date: 09/Sep/16 15:19
Worklog Time Spent: 10m 
  Work Description: GitHub user shinrich opened a pull request:

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

TS-4468: http.server_session_sharing.match check SNI

Started with patch proposed by Jered Floyd on the bug.  Tested the basic 
case of SNI name match/mismatch and reuse seem to work as expected.

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

$ git pull https://github.com/shinrich/trafficserver ts-4468

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

https://github.com/apache/trafficserver/pull/1000.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1000


commit 262707c9ae1eb929fd1b91821569ff7aa9297f0e
Author: Susan Hinrichs 
Date:   2016-09-09T15:14:18Z

TS-4468: http.server_session_sharing.match check SNI




Issue Time Tracking
---

Worklog Id: (was: 28587)
Time Spent: 10m
Remaining Estimate: 0h

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[jira] [Work logged] (TS-4503) MachineFatal should shutdown without cleanup

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4503?focusedWorklogId=28585&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28585
 ]

ASF GitHub Bot logged work on TS-4503:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:16
Start Date: 09/Sep/16 15:16
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/991#discussion_r78197657
  
--- Diff: proxy/logging/LogBuffer.h ---
@@ -25,6 +25,7 @@
 #define LOG_BUFFER_H
 
 #include "ts/ink_platform.h"
+#include "ts/Diags.h"
--- End diff --

Is this change necessary?


Issue Time Tracking
---

Worklog Id: (was: 28585)
Time Spent: 2h 20m  (was: 2h 10m)

> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[GitHub] trafficserver pull request #995: TS-4731: Changes return codes for IsInterna...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/995#discussion_r78196913
  
--- Diff: doc/developer-guide/api/functions/TSHttpTxnIsInternal.en.rst ---
@@ -41,8 +41,8 @@ was originated within Traffic Server.
 Return Values
 =
 
-Both these APIs returns a :type:`TSReturnCode`, indicating whether the
-object was internal (:data:`TS_SUCCESS`) or not (:data:`TS_ERROR`).
+Both these APIs returns a :type:`int`, indicating whether the
--- End diff --

s/returns/return/


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #991: TS-4503: Remove the class ErrorClass and all its c...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/991
  
This looks good, I have 1 small comment.

@persiaAziz can you update the commit message to have a shorter summary and 
a better description of this change, see the commit message 
[guidelines](https://cwiki.apache.org/confluence/display/TS/CommitPolicies). 
Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #986: TS-4825: Add the TSVConnInternalSet() API.

[jpeach]

Github user jpeach closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #986: TS-4825: Add the TSVConnInternalSet() API.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/986
  
Abandoning this PR in light of the dev@ list discussion (see references on 
[TS-4825](https://issues.apache.org/jira/browse/TS-4825)).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4825) Mark a transaction as not internal

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4825?focusedWorklogId=28589&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28589
 ]

ASF GitHub Bot logged work on TS-4825:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:24
Start Date: 09/Sep/16 15:24
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/986
  
Abandoning this PR in light of the dev@ list discussion (see references on 
[TS-4825](https://issues.apache.org/jira/browse/TS-4825)).


Issue Time Tracking
---

Worklog Id: (was: 28589)
Time Spent: 1h  (was: 50m)

> Mark a transaction as not internal
> --
>
> Key: TS-4825
> URL: https://issues.apache.org/jira/browse/TS-4825
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If you have a protocol plugin that generates HTTP requests, you typically 
> want those to be treated as external client requests not as internal 
> requests. We should have an API to mark these as non-internal.



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

[jira] [Work logged] (TS-4825) Mark a transaction as not internal

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4825?focusedWorklogId=28588&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28588
 ]

ASF GitHub Bot logged work on TS-4825:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:24
Start Date: 09/Sep/16 15:24
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 28588)
Time Spent: 1h  (was: 50m)

> Mark a transaction as not internal
> --
>
> Key: TS-4825
> URL: https://issues.apache.org/jira/browse/TS-4825
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If you have a protocol plugin that generates HTTP requests, you typically 
> want those to be treated as external client requests not as internal 
> requests. We should have an API to mark these as non-internal.



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

[GitHub] trafficserver issue #999: TS-4759: Fix stream states management

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/999
  
The changes look reasonable to me.  Separate tracking sending EOS and 
receiving EOS seems like a good idea


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4759) Intermittent HTTP/2 failure with h2spec (6.4.)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4759?focusedWorklogId=28591&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28591
 ]

ASF GitHub Bot logged work on TS-4759:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:26
Start Date: 09/Sep/16 15:26
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/999
  
The changes look reasonable to me.  Separate tracking sending EOS and 
receiving EOS seems like a good idea


Issue Time Tracking
---

Worklog Id: (was: 28591)
Time Spent: 40m  (was: 0.5h)

> Intermittent HTTP/2 failure with h2spec (6.4.)
> --
>
> Key: TS-4759
> URL: https://issues.apache.org/jira/browse/TS-4759
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {noformat}
>   6.4. RST_STREAM
> × Sends a RST_STREAM frame with a length other than 4 octets
>   - The endpoint MUST respond with a connection error of type 
> FRAME_SIZE_ERROR.
> Expected: GOAWAY frame (ErrorCode: FRAME_SIZE_ERROR)
>   Connection close
>   Actual: DATA frame (Length: 0, Flags: 1)
> {noformat}
> ( h2spec v1.4.2 )



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

[GitHub] trafficserver issue #971: TS-1882: Check for unrecognized configuration valu...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-1882) ATS doesn't warn about unknown config items

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1882?focusedWorklogId=28592&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28592
 ]

ASF GitHub Bot logged work on TS-1882:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:28
Start Date: 09/Sep/16 15:28
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28592)
Time Spent: 3h 10m  (was: 3h)

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3216?focusedWorklogId=28595&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28595
 ]

ASF GitHub Bot logged work on TS-3216:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:31
Start Date: 09/Sep/16 15:31
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/990
  
I like the change to store the pointer to hpkp in the netvc rather than 
pointer to the certificate context.  Looks good to me.


Issue Time Tracking
---

Worklog Id: (was: 28595)
Time Spent: 1h  (was: 50m)

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[GitHub] trafficserver issue #990: TS-3216: Add HPKP Support

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/990
  
I like the change to store the pointer to hpkp in the netvc rather than 
pointer to the certificate context.  Looks good to me.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #977: TS-4657: SNI hook sends hook ID for events

[shinrich]

Github user shinrich closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4657) SNI hook sends hook ID for events

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4657?focusedWorklogId=28596&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28596
 ]

ASF GitHub Bot logged work on TS-4657:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:31
Start Date: 09/Sep/16 15:31
Worklog Time Spent: 10m 
  Work Description: Github user shinrich closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 28596)
Time Spent: 1.5h  (was: 1h 20m)

> SNI hook sends hook ID for events
> -
>
> Key: TS-4657
> URL: https://issues.apache.org/jira/browse/TS-4657
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> If you use the {{TS_SSL_SNI_HOOK}} hook, it will send {{TS_SSL_SNI_HOOK}} 
> values as the event. {{TS_SSL_SNI_HOOK}} is not a valid {{TSEvent}} value.
> It is also weird that {{TS_SSL_SNI_HOOK}} and {{TS_SSL_CERT_HOOK}} have the 
> same value. One of these ought to be redundant.



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

Build failed in Jenkins: in_tree-master #2207

[jenkins]

See 

Changes:

[shinrich] TS-4657: SNI hook sends hook ID for events

--
Started by remote host 2001:4800:7821:102:be76:4eff:fe05:ad8b
Building on master in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > http://192.168.3.1/mirror/trafficserver.git # timeout=10
Cleaning workspace
 > /usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > /usr/bin/git reset --hard # timeout=10
 > /usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from http://192.168.3.1/mirror/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > http://192.168.3.1/mirror/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 81fabee47143c4a51a44aaa27fcc4a5e21fa104e 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 81fabee47143c4a51a44aaa27fcc4a5e21fa104e
 > /usr/bin/git rev-list d362a73d3ff25ca4ce553e8436b32a6ab76b10fc # timeout=10
FATAL: Unable to produce a script file
java.io.IOException: Failed to create a temp file on 

at hudson.FilePath.createTextTempFile(FilePath.java:1410)
at 
hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:142)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:80)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:64)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.Build$BuildExecution.build(Build.java:205)
at hudson.model.Build$BuildExecution.doRun(Build.java:162)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: java.io.IOException: Failed to create a temporary directory in /tmp
at hudson.FilePath$17.invoke(FilePath.java:1396)
at hudson.FilePath$17.invoke(FilePath.java:1384)
at hudson.FilePath.act(FilePath.java:1018)
at hudson.FilePath.act(FilePath.java:996)
at hudson.FilePath.createTextTempFile(FilePath.java:1384)
... 12 more
Caused by: java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2024)
at hudson.FilePath$17.invoke(FilePath.java:1394)
... 16 more
Build step 'Execute shell' marked build as failure

[GitHub] trafficserver pull request #990: TS-3216: Add HPKP Support

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/990#discussion_r78200394
  
--- Diff: iocore/net/SSLCertLookup.cc ---
@@ -167,6 +167,10 @@ SSLCertContext::release()
 keyblock = NULL;
   }
 
+  if (hpkp) {
+ats_free(hpkp);
--- End diff --

You don't need the NULL check before ats_free.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: out_of_tree-master #1980

[jenkins]

See 

Changes:

[shinrich] TS-4657: SNI hook sends hook ID for events

--
Started by remote host 2001:4800:7821:102:be76:4eff:fe05:ad8b
Building on master in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > http://192.168.3.1/mirror/trafficserver.git # timeout=10
Cleaning workspace
 > /usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > /usr/bin/git reset --hard # timeout=10
 > /usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from http://192.168.3.1/mirror/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > http://192.168.3.1/mirror/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 81fabee47143c4a51a44aaa27fcc4a5e21fa104e 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 81fabee47143c4a51a44aaa27fcc4a5e21fa104e
 > /usr/bin/git rev-list d362a73d3ff25ca4ce553e8436b32a6ab76b10fc # timeout=10
FATAL: Unable to produce a script file
java.io.IOException: Failed to create a temp file on 

at hudson.FilePath.createTextTempFile(FilePath.java:1410)
at 
hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:142)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:80)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:64)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.Build$BuildExecution.build(Build.java:205)
at hudson.model.Build$BuildExecution.doRun(Build.java:162)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: java.io.IOException: Failed to create a temporary directory in /tmp
at hudson.FilePath$17.invoke(FilePath.java:1396)
at hudson.FilePath$17.invoke(FilePath.java:1384)
at hudson.FilePath.act(FilePath.java:1018)
at hudson.FilePath.act(FilePath.java:996)
at hudson.FilePath.createTextTempFile(FilePath.java:1384)
... 12 more
Caused by: java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2024)
at hudson.FilePath$17.invoke(FilePath.java:1394)
... 16 more
Build step 'Execute shell' marked build as failure

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3216?focusedWorklogId=28597&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28597
 ]

ASF GitHub Bot logged work on TS-3216:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:32
Start Date: 09/Sep/16 15:32
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/990#discussion_r78200394
  
--- Diff: iocore/net/SSLCertLookup.cc ---
@@ -167,6 +167,10 @@ SSLCertContext::release()
 keyblock = NULL;
   }
 
+  if (hpkp) {
+ats_free(hpkp);
--- End diff --

You don't need the NULL check before ats_free.


Issue Time Tracking
---

Worklog Id: (was: 28597)
Time Spent: 1h 10m  (was: 1h)

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[GitHub] trafficserver issue #1000: TS-4468: http.server_session_sharing.match check ...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4468?focusedWorklogId=28598&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28598
 ]

ASF GitHub Bot logged work on TS-4468:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:34
Start Date: 09/Sep/16 15:34
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28598)
Time Spent: 0.5h  (was: 20m)

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[GitHub] trafficserver pull request #942: TS 4263: Global key block configurable via ...

[shinrich]

Github user shinrich closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #990: TS-3216: Add HPKP Support

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/990#discussion_r78201056
  
--- Diff: proxy/hdrs/HdrToken.cc ---
@@ -70,7 +70,8 @@ static const char *_hdrtoken_strs[] = {
   "Newsgroups",   // NNTP
   "Organization", // NNTP
   "Path", // NNTP
-  "Pragma", "Proxy-Authenticate", "Proxy-Authorization", 
"Proxy-Connection", "Public", "Range",
+  "Pragma", "Proxy-Authenticate", "Proxy-Authorization", 
"Proxy-Connection", "Public-Key-Pins-Report-Only", "Public-Key-Pins",
+  "Public", "Range",
--- End diff --

Can you please use clang no-format so that this array is consistently 
formatted with on entry per line?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3216?focusedWorklogId=28599&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28599
 ]

ASF GitHub Bot logged work on TS-3216:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:36
Start Date: 09/Sep/16 15:36
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/990#discussion_r78201056
  
--- Diff: proxy/hdrs/HdrToken.cc ---
@@ -70,7 +70,8 @@ static const char *_hdrtoken_strs[] = {
   "Newsgroups",   // NNTP
   "Organization", // NNTP
   "Path", // NNTP
-  "Pragma", "Proxy-Authenticate", "Proxy-Authorization", 
"Proxy-Connection", "Public", "Range",
+  "Pragma", "Proxy-Authenticate", "Proxy-Authorization", 
"Proxy-Connection", "Public-Key-Pins-Report-Only", "Public-Key-Pins",
+  "Public", "Range",
--- End diff --

Can you please use clang no-format so that this array is consistently 
formatted with on entry per line?


Issue Time Tracking
---

Worklog Id: (was: 28599)
Time Spent: 1h 20m  (was: 1h 10m)

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

Build failed in Jenkins: docs-master #141

[jenkins]

See 

Changes:

[persia] TS-4263: Global key block configurable via Records.config

[Masakazu Kitajo] TS-2237: Add unit tests for escapify_url and pure_escapify_url

[shinrich] TS-4657: SNI hook sends hook ID for events

[Bryan Call] TS-4837: Add -Wextra to the build

--
Started by remote host 2001:4800:7821:102:be76:4eff:fe05:ad8b
Building on master in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > http://192.168.3.1/mirror/trafficserver.git # timeout=10
Fetching upstream changes from http://192.168.3.1/mirror/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > http://192.168.3.1/mirror/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 7d00d7a4f2ee4a1d7b1c5fb2073c39b572ea8171 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 7d00d7a4f2ee4a1d7b1c5fb2073c39b572ea8171
 > /usr/bin/git rev-list 941584c6ddde149ba967403fae4a1a6b35f165c3 # timeout=10
FATAL: Unable to produce a script file
java.io.IOException: Failed to create a temp file on 

at hudson.FilePath.createTextTempFile(FilePath.java:1410)
at 
hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:142)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:80)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:64)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.Build$BuildExecution.build(Build.java:205)
at hudson.model.Build$BuildExecution.doRun(Build.java:162)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: java.io.IOException: Failed to create a temporary directory in /tmp
at hudson.FilePath$17.invoke(FilePath.java:1396)
at hudson.FilePath$17.invoke(FilePath.java:1384)
at hudson.FilePath.act(FilePath.java:1018)
at hudson.FilePath.act(FilePath.java:996)
at hudson.FilePath.createTextTempFile(FilePath.java:1384)
... 12 more
Caused by: java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2024)
at hudson.FilePath$17.invoke(FilePath.java:1394)
... 16 more
Build step 'Execute shell' marked build as failure

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28600&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28600
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:37
Start Date: 09/Sep/16 15:37
Worklog Time Spent: 10m 
  Work Description: Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/980
  
Jpeach

I tested your branch 
https://github.com/jpeach/trafficserver/commit/b7ddaae3444e5cf1316b551b4dbde018e1ff29a9

It did work for me on rhel6.



Issue Time Tracking
---

Worklog Id: (was: 28600)
Time Spent: 2h 10m  (was: 2h)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[GitHub] trafficserver issue #980: TS-4152: Build failure when curses is not availabl...

[dragon512]

Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/980
  
Jpeach

I tested your branch 
https://github.com/jpeach/trafficserver/commit/b7ddaae3444e5cf1316b551b4dbde018e1ff29a9

It did work for me on rhel6.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1000: TS-4468: http.server_session_sharing.match check ...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4468?focusedWorklogId=28594&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28594
 ]

ASF GitHub Bot logged work on TS-4468:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:31
Start Date: 09/Sep/16 15:31
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28594)
Time Spent: 20m  (was: 10m)

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[GitHub] trafficserver pull request #990: TS-3216: Add HPKP Support

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/990#discussion_r78202428
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -1866,10 +1934,17 @@ ssl_store_ssl_context(const SSLConfigParams 
*params, SSLCertLookup *lookup, cons
 keyblock = ssl_context_enable_tickets(ctx, NULL);
   }
 
+  // Generate HPKP header if hpkp is enabled.
+  if (sslMultCertSettings.hpkp_enabled >= 0 ? 
sslMultCertSettings.hpkp_enabled : params->hpkp_enabled) {
--- End diff --

So it is not possible to enable HPKP globally then disable it on specific 
certificates? I think the expected behavior is for the certificate settings to 
always have precedence (if they are specified).  See 
[TS-2773](https://issues.apache.org/jira/browse/TS-2773) for 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3216?focusedWorklogId=28602&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28602
 ]

ASF GitHub Bot logged work on TS-3216:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:44
Start Date: 09/Sep/16 15:44
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/990#discussion_r78202428
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -1866,10 +1934,17 @@ ssl_store_ssl_context(const SSLConfigParams 
*params, SSLCertLookup *lookup, cons
 keyblock = ssl_context_enable_tickets(ctx, NULL);
   }
 
+  // Generate HPKP header if hpkp is enabled.
+  if (sslMultCertSettings.hpkp_enabled >= 0 ? 
sslMultCertSettings.hpkp_enabled : params->hpkp_enabled) {
--- End diff --

So it is not possible to enable HPKP globally then disable it on specific 
certificates? I think the expected behavior is for the certificate settings to 
always have precedence (if they are specified).  See 
[TS-2773](https://issues.apache.org/jira/browse/TS-2773) for 


Issue Time Tracking
---

Worklog Id: (was: 28602)
Time Spent: 1.5h  (was: 1h 20m)

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[jira] [Resolved] (TS-4657) SNI hook sends hook ID for events

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4657.

Resolution: Fixed

> SNI hook sends hook ID for events
> -
>
> Key: TS-4657
> URL: https://issues.apache.org/jira/browse/TS-4657
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> If you use the {{TS_SSL_SNI_HOOK}} hook, it will send {{TS_SSL_SNI_HOOK}} 
> values as the event. {{TS_SSL_SNI_HOOK}} is not a valid {{TSEvent}} value.
> It is also weird that {{TS_SSL_SNI_HOOK}} and {{TS_SSL_CERT_HOOK}} have the 
> same value. One of these ought to be redundant.



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

[jira] [Work logged] (TS-1882) ATS doesn't warn about unknown config items

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1882?focusedWorklogId=28601&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28601
 ]

ASF GitHub Bot logged work on TS-1882:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:38
Start Date: 09/Sep/16 15:38
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28601)
Time Spent: 3h 20m  (was: 3h 10m)

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[GitHub] trafficserver issue #971: TS-1882: Check for unrecognized configuration valu...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (TS-3046) Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-3046.

Resolution: Fixed

> Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle 
> SSL connections
> 
>
> Key: TS-3046
> URL: https://issues.apache.org/jira/browse/TS-3046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>Priority: Blocker
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> This bug is a follow up on completely phasing out ET_SSL threads (refer 
> TS-2574 and TS-3045). 



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

[GitHub] trafficserver pull request #990: TS-3216: Add HPKP Support

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/990#discussion_r78203123
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

Who owns the ``hpkp`` pointer at this time?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1001: TS-4152: Update ax_with_curses.m4

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4152: Update ax_with_curses.m4



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

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

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

https://github.com/apache/trafficserver/pull/1001.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1001


commit b7ddaae3444e5cf1316b551b4dbde018e1ff29a9
Author: James Peach 
Date:   2016-09-08T21:24:02Z

TS-4152: Update ax_with_curses.m4




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3216?focusedWorklogId=28603&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28603
 ]

ASF GitHub Bot logged work on TS-3216:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:48
Start Date: 09/Sep/16 15:48
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/990#discussion_r78203123
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

Who owns the ``hpkp`` pointer at this time?


Issue Time Tracking
---

Worklog Id: (was: 28603)
Time Spent: 1h 40m  (was: 1.5h)

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[jira] [Commented] (TS-4453) READ_COMPLETE signal is not being sent for short POST's

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4453:


I haven't seen this lately.  I think I solved a problem like this internally.  
Let me review my various versions for the fix to make sure it was propagated to 
master.

Are folks still seeing this?

> READ_COMPLETE signal is not being sent for short POST's
> ---
>
> Key: TS-4453
> URL: https://issues.apache.org/jira/browse/TS-4453
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> Reported by [~briang].  Since TS-3612 commit, he has noticed that the 
> READ_COMPLETE event is not being delivered to the VIO in the case of short 
> POSTs.



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

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28604&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28604
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:49
Start Date: 09/Sep/16 15:49
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

TS-4152: Update ax_with_curses.m4



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

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

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

https://github.com/apache/trafficserver/pull/1001.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1001


commit b7ddaae3444e5cf1316b551b4dbde018e1ff29a9
Author: James Peach 
Date:   2016-09-08T21:24:02Z

TS-4152: Update ax_with_curses.m4




Issue Time Tracking
---

Worklog Id: (was: 28604)
Time Spent: 2h 20m  (was: 2h 10m)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[GitHub] trafficserver pull request #980: TS-4152: Build failure when curses is not a...

[dragon512]

Github user dragon512 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #980: TS-4152: Build failure when curses is not availabl...

[dragon512]

Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/980
  
closing my pull request as James has a better fix


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28606&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28606
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:50
Start Date: 09/Sep/16 15:50
Worklog Time Spent: 10m 
  Work Description: Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/980
  
closing my pull request as James has a better fix


Issue Time Tracking
---

Worklog Id: (was: 28606)
Time Spent: 2.5h  (was: 2h 20m)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28605&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28605
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:50
Start Date: 09/Sep/16 15:50
Worklog Time Spent: 10m 
  Work Description: Github user dragon512 closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 28605)
Time Spent: 2.5h  (was: 2h 20m)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[jira] [Created] (TS-4839) Create http.server_session_sharing.match = lax_hostname

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-4839:
--

 Summary: Create http.server_session_sharing.match = lax_hostname
 Key: TS-4839
 URL: https://issues.apache.org/jira/browse/TS-4839
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Susan Hinrichs


With TS-4468, we restrict session reuse for both or hostname to match the SNI 
name as well as the hostname for session reuse.  By default this strict 
matching is appropriate.  The origin server may be checking that the SNI name 
matches the HTTP request hostname.

However, for some origins, this check is not performed.  And the strict check 
will reduce session reuse.  For a reverse proxy case, we may want to 
reintroduce the original lax matching for the improved performance.



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

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28607&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28607
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 15:57
Start Date: 09/Sep/16 15:57
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28607)
Time Spent: 2h 40m  (was: 2.5h)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28608&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28608
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 16:02
Start Date: 09/Sep/16 16:02
Worklog Time Spent: 10m 
  Work Description: Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/1001
  
hmm maybe i should reopen the one I did as that seems to work...


Issue Time Tracking
---

Worklog Id: (was: 28608)
Time Spent: 2h 50m  (was: 2h 40m)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[GitHub] trafficserver issue #1001: TS-4152: Update ax_with_curses.m4

[dragon512]

Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/1001
  
hmm maybe i should reopen the one I did as that seems to work...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1001: TS-4152: Update ax_with_curses.m4

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1001: TS-4152: Update ax_with_curses.m4

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28609&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28609
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 16:04
Start Date: 09/Sep/16 16:04
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28609)
Time Spent: 3h  (was: 2h 50m)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[jira] [Resolved] (TS-4453) READ_COMPLETE signal is not being sent for short POST's

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4453.

Resolution: Cannot Reproduce

> READ_COMPLETE signal is not being sent for short POST's
> ---
>
> Key: TS-4453
> URL: https://issues.apache.org/jira/browse/TS-4453
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> Reported by [~briang].  Since TS-3612 commit, he has noticed that the 
> READ_COMPLETE event is not being delivered to the VIO in the case of short 
> POSTs.



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

[jira] [Commented] (TS-4453) READ_COMPLETE signal is not being sent for short POST's

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4453:


I re-examined my internal change logs and tried to reproduce the short post 
problem on an install of the current master using HTTP2 and HTTP/1.1.  I was 
unable to reproduce the problem.  In both cases according to the logs the short 
post body was processed as a PRECOMPLETE, which means the post body was read in 
with the request header.  

I'm guessing that the fix got pulled in with TS-4507.  I am going to close the 
issue for now.  We can reopen it if people are still seeing this in the wild.

> READ_COMPLETE signal is not being sent for short POST's
> ---
>
> Key: TS-4453
> URL: https://issues.apache.org/jira/browse/TS-4453
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> Reported by [~briang].  Since TS-3612 commit, he has noticed that the 
> READ_COMPLETE event is not being delivered to the VIO in the case of short 
> POSTs.



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

[GitHub] trafficserver issue #1001: TS-4152: Update ax_with_curses.m4

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28614&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28614
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 16:25
Start Date: 09/Sep/16 16:25
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28614)
Time Spent: 3h 10m  (was: 3h)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[GitHub] trafficserver issue #1001: TS-4152: Update ax_with_curses.m4

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4152) Build failure when curses is not available

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4152?focusedWorklogId=28615&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28615
 ]

ASF GitHub Bot logged work on TS-4152:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 16:29
Start Date: 09/Sep/16 16:29
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 28615)
Time Spent: 3h 20m  (was: 3h 10m)

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[GitHub] trafficserver issue #997: TS-4835: Stale while revalidate should only ignore...

[PSUdaemon]

Github user PSUdaemon commented on the issue:

https://github.com/apache/trafficserver/pull/997
  
👍 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[PSUdaemon]

Github user PSUdaemon commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/834#discussion_r78213185
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -64,23 +67,127 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
   const char *tmp = NULL;
   int len;
   URL *url = hrdata->hdr->url_get();
+  char buffer[1024];
+  int slen = 0;
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "ParentConsistentHash::%s() 
hrdata->cache_info_parent_selection_url = 0x%lx", __func__,
+(unsigned long int)hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ParentConsistentHash::%s() ps_url = 0x%lx", 
__func__, (unsigned long int)ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref(&len);
+  if (tmp && len > 0) {
+// Print the over-ride URL
+if (is_debug_tag_set("parent_select")) {
+  slen = (len > 1023) ? 1023 : len;
--- End diff --

There is a MIN macro you can use for this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4707?focusedWorklogId=28620&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28620
 ]

ASF GitHub Bot logged work on TS-4707:
--

Author: ASF GitHub Bot
Created on: 09/Sep/16 16:57
Start Date: 09/Sep/16 16:57
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/834#discussion_r78213185
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -64,23 +67,127 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
   const char *tmp = NULL;
   int len;
   URL *url = hrdata->hdr->url_get();
+  char buffer[1024];
+  int slen = 0;
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "ParentConsistentHash::%s() 
hrdata->cache_info_parent_selection_url = 0x%lx", __func__,
+(unsigned long int)hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ParentConsistentHash::%s() ps_url = 0x%lx", 
__func__, (unsigned long int)ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref(&len);
+  if (tmp && len > 0) {
+// Print the over-ride URL
+if (is_debug_tag_set("parent_select")) {
+  slen = (len > 1023) ? 1023 : len;
--- End diff --

There is a MIN macro you can use for this.


Issue Time Tracking
---

Worklog Id: (was: 28620)
Time Spent: 4h 40m  (was: 4.5h)

> Parent Consistent Hash Selection - add fname and maxdirs options.
> -
>
> Key: TS-4707
> URL: https://issues.apache.org/jira/browse/TS-4707
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Peter Chou
>Assignee: Peter Chou
> Fix For: 7.0.0
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> This enhancement adds two options, "fname" and "maxdirs", which can be used 
> to exclude the file-name and some of the directories in the path. The 
> remaining portions of the path are then used as part of the hash computation 
> for selecting among multiple parent caches.
> For our usage, it was desirable from an operational perspective to direct all 
> components of particular sub-tree to a single parent cache (to simplify 
> trouble-shooting, pre-loading, etc.). This can be achieved by excluding the 
> query-string, file-name, and right-most portions of the path from the hash 
> computation.



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[PSUdaemon]

Github user PSUdaemon commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/834#discussion_r78213701
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -64,23 +67,127 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
   const char *tmp = NULL;
   int len;
   URL *url = hrdata->hdr->url_get();
+  char buffer[1024];
+  int slen = 0;
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "ParentConsistentHash::%s() 
hrdata->cache_info_parent_selection_url = 0x%lx", __func__,
+(unsigned long int)hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ParentConsistentHash::%s() ps_url = 0x%lx", 
__func__, (unsigned long int)ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref(&len);
+  if (tmp && len > 0) {
+// Print the over-ride URL
+if (is_debug_tag_set("parent_select")) {
+  slen = (len > 1023) ? 1023 : len;
+  strncpy(buffer, tmp, slen);
+  buffer[slen] = 0;
+  Debug("parent_select", "ParentConsistentHash::%s() Using 
Over-Ride String='%s'.", __func__, buffer);
+}
+h->update(tmp, len);
+goto done;
--- End diff --

I know this is a pattern used throughout the code base, but I see you added 
this one new (in addition to the new label below). I think we should try to 
avoid this if at all possible.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---