[GitHub] trafficserver pull request #818: TS-4683 Adds better error handling on confi...

[jpeach]

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

https://github.com/apache/trafficserver/pull/818#discussion_r71650582
  
--- Diff: lib/ts/tests.cc ---
@@ -19,7 +19,7 @@
   limitations under the License.
 */
 
-#include "ts/TestBox.h"
+#include "ts/Regression.h"
--- End diff --

Is this change related?


---
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-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/818#discussion_r71650582
  
--- Diff: lib/ts/tests.cc ---
@@ -19,7 +19,7 @@
   limitations under the License.
 */
 
-#include "ts/TestBox.h"
+#include "ts/Regression.h"
--- End diff --

Is this change related?


Issue Time Tracking
---

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

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



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

[jira] [Work logged] (TS-4680) Not thread safe initialization in TS*DirGet() functions

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 21/Jul/16 05:53
Start Date: 21/Jul/16 05:53
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

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


Issue Time Tracking
---

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

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
>  Time Spent: 2h
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #815: TS-4680: thread safe initialization in TS*DirGet()...

[jpeach]

Github user jpeach commented on the issue:

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


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

[GitHub] trafficserver pull request #819: TS-4311 Removes support for SPDY completely

[jpeach]

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

https://github.com/apache/trafficserver/pull/819#discussion_r71649770
  
--- Diff: lib/ts/ink_config.h.in ---
@@ -127,5 +127,6 @@
 #define TS_BUILD_CANONICAL_HOST "@host@"
 
 #define TS_BUILD_DEFAULT_LOOPBACK_IFACE "@default_loopback_iface@"
+/* clang-format off */
--- End diff --

Should be "clang-format on"? Though do you really need it here?


---
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-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/819#discussion_r71649770
  
--- Diff: lib/ts/ink_config.h.in ---
@@ -127,5 +127,6 @@
 #define TS_BUILD_CANONICAL_HOST "@host@"
 
 #define TS_BUILD_DEFAULT_LOOPBACK_IFACE "@default_loopback_iface@"
+/* clang-format off */
--- End diff --

Should be "clang-format on"? Though do you really need it here?


Issue Time Tracking
---

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

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



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

[jira] [Commented] (TS-2987) TS API to identify if the client connection is via HTTP/2

[James Peach (JIRA)]

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

James Peach commented on TS-2987:
-

If you look in the git history we used to have a "protocol stack" object that 
contained a bit mask of all the protocol layers beneath a HTTP transaction. Not 
sure we would resurrect that code, but the concept may still be useful. It 
would let you express that this requests is HTTP/2 over TCP or HTTP/2 over QUIC 
or HTTP/1 over TLS.

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
> Fix For: 7.0.0
>
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Work logged] (TS-4072) Diagnostic log rolling races

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 21/Jul/16 03:50
Start Date: 21/Jul/16 03:50
Worklog Time Spent: 10m 
  Work Description: Github user danobi commented on the issue:

https://github.com/apache/trafficserver/pull/568
  
@zwoop clang-formatted & rebased


Issue Time Tracking
---

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

> Diagnostic log rolling races
> 
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced 
> with a new log object. Since the global {{diags}} points to a a single 
> {{Diags}} object there is nothing to prevent a different thread logging 
> through this object at the time it is deleted.



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

[GitHub] trafficserver issue #568: TS-4072 Diagnostic log rolling races

[danobi]

Github user danobi commented on the issue:

https://github.com/apache/trafficserver/pull/568
  
@zwoop clang-formatted & rebased


---
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-3474) HTTP/2 Server Push support in ATS

[Masakazu Kitajo (JIRA)]

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

Masakazu Kitajo updated TS-3474:

Fix Version/s: (was: sometime)
   7.0.0

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



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

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

[Masakazu Kitajo (JIRA)]

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

Masakazu Kitajo commented on TS-3474:
-

I'm going to send a pull request by the end of this month.

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



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

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

[Masakazu Kitajo (JIRA)]

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

Masakazu Kitajo reassigned TS-3474:
---

Assignee: Masakazu Kitajo

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



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

[jira] [Updated] (TS-2987) TS API to identify if the client connection is via HTTP/2

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-2987:

Fix Version/s: 7.0.0

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
> Fix For: 7.0.0
>
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

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

[jenkins]

See 

[jira] [Commented] (TS-2987) TS API to identify if the client connection is via HTTP/2

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba commented on TS-2987:
-

I agree. Tracking protocols using {{plugin_tag}} is a kind of temporal hack for 
SPDY and we should stop it too.
IMO, wrapping of {{ProxyClientTransaction::get_protocol_string()}} might be 
fine.

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Comment Edited] (TS-2987) TS API to identify if the client connection is via HTTP/2

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba edited comment on TS-2987 at 7/21/16 2:20 AM:
--

I agree. Tracking protocols using {{plugin_tag}} is a kind of temporal hack for 
SPDY and we should stop it too.
IMO, wrapping {{ProxyClientTransaction::get_protocol_string()}} might be fine.


was (Author: masaori):
I agree. Tracking protocols using {{plugin_tag}} is a kind of temporal hack for 
SPDY and we should stop it too.
IMO, wrapping of {{ProxyClientTransaction::get_protocol_string()}} might be 
fine.

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

Jenkins build is back to normal : osx-master » clang,osx,debug #1039

[jenkins]

See 

[jira] [Work logged] (TS-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[GitHub] trafficserver issue #773: TS-4622 Use port from SRV response when connecting...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/773
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/465/ 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 #773: TS-4622 Use port from SRV response when connecting...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/773
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/360/ 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-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[jira] [Work logged] (TS-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[GitHub] trafficserver issue #773: TS-4622 Use port from SRV response when connecting...

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Resolved] (TS-4639) Add git to vagrant builds

[James Peach (JIRA)]

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

James Peach resolved TS-4639.
-
Resolution: Fixed

> Add git to vagrant builds
> -
>
> Key: TS-4639
> URL: https://issues.apache.org/jira/browse/TS-4639
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build, CI
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The vagrant builds do no currently install git. This means to run "make 
> clang-format" we have to manually install git. I would like to add git to the 
> build scripts.



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

[GitHub] trafficserver pull request #816: TS-4639: Add git to Vagrant builds

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4639) Add git to vagrant builds

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 21/Jul/16 01:57
Start Date: 21/Jul/16 01:57
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

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

> Add git to vagrant builds
> -
>
> Key: TS-4639
> URL: https://issues.apache.org/jira/browse/TS-4639
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build, CI
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The vagrant builds do no currently install git. This means to run "make 
> clang-format" we have to manually install git. I would like to add git to the 
> build scripts.



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

[jira] [Work logged] (TS-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/773
  
 This looks good to me and I think it will be safe w/ 
"TsHttpTxnServerAddrSet()".


Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[GitHub] trafficserver issue #773: TS-4622 Use port from SRV response when connecting...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/773
  
👍 This looks good to me and I think it will be safe w/ 
"TsHttpTxnServerAddrSet()".


---
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-2987) TS API to identify if the client connection is via HTTP/2

[Kit Chan (JIRA)]

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

Kit Chan updated TS-2987:
-
Component/s: (was: SPDY)
 (was: Plugins)
 TS API
 HTTP/2

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Commented] (TS-2987) TS API to identify if the client connection is via HTTP/2

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-2987:
--

I think [~sudheerv] originally has a patch to use plugin_tag for this purpose. 
I am not too sure why it is no longer attached to this jira. 

[~sudheerv], can you share some history with us on this?

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins, SPDY
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Commented] (TS-2987) TS API to identify if the client connection is via HTTP/2

[James Peach (JIRA)]

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

James Peach commented on TS-2987:
-

Yes, but let's try not to couple this to plugins.

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins, SPDY
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Commented] (TS-2987) TS API to identify if the client connection is via HTTP/2

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-2987:
--

Reopening since I think we still need an API for us to identify if the client 
connection is via HTTP/2 or not. 

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins, SPDY
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Reopened] (TS-2987) TS API to identify if the client connection is via HTTP/2

[Kit Chan (JIRA)]

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

Kit Chan reopened TS-2987:
--

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins, SPDY
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Updated] (TS-2987) TS API to identify if the client connection is via HTTP/2

[Kit Chan (JIRA)]

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

Kit Chan updated TS-2987:
-
Summary: TS API to identify if the client connection is via HTTP/2  (was: 
TS API to identify if the client connection is via SPDY)

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins, SPDY
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Work logged] (TS-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



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

[GitHub] trafficserver issue #819: TS-4311 Removes support for SPDY completely

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/819
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/359/ 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-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



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

[GitHub] trafficserver issue #819: TS-4311 Removes support for SPDY completely

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/819
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/463/ 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 pull request #819: TS-4311 Removes support for SPDY completely

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4311 Removes support for SPDY completely



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

$ git pull https://github.com/zwoop/trafficserver TS-4311

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

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


commit 2ee78fb57c94328a95b5aead5a04cca6272fdaa0
Author: Leif Hedstrom 
Date:   2016-07-20T01:23:09Z

TS-4311 Removes support for SPDY completely




---
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-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 21/Jul/16 00:18
Start Date: 21/Jul/16 00:18
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4311 Removes support for SPDY completely



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

$ git pull https://github.com/zwoop/trafficserver TS-4311

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

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


commit 2ee78fb57c94328a95b5aead5a04cca6272fdaa0
Author: Leif Hedstrom 
Date:   2016-07-20T01:23:09Z

TS-4311 Removes support for SPDY completely




Issue Time Tracking
---

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

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



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

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

[jenkins]

See 


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

Build failed in Jenkins: osx-master » clang,osx,debug #1038

[jenkins]

See 


Changes:

[Leif Hedstrom] TS-4667 Uses the WKS in the gzip plugin

--
[...truncated 2320 lines...]
libtool: install: /usr/bin/install -c .libs/collapsed_connection.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in collapsed_forwarding
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
collapsed_forwarding.la 
'
libtool: install: /usr/bin/install -c .libs/collapsed_forwarding.so 

libtool: install: /usr/bin/install -c .libs/collapsed_forwarding.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in custom_redirect
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
custom_redirect.la 
'
libtool: install: /usr/bin/install -c .libs/custom_redirect.so 

libtool: install: /usr/bin/install -c .libs/custom_redirect.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in epic
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   epic.la 
'
libtool: install: /usr/bin/install -c .libs/epic.so 

libtool: install: /usr/bin/install -c .libs/epic.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in escalate
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   escalate.la 
'
libtool: install: /usr/bin/install -c .libs/escalate.so 

libtool: install: /usr/bin/install -c .libs/escalate.lai 

make[4]: Nothing to be done for `install-data-am'.
Making install in esi
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   esi.la 
combo_handler.la 
'
libtool: install: /usr/bin/install -c .libs/esi.so 

libtool: install: /usr/bin/install -c .libs/esi.lai 

libtool: install: /usr/bin/install -c .libs/combo_handler.so 

[jira] [Work logged] (TS-4667) The gzip plugin uses non-WKS strings where it should

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Jul/16 23:49
Start Date: 20/Jul/16 23:49
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> The gzip plugin uses non-WKS strings where it should
> 
>
> Key: TS-4667
> URL: https://issues.apache.org/jira/browse/TS-4667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> In all its handling of MIME header fields, it uses its own strings, instead 
> of our WKS strings that are available via plugin APIs. Albeit benign, this 
> sets a bad precedence, and we should do it right :).



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

[GitHub] trafficserver pull request #817: TS-4667 Uses the WKS in the gzip plugin

[zwoop]

Github user zwoop closed the pull request at:

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


---
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-4667) The gzip plugin uses non-WKS strings where it should

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> The gzip plugin uses non-WKS strings where it should
> 
>
> Key: TS-4667
> URL: https://issues.apache.org/jira/browse/TS-4667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In all its handling of MIME header fields, it uses its own strings, instead 
> of our WKS strings that are available via plugin APIs. Albeit benign, this 
> sets a bad precedence, and we should do it right :).



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

[GitHub] trafficserver issue #817: TS-4667 Uses the WKS in the gzip plugin

[jpeach]

Github user jpeach commented on the issue:

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


---
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-4291) Custom log field {{pqhl}} should not count internal headers.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/588
  
So, now that we're on the 7.0.0 release cycle, I wonder if we should have 
pqhl, cqhl, pshl, and sshl all exclude any @ headers? If not, if we really want 
this, don't we also want all 4 variants of these tags for consistency? I.e. 
pqhnl, cqhln, pshln, and sshln ?

@jpeach Wdyt? I'm leaning more towards a 7.0.0 incompatible change and 
exclude any @ headers from these calculations, but maybe that's just a too 
expensive change to make (computational expensive).


Issue Time Tracking
---

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

> Custom log field {{pqhl}} should not count internal headers.
> 
>
> Key: TS-4291
> URL: https://issues.apache.org/jira/browse/TS-4291
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> [~zwoop] suggested to add a simple API (not necessarily exposed to plugins at 
> the moment), to count the length of @-custom headers and deduct that when 
> reporting {{pqhl}}. Also, apply the same modification to lengths of other leg 
> request/response objects (e.g client_req, client_resp, server_req, 
> server_resp).
> IRC discussion below.
> {code}
> oag
> 7:55 If anyone is around who is familiar with the @-headers trick, I have a 
> question:
> 7:55 I have observed that @custom-header in an outgoing request changes the 
> value of the pqhl log field, even though the header is never actually sent.
> 7:55 This is true in 5.3.1. Does anyone know if this as been changed in 6.x.x 
> ?
> 7:55 Would like it if pqhl was an accurate reflection of data to the origin 
> server.
> 7:55 (pqhl + pqbl that is.)
> zwoop
> 7:55 oag  I'm pretty sure that is intended, if you don't want it there, why 
> not add it to another header ?
> 7:55 the way it works is that it "filters" out the @ header before sending, 
> and returning, headers
> 7:55 (afaik)
> 7:55 entirely possible I'm wrong too, but that was my impression from before.
> ***
> 7:55 Playback Complete.
> 7:57 esproul [~ad...@static-108-48-124-82.washdc.fios.verizon.net] entered 
> the room.
> sudheerv
> 8:07 zwoop: oag: umm..interesting, like zwoop said while it is intentional 
> that @-custom headers are meant never to be leaked outside, the pqhl adding 
> the @-headers seems like not something desirable
> 8:08 i'd be okay if we agree to not add it to pqhl
> 8:08 pqhl
> The proxy request header length; the header length in Traffic Server’s 
> request to the origin server.
> 8:09 given that pqhl is defined as the header length in the outbound request
> 8:09 adding @-headers to it seems inconsistent/inaccurate
> 8:10 as a matter of fact, i use @headers pretty "heavily" in our 
> products..but, don't enable pqhl
> 8:10 (at the moment anyway)
> zwoop
> 8:15 sudheerv  but that sets a poor precedence. You want to exclude @ headers 
> from pqhl, but not the other 3 internal header log tags that we have ?
> zwoop
> 8:16 One very important feature of the @-headers is to be able to log 
> internal (plugin generated) information in our custom logs
> sudheerv
> 8:16 zwoop: but, pqhl is just the length of the outgoing headers?
> zwoop
> 8:16 ah
> sudheerv
> 8:16 i haven't looked at in detail, but, excluding @ headers ( and the other 
> intenral headers)
> zwoop
> 8:16 in bytes ?
> sudheerv
> 8:16 from pqhl
> 8:16 will it mess up the log fields?
> 8:16 yeah
> zwoop
> 8:16 I thought it was the request header object.
> 8:16 Yeah, I don't know
> sudheerv
> 8:17 yeah, worth double checking - when the wise man complains :)
> zwoop
> 8:17 maybe you'd have to keep two lengths then, one with, and one without the 
> @ headers ?
> sudheerv
> 8:17 but, yeah, i'd not want to exclude the headers from log fields
> 8:17 just the length
> 8:17 sure, yeah unless it's already computing them in one place
> zwoop
> 8:17 m_proxy_request->length_get()
> sudheerv
> 8:17 where it'd be easier to exclude them - need ot check that part of the 
> code
> 8:17 ah, ok
> 8:19 so, would you be okay to modify pqhl (lenght in bytes) to exclude the 
> internal headers?
> zwoop
> 8:19 http://pastebin.com/svwPmaa0
> 8:19 looks like it counts the size of the "blocks" used, and not individual 
> header. It'd likely get much, much more expensive if you have 

[GitHub] trafficserver issue #588: TS-4291 Adds log field "pqnhl" which ignores inter...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/588
  
So, now that we're on the 7.0.0 release cycle, I wonder if we should have 
pqhl, cqhl, pshl, and sshl all exclude any @ headers? If not, if we really want 
this, don't we also want all 4 variants of these tags for consistency? I.e. 
pqhnl, cqhln, pshln, and sshln ?

@jpeach Wdyt? I'm leaning more towards a 7.0.0 incompatible change and 
exclude any @ headers from these calculations, but maybe that's just a too 
expensive change to make (computational expensive).


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

[GitHub] trafficserver pull request #310: TS-3978: Allow empty document caching to fo...

[zwoop]

Github user zwoop closed the pull request at:

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


---
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-4072) Diagnostic log rolling races

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/568
  
Well, this slipped through the net. @danobi  Can you please make an update 
to the PR, that does not have merge conflicts?


Issue Time Tracking
---

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

> Diagnostic log rolling races
> 
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced 
> with a new log object. Since the global {{diags}} points to a a single 
> {{Diags}} object there is nothing to prevent a different thread logging 
> through this object at the time it is deleted.



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

[GitHub] trafficserver issue #568: TS-4072 Diagnostic log rolling races

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/568
  
Well, this slipped through the net. @danobi  Can you please make an update 
to the PR, that does not have merge conflicts?


---
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-3978) Allow empty document caching to follow normal logic

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Jul/16 20:43
Start Date: 20/Jul/16 20:43
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> Allow empty document caching to follow normal logic
> ---
>
> Key: TS-3978
> URL: https://issues.apache.org/jira/browse/TS-3978
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Felicity Tarnell
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, allow_empty_doc only works if the origin sends a content-length 
> header.  It should have a setting to enable empty documents to be cached in 
> the normal way without any special handling.



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

[jira] [Work logged] (TS-3978) Allow empty document caching to follow normal logic

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/310
  
I'm going to close this for now, please open a new PR after we discuss this 
more?


Issue Time Tracking
---

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

> Allow empty document caching to follow normal logic
> ---
>
> Key: TS-3978
> URL: https://issues.apache.org/jira/browse/TS-3978
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Felicity Tarnell
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, allow_empty_doc only works if the origin sends a content-length 
> header.  It should have a setting to enable empty documents to be cached in 
> the normal way without any special handling.



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

[GitHub] trafficserver issue #310: TS-3978: Allow empty document caching to follow no...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/310
  
I'm going to close this for now, please open a new PR after we discuss this 
more?


---
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-4680) Not thread safe initialization in TS*DirGet() functions

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #815: TS-4680: thread safe initialization in TS*DirGet()...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/815
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/358/ 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-4680) Not thread safe initialization in TS*DirGet() functions

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #815: TS-4680: thread safe initialization in TS*DirGet()...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/815
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/462/ 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-4680) Not thread safe initialization in TS*DirGet() functions

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/815
  
Yeah, like that. Makes you wonder why TSPluginDirGet() was so different 
though ... I've had issues before with these APIs, where transfer of ownership 
was not clear. I'll take a peek in a bit.

[approve ci].


Issue Time Tracking
---

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

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver issue #815: TS-4680: thread safe initialization in TS*DirGet()...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/815
  
Yeah, like that. Makes you wonder why TSPluginDirGet() was so different 
though ... I've had issues before with these APIs, where transfer of ownership 
was not clear. I'll take a peek in a bit.

[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] [Commented] (TS-2987) TS API to identify if the client connection is via SPDY

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-2987:
---

[~kichan] Should we reopen it? If you do, maybe reword it such that it's not 
SPDY but H2 ?

> TS API to identify if the client connection is via SPDY
> ---
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins, SPDY
>Reporter: Sudheer Vinukonda
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Work logged] (TS-4667) The gzip plugin uses non-WKS strings where it should

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/817
  
@oschaaf  please review.


Issue Time Tracking
---

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

> The gzip plugin uses non-WKS strings where it should
> 
>
> Key: TS-4667
> URL: https://issues.apache.org/jira/browse/TS-4667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In all its handling of MIME header fields, it uses its own strings, instead 
> of our WKS strings that are available via plugin APIs. Albeit benign, this 
> sets a bad precedence, and we should do it right :).



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

[GitHub] trafficserver issue #817: TS-4667 Uses the WKS in the gzip plugin

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/817
  
@oschaaf  please review.


---
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-4639) Add git to vagrant builds

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/816
  
I don't speak Vagrant, but this seems reasonable to me.


Issue Time Tracking
---

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

> Add git to vagrant builds
> -
>
> Key: TS-4639
> URL: https://issues.apache.org/jira/browse/TS-4639
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build, CI
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The vagrant builds do no currently install git. This means to run "make 
> clang-format" we have to manually install git. I would like to add git to the 
> build scripts.



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

[GitHub] trafficserver issue #816: TS-4639: Add git to Vagrant builds

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/816
  
I don't speak Vagrant, but this seems reasonable to me.


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

[jira] [Work logged] (TS-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



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

[GitHub] trafficserver issue #818: TS-4683 Adds better error handling on config probl...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/357/ 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-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



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

[GitHub] trafficserver issue #818: TS-4683 Adds better error handling on config probl...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/461/ 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-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



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

[GitHub] trafficserver issue #818: TS-4683 Adds better error handling on config probl...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/356/ 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-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



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

[GitHub] trafficserver issue #818: TS-4683 Adds better error handling on config probl...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/460/ 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-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Jul/16 16:12
Start Date: 20/Jul/16 16:12
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4683 Adds better error handling on config problems



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

$ git pull https://github.com/zwoop/trafficserver TS-4683

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

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


commit 983e4c469805950d9c8a68bc1de35aabf112ed7e
Author: Leif Hedstrom 
Date:   2016-07-19T03:45:21Z

TS-4683 Adds better error handling on config problems




Issue Time Tracking
---

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

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



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

[GitHub] trafficserver pull request #818: TS-4683 Adds better error handling on confi...

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4683 Adds better error handling on config problems



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

$ git pull https://github.com/zwoop/trafficserver TS-4683

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

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


commit 983e4c469805950d9c8a68bc1de35aabf112ed7e
Author: Leif Hedstrom 
Date:   2016-07-19T03:45:21Z

TS-4683 Adds better error handling on config problems




---
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 #817: TS-4667 Uses the WKS in the gzip plugin

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/817
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/355/ 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-4667) The gzip plugin uses non-WKS strings where it should

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> The gzip plugin uses non-WKS strings where it should
> 
>
> Key: TS-4667
> URL: https://issues.apache.org/jira/browse/TS-4667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In all its handling of MIME header fields, it uses its own strings, instead 
> of our WKS strings that are available via plugin APIs. Albeit benign, this 
> sets a bad precedence, and we should do it right :).



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

[jira] [Work logged] (TS-4667) The gzip plugin uses non-WKS strings where it should

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> The gzip plugin uses non-WKS strings where it should
> 
>
> Key: TS-4667
> URL: https://issues.apache.org/jira/browse/TS-4667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In all its handling of MIME header fields, it uses its own strings, instead 
> of our WKS strings that are available via plugin APIs. Albeit benign, this 
> sets a bad precedence, and we should do it right :).



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

[GitHub] trafficserver issue #817: TS-4667 Uses the WKS in the gzip plugin

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/817
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/459/ 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-4667) The gzip plugin uses non-WKS strings where it should

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Jul/16 15:54
Start Date: 20/Jul/16 15:54
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4667 Uses the WKS in the gzip plugin

Instead of just using strings, like "deflate". Albeit, it's functionally 
the same, this is a bad pattern that we should discourage (using the WKS's 
consistently is better performance, and better to read).

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

$ git pull https://github.com/zwoop/trafficserver TS-4667

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

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


commit 82a7db79306949a85cc7fe9f7bde48b849e2860a
Author: Leif Hedstrom 
Date:   2016-07-20T15:37:37Z

TS-4667 Uses the WKS in the gzip plugin




Issue Time Tracking
---

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

> The gzip plugin uses non-WKS strings where it should
> 
>
> Key: TS-4667
> URL: https://issues.apache.org/jira/browse/TS-4667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In all its handling of MIME header fields, it uses its own strings, instead 
> of our WKS strings that are available via plugin APIs. Albeit benign, this 
> sets a bad precedence, and we should do it right :).



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

[GitHub] trafficserver pull request #817: TS-4667 Uses the WKS in the gzip plugin

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4667 Uses the WKS in the gzip plugin

Instead of just using strings, like "deflate". Albeit, it's functionally 
the same, this is a bad pattern that we should discourage (using the WKS's 
consistently is better performance, and better to read).

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

$ git pull https://github.com/zwoop/trafficserver TS-4667

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

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


commit 82a7db79306949a85cc7fe9f7bde48b849e2860a
Author: Leif Hedstrom 
Date:   2016-07-20T15:37:37Z

TS-4667 Uses the WKS in the gzip plugin




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

[GitHub] trafficserver pull request #816: TS-4639: Add git to Vagrant builds

[strotyl]

GitHub user strotyl opened a pull request:

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

TS-4639: Add git to Vagrant builds



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

$ git pull https://github.com/strotyl/trafficserver TS-4639

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

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


commit 9893aa87d24f2fc15b3217f00b1b7be056714028
Author: Tyler Stroh 
Date:   2016-07-08T18:00:25Z

TS-4639: Add git to Vagrant builds




---
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-4639) Add git to vagrant builds

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Jul/16 15:38
Start Date: 20/Jul/16 15:38
Worklog Time Spent: 10m 
  Work Description: GitHub user strotyl opened a pull request:

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

TS-4639: Add git to Vagrant builds



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

$ git pull https://github.com/strotyl/trafficserver TS-4639

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

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


commit 9893aa87d24f2fc15b3217f00b1b7be056714028
Author: Tyler Stroh 
Date:   2016-07-08T18:00:25Z

TS-4639: Add git to Vagrant builds




Issue Time Tracking
---

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

> Add git to vagrant builds
> -
>
> Key: TS-4639
> URL: https://issues.apache.org/jira/browse/TS-4639
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build, CI
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The vagrant builds do no currently install git. This means to run "make 
> clang-format" we have to manually install git. I would like to add git to the 
> build scripts.



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

[GitHub] trafficserver pull request #812: TS-4688 handle DNS compression labels in SR...

[jacksontj]

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

https://github.com/apache/trafficserver/pull/812#discussion_r71542146
  
--- Diff: iocore/dns/DNS.cc ---
@@ -1514,24 +1514,24 @@ dns_process(DNSHandler *handler, HostEnt *buf, int 
len)
 cp += dn_skipname(cp, eom);
 here = cp; /* hack */
 SRV *srv = >srv_hosts.hosts[num_srv];
-int r= ink_ns_name_ntop(srv_off + SRV_SERVER, srv->host, 
MAXDNAME);
-if (r <= 0) {
-  /* FIXME: is this really an error? or just a continue; */
+
+// expand the name
+n = ink_dn_expand((u_char *)h, eom, srv_off + SRV_SERVER, (u_char 
*)srv->host, MAXDNAME);
+if (n < 0) {
   ++error;
-  goto Lerror;
+  break;
 }
 Debug("dns_srv", "Discovered SRV record [from NS lookup] with 
cost:%d weight:%d port:%d with host:%s",
   ink_get16(srv_off + SRV_COST), ink_get16(srv_off + 
SRV_WEIGHT), ink_get16(srv_off + SRV_PORT), srv->host);
 
-srv->port= ink_get16(srv_off + SRV_PORT);
-srv->priority= ink_get16(srv_off + SRV_COST);
-srv->weight  = ink_get16(srv_off + SRV_WEIGHT);
-srv->host_len= r;
-srv->host[r - 1] = '\0';
-srv->key = makeHostHash(srv->host);
+srv->port = ink_get16(srv_off + SRV_PORT);
+srv->priority = ink_get16(srv_off + SRV_COST);
+srv->weight   = ink_get16(srv_off + SRV_WEIGHT);
+srv->host_len = ::strlen(srv->host) + 1;
--- End diff --

Sadly no, `n` is the length of the compressed string, not the expanded 
string-- meaning I have to calculate the len of the expanded string.


---
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-4688) DNS resolver doesn't handle DNS compression labels for SRV responses

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/812#discussion_r71542146
  
--- Diff: iocore/dns/DNS.cc ---
@@ -1514,24 +1514,24 @@ dns_process(DNSHandler *handler, HostEnt *buf, int 
len)
 cp += dn_skipname(cp, eom);
 here = cp; /* hack */
 SRV *srv = >srv_hosts.hosts[num_srv];
-int r= ink_ns_name_ntop(srv_off + SRV_SERVER, srv->host, 
MAXDNAME);
-if (r <= 0) {
-  /* FIXME: is this really an error? or just a continue; */
+
+// expand the name
+n = ink_dn_expand((u_char *)h, eom, srv_off + SRV_SERVER, (u_char 
*)srv->host, MAXDNAME);
+if (n < 0) {
   ++error;
-  goto Lerror;
+  break;
 }
 Debug("dns_srv", "Discovered SRV record [from NS lookup] with 
cost:%d weight:%d port:%d with host:%s",
   ink_get16(srv_off + SRV_COST), ink_get16(srv_off + 
SRV_WEIGHT), ink_get16(srv_off + SRV_PORT), srv->host);
 
-srv->port= ink_get16(srv_off + SRV_PORT);
-srv->priority= ink_get16(srv_off + SRV_COST);
-srv->weight  = ink_get16(srv_off + SRV_WEIGHT);
-srv->host_len= r;
-srv->host[r - 1] = '\0';
-srv->key = makeHostHash(srv->host);
+srv->port = ink_get16(srv_off + SRV_PORT);
+srv->priority = ink_get16(srv_off + SRV_COST);
+srv->weight   = ink_get16(srv_off + SRV_WEIGHT);
+srv->host_len = ::strlen(srv->host) + 1;
--- End diff --

Sadly no, `n` is the length of the compressed string, not the expanded 
string-- meaning I have to calculate the len of the expanded string.


Issue Time Tracking
---

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

> DNS resolver doesn't handle DNS compression labels for SRV responses
> 
>
> Key: TS-4688
> URL: https://issues.apache.org/jira/browse/TS-4688
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> If you get an SRV response from DNS with compression labels-- ATS' resolver 
> doesn't expand the names so the lookup fails.



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

[jira] [Work logged] (TS-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Jul/16 14:58
Start Date: 20/Jul/16 14:58
Worklog Time Spent: 10m 
  Work Description: Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/773
  
@jpeach 

I did some testing of my own and I can't reproduce any problems with 
`TsHttpTxnServerAddrSet()` at all. TSHttpTxnServerAddrSet() is supposed to be 
called before the DNS lookup. If called then the core bypasses the entire 
OS_DNS stuff which includes this port setting block in HttpTransact.

I tested calling the API on both the `TS_EVENT_HTTP_READ_REQUEST_HDR` and 
`TS_EVENT_HTTP_OS_DNS` hooks-- with no problem at all.

You mentioned in a previous comment that it was broken in your testing, can 
you share the code you were using to see it broken?


Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[GitHub] trafficserver issue #773: TS-4622 Use port from SRV response when connecting...

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/773
  
@jpeach 

I did some testing of my own and I can't reproduce any problems with 
`TsHttpTxnServerAddrSet()` at all. TSHttpTxnServerAddrSet() is supposed to be 
called before the DNS lookup. If called then the core bypasses the entire 
OS_DNS stuff which includes this port setting block in HttpTransact.

I tested calling the API on both the `TS_EVENT_HTTP_READ_REQUEST_HDR` and 
`TS_EVENT_HTTP_OS_DNS` hooks-- with no problem at all.

You mentioned in a previous comment that it was broken in your testing, can 
you share the code you were using to see it broken?


---
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-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[GitHub] trafficserver issue #773: TS-4622 Use port from SRV response when connecting...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/773
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/354/ 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 #773: TS-4622 Use port from SRV response when connecting...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/773
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/458/ 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-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[jira] [Work logged] (TS-4622) Ports from SRV lookups aren't used

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Jul/16 14:32
Start Date: 20/Jul/16 14:32
Worklog Time Spent: 10m 
  Work Description: Github user jacksontj commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/773#discussion_r71536060
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -1783,7 +1783,13 @@ HttpTransact::OSDNSLookup(State *s)
   // update some state variables with hostdb information that has
   // been provided.
   ats_ip_copy(>server_info.dst_addr, s->host_db_info.ip());
-  s->server_info.dst_addr.port() = 
htons(s->hdr_info.client_request.port_get()); // now we can set the port.
+  // TODO ideally only if ports aren't defined in remap
+  // If the SRV response has a port number, we should honor it. Otherwise 
we do the port defined in remap
+  if (s->dns_info.srv_port) {
+s->server_info.dst_addr.port() = htons(s->dns_info.srv_port);
+  } else {
+s->server_info.dst_addr.port() = 
htons(s->hdr_info.client_request.port_get()); // now we can set the port.
+  }
--- End diff --

I'll change the conditional-- that definitely makes sense.

From looking at the API callout code-- it does seem like its already broken 
:/

It seems that `TSHttpTxnServerAddrSet()` is called before the DNS lookup-- 
and if so it bypasses the [dns lookup| 
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L7179].
 So, I would think in this section of HttpTransact we would want to skip all 
port setting if `api_server_addr_set` is true.


Issue Time Tracking
---

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

> Ports from SRV lookups aren't used
> --
>
> Key: TS-4622
> URL: https://issues.apache.org/jira/browse/TS-4622
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Although the dns processor parses out the ports and we keep track of them, it 
> seems that the port from the SRV response is not used at all when connecting 
> to the origin. Simple fix, we simply need to set the port before doing 
> `do_http_server_open` (potentially earlier if we want to let plugins etc. 
> override the port?)



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

[GitHub] trafficserver pull request #773: TS-4622 Use port from SRV response when con...

[jacksontj]

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

https://github.com/apache/trafficserver/pull/773#discussion_r71536060
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -1783,7 +1783,13 @@ HttpTransact::OSDNSLookup(State *s)
   // update some state variables with hostdb information that has
   // been provided.
   ats_ip_copy(>server_info.dst_addr, s->host_db_info.ip());
-  s->server_info.dst_addr.port() = 
htons(s->hdr_info.client_request.port_get()); // now we can set the port.
+  // TODO ideally only if ports aren't defined in remap
+  // If the SRV response has a port number, we should honor it. Otherwise 
we do the port defined in remap
+  if (s->dns_info.srv_port) {
+s->server_info.dst_addr.port() = htons(s->dns_info.srv_port);
+  } else {
+s->server_info.dst_addr.port() = 
htons(s->hdr_info.client_request.port_get()); // now we can set the port.
+  }
--- End diff --

I'll change the conditional-- that definitely makes sense.

From looking at the API callout code-- it does seem like its already broken 
:/

It seems that `TSHttpTxnServerAddrSet()` is called before the DNS lookup-- 
and if so it bypasses the [dns lookup| 
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L7179].
 So, I would think in this section of HttpTransact we would want to skip all 
port setting if `api_server_addr_set` is true.


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

[jira] [Resolved] (TS-4653) ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally

[Kit Chan (JIRA)]

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

Kit Chan resolved TS-4653.
--
Resolution: Fixed

> ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally
> 
>
> Key: TS-4653
> URL: https://issues.apache.org/jira/browse/TS-4653
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> In the ESI spec, we can print out cookie information with $HTTP_COOKIE. This 
> can be problematic and unintentionally print out sensitive info on a web page.
> We should have mechanism to disable this by default and allow us to fine tune 
> it so we can choose to expose this functionality for only the cookie that we 
> allow 



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

[jira] [Work logged] (TS-4653) ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally
> 
>
> Key: TS-4653
> URL: https://issues.apache.org/jira/browse/TS-4653
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> In the ESI spec, we can print out cookie information with $HTTP_COOKIE. This 
> can be problematic and unintentionally print out sensitive info on a web page.
> We should have mechanism to disable this by default and allow us to fine tune 
> it so we can choose to expose this functionality for only the cookie that we 
> allow 



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

[GitHub] trafficserver issue #798: TS-4653: esi plugin - disable HTTP_COOKIE variable...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/798
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/352/ 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-4653) ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 25752)
Time Spent: 4.5h  (was: 4h 20m)

> ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally
> 
>
> Key: TS-4653
> URL: https://issues.apache.org/jira/browse/TS-4653
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> In the ESI spec, we can print out cookie information with $HTTP_COOKIE. This 
> can be problematic and unintentionally print out sensitive info on a web page.
> We should have mechanism to disable this by default and allow us to fine tune 
> it so we can choose to expose this functionality for only the cookie that we 
> allow 



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

[GitHub] trafficserver issue #798: TS-4653: esi plugin - disable HTTP_COOKIE variable...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/798
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/457/ 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 pull request #798: TS-4653: esi plugin - disable HTTP_COOKIE v...

[shukitchan]

Github user shukitchan closed the pull request at:

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


---
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-4653) ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 25751)
Time Spent: 4h 20m  (was: 4h 10m)

> ESI plugin - $HTTP_COOKIE can leak important cookie info unintentionally
> 
>
> Key: TS-4653
> URL: https://issues.apache.org/jira/browse/TS-4653
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> In the ESI spec, we can print out cookie information with $HTTP_COOKIE. This 
> can be problematic and unintentionally print out sensitive info on a web page.
> We should have mechanism to disable this by default and allow us to fine tune 
> it so we can choose to expose this functionality for only the cookie that we 
> allow 



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