[jira] [Work logged] (TS-4713) Remove obsolete TSFetchClientProtoStackSet/Get

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/838
  
+1



Issue Time Tracking
---

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

> Remove obsolete TSFetchClientProtoStackSet/Get
> --
>
> Key: TS-4713
> URL: https://issues.apache.org/jira/browse/TS-4713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #838: TS-4713: Remove obsolete TSFetchClientProtoStackSe...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/838
  
+1



---
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-4713) Remove obsolete TSFetchClientProtoStackSet/Get

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove obsolete TSFetchClientProtoStackSet/Get
> --
>
> Key: TS-4713
> URL: https://issues.apache.org/jira/browse/TS-4713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #838: TS-4713: Remove obsolete TSFetchClientProtoStackSe...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/838
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/399/ 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-4713) Remove obsolete TSFetchClientProtoStackSet/Get

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove obsolete TSFetchClientProtoStackSet/Get
> --
>
> Key: TS-4713
> URL: https://issues.apache.org/jira/browse/TS-4713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #838: TS-4713: Remove obsolete TSFetchClientProtoStackSe...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/838
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/502/ 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] [Updated] (TS-4713) Remove obsolete TSFetchClientProtoStackSet/Get

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4713:

Fix Version/s: 7.0.0

> Remove obsolete TSFetchClientProtoStackSet/Get
> --
>
> Key: TS-4713
> URL: https://issues.apache.org/jira/browse/TS-4713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[jira] [Work logged] (TS-4713) Remove obsolete TSFetchClientProtoStackSet/Get

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4713: Remove obsolete TSFetchClientProtoStackSet/Get



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

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

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

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


commit 87b898c146ad4b4408030390e7b82fcaee423792
Author: Masaori Koshiba 
Date:   2016-08-03T02:26:31Z

TS-4713: Remove obsolete TSFetchClientProtoStackSet/Get




Issue Time Tracking
---

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

> Remove obsolete TSFetchClientProtoStackSet/Get
> --
>
> Key: TS-4713
> URL: https://issues.apache.org/jira/browse/TS-4713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[jira] [Assigned] (TS-4713) Remove obsolete TSFetchClientProtoStackSet/Get

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba reassigned TS-4713:
---

Assignee: Masaori Koshiba

> Remove obsolete TSFetchClientProtoStackSet/Get
> --
>
> Key: TS-4713
> URL: https://issues.apache.org/jira/browse/TS-4713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>




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

[GitHub] trafficserver pull request #838: TS-4713: Remove obsolete TSFetchClientProto...

[masaori335]

GitHub user masaori335 opened a pull request:

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

TS-4713: Remove obsolete TSFetchClientProtoStackSet/Get



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

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

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

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


commit 87b898c146ad4b4408030390e7b82fcaee423792
Author: Masaori Koshiba 
Date:   2016-08-03T02:26:31Z

TS-4713: Remove obsolete TSFetchClientProtoStackSet/Get




---
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-4713) Remove obsolete TSFetchClientProtoStackSet/Get

[Masaori Koshiba (JIRA)]

Masaori Koshiba created TS-4713:
---

 Summary: Remove obsolete TSFetchClientProtoStackSet/Get
 Key: TS-4713
 URL: https://issues.apache.org/jira/browse/TS-4713
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: Masaori Koshiba






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

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

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
Looks good. Please squash commits.


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

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

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

https://github.com/apache/trafficserver/pull/833
  
Looks good. Please squash commits.


Issue Time Tracking
---

Worklog Id: (was: 26173)
Time Spent: 3h 20m  (was: 3h 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: 3h 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-4553) Add Brotli compression support

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/776
  
@zwoop Hi, I am working in the streaming encode. Can you share the 
brotli.cc that @bgaff sent to you with me?


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #776: TS-4553: Brotli plugin

[caricaturecm]

Github user caricaturecm commented on the issue:

https://github.com/apache/trafficserver/pull/776
  
@zwoop Hi, I am working in the streaming encode. Can you share the 
brotli.cc that @bgaff sent to you with me?


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

[jira] [Work logged] (TS-4706) SSL hostname verification failed due to truncated SNI name

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 03/Aug/16 00:21
Start Date: 03/Aug/16 00:21
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {code}



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

[GitHub] trafficserver pull request #837: TS-4706 Truncated SNI name during escalatio...

[zwoop]

Github user zwoop closed the pull request at:

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


---
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-4706) SSL hostname verification failed due to truncated SNI name

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {code}



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

[GitHub] trafficserver issue #837: TS-4706 Truncated SNI name during escalation

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/837
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/398/ 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] [Updated] (TS-4706) SSL hostname verification failed due to truncated SNI name

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4706:
--
Backport to Version: 6.2.1

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {code}



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

[GitHub] trafficserver issue #837: TS-4706 Truncated SNI name during escalation

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/837
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/501/ 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-4706) SSL hostname verification failed due to truncated SNI name

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {code}



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

[jira] [Work logged] (TS-4706) SSL hostname verification failed due to truncated SNI name

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/837
  
@zwoop thanks for reviewing! 

As far as can tell the escalate plugin was implemented later then the 
HttpHdr caching and the caching implementation does not support its use-case 
well. The reason we started noticing the truncated/garbage name problems is 
that SSL handshake changed (got stricter) 

This fix is meant to solve the immediate problem of having 
`t_state.hdr_info.server_request` cache not being invalidated after the 
escalate plugin called `TSHttpTxnRedirectUrlSet()` to retry the request to a 
secondary origin after the primary origin failed.

This code change would invalidate (only invalidate) client request and 
server request `HttpHdr` at the same time only during 
`HttpSM::redirect_request()`, the caching state of the 2 objects would not 
necessarily be kept (or assumed to be) in sync (client request and server 
request HttpHdr were not meant to be invariant).

Filed Jira: [TS-4712](https://issues.apache.org/jira/browse/TS-4712) to 
look into the `HttpHdr` caching use-cases and verify the HttpHdr caching 
functionality.


Issue Time Tracking
---

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

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {code}



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

[GitHub] trafficserver issue #837: TS-4706 Truncated SNI name during escalation

[gtenev]

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/837
  
@zwoop thanks for reviewing! 

As far as can tell the escalate plugin was implemented later then the 
HttpHdr caching and the caching implementation does not support its use-case 
well. The reason we started noticing the truncated/garbage name problems is 
that SSL handshake changed (got stricter) 

This fix is meant to solve the immediate problem of having 
`t_state.hdr_info.server_request` cache not being invalidated after the 
escalate plugin called `TSHttpTxnRedirectUrlSet()` to retry the request to a 
secondary origin after the primary origin failed.

This code change would invalidate (only invalidate) client request and 
server request `HttpHdr` at the same time only during 
`HttpSM::redirect_request()`, the caching state of the 2 objects would not 
necessarily be kept (or assumed to be) in sync (client request and server 
request HttpHdr were not meant to be invariant).

Filed Jira: [TS-4712](https://issues.apache.org/jira/browse/TS-4712) to 
look into the `HttpHdr` caching use-cases and verify the HttpHdr caching 
functionality.


---
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-4712) Verify HttpHdr caching functionality

[Gancho Tenev (JIRA)]

Gancho Tenev created TS-4712:


 Summary: Verify HttpHdr caching functionality
 Key: TS-4712
 URL: https://issues.apache.org/jira/browse/TS-4712
 Project: Traffic Server
  Issue Type: Task
  Components: Cleanup, Core
Reporter: Gancho Tenev


After finding an use-case that was not supported well by the HttpHdr caching 
functionality ([TS-4706|https://issues.apache.org/jira/browse/TS-4706]) it may 
make sense to look into its use-cases and verify its functionality.



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

[jira] [Work logged] (TS-4706) SSL hostname verification failed due to truncated SNI name

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {code}



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

[GitHub] trafficserver issue #837: TS-4706 Truncated SNI name during escalation

[zwoop]

Github user zwoop commented on the issue:

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


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

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

Author: ASF GitHub Bot
Created on: 02/Aug/16 23:43
Start Date: 02/Aug/16 23:43
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

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

> 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
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  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] [Resolved] (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 resolved TS-4709.
-
   Resolution: Fixed
Fix Version/s: 7.0.0

> 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
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  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 closed the pull request at:

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-4703) Adds an API call to retrieve transaction protocol

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/829
  
@amc we should have this discussion on ``@dev``. My main objection to this 
API is that is makes promises it doesn't (maybe can't) keep. It just tells you 
whether this is HTTP/1 or HTTP/2. That's fine, and an API that does that it 
also fine, but that should look different to this.


Issue Time Tracking
---

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

> 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: 2h 20m
>  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 issue #829: TS-4703: Adds an API call to retrieve transaction ...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/829
  
@amc we should have this discussion on ``@dev``. My main objection to this 
API is that is makes promises it doesn't (maybe can't) keep. It just tells you 
whether this is HTTP/1 or HTTP/2. That's fine, and an API that does that it 
also fine, but that should look different to this.


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

[jira] [Work logged] (TS-4706) SSL hostname verification failed due to truncated SNI name

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/837
  
I'm generally ok with this for the immediate fixage. My only concern here 
is that there's now an invariant (it seems) between the client and server 
HttpHdr, where the caches should be invalidated together for both. That sort of 
feels like it then could be lifted up in the stack a bit maybe, or at least 
assertion that the invariant is never broken again.

Alternatively, if there's improvements that can be done here (later) such 
that the invalidation can be disjoint again, safely, for better performance 
etc., that'd be cool too. Maybe file a separate lira for this cleanup for later?


Issue Time Tracking
---

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

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {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=26159=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26159
 ]

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

Author: ASF GitHub Bot
Created on: 02/Aug/16 19:58
Start Date: 02/Aug/16 19:58
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/397/ for details.
 



Issue Time Tracking
---

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

> 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: 3h 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)

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

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

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

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



Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #834: TS-4707 : Parent Consistent Hash Selection - add f...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/396/ 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 *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/397/ 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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> 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: 0.5h
>  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 issue #834: TS-4707 : Parent Consistent Hash Selection - add f...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/499/ 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=26156=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26156
 ]

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

Author: ASF GitHub Bot
Created on: 02/Aug/16 19:54
Start Date: 02/Aug/16 19:54
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/500/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26156)
Time Spent: 3h  (was: 2h 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: 3h
>  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/500/ 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=26155=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26155
 ]

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

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

https://github.com/apache/trafficserver/pull/833
  
Trying another build, for some reason builds are not stable now [approve 
ci].


Issue Time Tracking
---

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

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
Trying another build, for some reason builds are not stable now [approve 
ci].


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834
  
@jrushford  Please review. [approve ci]


Issue Time Tracking
---

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

> 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: 20m
>  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)

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/835
  
Seems clean, ship it.


Issue Time Tracking
---

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

> 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: 50m
>  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 #834: TS-4707 : Parent Consistent Hash Selection - add f...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@jrushford  Please review. [approve ci]


---
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 #836: TS-4710 make srv_enabled transaction overrideable

[zwoop]

Github user zwoop commented on the issue:

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


REGRESSION TEST SDK_API_OVERRIDABLE_CONFIGS started
FATAL: InkAPI.cc:8354: failed assertion 
`sdk_sanity_check_null_ptr((void *)name) == TS_SUCCESS`



---
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 #837: TS-4706 Truncated SNI name during escalation

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/837
  
:+1:


---
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-4706) SSL hostname verification failed due to truncated SNI name

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4706 Truncated SNI name during escalation

A fix for a problem with SSL hostname verification failing due to truncated 
SNI name.

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

$ git pull https://github.com/gtenev/trafficserver TS-4706

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

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


commit 4d02d0e877e24b1dc94948c236462417bdd9bbf0
Author: Gancho Tenev 
Date:   2016-07-29T23:39:44Z

TS-4706 Truncated SNI name during escalation

SSL hostname verification failing due to truncated SNI name.




Issue Time Tracking
---

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

> SSL hostname verification failed due to truncated SNI name
> --
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation 
> plugin is used to redirect a failed request (404) from a primary origin 
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG:  (ssl) using SNI 
> name ‘secondary.c'’ for client handshake
> DEBUG:  (ssl.error) 
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG:  (ssl) using SNI 
> name 'secondary.c’’ for client handshake
> DEBUG:  (ssl) Hostname verification 
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to 
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so 
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no 
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for 
> client handshake'
> DEBUG:  (ssl) using SNI 
> name 'primary.com' for client handshake
> DEBUG:  (ssl) using SNI 
> name 'secondary.com' for client handshake
> {code}



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

[GitHub] trafficserver pull request #837: TS-4706 Truncated SNI name during escalatio...

[gtenev]

GitHub user gtenev opened a pull request:

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

TS-4706 Truncated SNI name during escalation

A fix for a problem with SSL hostname verification failing due to truncated 
SNI name.

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

$ git pull https://github.com/gtenev/trafficserver TS-4706

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

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


commit 4d02d0e877e24b1dc94948c236462417bdd9bbf0
Author: Gancho Tenev 
Date:   2016-07-29T23:39:44Z

TS-4706 Truncated SNI name during escalation

SSL hostname verification failing due to truncated SNI name.




---
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] [Updated] (TS-4541) SEGV in send_a_data_frame with HTTP/2 (possibly ASAN mutex)

[Leif Hedstrom (JIRA)]

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

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

> SEGV in send_a_data_frame with HTTP/2 (possibly ASAN  mutex)
> 
>
> Key: TS-4541
> URL: https://issues.apache.org/jira/browse/TS-4541
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Priority: Critical
>  Labels: A
> Fix For: 7.0.0
>
>
> {code}
> ==26628==ERROR: AddressSanitizer: SEGV on unknown address 0x0038 (pc 
> 0x009ad1b9 sp 0x2b7e55d79740 bp 0x2b7e55d7d8f0 T15)
> #0 0x9ad1b8 in Mutex_lock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 0x9ad1b8 in MutexLock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 0x9ad1b8 in Http2ConnectionState::send_a_data_frame(Http2Stream*, 
> unsigned long&) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1040
> #3 0x9af71d in 
> Http2ConnectionState::send_data_frames_depends_on_priority() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x9b1ff9 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0xe9f5e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xe9f5e3 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0xea18c9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b7e4d575aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #10 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Updated] (TS-4541) SEGV in send_a_data_frame with HTTP/2 (possibly ASAN mutex)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4541:
--
Priority: Critical  (was: Major)

> SEGV in send_a_data_frame with HTTP/2 (possibly ASAN  mutex)
> 
>
> Key: TS-4541
> URL: https://issues.apache.org/jira/browse/TS-4541
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Priority: Critical
>  Labels: A
> Fix For: 7.0.0
>
>
> {code}
> ==26628==ERROR: AddressSanitizer: SEGV on unknown address 0x0038 (pc 
> 0x009ad1b9 sp 0x2b7e55d79740 bp 0x2b7e55d7d8f0 T15)
> #0 0x9ad1b8 in Mutex_lock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 0x9ad1b8 in MutexLock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 0x9ad1b8 in Http2ConnectionState::send_a_data_frame(Http2Stream*, 
> unsigned long&) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1040
> #3 0x9af71d in 
> Http2ConnectionState::send_data_frames_depends_on_priority() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x9b1ff9 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0xe9f5e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xe9f5e3 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0xea18c9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b7e4d575aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #10 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Updated] (TS-4541) SEGV in send_a_data_frame with HTTP/2 (possibly ASAN mutex)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4541:
--
Summary: SEGV in send_a_data_frame with HTTP/2 (possibly ASAN  mutex)  
(was: ASAN error with HTTP/2 mutex)

> SEGV in send_a_data_frame with HTTP/2 (possibly ASAN  mutex)
> 
>
> Key: TS-4541
> URL: https://issues.apache.org/jira/browse/TS-4541
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==26628==ERROR: AddressSanitizer: SEGV on unknown address 0x0038 (pc 
> 0x009ad1b9 sp 0x2b7e55d79740 bp 0x2b7e55d7d8f0 T15)
> #0 0x9ad1b8 in Mutex_lock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 0x9ad1b8 in MutexLock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 0x9ad1b8 in Http2ConnectionState::send_a_data_frame(Http2Stream*, 
> unsigned long&) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1040
> #3 0x9af71d in 
> Http2ConnectionState::send_data_frames_depends_on_priority() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x9b1ff9 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0xe9f5e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xe9f5e3 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0xea18c9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b7e4d575aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #10 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Commented] (TS-4541) ASAN error with HTTP/2 mutex

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4541:
---

So, I'm fairly certain we've seen this SEGV without ASAN. I.e. it's not an ASAN 
issue as much as a segv. My crash is:

{code}
#0  Http2ConnectionState::send_a_data_frame (this=this@entry=0x238, 
stream=stream@entry=0x2ae93158a9c0,
payload_length=@0x2aaab4a10988: 0) at Http2ConnectionState.cc:1029
#1  0x2acf7f27 in Http2ConnectionState::send_data_frames (this=0x238, 
stream=0x2ae93158a9c0)
at Http2ConnectionState.cc:1104
#2  0x2acfe855 in Http2Stream::send_response_body (this=) at Http2Stream.cc:543
#3  0x2acf31b2 in Http2ConnectionState::restart_streams 
(this=0x2ab743345618) at Http2ConnectionState.cc:914
#4  rcv_window_update_frame (cstate=..., frame=...) at 
Http2ConnectionState.cc:627
#5  0x2acf88d8 in Http2ConnectionState::main_event_handler 
(this=0x2ab743345618, event=,
edata=) at Http2ConnectionState.cc:823
#6  0x2acee373 in Continuation::handleEvent (data=0x2aaab4a10ab0, 
event=2253, this=0x2ab743345618)
at ../../iocore/eventsystem/I_Continuation.h:153
#7  send_connection_event (cont=cont@entry=0x2ab743345618, 
event=event@entry=2253, edata=edata@entry=0x2aaab4a10ab0)
at Http2ClientSession.cc:58
#8  0x2acee612 in Http2ClientSession::state_complete_frame_read 
(this=0x2ab7433453e0, event=,
edata=0x2aaaed8f69d8) at Http2ClientSession.cc:426
#9  0x2acefb32 in Continuation::handleEvent (data=0x2aaaed8f69d8, 
event=100, this=0x2ab7433453e0)
at ../../iocore/eventsystem/I_Continuation.h:153
#10 Http2ClientSession::state_start_frame_read (this=0x2ab7433453e0, 
event=, edata=0x2aaaed8f69d8)
at Http2ClientSession.cc:399
#11 0x2ae66beb in Continuation::handleEvent (data=0x2aaaed8f69d8, 
event=100, this=)
at ../../iocore/eventsystem/I_Continuation.h:153
#12 read_signal_and_update (vc=0x2aaaed8f68c0, vc@entry=0x1, 
event=event@entry=100) at UnixNetVConnection.cc:153
#13 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aaaed8f68c0, 
event=event@entry=100) at UnixNetVConnection.cc:1036
#14 0x2ae464b3 in SSLNetVConnection::net_read_io (this=0x2aaaed8f68c0, 
nh=0x2aaab350acc0, lthread=0x2aaab3507000)
at SSLNetVConnection.cc:595
#15 0x2ae5434c in NetHandler::mainNetEvent (this=0x2aaab350acc0, 
event=, e=)
at UnixNet.cc:513
#16 0x2ae8c0a6 in Continuation::handleEvent (data=0x2aaab0bf9d40, 
event=5, this=) at I_Continuation.h:153
#17 EThread::process_event (calling_code=5, e=0x2aaab0bf9d40, 
this=0x2aaab3507000) at UnixEThread.cc:148
#18 EThread::execute (this=0x2aaab3507000) at UnixEThread.cc:275
#19 0x2ae8aea6 in spawn_thread_internal (a=0x2aaab0b25d90) at 
Thread.cc:86
#20 0x2d6b9aa1 in start_thread (arg=0x2aaab4a11700) at 
pthread_create.c:301
#21 0x2e8c293d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
{code}

This is without ASAN enabled.

> ASAN error with HTTP/2 mutex
> 
>
> Key: TS-4541
> URL: https://issues.apache.org/jira/browse/TS-4541
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==26628==ERROR: AddressSanitizer: SEGV on unknown address 0x0038 (pc 
> 0x009ad1b9 sp 0x2b7e55d79740 bp 0x2b7e55d7d8f0 T15)
> #0 0x9ad1b8 in Mutex_lock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 0x9ad1b8 in MutexLock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 0x9ad1b8 in Http2ConnectionState::send_a_data_frame(Http2Stream*, 
> unsigned long&) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1040
> #3 0x9af71d in 
> Http2ConnectionState::send_data_frames_depends_on_priority() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x9b1ff9 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0xe9f5e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xe9f5e3 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0xea18c9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b7e4d575aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #10 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Work logged] (TS-4270) stats_over_http: make it a remap plugin

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/732
  
Sorry, I dropped the ball here. I'm currently really busy and I don't know 
when I'll have time to pick this up again. I'm going to close it to avoid 
having something open forever.


Issue Time Tracking
---

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

> stats_over_http: make it a remap plugin
> ---
>
> Key: TS-4270
> URL: https://issues.apache.org/jira/browse/TS-4270
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This would avoid the overhead of checking the request URI path on every 
> request, to see if the request should be intercepted. We could user a pattern 
> similar to the generator.so plugin, which allows it to be both a remap and 
> global plugin, and using TSHttpTxnServerIntercept for the remap case.



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

[GitHub] trafficserver issue #732: [TS-4270] Make stats_over_http a remap plugin.

[calavera]

Github user calavera commented on the issue:

https://github.com/apache/trafficserver/pull/732
  
Sorry, I dropped the ball here. I'm currently really busy and I don't know 
when I'll have time to pick this up again. I'm going to close it to avoid 
having something open forever.


---
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-4270) stats_over_http: make it a remap plugin

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Aug/16 17:21
Start Date: 02/Aug/16 17:21
Worklog Time Spent: 10m 
  Work Description: Github user calavera closed the pull request at:

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


Issue Time Tracking
---

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

> stats_over_http: make it a remap plugin
> ---
>
> Key: TS-4270
> URL: https://issues.apache.org/jira/browse/TS-4270
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This would avoid the overhead of checking the request URI path on every 
> request, to see if the request should be intercepted. We could user a pattern 
> similar to the generator.so plugin, which allows it to be both a remap and 
> global plugin, and using TSHttpTxnServerIntercept for the remap case.



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

[GitHub] trafficserver pull request #732: [TS-4270] Make stats_over_http a remap plug...

[calavera]

Github user calavera closed the pull request at:

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


---
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-4703) Adds an API call to retrieve transaction protocol

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/829
  
I updated the PR with TSHttpSsnClientProtocolGet(TSHttpSsn ssnp). @zwoop , 
for refactoring documentation I could open another JIRA issue and take care of 
it if it should be done.


Issue Time Tracking
---

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

> 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: 2h 10m
>  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 issue #829: TS-4703: Adds an API call to retrieve transaction ...

[petarpenkov]

Github user petarpenkov commented on the issue:

https://github.com/apache/trafficserver/pull/829
  
I updated the PR with TSHttpSsnClientProtocolGet(TSHttpSsn ssnp). @zwoop , 
for refactoring documentation I could open another JIRA issue and take care of 
it if it should be done.


---
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-4703) Adds an API call to retrieve transaction protocol

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/829
  
I have to disagree with James. Once upon a time, this worked (if any one 
remember the "proto stack" thing). It was an explicit goal of the TS-3612 work 
to get this capability back. It is useful in a number of situations to be able 
to know what protocol the user agent is using to talk to ATS. I know I took no 
small amount of heat when I broke this originally.


Issue Time Tracking
---

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

> 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: 2h
>  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 issue #829: TS-4703: Adds an API call to retrieve transaction ...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/829
  
I have to disagree with James. Once upon a time, this worked (if any one 
remember the "proto stack" thing). It was an explicit goal of the TS-3612 work 
to get this capability back. It is useful in a number of situations to be able 
to know what protocol the user agent is using to talk to ATS. I know I took no 
small amount of heat when I broke this originally.


---
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 #787: TS-4507: Fix SSN and TXN hook ordering.

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/787
  
I've reviewed the changes and I don't think they can really be split up. 
Part of the reason is similar changes in both the HTTP/1 and HTTP/2 classes, 
which makes the change appear bigger than it is. I'm +1 on committing this, 
especially since we've been successfully testing them in production inside 
Yahoo!.


---
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-4507) It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/787
  
I've reviewed the changes and I don't think they can really be split up. 
Part of the reason is similar changes in both the HTTP/1 and HTTP/2 classes, 
which makes the change appear bigger than it is. I'm +1 on committing this, 
especially since we've been successfully testing them in production inside 
Yahoo!.


Issue Time Tracking
---

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

> It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook
> --
>
> Key: TS-4507
> URL: https://issues.apache.org/jira/browse/TS-4507
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> One of our plugins will occasionally crash.  It appears there is still a path 
> for HTTP2 that has the SSN_CLOSE hook close before the TXN_CLOSE hook.
> Working through solutions that delay the SSN_CLOSE hook until after all the 
> TXN_CLOSE hooks, but does not lose the SSN_CLOSE. 



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

[jira] [Commented] (TS-4587) Revisit TSRemapOSResponse

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-4587:
--

Another interesting finding - 

In proxy/http/remap/RemapPlugins.cc
{code}
  if (_s && _cur == 0) {
_s->fp_tsremap_os_response = plugin->fp_tsremap_os_response;
_s->remap_plugin_instance  = ih;
  }
{code}

What it means is that if I have multiple remap plugins in one remap rule, only 
the first's TSRemapOSResponse will be used. 

> Revisit TSRemapOSResponse
> -
>
> Key: TS-4587
> URL: https://issues.apache.org/jira/browse/TS-4587
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Core, Plugins, Remap API, TS API
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> I looked at {{TSRemapOSResponse}}. This is a remap callback that is invoked 
> synchronously in {{HttpTransact::handle_response_from_server()}} and gets 
> passed a {{ServerState_t}} value.
> Note that there is no TSAPI analog for {{ServerState_t}}.
> The main difference between {{TSRemapOSResponse}} is that connection retries 
> will  be visible to {{TSRemapOSResponse}}. It's not that clear to me whether 
> we have enough API for that to be interesting.
> This ticket is to investigate the utility of {{TSRemapOSResponse}}. If it is 
> really helpful, then we should support it as a proper hook (global and 
> transaction). If it's not then consider removing it.



--
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 agree with u to return bool from SessionAccept::accept().

SessionAccept did not consume any parameters, It is just transfer 
parameters to ClientSession.
as your said "Both the vc and the buffer should be treated consistently", 
I'm prefer to move do_io_close() and free MIOBuffer from SessionAccept to 
ProtocolProbeTrampoline.

Just return false if ipallow check fails in XXXSessionAccept::accept().
Then, the NetVC and MIOBuffer will be close in ProtocolProbeTrampoline.



---
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.
---