[jira] [Updated] (TS-4693) SRV priorities don't work

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4693:
---
Fix Version/s: (was: sometime)
   7.0.0

> SRV priorities don't work
> -
>
> Key: TS-4693
> URL: https://issues.apache.org/jira/browse/TS-4693
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Although priorities are stored in hostdb (and code exists that attempts to do 
> priorities)-- from some black-box testing it seems that the priorities aren't 
> taken into consideration for LB.



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

[jira] [Closed] (TS-4692) SRV weights don't work

[Thomas Jackson (JIRA)]

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

Thomas Jackson closed TS-4692.
--
Resolution: Duplicate

> SRV weights don't work
> --
>
> Key: TS-4692
> URL: https://issues.apache.org/jira/browse/TS-4692
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> Although weights are stored in hostdb (and code exists that attempts to do 
> weighting)-- from some black-box testing it seems that the weighting isn't 
> taken into consideration for LB.



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

[jira] [Commented] (TS-4693) SRV priorities don't work

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-4693:


PR with fix (and re-enabling tests: 
https://github.com/apache/trafficserver/pull/827)

> SRV priorities don't work
> -
>
> Key: TS-4693
> URL: https://issues.apache.org/jira/browse/TS-4693
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Although priorities are stored in hostdb (and code exists that attempts to do 
> priorities)-- from some black-box testing it seems that the priorities aren't 
> taken into consideration for LB.



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

[GitHub] trafficserver pull request #827: Ts 4693

[jacksontj]

GitHub user jacksontj opened a pull request:

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

Ts 4693



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

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

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

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


commit 832f04bcdf85ce6e04168ec48c8216e21a61840a
Author: Thomas Jackson 
Date:   2016-07-27T05:34:40Z

TS-4693 fix priority selection for SRV records

The "is_alive" check was backwards, meaning that instead of excluding dead 
hosts we were excluding healthy hosts. In the failure mode where all reals are 
dead select_best_srv picks a host at random since we believe all reals to be 
dead.

commit 0065f0e1619037a7e4727eb161f01f6c65b1d3d0
Author: Thomas Jackson 
Date:   2016-07-21T16:15:56Z

Fix test_hostdb SRV testing

Add better parsing for the proxy property-- so it can be used for http and 
https

commit e5c7b435f9433e653f8a7183fd2cbf20b42dcca9
Author: Thomas Jackson 
Date:   2016-07-27T05:50:29Z

Re-enable tests for SRV priority and weight




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

Jenkins build is back to normal : centos_7-master » clang,centos_7,release #1872

[jenkins]

See 

[jira] [Work logged] (TS-4612) Proposal: InactivityCop Optimize

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/771
  
@bryancall to review the codes of ClusterHandlerBase.cc 
```
 979 thread = eventProcessor.eventthread[ET_CLUSTER][id % 
num_of_cluster_threads];
 980 if (net_vc->thread == thread) {
 981   cluster_connect_state = CLCON_CONN_BIND_OK;
 982   break;
 983 } else {
 984   cluster_connect_state = 
ClusterHandler::CLCON_CONN_BIND_CLEAR;
 985 }
```

From my understanding of the code, the codes from L1007 to L1033 means:
1. the net_vc bind to unmatched thread
2. It should unbind(L1012-1022) and then rebind(L1024-L1027) to another 
thread

I think the unbind include remove vc from cop_list here.
because the InactivityCop only push the vc->thread == this_ethread() into 
cop_list, but the vc->thread set to NULL in L1014.

```
// Copy the list and use pop() to catch any closes caused by callbacks.
forl_LL(UnixNetVConnection, vc, nh.open_list)
{   
  if (vc->thread == this_ethread()) {
nh.cop_list.push(vc);
  }   
}
```



Issue Time Tracking
---

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

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



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

[GitHub] trafficserver issue #771: TS-4612: Proposal: InactivityCop Optimize

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
@bryancall to review the codes of ClusterHandlerBase.cc 
```
 979 thread = eventProcessor.eventthread[ET_CLUSTER][id % 
num_of_cluster_threads];
 980 if (net_vc->thread == thread) {
 981   cluster_connect_state = CLCON_CONN_BIND_OK;
 982   break;
 983 } else {
 984   cluster_connect_state = 
ClusterHandler::CLCON_CONN_BIND_CLEAR;
 985 }
```

From my understanding of the code, the codes from L1007 to L1033 means:
1. the net_vc bind to unmatched thread
2. It should unbind(L1012-1022) and then rebind(L1024-L1027) to another 
thread

I think the unbind include remove vc from cop_list here.
because the InactivityCop only push the vc->thread == this_ethread() into 
cop_list, but the vc->thread set to NULL in L1014.

```
// Copy the list and use pop() to catch any closes caused by callbacks.
forl_LL(UnixNetVConnection, vc, nh.open_list)
{   
  if (vc->thread == this_ethread()) {
nh.cop_list.push(vc);
  }   
}
```



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

Build failed in Jenkins: centos_7-master » clang,centos_7,release #1871

[jenkins]

See 


--
[...truncated 6023 lines...]
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
 during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
 during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
Making install in stream_editor
make[3]: Entering directory 
`
make[4]: Entering directory 
`
 /usr/bin/mkdir -p 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
stream_editor.la 
'
libtool: install: /usr/bin/install -c .libs/stream_editor.so 

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

libtool: finish: PATH="/usr/local/bin:/usr/bin:/sbin" ldconfig -n 

--
Libraries have been installed in:
   


If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
 during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
 during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
Making install in ts_lua
make[3]: Entering directory 
`
make[4]: Entering directory 
`
 /usr/bin/mkdir -p 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   tslua.la 
'
libtool: install: /usr/bin/install -c .libs/tslua.so 

libtool: install: 

[jira] [Work logged] (TS-4679) Allow ssl_multicert line to have no ssl_cert_name specified

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/810#discussion_r72265027
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -1583,7 +1583,10 @@ SSLInitServerContext(const SSLConfigParams *params, 
const ssl_user_config 
 SSL_CTX_set_default_passwd_cb_userdata(ctx, );
   }
 
-  if (sslMultCertSettings.cert) {
+  if (!sslMultCertSettings.cert && sslMultCertSettings.opt != 
SSLCertContext::OPT_TUNNEL) {
+Warning("No ssl_cert_name specified and no tunnel action set");
+goto fail;
+  } else if (sslMultCertSettings.cert) {
--- End diff --

I think this is "ok", it just reads a little odd. I probably would have 
preferred e.g.

if (!sslMultCertSettings.cert) {
if (sslMultCertSettings.opt != SSLCertContext::OPT_TUNNEL) {
Warning( ...)
}
} else {
SimpleTokenizer cert_tok((const ...

I know, a little nitpick, but the fear being that we repeat the conditional 
multiple time, having a risk of inconsistencies.


Issue Time Tracking
---

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

> Allow ssl_multicert line to have no ssl_cert_name specified
> ---
>
> Key: TS-4679
> URL: https://issues.apache.org/jira/browse/TS-4679
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> It is reasonable to not specify a ssl_cert_name if the action=tunnel is 
> specified.  As the code currently stands you must enter a dummy ssl_cert_name 
> even in the blind tunnel case because of sanity checks in the ssl_multicert 
> loading code.
> The following should be an allowable entry
> {code}
> dest_ip=10.10.10.10 action=tunnel
> {code}



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

[jira] [Work logged] (TS-4679) Allow ssl_multicert line to have no ssl_cert_name specified

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Allow ssl_multicert line to have no ssl_cert_name specified
> ---
>
> Key: TS-4679
> URL: https://issues.apache.org/jira/browse/TS-4679
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> It is reasonable to not specify a ssl_cert_name if the action=tunnel is 
> specified.  As the code currently stands you must enter a dummy ssl_cert_name 
> even in the blind tunnel case because of sanity checks in the ssl_multicert 
> loading code.
> The following should be an allowable entry
> {code}
> dest_ip=10.10.10.10 action=tunnel
> {code}



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

[GitHub] trafficserver issue #810: TS-4679: Allow multicert line with action but no s...

[zwoop]

Github user zwoop commented on the issue:

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


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

[GitHub] trafficserver pull request #810: TS-4679: Allow multicert line with action b...

[zwoop]

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

https://github.com/apache/trafficserver/pull/810#discussion_r72265027
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -1583,7 +1583,10 @@ SSLInitServerContext(const SSLConfigParams *params, 
const ssl_user_config 
 SSL_CTX_set_default_passwd_cb_userdata(ctx, );
   }
 
-  if (sslMultCertSettings.cert) {
+  if (!sslMultCertSettings.cert && sslMultCertSettings.opt != 
SSLCertContext::OPT_TUNNEL) {
+Warning("No ssl_cert_name specified and no tunnel action set");
+goto fail;
+  } else if (sslMultCertSettings.cert) {
--- End diff --

I think this is "ok", it just reads a little odd. I probably would have 
preferred e.g.

if (!sslMultCertSettings.cert) {
if (sslMultCertSettings.opt != SSLCertContext::OPT_TUNNEL) {
Warning( ...)
}
} else {
SimpleTokenizer cert_tok((const ...

I know, a little nitpick, but the fear being that we repeat the conditional 
multiple time, having a risk of inconsistencies.


---
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-4678) plugin promotions to stable

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> plugin promotions to stable
> ---
>
> Key: TS-4678
> URL: https://issues.apache.org/jira/browse/TS-4678
> Project: Traffic Server
>  Issue Type: Task
>  Components: Plugins
>Reporter: Miles Libbey
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> At the ATS Summit in Vancouver, we had a brief discussion about each the 
> experimental plugins for the upcoming 7.0 release. In the room, the consensus 
> was:
> - Move to stable (eg, used, and unlikely to be breaking compatibility in the 
> short term):
> authproxy
> background_fetch
> esi
> generator
> regex_revalidate
> s3_auth
> xdebug
> - Candidates to be moved to examples
> ssl_cert_loader
> - Candidates for deprecation
> custom_redirect -- might be able to do this in header_rewrite
> header_normalize



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

[GitHub] trafficserver pull request #821: TS-4678 Promotes a few plugins to stable

[zwoop]

Github user zwoop closed the pull request at:

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


---
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-3620) Enable HTTP/2 by default

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Enable HTTP/2 by default
> 
>
> Key: TS-3620
> URL: https://issues.apache.org/jira/browse/TS-3620
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I think the consensus is that this should get controlled via normal 
> server_ports configuration. For 6.0.0, we'll make HTTP/2 "default" I'd 
> imagine if we have compiled in support for ALPN, and the TLS port is enabled.
> Someone would then just specify in server_ports to disable "h2", right ?



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

[GitHub] trafficserver issue #826: TS-3620: Enable HTTP/2 by default

[zwoop]

Github user zwoop commented on the issue:

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


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

[jira] [Work logged] (TS-3620) Enable HTTP/2 by default

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Enable HTTP/2 by default
> 
>
> Key: TS-3620
> URL: https://issues.apache.org/jira/browse/TS-3620
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I think the consensus is that this should get controlled via normal 
> server_ports configuration. For 6.0.0, we'll make HTTP/2 "default" I'd 
> imagine if we have compiled in support for ALPN, and the TLS port is enabled.
> Someone would then just specify in server_ports to disable "h2", right ?



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

[GitHub] trafficserver issue #826: TS-3620: Enable HTTP/2 by default

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/826
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/382/ 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-3620) Enable HTTP/2 by default

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Enable HTTP/2 by default
> 
>
> Key: TS-3620
> URL: https://issues.apache.org/jira/browse/TS-3620
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I think the consensus is that this should get controlled via normal 
> server_ports configuration. For 6.0.0, we'll make HTTP/2 "default" I'd 
> imagine if we have compiled in support for ALPN, and the TLS port is enabled.
> Someone would then just specify in server_ports to disable "h2", right ?



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

[GitHub] trafficserver issue #826: TS-3620: Enable HTTP/2 by default

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Updated] (TS-3620) Enable HTTP/2 by default

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3620:
---
Summary: Enable HTTP/2 by default  (was: Should we eliminate 
proxy.config.http2.enabled ?)

> Enable HTTP/2 by default
> 
>
> Key: TS-3620
> URL: https://issues.apache.org/jira/browse/TS-3620
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> I think the consensus is that this should get controlled via normal 
> server_ports configuration. For 6.0.0, we'll make HTTP/2 "default" I'd 
> imagine if we have compiled in support for ALPN, and the TLS port is enabled.
> Someone would then just specify in server_ports to disable "h2", right ?



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

[jira] [Work logged] (TS-3620) Enable HTTP/2 by default

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-3620: Enable HTTP/2 by default



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

$ git pull https://github.com/bryancall/trafficserver TS-3620

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

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


commit ead21d218f62695b520d779007c058edb289ebb6
Author: Bryan Call 
Date:   2016-07-26T14:14:22Z

TS-3620: Enable HTTP/2 by default




Issue Time Tracking
---

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

> Enable HTTP/2 by default
> 
>
> Key: TS-3620
> URL: https://issues.apache.org/jira/browse/TS-3620
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I think the consensus is that this should get controlled via normal 
> server_ports configuration. For 6.0.0, we'll make HTTP/2 "default" I'd 
> imagine if we have compiled in support for ALPN, and the TLS port is enabled.
> Someone would then just specify in server_ports to disable "h2", right ?



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

[GitHub] trafficserver pull request #826: TS-3620: Enable HTTP/2 by default

[bryancall]

GitHub user bryancall opened a pull request:

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

TS-3620: Enable HTTP/2 by default



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

$ git pull https://github.com/bryancall/trafficserver TS-3620

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

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


commit ead21d218f62695b520d779007c058edb289ebb6
Author: Bryan Call 
Date:   2016-07-26T14:14:22Z

TS-3620: Enable HTTP/2 by default




---
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-4694) Some refactoring after SPDY is removed

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba resolved TS-4694.
-
Resolution: Fixed

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



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

[jira] [Assigned] (TS-4694) Some refactoring after SPDY is removed

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba reassigned TS-4694:
---

Assignee: Masaori Koshiba  (was: Susan Hinrichs)

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



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

[jira] [Assigned] (TS-3620) Should we eliminate proxy.config.http2.enabled ?

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-3620:
--

Assignee: Bryan Call

> Should we eliminate proxy.config.http2.enabled ?
> 
>
> Key: TS-3620
> URL: https://issues.apache.org/jira/browse/TS-3620
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> I think the consensus is that this should get controlled via normal 
> server_ports configuration. For 6.0.0, we'll make HTTP/2 "default" I'd 
> imagine if we have compiled in support for ALPN, and the TLS port is enabled.
> Someone would then just specify in server_ports to disable "h2", right ?



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

[jira] [Created] (TS-4702) Reduce strlen() calls in LogAccessHttp::marshal_client_req_protocol_version()

[Masaori Koshiba (JIRA)]

Masaori Koshiba created TS-4702:
---

 Summary: Reduce strlen() calls in 
LogAccessHttp::marshal_client_req_protocol_version()
 Key: TS-4702
 URL: https://issues.apache.org/jira/browse/TS-4702
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: Masaori Koshiba


It is better to reduce strlen() calls in 
LogAccessHttp::marshal_client_req_protocol_version(). This is from [discussion 
on the Pull-Request for 
TS-4694|https://github.com/apache/trafficserver/pull/825#discussion_r72022413]



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

[jira] [Updated] (TS-4702) Reduce strlen() calls in LogAccessHttp::marshal_client_req_protocol_version()

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4702:

Fix Version/s: sometime

> Reduce strlen() calls in LogAccessHttp::marshal_client_req_protocol_version()
> -
>
> Key: TS-4702
> URL: https://issues.apache.org/jira/browse/TS-4702
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Masaori Koshiba
> Fix For: sometime
>
>
> It is better to reduce strlen() calls in 
> LogAccessHttp::marshal_client_req_protocol_version(). This is from 
> [discussion on the Pull-Request for 
> TS-4694|https://github.com/apache/trafficserver/pull/825#discussion_r72022413]



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

[GitHub] trafficserver pull request #825: TS-4694: Some refactoring after SPDY is rem...

[masaori335]

Github user masaori335 closed the pull request at:

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


---
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-4694) Some refactoring after SPDY is removed

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



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

[jira] [Work logged] (TS-4694) Some refactoring after SPDY is removed

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/825#discussion_r7506
  
--- Diff: proxy/ProxyClientTransaction.h ---
@@ -211,7 +211,11 @@ class ProxyClientTransaction : public VConnection
 
   virtual bool allow_half_open() const = 0;
 
-  virtual const char *get_protocol_string() const = 0;
+  virtual const char *
--- End diff --

Currently plugins can not set client_protocol of HttpSM ( which is going to 
be added by this patch ), but it could be set in the future. And it also has 
consistency for other stats in HttpSM (e.g. client_sec_protocol, 
client_cipher_suite). So, let's leave it string.

I'll file a new tickets for optimization.


Issue Time Tracking
---

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

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



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

[GitHub] trafficserver pull request #825: TS-4694: Some refactoring after SPDY is rem...

[masaori335]

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

https://github.com/apache/trafficserver/pull/825#discussion_r7506
  
--- Diff: proxy/ProxyClientTransaction.h ---
@@ -211,7 +211,11 @@ class ProxyClientTransaction : public VConnection
 
   virtual bool allow_half_open() const = 0;
 
-  virtual const char *get_protocol_string() const = 0;
+  virtual const char *
--- End diff --

Currently plugins can not set client_protocol of HttpSM ( which is going to 
be added by this patch ), but it could be set in the future. And it also has 
consistency for other stats in HttpSM (e.g. client_sec_protocol, 
client_cipher_suite). So, let's leave it string.

I'll file a new tickets for optimization.


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

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3474:


Cool

> 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] [Work logged] (TS-4694) Some refactoring after SPDY is removed

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/825
  
Looks good


Issue Time Tracking
---

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

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



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

[GitHub] trafficserver issue #825: TS-4694: Some refactoring after SPDY is removed

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/825
  
Looks good


---
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-4694) Some refactoring after SPDY is removed

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 26/Jul/16 07:28
Start Date: 26/Jul/16 07:28
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/825#discussion_r72200488
  
--- Diff: proxy/ProxyClientTransaction.h ---
@@ -211,7 +211,11 @@ class ProxyClientTransaction : public VConnection
 
   virtual bool allow_half_open() const = 0;
 
-  virtual const char *get_protocol_string() const = 0;
+  virtual const char *
--- End diff --

Can plugins set the string? If so, an enum would not suffice, right?


Issue Time Tracking
---

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

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



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

[GitHub] trafficserver pull request #825: TS-4694: Some refactoring after SPDY is rem...

[zwoop]

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

https://github.com/apache/trafficserver/pull/825#discussion_r72200488
  
--- Diff: proxy/ProxyClientTransaction.h ---
@@ -211,7 +211,11 @@ class ProxyClientTransaction : public VConnection
 
   virtual bool allow_half_open() const = 0;
 
-  virtual const char *get_protocol_string() const = 0;
+  virtual const char *
--- End diff --

Can plugins set the string? If so, an enum would not suffice, right?


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