[jira] [Commented] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4813:
---

Susan: You can login to the qa1 box, and run e.g.

$ cd /opt/ats.crash && gdb ./bin/traffic_server core.14958


For some reason, current master no longer produces core files on this box, but 
I saved the binaries and a few core files from before in that directory.

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Critical
>  Labels: crash
> Fix For: 7.0.0
>
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[jira] [Work logged] (TS-4851) Remove proxy.config.ssl.number.threads remnants.

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Remove proxy.config.ssl.number.threads remnants.
> 
>
> Key: TS-4851
> URL: https://issues.apache.org/jira/browse/TS-4851
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> TS-3046 left remnants of {{proxy.config.ssl.number.threads}} behind. We 
> should remove them to avoid any confusion.
> {noformat}
> angler:trafficserver.git jpeach$ git grep proxy.config.ssl.number.threads
> ci/jenkins/ats_conf.pl:$recedit->set(conf => 
> "proxy.config.ssl.number.threads", val => "8");
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> doc/admin-guide/files/records.config.en.rst:.. ts:cv:: CONFIG 
> proxy.config.ssl.number.threads INT -1
> lib/perl/lib/Apache/TS/AdminClient.pm: proxy.config.ssl.number.threads
> proxy/config/records.config.default.in:CONFIG proxy.config.ssl.number.threads 
> INT -1
> {noformat}



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

[GitHub] trafficserver issue #1011: TS-4851: Remove proxy.config.ssl.number.threads r...

[jpeach]

Github user jpeach commented on the issue:

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


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

[jira] [Created] (TS-4858) Global session ticket key block leaks.

[James Peach (JIRA)]

James Peach created TS-4858:
---

 Summary: Global session ticket key block leaks.
 Key: TS-4858
 URL: https://issues.apache.org/jira/browse/TS-4858
 Project: Traffic Server
  Issue Type: Bug
  Components: SSL
Reporter: James Peach


>From source inspection, ``global_default_keyblock`` is always assigned so it 
>will leak on configuration reload.

Have not reproduced this since I wasn't able to get SSL config reload to work 
:-(



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

[jira] [Comment Edited] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs edited comment on TS-4813 at 9/13/16 3:46 AM:
-

It would be interesting to dig through a core and see if the client session was 
HTTP/2.  It looks like producer_handler should deal with the timeout cases, but 
it does not appear to.  


was (Author: shinrich):
It would be interesting to dig through a core and see if the client session was 
HTTP/2.

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Critical
>  Labels: crash
> Fix For: 7.0.0
>
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[jira] [Commented] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4813:


It would be interesting to dig through a core and see if the client session was 
HTTP/2.

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Critical
>  Labels: crash
> Fix For: 7.0.0
>
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

Build failed in Jenkins: clang-analyzer #2629

[jenkins]

See 

Changes:

[James Peach] TS-4838: CONNECT requests get forgotten across threads.

--
[...truncated 5353 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 70%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 80%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading sources... [ 84%] developer-guide/documentation/building.en
reading sources... [ 84%] developer-guide/documentation/conventions.en
reading 

[jira] [Work logged] (TS-4769) TSSslServerContextCreate always returns null

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> TSSslServerContextCreate always returns null
> 
>
> Key: TS-4769
> URL: https://issues.apache.org/jira/browse/TS-4769
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL, TS API
>Reporter: Mathias Biilmann Christensen
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The change to SSLInitServerContext in 
> https://github.com/apache/trafficserver/pull/810 breaks the 
> TSSslServerContextCreate API method, since this one calls 
> TSSslServerContextCreate with an empty sslMultCertSettings.
> This means plugins can't create a fresh SSL context and set the certificates 
> themselves.



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

[GitHub] trafficserver pull request #975: TS-4769: TSSslServerContextCreate always re...

[shinrich]

Github user shinrich closed the pull request at:

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


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

[jira] [Created] (TS-4857) Memory leak in BaseLogFile.

[James Peach (JIRA)]

James Peach created TS-4857:
---

 Summary: Memory leak in BaseLogFile.
 Key: TS-4857
 URL: https://issues.apache.org/jira/browse/TS-4857
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Logging
Reporter: James Peach


Seeing these 2 leaks on startup:

{noformat}
leaks Report Version:  2.0
Process 63871: 8602 nodes malloced for 63738 KB
Process 63871: 2 leaks for 736 total leaked bytes.
Leak: 0x7f94696002d0  size=64  zone: DefaultMallocZone_0xc9ea000  length: 47  
has-length-byte:  "opt/ats/var/log/trafficserver/.traffic.out.meta"
Call stack: [thread 0x7fff7d0ce000]: | 0x8 | start | main Main.cc:1513 
| Diags::set_stdout_output(char const*) Diags.cc:787 | 
BaseLogFile::open_file(int) BaseLogFile.cc:320 | 
BaseMetaInfo::BaseMetaInfo(char const*) .BaseLogFile.h:109 | 
BaseMetaInfo::BaseMetaInfo(char const*) .BaseLogFile.h:108 | 
BaseMetaInfo::_build_name(char const*) BaseLogFile.cc:471 | ats_malloc 
ink_memory.cc:59 | malloc | malloc_zone_malloc
Leak: 0x7f9469600630  size=672  zone: DefaultMallocZone_0xc9ea000
0x696002d0 0x7f94 0x57d77387 0x ..`i.s.W
0x 0x 0x000b 0x61657200 .rea
0x6e6f6974 0x6d69745f 0x203d0065 0x33373431 tion_time.= 1473
0x36373337 0x3d003730 0x 0x 737607.=
0x 0x 0x 0x 
0x 0x 0x 0x 
0x 0x 0x 0x 
0x 0x 0x 0x 
...
Call stack: [thread 0x7fff7d0ce000]: | 0x8 | start | main Main.cc:1513 
| Diags::set_stdout_output(char const*) Diags.cc:787 | 
BaseLogFile::open_file(int) BaseLogFile.cc:320 | operator new(unsigned long) | 
malloc | malloc_zone_malloc
{noformat}



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

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

[jenkins]

See 


--
[...truncated 19455 lines...]
*** TEST 57 *** PASSED ***
*** TEST 58 *** STARTING ***
*** TEST 58 *** PASSED ***
*** TEST 59 *** STARTING ***
*** TEST 59 *** PASSED ***
*** TEST 60 *** STARTING ***
*** TEST 60 *** PASSED ***
*** TEST 61 *** STARTING ***
*** TEST 61 *** PASSED ***
*** TEST 62 *** STARTING ***
*** TEST 62 *** PASSED ***
*** TEST 63 *** STARTING ***
*** TEST 63 *** PASSED ***
*** TEST 64 *** STARTING ***
*** TEST 64 *** PASSED ***
*** TEST 65 *** STARTING ***
*** TEST 65 *** PASSED ***
*** TEST 66 *** STARTING ***
*** TEST 66 *** PASSED ***
*** TEST 67 *** STARTING ***
*** TEST 67 *** PASSED ***
*** TEST 68 *** STARTING ***
*** TEST 68 *** PASSED ***
*** TEST 69 *** STARTING ***
*** TEST 69 *** PASSED ***
*** TEST 70 *** STARTING ***
*** TEST 70 *** PASSED ***
*** TEST 71 *** STARTING ***
*** TEST 71 *** PASSED ***
*** TEST 72 *** STARTING ***
*** TEST 72 *** PASSED ***
*** TEST 73 *** STARTING ***
*** TEST 73 *** PASSED ***
*** TEST 74 *** STARTING ***
*** TEST 74 *** PASSED ***
*** TEST 75 *** STARTING ***
*** TEST 75 *** PASSED ***
*** TEST 76 *** STARTING ***
*** TEST 76 *** PASSED ***
*** TEST 77 *** STARTING ***
*** TEST 77 *** PASSED ***
*** TEST 78 *** STARTING ***
*** TEST 78 *** PASSED ***
*** TEST 79 *** STARTING ***
*** TEST 79 *** PASSED ***
*** TEST 80 *** STARTING ***
*** TEST 80 *** PASSED ***
*** TEST 81 *** STARTING ***
*** TEST 81 *** PASSED ***
*** TEST 82 *** STARTING ***
*** TEST 82 *** PASSED ***
*** TEST 83 *** STARTING ***
*** TEST 83 *** PASSED ***
*** TEST 84 *** STARTING ***
*** TEST 84 *** PASSED ***
*** TEST 85 *** STARTING ***
*** TEST 85 *** PASSED ***
*** TEST 86 *** STARTING ***
*** TEST 86 *** PASSED ***
*** TEST 87 *** STARTING ***
*** TEST 87 *** PASSED ***
*** TEST 88 *** STARTING ***
*** TEST 88 *** PASSED ***
*** TEST 89 *** STARTING ***
*** TEST 89 *** PASSED ***
*** TEST 90 *** STARTING ***
*** TEST 90 *** PASSED ***
*** TEST 91 *** STARTING ***
*** TEST 91 *** PASSED ***
*** TEST 92 *** STARTING ***
*** TEST 92 *** PASSED ***
*** TEST 93 *** STARTING ***
*** TEST 93 *** PASSED ***
*** TEST 94 *** STARTING ***
*** TEST 94 *** PASSED ***
*** TEST 95 *** STARTING ***
*** TEST 95 *** PASSED ***
*** TEST 96 *** STARTING ***
*** TEST 96 *** PASSED ***
*** TEST 97 *** STARTING ***
*** TEST 97 *** PASSED ***
*** TEST 98 *** STARTING ***
*** TEST 98 *** PASSED ***
*** TEST 99 *** STARTING ***
*** TEST 99 *** PASSED ***
*** TEST 100 *** STARTING ***
*** TEST 100 *** PASSED ***
*** TEST 101 *** STARTING ***
*** TEST 101 *** PASSED ***
*** TEST 102 *** STARTING ***
*** TEST 102 *** PASSED ***
*** TEST 103 *** STARTING ***
*** TEST 103 *** PASSED ***
*** TEST 104 *** STARTING ***
*** TEST 104 *** PASSED ***
*** TEST 105 *** STARTING ***
*** TEST 105 *** PASSED ***
*** TEST 106 *** STARTING ***
*** TEST 106 *** PASSED ***
*** TEST 107 *** STARTING ***
*** TEST 107 *** PASSED ***
*** TEST 108 *** STARTING ***
*** TEST 108 *** PASSED ***
*** TEST 109 *** STARTING ***
*** TEST 109 *** PASSED ***
*** TEST 110 *** STARTING ***
*** TEST 110 *** PASSED ***
*** TEST 111 *** STARTING ***
*** TEST 111 *** PASSED ***
*** TEST 112 *** STARTING ***
*** TEST 112 *** PASSED ***
*** TEST 113 *** STARTING ***
*** TEST 113 *** PASSED ***
*** TEST 114 *** STARTING ***
*** TEST 114 *** PASSED ***
*** TEST 115 *** STARTING ***
*** TEST 115 *** PASSED ***
*** TEST 116 *** STARTING ***
*** TEST 116 *** PASSED ***
*** TEST 117 *** STARTING ***
*** TEST 117 *** PASSED ***
*** TEST 118 *** STARTINREGRESSION_RESULT PARENTSELECTION:  
PASSED
REGRESSION_TEST DONE: PASSED
G ***
*** TEST 118 *** PASSED ***
*** TEST 119 *** STARTING ***
*** TEST 119 *** PASSED ***
*** TEST 120 *** STARTING ***
*** TEST 120 *** PASSED ***
*** TEST 121 *** STARTING ***
*** TEST 121 *** PASSED ***
*** TEST 122 *** STARTING ***
*** TEST 122 *** PASSED ***
*** TEST 123 *** STARTING ***
*** TEST 123 *** PASSED ***
*** TEST 124 *** STARTING ***
*** TEST 124 *** PASSED ***
*** TEST 125 *** STARTING ***
*** TEST 125 *** PASSED ***
*** TEST 126 *** STARTING ***
*** TEST 126 *** PASSED ***
*** TEST 127 *** STARTING ***
*** TEST 127 *** PASSED ***
*** TEST 128 *** STARTING ***
*** TEST 128 *** PASSED ***
*** TEST 129 *** STARTING ***
*** TEST 129 *** PASSED ***
*** TEST 130 *** STARTING ***
*** TEST 130 *** PASSED ***
*** TEST 131 *** STARTING ***
*** TEST 131 *** PASSED ***
*** TEST 132 *** STARTING ***
*** TEST 132 *** PASSED ***
*** TEST 133 *** STARTING ***
*** TEST 133 *** PASSED ***
*** TEST 134 *** STARTING ***
*** TEST 134 *** PASSED ***
*** TEST 135 *** STARTING ***
*** TEST 135 *** PASSED ***
*** TEST 136 *** STARTING ***
*** TEST 136 *** PASSED ***
*** TEST 137 *** STARTING ***
*** TEST 137 *** PASSED ***
*** TEST 138 *** STARTING ***
*** TEST 138 *** PASSED ***
*** TEST 139 *** STARTING ***
*** TEST 139 *** PASSED ***
*** TEST 140 

[jira] [Work logged] (TS-4851) Remove proxy.config.ssl.number.threads remnants.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove proxy.config.ssl.number.threads remnants.
> 
>
> Key: TS-4851
> URL: https://issues.apache.org/jira/browse/TS-4851
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> TS-3046 left remnants of {{proxy.config.ssl.number.threads}} behind. We 
> should remove them to avoid any confusion.
> {noformat}
> angler:trafficserver.git jpeach$ git grep proxy.config.ssl.number.threads
> ci/jenkins/ats_conf.pl:$recedit->set(conf => 
> "proxy.config.ssl.number.threads", val => "8");
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> doc/admin-guide/files/records.config.en.rst:.. ts:cv:: CONFIG 
> proxy.config.ssl.number.threads INT -1
> lib/perl/lib/Apache/TS/AdminClient.pm: proxy.config.ssl.number.threads
> proxy/config/records.config.default.in:CONFIG proxy.config.ssl.number.threads 
> INT -1
> {noformat}



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

[jira] [Work logged] (TS-4851) Remove proxy.config.ssl.number.threads remnants.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove proxy.config.ssl.number.threads remnants.
> 
>
> Key: TS-4851
> URL: https://issues.apache.org/jira/browse/TS-4851
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> TS-3046 left remnants of {{proxy.config.ssl.number.threads}} behind. We 
> should remove them to avoid any confusion.
> {noformat}
> angler:trafficserver.git jpeach$ git grep proxy.config.ssl.number.threads
> ci/jenkins/ats_conf.pl:$recedit->set(conf => 
> "proxy.config.ssl.number.threads", val => "8");
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> doc/admin-guide/files/records.config.en.rst:.. ts:cv:: CONFIG 
> proxy.config.ssl.number.threads INT -1
> lib/perl/lib/Apache/TS/AdminClient.pm: proxy.config.ssl.number.threads
> proxy/config/records.config.default.in:CONFIG proxy.config.ssl.number.threads 
> INT -1
> {noformat}



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

[GitHub] trafficserver issue #1011: TS-4851: Remove proxy.config.ssl.number.threads r...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1011
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/788/ 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 #1011: TS-4851: Remove proxy.config.ssl.number.threads r...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1011
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/684/ 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-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

[James Peach (JIRA)]

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

James Peach resolved TS-4838.
-
Resolution: Fixed

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver pull request #1002: TS-4838: CONNECT requests get forgotten ac...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4098) Remap filtering isn't working to only allow certain methods

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1010
  
@kawaiirice Can you please take a look at 
[this}(https://cwiki.apache.org/confluence/display/TS/CommitPolicies) and 
update the commit message accordingly? thanks


Issue Time Tracking
---

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

> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Limiting a remap rule to only use a certain methods doesn't work.  Also the 
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup 
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p 
> eN:tMc  i p sS])
> {code}



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

[GitHub] trafficserver issue #1010: [TS-4098]Fix remap filtering for nonstandard meth...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1010
  
@kawaiirice Can you please take a look at 
[this}(https://cwiki.apache.org/confluence/display/TS/CommitPolicies) and 
update the commit message accordingly? thanks


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

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

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-2987.

Resolution: Fixed

> 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
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> 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-4851) Remove proxy.config.ssl.number.threads remnants.

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4851: Remove proxy.config.ssl.number.threads remnants



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

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

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

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


commit 19bf6564349f6b59ce6d768e87dd3e8559f26950
Author: Susan Hinrichs 
Date:   2016-09-13T03:03:18Z

TS-4851: Remove proxy.config.ssl.number.threads remnants




Issue Time Tracking
---

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

> Remove proxy.config.ssl.number.threads remnants.
> 
>
> Key: TS-4851
> URL: https://issues.apache.org/jira/browse/TS-4851
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TS-3046 left remnants of {{proxy.config.ssl.number.threads}} behind. We 
> should remove them to avoid any confusion.
> {noformat}
> angler:trafficserver.git jpeach$ git grep proxy.config.ssl.number.threads
> ci/jenkins/ats_conf.pl:$recedit->set(conf => 
> "proxy.config.ssl.number.threads", val => "8");
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> ci/tsqa/tests/test_keepalive.py:
> cls.configs['records.config']['CONFIG']['proxy.config.ssl.number.threads'] = 
> -1
> doc/admin-guide/files/records.config.en.rst:.. ts:cv:: CONFIG 
> proxy.config.ssl.number.threads INT -1
> lib/perl/lib/Apache/TS/AdminClient.pm: proxy.config.ssl.number.threads
> proxy/config/records.config.default.in:CONFIG proxy.config.ssl.number.threads 
> INT -1
> {noformat}



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

[GitHub] trafficserver pull request #1011: TS-4851: Remove proxy.config.ssl.number.th...

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4851: Remove proxy.config.ssl.number.threads remnants



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

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

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

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


commit 19bf6564349f6b59ce6d768e87dd3e8559f26950
Author: Susan Hinrichs 
Date:   2016-09-13T03:03:18Z

TS-4851: Remove proxy.config.ssl.number.threads remnants




---
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: clang-analyzer #2628

[jenkins]

See 

Changes:

[Bryan Call] TS-4732: Changing the do_io_read API so it can be called with NULL 
and 0

[Phil Sorber] TS-4806: Add ability to pass a new stack to thread creation.

[Phil Sorber] TS-4806: Normalize stacksize

[Phil Sorber] TS-4806: Allocate thread stacks on corresponding NUMA nodes.

[Phil Sorber] TS-4806: Stop re-using main thread as net thread.

[Phil Sorber] TS-4806: Make stacks use huge pages if enabled.

--
[...truncated 5353 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 70%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 80%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading 

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28898)
Time Spent: 6h 20m  (was: 6h 10m)

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



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

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

[atsci]

Github user atsci commented on the issue:

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28897)
Time Spent: 6h 10m  (was: 6h)

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



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

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

[atsci]

Github user atsci commented on the issue:

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/833
  
@bryancall That's odd. I just rebased again but I don't see any problems.

> After removing TSUrlHttpQueryGet() from the plugin I am seeing many 
server pushes for the URL in the logs.

If you simply removed the line, this is understandable.  I guess the 
variable is not initialized and have some value other than 0. It triggers many 
server pushes, because the sample plugin is using query string length stored in 
the variable.


Issue Time Tracking
---

Worklog Id: (was: 28896)
Time Spent: 6h  (was: 5h 50m)

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



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

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

[maskit]

Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
@bryancall That's odd. I just rebased again but I don't see any problems.

> After removing TSUrlHttpQueryGet() from the plugin I am seeing many 
server pushes for the URL in the logs.

If you simply removed the line, this is understandable.  I guess the 
variable is not initialized and have some value other than 0. It triggers many 
server pushes, because the sample plugin is using query string length stored in 
the variable.


---
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-4806) Fix up event processor thread stacks

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 13/Sep/16 01:38
Start Date: 13/Sep/16 01:38
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

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


Issue Time Tracking
---

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

> Fix up event processor thread stacks
> 
>
> Key: TS-4806
> URL: https://issues.apache.org/jira/browse/TS-4806
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> Fix event processor to create stacks on the appropriate numa node and with 
> the appropriate page size. Also, stop using the main thread as ET_NET 0 since 
> we can't control any of these aspects of it.



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

[GitHub] trafficserver pull request #956: TS-4806: Fix up event processor thread stac...

[PSUdaemon]

Github user PSUdaemon closed the pull request at:

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


---
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 : ubuntu_16_04-master » clang,ubuntu_16_04,debug #342

[jenkins]

See 

[jira] [Resolved] (TS-4732) Still seeing VC errors on master

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4732.

Resolution: Fixed

> Still seeing VC errors on master
> 
>
> Key: TS-4732
> URL: https://issues.apache.org/jira/browse/TS-4732
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}



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

Build failed in Jenkins: clang-analyzer #2627

[jenkins]

See 

Changes:

[ppenkov] TS-4755: Header Frequency plugin. Initial version

[ppenkov] TS-4755: Custom log and locking added

[ppenkov] TS-4755: back to stdout, locking in TSContCreate

[ppenkov] TS-4755: Formatted with clang

--
[...truncated 5353 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 70%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 80%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading 

Build failed in Jenkins: ubuntu_16_04-master » clang,ubuntu_16_04,debug #341

[jenkins]

See 


--
[...truncated 20348 lines...]
*** TEST 56 *** STARTING ***
*** TEST 56 *** PASSED ***
*** TEST 57 *** STARTING ***
*** TEST 57 *** PASSED ***
*** TEST 58 *** STARTING ***
*** TEST 58 *** PASSED ***
*** TEST 59 *** STARTING ***
*** TEST 59 *** PASSED ***
*** TEST 60 *** STARTING ***
*** TEST 60 *** PASSED ***
*** TEST 61 *** STARTING ***
*** TEST 61 *** PASSED ***
*** TEST 62 *** STARTING ***
*** TEST 62 *** PASSED ***
*** TEST 63 *** STARTING ***
*** TEST 63 *** PASSED ***
*** TEST 64 *** STARTING ***
*** TEST 64 *** PASSED ***
*** TEST 65 *** STARTING ***
*** TEST 65 *** PASSED ***
*** TEST 66 *** STARTING ***
*** TEST 66 *** PASSED ***
*** TEST 67 *** STARTING ***
*** TEST 67 *** PASSED ***
*** TEST 68 *** STARTING ***
*** TEST 68 *** PASSED ***
*** TEST 69 *** STARTING ***
*** TEST 69 *** PASSED ***
*** TEST 70 *** STARTING ***
*** TEST 70 *** PASSED ***
*** TEST 71 *** STARTING ***
*** TEST 71 *** PASSED ***
*** TEST 72 *** STARTING ***
*** TEST 72 *** PASSED ***
*** TEST 73 *** STARTING ***
*** TEST 73 *** PASSED ***
*** TEST 74 *** STARTING ***
*** TEST 74 *** PASSED ***
*** TEST 75 *** STARTING ***
*** TEST 75 *** PASSED ***
*** TEST 76 *** STARTING ***
*** TEST 76 *** PASSED ***
*** TEST 77 *** STARTING ***
*** TEST 77 *** PASSED ***
*** TEST 78 *** STARTING ***
*** TEST 78 *** PASSED ***
*** TEST 79 *** STARTING ***
*** TEST 79 *** PASSED ***
*** TEST 80 *** STARTING ***
*** TEST 80 *** PASSED ***
*** TEST 81 *** STARTING ***
*** TEST 81 *** PASSED ***
*** TEST 82 *** STARTING ***
*** TEST 82 *** PASSED ***
*** TEST 83 *** STARTING ***
*** TEST 83 *** PASSED ***
*** TEST 84 *** STARTING ***
*** TEST 84 *** PASSED ***
*** TEST 85 *** STARTING ***
*** TEST 85 *** PASSED ***
*** TEST 86 *** STARTING ***
*** TEST 86 *** PASSED ***
*** TEST 87 *** STARTING ***
*** TEST 87 *** PASSED ***
*** TEST 88 *** STARTING ***
*** TEST 88 *** PASSED ***
*** TEST 89 *** STARTING ***
*** TEST 89 *** PASSED ***
*** TEST 90 *** STARTING ***
*** TEST 90 *** PASSED ***
*** TEST 91 *** STARTING ***
*** TEST 91 *** PASSED ***
*** TEST 92 *** STARTING ***
*** TEST 92 *** PASSED ***
*** TEST 93 *** STARTING ***
*** TEST 93 *** PASSED ***
*** TEST 94 *** STARTING ***
*** TEST 94 *** PASSED ***
*** TEST 95 *** STARTING ***
*** TEST 95 *** PASSED ***
*** TEST 96 *** STARTING ***
*** TEST 96 *** PASSED ***
*** TEST 97 *** STARTING ***
*** TEST 97 *** PASSED ***
*** TEST 98 *** STARTING ***
*** TEST 98 *** PASSED ***
*** TEST 99 *** STARTING ***
*** TEST 99 *** PASSED ***
*** TEST 100 *** STARTING ***
*** TEST 100 *** PASSED ***
*** TEST 101 *** STARTING ***
*** TEST 101 *** PASSED ***
*** TEST 102 *** STARTING ***
*** TEST 102 *** PASSED ***
*** TEST 103 *** STARTING ***
*** TEST 103 *** PASSED ***
*** TEST 104 *** STARTING ***
*** TEST 104 *** PASSED ***
*** TEST 105 *** STARTING ***
*** TEST 105 *** PASSED ***
*** TEST 106 *** STARTING ***
*** TEST 106 *** PASSED ***
*** TEST 107 *** STARTING ***
*** TEST 107 *** PASSED ***
*** TEST 108 *** STARTING ***
*** TEST 108 *** PASSED ***
*** TEST 109 *** STARTING ***
*** TEST 109 *** PASSED ***
*** TESTREGRESSION_RESULT PARENTSELECTION:  PASSED
REGRESSION_TEST DONE: FAILED
 110 *** STARTING ***
*** TEST 110 *** PASSED ***
*** TEST 111 *** STARTING ***
*** TEST 111 *** PASSED ***
*** TEST 112 *** STARTING ***
*** TEST 112 *** PASSED ***
*** TEST 113 *** STARTING ***
*** TEST 113 *** PASSED ***
*** TEST 114 *** STARTING ***
*** TEST 114 *** PASSED ***
*** TEST 115 *** STARTING ***
*** TEST 115 *** PASSED ***
*** TEST 116 *** STARTING ***
*** TEST 116 *** PASSED ***
*** TEST 117 *** STARTING ***
*** TEST 117 *** PASSED ***
*** TEST 118 *** STARTING ***
*** TEST 118 *** PASSED ***
*** TEST 119 *** STARTING ***
*** TEST 119 *** PASSED ***
*** TEST 120 *** STARTING ***
*** TEST 120 *** PASSED ***
*** TEST 121 *** STARTING ***
*** TEST 121 *** PASSED ***
*** TEST 122 *** STARTING ***
*** TEST 122 *** PASSED ***
*** TEST 123 *** STARTING ***
*** TEST 123 *** PASSED ***
*** TEST 124 *** STARTING ***
*** TEST 124 *** PASSED ***
*** TEST 125 *** STARTING ***
*** TEST 125 *** PASSED ***
*** TEST 126 *** STARTING ***
*** TEST 126 *** PASSED ***
*** TEST 127 *** STARTING ***
*** TEST 127 *** PASSED ***
*** TEST 128 *** STARTING ***
*** TEST 128 *** PASSED ***
*** TEST 129 *** STARTING ***
*** TEST 129 *** PASSED ***
*** TEST 130 *** STARTING ***
*** TEST 130 *** PASSED ***
*** TEST 131 *** STARTING ***
*** TEST 131 *** PASSED ***
*** TEST 132 *** STARTING ***
*** TEST 132 *** PASSED ***
*** TEST 133 *** STARTING ***
*** TEST 133 *** PASSED ***
*** TEST 134 *** STARTING ***
*** TEST 134 *** PASSED ***
*** TEST 135 *** STARTING ***
*** TEST 135 *** PASSED ***
*** TEST 136 *** STARTING ***
*** TEST 136 *** PASSED ***
*** TEST 137 *** STARTING ***
*** TEST 137 *** PASSED ***
*** TEST 138 *** STARTING ***
*** TEST 

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

[jenkins]

See 

[jira] [Work logged] (TS-4732) Still seeing VC errors on master

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 12/Sep/16 23:40
Start Date: 12/Sep/16 23:40
Worklog Time Spent: 10m 
  Work Description: Github user bryancall closed the pull request at:

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


Issue Time Tracking
---

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

> Still seeing VC errors on master
> 
>
> Key: TS-4732
> URL: https://issues.apache.org/jira/browse/TS-4732
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}



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

[GitHub] trafficserver pull request #857: TS-4732: Changing the do_io_read API so it ...

[bryancall]

Github user bryancall closed the pull request at:

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


---
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-4732) Still seeing VC errors on master

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/857
  
I am going to go with this right now and open a bug for disable_read() and 
disable_write()


Issue Time Tracking
---

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

> Still seeing VC errors on master
> 
>
> Key: TS-4732
> URL: https://issues.apache.org/jira/browse/TS-4732
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_read invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR: 
>  do_io_write invoked on closed vc 
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}



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

[GitHub] trafficserver issue #857: TS-4732: Changing the do_io_read API so it can be ...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/857
  
I am going to go with this right now and open a bug for disable_read() and 
disable_write()


---
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-4026) Remove clustering feature in 7.0.0 release

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/978
  
 - Looks good


Issue Time Tracking
---

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

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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

[GitHub] trafficserver issue #978: TS-4026: Disable clustering

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/978
  
👍 - 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] [Resolved] (TS-4755) Create a plugin that would count the frequency of headers

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4755.

Resolution: Fixed

> Create a plugin that would count the frequency of headers
> -
>
> Key: TS-4755
> URL: https://issues.apache.org/jira/browse/TS-4755
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Bryan Call
>Assignee: Petar Penkov
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Create a plugin that would count the frequency of headers.  Have separate 
> frequency counters for origin and client.



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

[jira] [Updated] (TS-4755) Create a plugin that would count the frequency of headers

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4755:
---
Fix Version/s: (was: 7.2.0)
   7.0.0

> Create a plugin that would count the frequency of headers
> -
>
> Key: TS-4755
> URL: https://issues.apache.org/jira/browse/TS-4755
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Bryan Call
>Assignee: Petar Penkov
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Create a plugin that would count the frequency of headers.  Have separate 
> frequency counters for origin and client.



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

[jira] [Work logged] (TS-4755) Create a plugin that would count the frequency of headers

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 12/Sep/16 23:32
Start Date: 12/Sep/16 23:32
Worklog Time Spent: 10m 
  Work Description: Github user bryancall closed the pull request at:

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


Issue Time Tracking
---

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

> Create a plugin that would count the frequency of headers
> -
>
> Key: TS-4755
> URL: https://issues.apache.org/jira/browse/TS-4755
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Bryan Call
>Assignee: Petar Penkov
> Fix For: 7.2.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Create a plugin that would count the frequency of headers.  Have separate 
> frequency counters for origin and client.



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

[GitHub] trafficserver pull request #877: TS-4755: Header Frequency plugin. Initial v...

[bryancall]

Github user bryancall closed the pull request at:

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


---
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 #769: TS 4593: Extend ip_allow.config to filter destinat...

[kawaiirice]

Github user kawaiirice commented on the issue:

https://github.com/apache/trafficserver/pull/769
  
What do you mean by fast accept check?


---
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 #1010: Fix remap filtering for nonstandard methods

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1010
  
Clang-forma, trailing white spaces here:

```C++
-} else {  
+} else {
```


---
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 #1010: Fix remap filtering for nonstandard methods

[atsci]

Github user atsci commented on the issue:

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/833
  
I had problems getting it to work.  I had problems with the plugin failing 
from TSUrlHttpQueryGet() in the plugin.  After removing TSUrlHttpQueryGet() 
from the plugin I am seeing many server plus for the URL in the logs.

However, I think it would be good to land and we can fix any problems 
before the 7.0.0 release is made.  


Issue Time Tracking
---

Worklog Id: (was: 28889)
Time Spent: 5h 50m  (was: 5h 40m)

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



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

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

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/833
  
I had problems getting it to work.  I had problems with the plugin failing 
from TSUrlHttpQueryGet() in the plugin.  After removing TSUrlHttpQueryGet() 
from the plugin I am seeing many server plus for the URL in the logs.

However, I think it would be good to land and we can fix any problems 
before the 7.0.0 release is made.  


---
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-4853) Parent Consistent Hash Selection - add parent selection URL and API.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Parent Consistent Hash Selection - add parent selection URL and API.
> 
>
> Key: TS-4853
> URL: https://issues.apache.org/jira/browse/TS-4853
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Peter Chou
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Add the ability (via TS and Lua APIs) to set an explicit parent selection URL 
> that will be used for parent consistent hash selection hashing.



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

[GitHub] trafficserver issue #1009: TS-4853 : Parent Consistent Hash Selection - add ...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1009
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/785/ 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-4853) Parent Consistent Hash Selection - add parent selection URL and API.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Parent Consistent Hash Selection - add parent selection URL and API.
> 
>
> Key: TS-4853
> URL: https://issues.apache.org/jira/browse/TS-4853
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Peter Chou
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add the ability (via TS and Lua APIs) to set an explicit parent selection URL 
> that will be used for parent consistent hash selection hashing.



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

[GitHub] trafficserver issue #1009: TS-4853 : Parent Consistent Hash Selection - add ...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1009
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/681/ 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 #1010: Fix remap filtering for nonstandard methods

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1010
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/682/ 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 #1010: Fix remap filtering for nonstandard methods

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1010
  
[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-4098) Remap filtering isn't working to only allow certain methods

[Quinn Lertratanakul (JIRA)]

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

Quinn Lertratanakul commented on TS-4098:
-

Fixed: https://github.com/apache/trafficserver/pull/1010

> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work.  Also the 
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup 
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p 
> eN:tMc  i p sS])
> {code}



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

[GitHub] trafficserver pull request #1010: Fix remap filtering for nonstandard method...

[kawaiirice]

GitHub user kawaiirice opened a pull request:

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

Fix remap filtering for nonstandard methods



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

$ git pull https://github.com/kawaiirice/trafficserver TS-4098

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

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


commit 1b6d1c5ca9ac8c0b8dde896913cc80195ebdcc98
Author: Quinn 
Date:   2016-09-12T23:04:33Z

Fix remap filtering for nonstandard methods




---
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 #769: TS 4593: Extend ip_allow.config to filter destinat...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/769
  
Where is the change that disables the fast accept check? That's needed or a 
deny can't be overridden by remap.


---
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 #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/769#discussion_r78470567
  
--- Diff: proxy/IPAllow.cc ---
@@ -190,9 +231,13 @@ IpAllow::BuildTable()
 }
 
 if (*line != '\0' && *line != '#') {
-  errPtr = parseConfigLine(line, _info, _allow_tags);
-
-  if (errPtr != NULL) {
+  if(strstr(line, ip_allow_dest_tags.match_ip) != NULL) {
--- End diff --

```
matcher_tags& allow_tags = strstr(line, ip_allow_dest_tags.match_ip) != 
NULL ? ip_allow_dest_tags : ip_allow_src_tags);
errPtr = parseConfigLine(line, _info, _tags);
```


---
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-4853) Parent Consistent Hash Selection - add parent selection URL and API.

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Parent Consistent Hash Selection - add parent selection URL and API.
> 
>
> Key: TS-4853
> URL: https://issues.apache.org/jira/browse/TS-4853
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Peter Chou
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add the ability (via TS and Lua APIs) to set an explicit parent selection URL 
> that will be used for parent consistent hash selection hashing.



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

[GitHub] trafficserver issue #1009: TS-4853 : Parent Consistent Hash Selection - add ...

[zwoop]

Github user zwoop commented on the issue:

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


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

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/769#discussion_r78470100
  
--- Diff: proxy/IPAllow.cc ---
@@ -153,6 +154,46 @@ IpAllow::Print()
   }
 }
   }
+  for (IpMap::iterator spot(_dest_map.begin()), limit(_dest_map.end()); 
spot != limit; ++spot) {
--- End diff --

Quinn will change this to be two calls to the same method, passing in the 
two maps.


---
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: clang-analyzer #2626

[jenkins]

See 

Changes:

[Bryan Call] TS-4767: Add warning for Linux AIO build option Fixed the #ifdef 
to be

--
[...truncated 5337 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 70%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 75%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 77%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 79%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading sources... [ 84%] developer-guide/documentation/building.en
reading sources... [ 84%] 

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28882)
Time Spent: 9h 40m  (was: 9.5h)

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



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

[GitHub] trafficserver issue #1007: TS-4703: Add API to retrieve client protocols

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1007
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/680/ 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-4703) Adds an API call to retrieve transaction protocol

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28881)
Time Spent: 9.5h  (was: 9h 20m)

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



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

[GitHub] trafficserver issue #1007: TS-4703: Add API to retrieve client protocols

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Commented] (TS-4856) Default SSL context fails to load.

[James Peach (JIRA)]

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

James Peach commented on TS-4856:
-

Hmm, I didn't realize that TS-4769 was still in review. This might be a 
duplicate of that.

> Default SSL context fails to load.
> --
>
> Key: TS-4856
> URL: https://issues.apache.org/jira/browse/TS-4856
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> This error message appears at startup:
> {noformat}
> [Sep 12 21:07:16.700] Server {0x7f98127d9780} ERROR: failed set default 
> context
> {noformat}
> Out of source context, this error is not especially grammatical.
> The problem seems to be a regression from TS-4671, since the default {{*}} 
> certificate fails to be constructed in {{SSLInitServerContext}} due to the 
> tunnel options check. The default context has neither a certificate nor a 
> tunnel option.
> AFAIK we still need a default certificate to make the TLS negotiation fail 
> when we don't get an actual certificate match.



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

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

[jenkins]

See 


Changes:

[Bryan Call] TS-4767: Add warning for Linux AIO build option Fixed the #ifdef 
to be

--
[...truncated 14485 lines...]

 real request (length=607)

GET http://people.netscape.com/jwz/hacks-1.gif HTTP/1.0
If-Modified-Since: Wednesday, 26-Feb-97 06:58:17 GMT; length=842
Referer: http://people.netscape.com/jwz/index.html
Proxy-Connection: Keep-Alive
User-Agent:  Mozilla/3.01 (X11; I; Linux 2.0.28 i586)
Pragma: no-cache
Host: people.netscape.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
X-1: blah
X-2: blah
X-3: blah
X-4: blah
X-5: blah
X-6: blah
X-7: blah
X-8: blah
X-9: blah
Pragma: no-cache
X-X-1: blah
X-X-2: blah
X-X-3: blah
X-X-4: blah
X-X-5: blah
X-X-6: blah
X-X-7: blah
X-X-8: blah
X-X-9: blah



[GET http://people.netscape.com/jwz/hacks-1.gif HTTP/1.0
If-Modified-Since: Wednesday, 26-Feb-97 06:58:17 GMT; length=842
Referer: http://people.netscape.com/jwz/index.html
Proxy-Connection: Keep-Alive
User-Agent:  Mozilla/3.01 (X11; I; Linux 2.0.28 i586)
Pragma: no-cache
Host: people.netscape.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
X-1: blah
X-2: blah
X-3: blah
X-4: blah
X-5: blah
X-6: blah
X-7: blah
X-8: blah
X-9: blah
Pragma: no-cache
X-X-1: blah
X-X-2: blah
X-X-3: blah
X-X-4: blah
X-X-5: blah
X-X-6: blah
X-X-7: blah
X-X-8: blah
X-X-9: blah

]


 real response (length=163)

HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT



[HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

 real request (length=123)

GET http://www.padding.com:80/ HTTP/1.0
X-1: blah1
X-3:   blah3
X-5: blah5
X-7:   blah7
X-9: blah9



[GET http://www.padding.com:80/ HTTP/1.0
X-1: blah1
X-3:   blah3
X-5: blah5
X-7: blah7
X-9: blah9

]


 real response (length=163)

HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT



[HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

 real request (length=56)

GET http://www.news.com/ HTTP/1.1
Connection: close



[GET http://www.news.com/ HTTP/1.1
Connection: close

]


 real response (length=163)

HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT



[HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(cache) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(cache) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Release) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Release) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Set) still in progress
Regression 

[GitHub] trafficserver issue #1007: TS-4703: Add API to retrieve client protocols

[zwoop]

Github user zwoop commented on the issue:

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


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

Worklog Id: (was: 28879)
Time Spent: 9h 20m  (was: 9h 10m)

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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



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

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

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1000
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/679/ 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-4856) Default SSL context fails to load.

[James Peach (JIRA)]

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

James Peach updated TS-4856:

Fix Version/s: 7.0.0

> Default SSL context fails to load.
> --
>
> Key: TS-4856
> URL: https://issues.apache.org/jira/browse/TS-4856
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> This error message appears at startup:
> {noformat}
> [Sep 12 21:07:16.700] Server {0x7f98127d9780} ERROR: failed set default 
> context
> {noformat}
> Out of source context, this error is not especially grammatical.
> The problem seems to be a regression from TS-4671, since the default {{*}} 
> certificate fails to be constructed in {{SSLInitServerContext}} due to the 
> tunnel options check. The default context has neither a certificate nor a 
> tunnel option.
> AFAIK we still need a default certificate to make the TLS negotiation fail 
> when we don't get an actual certificate match.



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

[jira] [Updated] (TS-4856) Default SSL context fails to load.

[James Peach (JIRA)]

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

James Peach updated TS-4856:

Assignee: Susan Hinrichs

> Default SSL context fails to load.
> --
>
> Key: TS-4856
> URL: https://issues.apache.org/jira/browse/TS-4856
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> This error message appears at startup:
> {noformat}
> [Sep 12 21:07:16.700] Server {0x7f98127d9780} ERROR: failed set default 
> context
> {noformat}
> Out of source context, this error is not especially grammatical.
> The problem seems to be a regression from TS-4671, since the default {{*}} 
> certificate fails to be constructed in {{SSLInitServerContext}} due to the 
> tunnel options check. The default context has neither a certificate nor a 
> tunnel option.
> AFAIK we still need a default certificate to make the TLS negotiation fail 
> when we don't get an actual certificate match.



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

Build failed in Jenkins: clang-analyzer #2625

[jenkins]

See 

Changes:

[shinrich] TS-4831: Fix HTTP/2 update_read_request crash.

[James Peach] Tidy up some comments and whitespace.

[James Peach] Improve clang-format for static arrays.

--
[...truncated 5337 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 70%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 75%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 77%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 79%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading sources... [ 84%] 

[jira] [Created] (TS-4856) Default SSL context fails to load.

[James Peach (JIRA)]

James Peach created TS-4856:
---

 Summary: Default SSL context fails to load.
 Key: TS-4856
 URL: https://issues.apache.org/jira/browse/TS-4856
 Project: Traffic Server
  Issue Type: Bug
  Components: SSL
Reporter: James Peach


This error message appears at startup:
{noformat}
[Sep 12 21:07:16.700] Server {0x7f98127d9780} ERROR: failed set default context
{noformat}

Out of source context, this error is not especially grammatical.

The problem seems to be a regression from TS-4671, since the default {{*}} 
certificate fails to be constructed in {{SSLInitServerContext}} due to the 
tunnel options check. The default context has neither a certificate nor a 
tunnel option.

AFAIK we still need a default certificate to make the TLS negotiation fail when 
we don't get an actual certificate match.



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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



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

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

[atsci]

Github user atsci commented on the issue:

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834
  
@jrushford -- Added regression test cases for "-R3 -r PARENTSELECTION".


Issue Time Tracking
---

Worklog Id: (was: 28874)
Time Spent: 11h 10m  (was: 11h)

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



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

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

[pbchou]

Github user pbchou commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@jrushford -- Added regression test cases for "-R3 -r PARENTSELECTION".


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1007
  
Don't know why the linux build failed.  Complained about a signed mismatch 
warning/error in a file that hasn't changed.

 CC   TsConfigSyntax.lo
TsConfigSyntax.c: In function 'tsconfig_scan_bytes':
TsConfigSyntax.c:1714:17: error: comparison between signed and unsigned 
integer expressions [-Werror=sign-compare]
  for ( i = 0; i < _yybytes_len; ++i )
 ^


Issue Time Tracking
---

Worklog Id: (was: 28873)
Time Spent: 9h 10m  (was: 9h)

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



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

[GitHub] trafficserver issue #1007: TS-4703: Add API to retrieve client protocols

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1007
  
Don't know why the linux build failed.  Complained about a signed mismatch 
warning/error in a file that hasn't changed.

 CC   TsConfigSyntax.lo
TsConfigSyntax.c: In function 'tsconfig_scan_bytes':
TsConfigSyntax.c:1714:17: error: comparison between signed and unsigned 
integer expressions [-Werror=sign-compare]
  for ( i = 0; i < _yybytes_len; ++i )
 ^


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1000
  
Pushed new version to address the case insensitive name comparison.


Issue Time Tracking
---

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

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



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

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

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1000
  
Pushed new version to address the case insensitive name comparison.


---
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 #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/769#discussion_r78457571
  
--- Diff: proxy/IPAllow.cc ---
@@ -271,10 +316,16 @@ IpAllow::BuildTable()
   }
 
   if (method_found) {
-_acls.push_back(AclRecord(acl_method_mask, line_num, 
nonstandard_methods, deny_nonstandard_methods));
-// Color with index because at this point the address
-// is volatile.
-_map.fill(, , reinterpret_cast(_acls.length() - 1));
+if(is_dest_ip) {
+  _dest_acls.push_back(AclRecord(acl_method_mask, line_num, 
nonstandard_methods, deny_nonstandard_methods));
--- End diff --

These cases should be more compact by selecting the map then applying the 
fill.
```
Vec& acls = is_dest_ip ? _dest_acls : _src_acls;
IpMap& map = is_dest_ip ? _dest_map : _src_map;
acls.push_back(AclRecord(acl_method_mask, line_num, nonstandard_methods, 
deny_nonstandard_methods));
map.fill(, , reinterpret_cast(_dest_acls.length() - 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.
---

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

[jenkins]

See 


Changes:

[shinrich] TS-4831: Fix HTTP/2 update_read_request crash.

[James Peach] Tidy up some comments and whitespace.

[James Peach] Improve clang-format for static arrays.

--
[...truncated 2456 lines...]
Making install in buffer_upload
 ../../../../build/_aux/install-sh -c -d 
'
 /bin/sh ../../../libtool   --mode=install /usr/bin/install -c   
buffer_upload.la 
'
libtool: install: /usr/bin/install -c .libs/buffer_upload.so 

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

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

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

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

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

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

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

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

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 

[jira] [Work logged] (TS-4831) HTTP/2 update_read_request crash

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> HTTP/2 update_read_request crash
> 
>
> Key: TS-4831
> URL: https://issues.apache.org/jira/browse/TS-4831
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Crash we have seen in production with our version of ATS.
> {code}
> gdb) bt
> #0  0x0051579a in Mutex_lock (m=0x0, t=0x2ab3039f8010) at 
> ../iocore/eventsystem/I_Lock.h:380
> #1  0x0053d422 in MutexLock::MutexLock (this=0x2ab30a053500, am=0x0, 
> t=0x2ab3039f8010) at ../iocore/eventsystem/I_Lock.h:447
> #2  0x00653f15 in Http2Stream::update_read_request 
> (this=0x2ab448582c60, read_len=9223372036854775807, call_update=true) at 
> Http2Stream.cc:420
> #3  0x0064d579 in rcv_data_frame (cs=..., cstate=..., frame=...) at 
> Http2ConnectionState.cc:145
> #4  0x0064fd8f in Http2ConnectionState::main_event_handler 
> (this=0x2ab47d30ae10, event=2253, edata=0x2ab30a055830)
> at Http2ConnectionState.cc:753
> #5  0x00515958 in Continuation::handleEvent (this=0x2ab47d30ae10, 
> event=2253, data=0x2ab30a055830)
> at ../iocore/eventsystem/I_Continuation.h:150
> #6  0x00649f09 in send_connection_event (cont=0x2ab47d30ae10, 
> event=2253, edata=0x2ab30a055830) at Http2ClientSession.cc:60
> #7  0x0064c2a5 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ab47d30abd0, event=100, edata=0x2ab4dc3469e0)
> at Http2ClientSession.cc:478
> #8  0x0064b03f in Http2ClientSession::main_event_handler 
> (this=0x2ab47d30abd0, event=100, edata=0x2ab4dc3469e0) at 
> Http2ClientSession.cc:292
> #9  0x00515958 in Continuation::handleEvent (this=0x2ab47d30abd0, 
> event=100, data=0x2ab4dc3469e0) at ../iocore/eventsystem/I_Continuation.h:150
> #10 0x0064bfed in Http2ClientSession::state_start_frame_read 
> (this=0x2ab47d30abd0, event=100, edata=0x2ab4dc3469e0)
> at Http2ClientSession.cc:451
> #11 0x0064b03f in Http2ClientSession::main_event_handler 
> (this=0x2ab47d30abd0, event=100, edata=0x2ab4dc3469e0) at 
> Http2ClientSession.cc:292
> #12 0x00515958 in Continuation::handleEvent (this=0x2ab47d30abd0, 
> event=100, data=0x2ab4dc3469e0) at ../iocore/eventsystem/I_Continuation.h:150
> #13 0x00786a49 in read_signal_and_update (event=100, 
> vc=0x2ab4dc3468c0) at UnixNetVConnection.cc:148
> #14 0x00789866 in UnixNetVConnection::readSignalAndUpdate 
> (this=0x2ab4dc3468c0, event=100) at UnixNetVConnection.cc:1013
> #15 0x0076e2bb in SSLNetVConnection::net_read_io 
> (this=0x2ab4dc3468c0, nh=0x2ab3039fbe00, lthread=0x2ab3039f8010) at 
> SSLNetVConnection.cc:576
> #16 0x00780465 in NetHandler::waitForActivity (this=0x2ab3039fbe00, 
> timeout=6000) at UnixNet.cc:546
> #17 0x007a7f6d in EThread::execute_regular (this=0x2ab3039f8010) at 
> UnixEThread.cc:266
> #18 0x007a80b0 in EThread::execute (this=0x2ab3039f8010) at 
> UnixEThread.cc:304
> #19 0x007a6c69 in spawn_thread_internal (a=0x157b530) at Thread.cc:85
> #20 0x2ab302293aa1 in start_thread () from /lib64/libpthread.so.0
> #21 0x003ab7ee893d in clone () from /lib64/libc.so.6
> {code}
> The read_vio has a NULL mutex and all the other values are 0 as well.  It 
> looks as if do_io_read(NULL, 0, NULL) was called on the stream.  Some places 
> in Http2Stream we check that read_vio.mutex is NULL before trying to access 
> it, but not all.  
> Should probably add similar NULL checks for write_vio.mutex.



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1000#discussion_r78455353
  
--- Diff: proxy/http/HttpSessionManager.cc ---
@@ -98,7 +113,10 @@ ServerSessionPool::acquireSession(sockaddr const *addr, 
INK_MD5 const _
 // Otherwise we need to scan further matches to match the host name as 
well.
 // Note we don't have to check the port because it's checked as part 
of the IP address key.
 if (TS_SERVER_SESSION_SHARING_MATCH_IP != match_style) {
-  while (loc && loc->hostname_hash != hostname_hash) {
+  while (loc) {
+if (loc->hostname_hash == hostname_hash && match_sni(sm, 
loc->get_netvc())) {
--- End diff --

The original patch did not have match_sni.   But the code was cut-n-pasted 
several places.  I'd rather not pollute the caller with more details.  Could 
change the function name to be less confusion.  Like match_sni_if_needed.


Issue Time Tracking
---

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

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



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

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

[shinrich]

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

https://github.com/apache/trafficserver/pull/1000#discussion_r78455353
  
--- Diff: proxy/http/HttpSessionManager.cc ---
@@ -98,7 +113,10 @@ ServerSessionPool::acquireSession(sockaddr const *addr, 
INK_MD5 const _
 // Otherwise we need to scan further matches to match the host name as 
well.
 // Note we don't have to check the port because it's checked as part 
of the IP address key.
 if (TS_SERVER_SESSION_SHARING_MATCH_IP != match_style) {
-  while (loc && loc->hostname_hash != hostname_hash) {
+  while (loc) {
+if (loc->hostname_hash == hostname_hash && match_sni(sm, 
loc->get_netvc())) {
--- End diff --

The original patch did not have match_sni.   But the code was cut-n-pasted 
several places.  I'd rather not pollute the caller with more details.  Could 
change the function name to be less confusion.  Like match_sni_if_needed.


---
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 #994: TS-4831: Fix HTTP/2 update_read_request cra...

[shinrich]

Github user shinrich closed the pull request at:

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


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834
  
@pbchou, thanks i look at this and get an API review started.


Issue Time Tracking
---

Worklog Id: (was: 28869)
Time Spent: 11h  (was: 10h 50m)

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



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

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

[jrushford]

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@pbchou, thanks i look at this and get an API review started.


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1000#discussion_r78454974
  
--- Diff: proxy/http/HttpSessionManager.cc ---
@@ -75,17 +75,32 @@ ServerSessionPool::match(HttpServerSession *ss, 
sockaddr const *addr, INK_MD5 co
  (TS_SERVER_SESSION_SHARING_MATCH_HOST == match_style || 
ats_ip_addr_port_eq(ss->get_server_ip(), addr));
 }
 
+bool
+ServerSessionPool::match_sni(HttpSM *sm, NetVConnection *netvc)
+{
+  // TS-4468: If the connection matches, make sure the SNI server
+  // name (if present) matches the request hostname
+  int len = 0;
+  const char *req_host= 
sm->t_state.hdr_info.server_request.host_get();
+  const char *session_sni = netvc->options.sni_servername;
+
+  return ((sm->t_state.scheme != URL_WKSIDX_HTTPS) || !session_sni || 
!strncmp(session_sni, req_host, len));
--- End diff --

If the scheme is not https, there is no need to do the SNI check.  
Agreed, might as well do a case insensitive compare here.


Issue Time Tracking
---

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

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



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

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

[shinrich]

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

https://github.com/apache/trafficserver/pull/1000#discussion_r78454974
  
--- Diff: proxy/http/HttpSessionManager.cc ---
@@ -75,17 +75,32 @@ ServerSessionPool::match(HttpServerSession *ss, 
sockaddr const *addr, INK_MD5 co
  (TS_SERVER_SESSION_SHARING_MATCH_HOST == match_style || 
ats_ip_addr_port_eq(ss->get_server_ip(), addr));
 }
 
+bool
+ServerSessionPool::match_sni(HttpSM *sm, NetVConnection *netvc)
+{
+  // TS-4468: If the connection matches, make sure the SNI server
+  // name (if present) matches the request hostname
+  int len = 0;
+  const char *req_host= 
sm->t_state.hdr_info.server_request.host_get();
+  const char *session_sni = netvc->options.sni_servername;
+
+  return ((sm->t_state.scheme != URL_WKSIDX_HTTPS) || !session_sni || 
!strncmp(session_sni, req_host, len));
--- End diff --

If the scheme is not https, there is no need to do the SNI check.  
Agreed, might as well do a case insensitive compare 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-4703) Adds an API call to retrieve transaction protocol

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28867)
Time Spent: 9h  (was: 8h 50m)

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



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

[GitHub] trafficserver issue #1007: TS-4703: Add API to retrieve client protocols

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1007
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/782/ 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.
---