[jira] [Created] (TS-4711) Remove proxy.config.log.custom_logs_enabled

[James Peach (JIRA)]

James Peach created TS-4711:
---

 Summary: Remove proxy.config.log.custom_logs_enabled
 Key: TS-4711
 URL: https://issues.apache.org/jira/browse/TS-4711
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: James Peach


Is there a use case for running without custom logs. Does it even work? Let's 
agree to remove the ability to disable custom logging.



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

[jira] [Work logged] (TS-4709) separate LogFilter parser

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/835
  
 


Issue Time Tracking
---

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

> separate LogFilter parser
> -
>
> Key: TS-4709
> URL: https://issues.apache.org/jira/browse/TS-4709
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Separate the LogFilter parser from the XML configuration parser so that it 
> can be tested and reused by the Lua configuration.



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

[GitHub] trafficserver issue #835: TS-4709: Separate LogFilter expression parsing.

[maskit]

Github user maskit commented on the issue:

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


---
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-4710) Make `proxy.config.srv_enabled` transaction overrideable

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Make `proxy.config.srv_enabled` transaction overrideable
> 
>
> Key: TS-4710
> URL: https://issues.apache.org/jira/browse/TS-4710
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #836: TS-4710 make srv_enabled transaction overrideable

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/836
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/395/ 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-4710) Make `proxy.config.srv_enabled` transaction overrideable

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Make `proxy.config.srv_enabled` transaction overrideable
> 
>
> Key: TS-4710
> URL: https://issues.apache.org/jira/browse/TS-4710
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




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

[jira] [Work logged] (TS-4710) Make `proxy.config.srv_enabled` transaction overrideable

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Make `proxy.config.srv_enabled` transaction overrideable
> 
>
> Key: TS-4710
> URL: https://issues.apache.org/jira/browse/TS-4710
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #836: TS-4710 make srv_enabled transaction overrideable

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/836
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/394/ 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] [Commented] (TS-4710) Make `proxy.config.srv_enabled` transaction overrideable

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-4710:


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

> Make `proxy.config.srv_enabled` transaction overrideable
> 
>
> Key: TS-4710
> URL: https://issues.apache.org/jira/browse/TS-4710
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[jira] [Work logged] (TS-4710) Make `proxy.config.srv_enabled` transaction overrideable

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Aug/16 01:47
Start Date: 02/Aug/16 01:47
Worklog Time Spent: 10m 
  Work Description: GitHub user jacksontj opened a pull request:

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

TS-4710



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

$ git pull https://github.com/jacksontj/trafficserver TS-4710

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

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


commit c295fdcc375b778af4a000b20e7cbef10d5e627a
Author: Thomas Jackson 
Date:   2016-08-02T01:44:54Z

TS-4710 document srv_enabled as overrideable

commit 36999f9073e01499c520181d0efe9ea7ccca289d
Author: Thomas Jackson 
Date:   2016-08-02T01:45:17Z

TS-4710 make `proxy.config.srv_enabled` transaction overrideable




Issue Time Tracking
---

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

> Make `proxy.config.srv_enabled` transaction overrideable
> 
>
> Key: TS-4710
> URL: https://issues.apache.org/jira/browse/TS-4710
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver pull request #836: TS-4710

[jacksontj]

GitHub user jacksontj opened a pull request:

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

TS-4710



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

$ git pull https://github.com/jacksontj/trafficserver TS-4710

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

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


commit c295fdcc375b778af4a000b20e7cbef10d5e627a
Author: Thomas Jackson 
Date:   2016-08-02T01:44:54Z

TS-4710 document srv_enabled as overrideable

commit 36999f9073e01499c520181d0efe9ea7ccca289d
Author: Thomas Jackson 
Date:   2016-08-02T01:45:17Z

TS-4710 make `proxy.config.srv_enabled` transaction overrideable




---
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-4710) Make `proxy.config.srv_enabled` transaction overrideable

[James Peach (JIRA)]

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

James Peach commented on TS-4710:
-

[~jacksontj] What semantics are you looking for here?

> Make `proxy.config.srv_enabled` transaction overrideable
> 
>
> Key: TS-4710
> URL: https://issues.apache.org/jira/browse/TS-4710
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>




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

[jira] [Assigned] (TS-4710) Make `proxy.config.srv_enabled` transaction overrideable

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4710:
--

Assignee: Thomas Jackson

> Make `proxy.config.srv_enabled` transaction overrideable
> 
>
> Key: TS-4710
> URL: https://issues.apache.org/jira/browse/TS-4710
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>




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

[jira] [Created] (TS-4710) Make `proxy.config.srv_enabled` transaction overrideable

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4710:
--

 Summary: Make `proxy.config.srv_enabled` transaction overrideable
 Key: TS-4710
 URL: https://issues.apache.org/jira/browse/TS-4710
 Project: Traffic Server
  Issue Type: Improvement
  Components: HostDB
Reporter: Thomas Jackson






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

[GitHub] trafficserver issue #835: TS-4709: Separate LogFilter expression parsing.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/835
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/393/ 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-4709) separate LogFilter parser

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> separate LogFilter parser
> -
>
> Key: TS-4709
> URL: https://issues.apache.org/jira/browse/TS-4709
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Separate the LogFilter parser from the XML configuration parser so that it 
> can be tested and reused by the Lua configuration.



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

[jira] [Work logged] (TS-4709) separate LogFilter parser

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> separate LogFilter parser
> -
>
> Key: TS-4709
> URL: https://issues.apache.org/jira/browse/TS-4709
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Separate the LogFilter parser from the XML configuration parser so that it 
> can be tested and reused by the Lua configuration.



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

[GitHub] trafficserver issue #835: TS-4709: Separate LogFilter expression parsing.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/835
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/496/ 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-4709) separate LogFilter parser

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Aug/16 00:27
Start Date: 02/Aug/16 00:27
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

TS-4709: Separate LogFilter expression parsing.

Separate LogFilter expression parsing from the configuration file
parser so that it can be tested and reused in other contexts.

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

$ git pull https://github.com/jpeach/trafficserver fix/TS-4709

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

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


commit a086c060ffee0f6a4f8386a7ee0aad50378d81b8
Author: James Peach 
Date:   2016-08-02T00:22:31Z

TS-4709: Separate LogFilter expression parsing.

Separate LogFilter expression parsing from the configuration file
parser so that it can be tested and reused in other contexts.




Issue Time Tracking
---

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

> separate LogFilter parser
> -
>
> Key: TS-4709
> URL: https://issues.apache.org/jira/browse/TS-4709
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Separate the LogFilter parser from the XML configuration parser so that it 
> can be tested and reused by the Lua configuration.



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

[GitHub] trafficserver pull request #835: TS-4709: Separate LogFilter expression pars...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4709: Separate LogFilter expression parsing.

Separate LogFilter expression parsing from the configuration file
parser so that it can be tested and reused in other contexts.

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

$ git pull https://github.com/jpeach/trafficserver fix/TS-4709

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

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


commit a086c060ffee0f6a4f8386a7ee0aad50378d81b8
Author: James Peach 
Date:   2016-08-02T00:22:31Z

TS-4709: Separate LogFilter expression parsing.

Separate LogFilter expression parsing from the configuration file
parser so that it can be tested and reused in other contexts.




---
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] [Assigned] (TS-4709) separate LogFilter parser

[James Peach (JIRA)]

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

James Peach reassigned TS-4709:
---

Assignee: James Peach

> separate LogFilter parser
> -
>
> Key: TS-4709
> URL: https://issues.apache.org/jira/browse/TS-4709
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>
> Separate the LogFilter parser from the XML configuration parser so that it 
> can be tested and reused by the Lua configuration.



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

[jira] [Created] (TS-4709) separate LogFilter parser

[James Peach (JIRA)]

James Peach created TS-4709:
---

 Summary: separate LogFilter parser
 Key: TS-4709
 URL: https://issues.apache.org/jira/browse/TS-4709
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: James Peach


Separate the LogFilter parser from the XML configuration parser so that it can 
be tested and reused by the Lua configuration.



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

[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=26134=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26134
 ]

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 22:49
Start Date: 01/Aug/16 22:49
Worklog Time Spent: 10m 
  Work Description: GitHub user pbchou opened a pull request:

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

TS-4707 : Parent Consistent Hash Selection - add fname and maxdirs

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.

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

$ git pull https://github.com/pbchou/trafficserver TS-4707

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

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


commit 09ff7e0466b5cebfb50901f8d29cc1b40b7c182c
Author: Peter Chou 
Date:   2016-08-01T22:34:59Z

TS-4707 : Parent Consistent Hash Selection - add fname and maxdirs options.
  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.




Issue Time Tracking
---

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

> 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
>  Time Spent: 10m
>  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 ...

[pbchou]

GitHub user pbchou opened a pull request:

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

TS-4707 : Parent Consistent Hash Selection - add fname and maxdirs

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.

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

$ git pull https://github.com/pbchou/trafficserver TS-4707

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

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


commit 09ff7e0466b5cebfb50901f8d29cc1b40b7c182c
Author: Peter Chou 
Date:   2016-08-01T22:34:59Z

TS-4707 : Parent Consistent Hash Selection - add fname and maxdirs options.
  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.




---
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-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 22:43
Start Date: 01/Aug/16 22:43
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/823
  
You don't need to hold a mutex to free anything. In all of these cases, the 
callee is supposed to consume both parameters. For consistency, we should not 
sometime consume only some of the parameters.


Issue Time Tracking
---

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

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



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

[GitHub] trafficserver issue #823: TS-4697: free MIOBuffer if fails on ipallow check.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/823
  
You don't need to hold a mutex to free anything. In all of these cases, the 
callee is supposed to consume both parameters. For consistency, we should not 
sometime consume only some of the parameters.


---
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] [Created] (TS-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[Peter Chou (JIRA)]

Peter Chou created TS-4707:
--

 Summary: 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


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)

[jira] [Work logged] (TS-4703) Adds an API call to retrieve transaction protocol

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 21:12
Start Date: 01/Aug/16 21:12
Worklog Time Spent: 10m 
  Work Description: Github user petarpenkov commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/829#discussion_r73053878
  
--- Diff: 
doc/developer-guide/api/functions/TSHttpTxnClientProtocolGet.en.rst ---
@@ -0,0 +1,34 @@
+.. Licensed to the Apache Software Foundation (ASF) under one or more
+   contributor license agreements.  See the NOTICE file distributed
+   with this work for additional information regarding copyright
+   ownership.  The ASF licenses this file to you under the Apache
+   License, Version 2.0 (the "License"); you may not use this file
+   except in compliance with the License.  You may obtain a copy of
+   the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied.  See the License for the specific language governing
+   permissions and limitations under the License.
+
+.. include:: ../../../common.defs
+
+.. default-domain:: c
+
+TSHttpTxnClientProtocolGet
+*
+
+Gets the protocol string (http, http/2) of a specified transaction. 
+
+Synopsis
+
+
+`#include `
+
+.. function:: const char * TSHttpTxnClientProtocolGet(TSHttpTxn txnp)
+
+Description
+===
--- End diff --

I am not sure if I am the right person to mess with docs because I am 
relatively new to the ATS practices. However I feel like TSHttpTxn* functions 
can be mashed together, same with TSHttpSsn*, same with TSMimeHdr*, TSHttpHdr* 
and so on. I am basing this off the history of my needs and my intuition that a 
user of the interface would want to see in one place ALL they can do with a 
Transaction, Session, etc... This will reduce the number of files in this 
folder significantly.


Issue Time Tracking
---

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

> Adds an API call to retrieve transaction protocol
> -
>
> Key: TS-4703
> URL: https://issues.apache.org/jira/browse/TS-4703
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Petar Penkov
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> It would be useful if there was a way to retrieve the underlying protocol for 
> a given transaction through the tsapi at the very least for plugin logging 
> purposes. This can be achieved with a very simple method since this 
> information is already available internally. 



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

[GitHub] trafficserver pull request #829: TS-4703: Adds an API call to retrieve trans...

[petarpenkov]

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

https://github.com/apache/trafficserver/pull/829#discussion_r73053878
  
--- Diff: 
doc/developer-guide/api/functions/TSHttpTxnClientProtocolGet.en.rst ---
@@ -0,0 +1,34 @@
+.. Licensed to the Apache Software Foundation (ASF) under one or more
+   contributor license agreements.  See the NOTICE file distributed
+   with this work for additional information regarding copyright
+   ownership.  The ASF licenses this file to you under the Apache
+   License, Version 2.0 (the "License"); you may not use this file
+   except in compliance with the License.  You may obtain a copy of
+   the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied.  See the License for the specific language governing
+   permissions and limitations under the License.
+
+.. include:: ../../../common.defs
+
+.. default-domain:: c
+
+TSHttpTxnClientProtocolGet
+*
+
+Gets the protocol string (http, http/2) of a specified transaction. 
+
+Synopsis
+
+
+`#include `
+
+.. function:: const char * TSHttpTxnClientProtocolGet(TSHttpTxn txnp)
+
+Description
+===
--- End diff --

I am not sure if I am the right person to mess with docs because I am 
relatively new to the ATS practices. However I feel like TSHttpTxn* functions 
can be mashed together, same with TSHttpSsn*, same with TSMimeHdr*, TSHttpHdr* 
and so on. I am basing this off the history of my needs and my intuition that a 
user of the interface would want to see in one place ALL they can do with a 
Transaction, Session, etc... This will reduce the number of files in this 
folder significantly.


---
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-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 21:04
Start Date: 01/Aug/16 21:04
Worklog Time Spent: 10m 
  Work Description: Github user ushachar commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
Yep. Getting back to this asap


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #712: TS-4523

[ushachar]

Github user ushachar commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
Yep. Getting back to this asap


---
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-4475) Crash in Log-Collation client after using inactivity-cop.

[Peter Chou (JIRA)]

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

Peter Chou commented on TS-4475:


Apologies, I had forgotten that we had modified the original solution to just 
ignore the time-out event and return EVENT_CONT instead. This seems to work for 
us (it generates a time-out debug message every 5 minutes if you just leave it 
idle), and it seemed to be a less drastic approach than killing the connection 
on time-out. So based on the previous comment from Oknet, we should go back to 
the original approach of killing the connection (treating it as an error 
instead of ignoring). Should I just piggy-back the VC_EVENT_INACTIVITY_TIMEOUT 
with the actions for VC_EVENT_EOS and VC_EVENT_ERROR (these two are already 
combined) in the switch() statement? It seems there is some code for handling 
these two events in addition to just calling client_fail(). Perhaps the 
time-out should execute these actions also?

> Crash in Log-Collation client after using inactivity-cop.
> -
>
> Key: TS-4475
> URL: https://issues.apache.org/jira/browse/TS-4475
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 6.1.1
>Reporter: Peter Chou
> Fix For: sometime
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Background: We recently tried making use of inactivity-cop by setting it to 
> 300s instead of the default one-day setting. This was to address an issue 
> where, under heavy load, ATS would become un-responsive to client requests, 
> and the condition would persist after traffic was stopped with the active 
> queue saying 0 connections but 'netstat -na' showing a bunch of established 
> connections (up to the throttle limit approximately).
> Inactivity cop seemed to help ATS handle this situation, but we have since 
> experienced a couple of core dumps over the last four day period. It seems 
> occasionally the Log Collation Client State Machine will have event value 105 
> or VC_EVENT_INACTIVITY_TIMEOUT, but when it reaches read_signal_and_update() 
> it tries to call the continuation handler which down the line does not know 
> about this event thus causing core dump !"unexpcted state" [sic].
> Here is the back-trace --
> (gdb) bt
> #0  0x2b67cd5405f7 in raise () from /lib64/libc.so.6
> #1  0x2b67cd541e28 in abort () from /lib64/libc.so.6
> #2  0x2b67cb032921 in ink_die_die_die () at ink_error.cc:43
> #3  0x2b67cb0329da in ink_fatal_va (fmt=0x2b67cb0442dc "%s:%d: failed 
> assert `%s`", ap=0x7ffc690e7ba8) at ink_error.cc:65
> #4  0x2b67cb032a79 in ink_fatal (message_format=0x2b67cb0442dc "%s:%d: 
> failed assert `%s`") at ink_error.cc:73
> #5  0x2b67cb0305a6 in _ink_assert (expression=0x7fb422 "!\"unexpcted 
> state\"", file=0x7fb35b "LogCollationClientSM.cc",
> line=445) at ink_assert.cc:37
> #6  0x0069c86b in LogCollationClientSM::client_idle 
> (this=0x2b681400bb00, event=105) at LogCollationClientSM.cc:445
> #7  0x0069b427 in LogCollationClientSM::client_handler 
> (this=0x2b681400bb00, event=105, data=0x2b680c017020)
> at LogCollationClientSM.cc:119
> #8  0x00502cc6 in Continuation::handleEvent (this=0x2b681400bb00, 
> event=105, data=0x2b680c017020)
> at ../iocore/eventsystem/I_Continuation.h:153
> #9  0x00783d40 in read_signal_and_update (event=105, 
> vc=0x2b680c016f00) at UnixNetVConnection.cc:150
> #10 0x00787a22 in UnixNetVConnection::mainEvent (this=0x2b680c016f00, 
> event=1, e=0x127ad60) at UnixNetVConnection.cc:1188
> #11 0x00502cc6 in Continuation::handleEvent (this=0x2b680c016f00, 
> event=1, data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x0077d943 in InactivityCop::check_inactivity (this=0x1209a00, 
> event=2, e=0x127ad60) at UnixNet.cc:102
> #13 0x00502cc6 in Continuation::handleEvent (this=0x1209a00, event=2, 
> data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #14 0x007a5df6 in EThread::process_event (this=0x2b67cf7bb010, 
> e=0x127ad60, calling_code=2) at UnixEThread.cc:128
> #15 0x007a61f5 in EThread::execute (this=0x2b67cf7bb010) at 
> UnixEThread.cc:207
> #16 0x00534430 in main (argv=0x7ffc690e82e8) at Main.cc:1918
> I believe it takes a wrong turn here --
> #9  0x00783d40 in read_signal_and_update (event=105, 
> vc=0x2b680c016f00) at UnixNetVConnection.cc:150
> 150 vc->read.vio._cont->handleEvent(event, >read.vio);
> (gdb) list
> 145 static inline int
> 146 read_signal_and_update(int event, UnixNetVConnection *vc)
> 147 {
> 148   vc->recursion++;
> 149   if (vc->read.vio._cont) {
> 150 vc->read.vio._cont->handleEvent(event, >read.vio);
> 151   } else {
> 152 

[jira] [Commented] (TS-4475) Crash in Log-Collation client after using inactivity-cop.

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-4475:
--

Acroding the source file: /proxy/logging/LogCollationClientSM.cc, the 
LogCollationClientSM::client_idle() handle LOG_COLL_CLIENT_IDLE state.
The netvc managed by LogCollationClientSM is a persistent connection, the 
client_idle() handle EOS for do_io_read and ERROR for do_io_write. Thus, there 
is no timeout event only idle state, the InactivityCop should not check timeout 
for the netvc managed by LogCollationClientSM.

Consider the LogCollationHostSM::read_hdr() would receive TIMEOUT Event from 
InactivityCop too, but it is call host_handler() with LOG_COLL_EVENT_ERROR 
event and no assert.
The host_handler() only log the error event and call host_done() to close the 
netvc.
Thus no crash report from LogCollationHostSM.

A possible solution:
Step 1. handle Timeout event at LogCollationClientSM::client_idle() and some 
others, and call client_fail() to close the timeouted netvc.
Step 2. Set a standalone inactivity timeout value for logcollation's netvc to 
keep the connection in a idle state.

The PR831 is not call client_fail() to close the timeouted netvc. 
[~pbchou] , can you replace "return EVENT_CONT" with "return 
client_fail(LOG_COLL_EVENT_SWITCH, NULL);" for VC_EVENT_INACTIVITY_TIMEOUT.

> Crash in Log-Collation client after using inactivity-cop.
> -
>
> Key: TS-4475
> URL: https://issues.apache.org/jira/browse/TS-4475
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 6.1.1
>Reporter: Peter Chou
> Fix For: sometime
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Background: We recently tried making use of inactivity-cop by setting it to 
> 300s instead of the default one-day setting. This was to address an issue 
> where, under heavy load, ATS would become un-responsive to client requests, 
> and the condition would persist after traffic was stopped with the active 
> queue saying 0 connections but 'netstat -na' showing a bunch of established 
> connections (up to the throttle limit approximately).
> Inactivity cop seemed to help ATS handle this situation, but we have since 
> experienced a couple of core dumps over the last four day period. It seems 
> occasionally the Log Collation Client State Machine will have event value 105 
> or VC_EVENT_INACTIVITY_TIMEOUT, but when it reaches read_signal_and_update() 
> it tries to call the continuation handler which down the line does not know 
> about this event thus causing core dump !"unexpcted state" [sic].
> Here is the back-trace --
> (gdb) bt
> #0  0x2b67cd5405f7 in raise () from /lib64/libc.so.6
> #1  0x2b67cd541e28 in abort () from /lib64/libc.so.6
> #2  0x2b67cb032921 in ink_die_die_die () at ink_error.cc:43
> #3  0x2b67cb0329da in ink_fatal_va (fmt=0x2b67cb0442dc "%s:%d: failed 
> assert `%s`", ap=0x7ffc690e7ba8) at ink_error.cc:65
> #4  0x2b67cb032a79 in ink_fatal (message_format=0x2b67cb0442dc "%s:%d: 
> failed assert `%s`") at ink_error.cc:73
> #5  0x2b67cb0305a6 in _ink_assert (expression=0x7fb422 "!\"unexpcted 
> state\"", file=0x7fb35b "LogCollationClientSM.cc",
> line=445) at ink_assert.cc:37
> #6  0x0069c86b in LogCollationClientSM::client_idle 
> (this=0x2b681400bb00, event=105) at LogCollationClientSM.cc:445
> #7  0x0069b427 in LogCollationClientSM::client_handler 
> (this=0x2b681400bb00, event=105, data=0x2b680c017020)
> at LogCollationClientSM.cc:119
> #8  0x00502cc6 in Continuation::handleEvent (this=0x2b681400bb00, 
> event=105, data=0x2b680c017020)
> at ../iocore/eventsystem/I_Continuation.h:153
> #9  0x00783d40 in read_signal_and_update (event=105, 
> vc=0x2b680c016f00) at UnixNetVConnection.cc:150
> #10 0x00787a22 in UnixNetVConnection::mainEvent (this=0x2b680c016f00, 
> event=1, e=0x127ad60) at UnixNetVConnection.cc:1188
> #11 0x00502cc6 in Continuation::handleEvent (this=0x2b680c016f00, 
> event=1, data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x0077d943 in InactivityCop::check_inactivity (this=0x1209a00, 
> event=2, e=0x127ad60) at UnixNet.cc:102
> #13 0x00502cc6 in Continuation::handleEvent (this=0x1209a00, event=2, 
> data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #14 0x007a5df6 in EThread::process_event (this=0x2b67cf7bb010, 
> e=0x127ad60, calling_code=2) at UnixEThread.cc:128
> #15 0x007a61f5 in EThread::execute (this=0x2b67cf7bb010) at 
> UnixEThread.cc:207
> #16 0x00534430 in main (argv=0x7ffc690e82e8) at Main.cc:1918
> I believe it takes a wrong turn here --
> #9  0x00783d40 in read_signal_and_update (event=105, 
> vc=0x2b680c016f00) 

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

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 12:14
Start Date: 01/Aug/16 12:14
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/830
  
Yes, we don't have to follow it, but we should follow it as much as 
possible. Because it could be happen that images are sent before CSS/JS, if we 
don't follow it.

How about use SETTINGS_MAX_CONCURRENT_STREAMS  as the max depth? It looks 
appropriate and we don't need new configures.

I'm seeing that with latest Chrome ( 51.0.2704.106 ). Chrome had that bug 
in Feb and reverted the changes. IIUC, the bug is about the order of streams 
not depth of streams. Now (maybe from Jun), it looks like they fixed the order 
and rolled it out.


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #830: TS-4554: Set max depth of Http2DependencyTree

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/830
  
Yes, we don't have to follow it, but we should follow it as much as 
possible. Because it could be happen that images are sent before CSS/JS, if we 
don't follow it.

How about use SETTINGS_MAX_CONCURRENT_STREAMS  as the max depth? It looks 
appropriate and we don't need new configures.

I'm seeing that with latest Chrome ( 51.0.2704.106 ). Chrome had that bug 
in Feb and reverted the changes. IIUC, the bug is about the order of streams 
not depth of streams. Now (maybe from Jun), it looks like they fixed the order 
and rolled it out.


---
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-4554) ASAN crash (stack overflow) with H2 priorities

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 11:44
Start Date: 01/Aug/16 11:44
Worklog Time Spent: 10m 
  Work Description: Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/830
  
My point is that we don't have to follow the crazy dependency request.

> Set max depth of Http2DependencyTree When the depth over the maximum, new 
node will be a children of root node.

This means nothing bad happens if we got a 1024 depth tree request, right?


By the way, isn't it just a bug on version 51? Does it happen on the latest 
version?
https://bugs.chromium.org/p/chromium/issues/detail?id=590225




Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #830: TS-4554: Set max depth of Http2DependencyTree

[maskit]

Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/830
  
My point is that we don't have to follow the crazy dependency request.

> Set max depth of Http2DependencyTree When the depth over the maximum, new 
node will be a children of root node.

This means nothing bad happens if we got a 1024 depth tree request, right?


By the way, isn't it just a bug on version 51? Does it happen on the latest 
version?
https://bugs.chromium.org/p/chromium/issues/detail?id=590225




---
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 #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/392/ 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 #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 *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/495/ 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=26122=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26122
 ]

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 26122)
Time Spent: 2.5h  (was: 2h 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: 2.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)

[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=26121=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26121
 ]

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 11:08
Start Date: 01/Aug/16 11:08
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/494/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26121)
Time Spent: 2h 20m  (was: 2h 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: 2h 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)

[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=26120=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26120
 ]

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

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

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



Issue Time Tracking
---

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

> 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: 2h 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

[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/494/ 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 #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 *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/391/ 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-4554) ASAN crash (stack overflow) with H2 priorities

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 10:57
Start Date: 01/Aug/16 10:57
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/830
  
Chrome 51:) The tree of it has all streams in only one branch (all headers 
frame has exclusive flag). So the depth is equal to steams.

For FireFox, 8 - 16 is big enough.


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #830: TS-4554: Set max depth of Http2DependencyTree

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/830
  
Chrome 51:) The tree of it has all streams in only one branch (all headers 
frame has exclusive flag). So the depth is equal to steams.

For FireFox, 8 - 16 is big enough.


---
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-4554) ASAN crash (stack overflow) with H2 priorities

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/830
  
I don't think 256 is reasonable value. Who need such a crazy dependency 
tree? The default can be smaller value until it works. I guess 8-16 are big 
enough in practice.


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #823: TS-4697: free MIOBuffer if fails on ipallow check.

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/823
  
@jpeach SessionAccept is a interface to create ClientSession. Its mutex is 
NULL, it is not safe to release any resource. The caller to SessionAccept is 
Trampline that mutex is copy from NetVC, it is safe to handle resource release. 
This is why I'm free MIOBuffer in Trampline.


---
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-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 10:00
Start Date: 01/Aug/16 10:00
Worklog Time Spent: 10m 
  Work Description: Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/823
  
@jpeach SessionAccept is a interface to create ClientSession. Its mutex is 
NULL, it is not safe to release any resource. The caller to SessionAccept is 
Trampline that mutex is copy from NetVC, it is safe to handle resource release. 
This is why I'm free MIOBuffer in Trampline.


Issue Time Tracking
---

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

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/830
  
1) 256 seems crazy deep, is that a reasonable default?

SETTINGS_MAX_CONCURRENT_STREAMS is 100 at least. And "idle" streams (that 
are not counted for concurrent streams) can be node of tree.
Those can be said for odd-numbered streams which is used by client and 
even-numbered streams which is used by server. So I chose 256. 
If we ignore server-push cases, it could be 128.
 
2) Do we want to make this configurable instead of static? Are there use 
cases where someone want more (or less) ?

Hmm, if someone wants to increase SETTINGS_MAX_CONCURRENT_STREAMS, it looks 
like this should be increased too. But this is a limit of recursion, so I don't 
think this should be configurable for now.


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #830: TS-4554: Set max depth of Http2DependencyTree

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/830
  
1) 256 seems crazy deep, is that a reasonable default?

SETTINGS_MAX_CONCURRENT_STREAMS is 100 at least. And "idle" streams (that 
are not counted for concurrent streams) can be node of tree.
Those can be said for odd-numbered streams which is used by client and 
even-numbered streams which is used by server. So I chose 256. 
If we ignore server-push cases, it could be 128.
 
2) Do we want to make this configurable instead of static? Are there use 
cases where someone want more (or less) ?

Hmm, if someone wants to increase SETTINGS_MAX_CONCURRENT_STREAMS, it looks 
like this should be increased too. But this is a limit of recursion, so I don't 
think this should be configurable for 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=26115=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26115
 ]

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 08:28
Start Date: 01/Aug/16 08:28
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/390/ for details.
 



Issue Time Tracking
---

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

> 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: 2h
>  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/390/ 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=26114=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26114
 ]

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

Author: ASF GitHub Bot
Created on: 01/Aug/16 08:23
Start Date: 01/Aug/16 08:23
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/493/ for details.
 



Issue Time Tracking
---

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

> 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: 1h 50m
>  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
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/493/ 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.
---