[GitHub] trafficserver issue #801: TS-4664: Fix crash by unifying event handlers for ...

2016-07-17 Thread jpeach
Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/801
  
I had to re-read this code to refresh my memory on how this works. I think 
that the invariant that the ``ProxyClientSession`` requires is that the API 
hooks are the first and last operations performed on the session. This means 
that the handler must be ``NULL`` when delivering the ``SSN_START`` event 
(which is always true because this is done before ``start()``). It also means 
that we should not have to worry about other event handlers when delivering 
``SSN_CLOSE``, because the only ``destroy()`` happens after this.

I agree that ``state_api_callout`` should not be virtual (it should be 
private).


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
> What do you think of a future feature (config) to disable this Via 
checking completely? If I know there's not chance of a loop, why bother 
checking the Via header?

@zwoop, makes sense. Should I create new jira for this?


Issue Time Tracking
---

Worklog Id: (was: 25613)
Time Spent: 3h 40m  (was: 3.5h)

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Work logged] (TS-4664) Crash due to separate event handlers for IO events and plugin events for ClientSession

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/801
  
I had to re-read this code to refresh my memory on how this works. I think 
that the invariant that the ``ProxyClientSession`` requires is that the API 
hooks are the first and last operations performed on the session. This means 
that the handler must be ``NULL`` when delivering the ``SSN_START`` event 
(which is always true because this is done before ``start()``). It also means 
that we should not have to worry about other event handlers when delivering 
``SSN_CLOSE``, because the only ``destroy()`` happens after this.

I agree that ``state_api_callout`` should not be virtual (it should be 
private).


Issue Time Tracking
---

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

> Crash due to separate event handlers for IO events and plugin events for 
> ClientSession
> --
>
> Key: TS-4664
> URL: https://issues.apache.org/jira/browse/TS-4664
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Found while tracking TS-4507 and original fix on that branch.
> Cleaned up handling regular events at the same time as plugin events. The 
> original code relied on the subclasses overriding handle_api_event to handle 
> the regular events, but the handler only handled the TIMEOUT event. Changed 
> that to augment the subclasses' main event handler to call out to 
> state_api_callout in the event of the plugin events.



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread yatsukhnenko
Github user yatsukhnenko commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
> What do you think of a future feature (config) to disable this Via 
checking completely? If I know there's not chance of a loop, why bother 
checking the Via header?

@zwoop, makes sense. Should I create new jira for this?


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


[jira] [Created] (TS-4670) Document SSL lifecycle hooks

2016-07-17 Thread James Peach (JIRA)
James Peach created TS-4670:
---

 Summary: Document SSL lifecycle hooks
 Key: TS-4670
 URL: https://issues.apache.org/jira/browse/TS-4670
 Project: Traffic Server
  Issue Type: Improvement
  Components: Documentation
Reporter: James Peach


The lifecycle hooks are documented in {{TSLifecycleHookAdd.en.rst}}. There are 
a few undocumented hooks:

* TS_LIFECYCLE_SERVER_SSL_CTX_INITIALIZED_HOOK
* TS_LIFECYCLE_CLIENT_SSL_CTX_INITIALIZED_HOOK




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


[jira] [Work logged] (TS-4583) CID 1021958: Null-pointer dereference after check

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/802
  
I don't think this change is correct. It seems to me that the invariant is 
that ``server_session`` and ``server_entry`` should be NULL or non-NULL 
together. So if we call ``release_server_session()`` when ``server_entry`` is 
NULL, we ought to hit the NULL check on ``server_session`` as well.


Issue Time Tracking
---

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

> CID 1021958: Null-pointer dereference after check
> -
>
> Key: TS-4583
> URL: https://issues.apache.org/jira/browse/TS-4583
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, 
> before calling release_server_session(), which dereferences server_entry.



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


[GitHub] trafficserver issue #802: TS-4583: Null-pointer dereference after check

2016-07-17 Thread jpeach
Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/802
  
I don't think this change is correct. It seems to me that the invariant is 
that ``server_session`` and ``server_entry`` should be NULL or non-NULL 
together. So if we call ``release_server_session()`` when ``server_entry`` is 
NULL, we ought to hit the NULL check on ``server_session`` as well.


---
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-4669) HttpSM should use hsm_release_assert consistently

2016-07-17 Thread James Peach (JIRA)

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

James Peach commented on TS-4669:
-

Also, add {{hsm_assert}} to use instead of {{ink_assert}}.

> HttpSM should use hsm_release_assert consistently
> -
>
> Key: TS-4669
> URL: https://issues.apache.org/jira/browse/TS-4669
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>
> {{hsm_release_assert}} dumps the internal state of the {{HttpSM}} object. 
> Everywhere there is a {{ink_release_assert}}, we really ought to be using 
> {{hsm_release_assert}}.



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


[jira] [Created] (TS-4669) HttpSM should use hsm_release_assert consistently

2016-07-17 Thread James Peach (JIRA)
James Peach created TS-4669:
---

 Summary: HttpSM should use hsm_release_assert consistently
 Key: TS-4669
 URL: https://issues.apache.org/jira/browse/TS-4669
 Project: Traffic Server
  Issue Type: Bug
  Components: Cleanup, Core
Reporter: James Peach


{{hsm_release_assert}} dumps the internal state of the {{HttpSM}} object. 
Everywhere there is a {{ink_release_assert}}, we really ought to be using 
{{hsm_release_assert}}.



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


[GitHub] trafficserver issue #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread jpeach
Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/805
  
This follows the pattern of the other APIs, but I notice the initialization 
is not thread safe. Shall we file a separate JIRA for that?


---
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-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/805
  
This follows the pattern of the other APIs, but I notice the initialization 
is not thread safe. Shall we file a separate JIRA for that?


Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[jira] [Work logged] (TS-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/805
  
The documentation for this API family is in 
{{doc/developer-guide/api/functions/TSInstallDirGet.en.rst}}, Just mention the 
new API there.


Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[GitHub] trafficserver issue #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread jpeach
Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/805
  
The documentation for this API family is in 
{{doc/developer-guide/api/functions/TSInstallDirGet.en.rst}}, Just mention the 
new API there.


---
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 #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
Did a quick test of this, and it looks good:

Via: http/1.1 fedora.ogre.com[f6f5162d-5a02-4d10-ac6e-35aede508fe5] 
(ApacheTrafficServer/7.0.0)



---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
Did a quick test of this, and it looks good:

Via: http/1.1 fedora.ogre.com[f6f5162d-5a02-4d10-ac6e-35aede508fe5] 
(ApacheTrafficServer/7.0.0)



Issue Time Tracking
---

Worklog Id: (was: 25609)
Time Spent: 3.5h  (was: 3h 20m)

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/337/ 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 #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/443/ 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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
@yatsukhnenko What do you think of a future feature (config) to disable 
this Via checking completely? If I know there's not chance of a loop, why 
bother checking the Via header? I guess one could just nuke the Via header on 
the incoming request, but there might be other reasons to keep it?

This is completely unrelated to this PR though, just thinking out loud.


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
@yatsukhnenko What do you think of a future feature (config) to disable 
this Via checking completely? If I know there's not chance of a loop, why 
bother checking the Via header? I guess one could just nuke the Via header on 
the incoming request, but there might be other reasons to keep it?

This is completely unrelated to this PR though, just thinking out loud.


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
I checked the core on this FreeBSD build, and it seems completely unrelated 
to pretty much anything :).

```
(gdb) bt
#0  0x in ?? ()
#1  0x006ec34a in EThread::process_event (this=0x804107000, 
e=0x803f2c880, calling_code=) at I_Continuation.h:153
#2  0x006ec8ec in EThread::execute (this=0x804107000) at 
../../../iocore/eventsystem/UnixEThread.cc:245
#3  0x006ebb82 in spawn_thread_internal (a=0x803ef5700) at 
../../../iocore/eventsystem/Thread.cc:84
#4  0x0008027514f5 in pthread_create () from /lib/libthr.so.3
#5  0x in ?? ()
```


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
I checked the core on this FreeBSD build, and it seems completely unrelated 
to pretty much anything :).

```
(gdb) bt
#0  0x in ?? ()
#1  0x006ec34a in EThread::process_event (this=0x804107000, 
e=0x803f2c880, calling_code=) at I_Continuation.h:153
#2  0x006ec8ec in EThread::execute (this=0x804107000) at 
../../../iocore/eventsystem/UnixEThread.cc:245
#3  0x006ebb82 in spawn_thread_internal (a=0x803ef5700) at 
../../../iocore/eventsystem/Thread.cc:84
#4  0x0008027514f5 in pthread_create () from /lib/libthr.so.3
#5  0x in ?? ()
```


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom commented on TS-4624:
---

Any objections / concerns on landing this ? We should document this properly 
for the 7.0.0 release notes as well ([~bcall]).

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
I suspect this failed for other reasons, trying again [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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
I suspect this failed for other reasons, trying again [approve ci].


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


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

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

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



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


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

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

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



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


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

2016-07-17 Thread atsci
Github user atsci commented on the issue:

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

2016-07-17 Thread atsci
Github user atsci commented on the issue:

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



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


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

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/798
  
@zwoop , i just did the cleanup. Good to merge?


Issue Time Tracking
---

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

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



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


[GitHub] trafficserver pull request #798: TS-4653: esi plugin - disable HTTP_COOKIE v...

2016-07-17 Thread shukitchan
Github user shukitchan commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/798#discussion_r71086266
  
--- Diff: plugins/experimental/esi/esi.cc ---
@@ -61,6 +61,7 @@ struct OptionInfo {
 };
 
 static HandlerManager *gHandlerManager = NULL;
+static Utils::HeaderValueList gWhitelistCookies;
--- End diff --

yeah... i can clean it up later on


---
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 #798: TS-4653: esi plugin - disable HTTP_COOKIE variable...

2016-07-17 Thread shukitchan
Github user shukitchan commented on the issue:

https://github.com/apache/trafficserver/pull/798
  
@zwoop , i just did the cleanup. Good to merge?


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


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

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/798#discussion_r71086266
  
--- Diff: plugins/experimental/esi/esi.cc ---
@@ -61,6 +61,7 @@ struct OptionInfo {
 };
 
 static HandlerManager *gHandlerManager = NULL;
+static Utils::HeaderValueList gWhitelistCookies;
--- End diff --

yeah... i can clean it up later on


Issue Time Tracking
---

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

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



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/335/ 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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 25593)
Time Spent: 2.5h  (was: 2h 20m)

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/441/ 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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
[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 #804: TS-4624: use the server UUID in the Via hea...

2016-07-17 Thread yatsukhnenko
Github user yatsukhnenko commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/804#discussion_r71085622
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

done :)


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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804#discussion_r71085622
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

done :)


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804#discussion_r71085418
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

Yeah nuke it IMO. The Machine UUID is guaranteed to be initiated on startup.


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver pull request #804: TS-4624: use the server UUID in the Via hea...

2016-07-17 Thread zwoop
Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/804#discussion_r71085418
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

Yeah nuke it IMO. The Machine UUID is guaranteed to be initiated on startup.


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
Thanks for explaining about API usage


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread yatsukhnenko
Github user yatsukhnenko commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
Thanks for explaining about API usage


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804#discussion_r71084817
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

Reinsurance :) Shoul I delete this check?


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver pull request #804: TS-4624: use the server UUID in the Via hea...

2016-07-17 Thread yatsukhnenko
Github user yatsukhnenko commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/804#discussion_r71084817
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

Reinsurance :) Shoul I delete this 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.
---


[jira] [Work logged] (TS-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/805
  
I added tests and created empty doc file(writing documentation is not a 
good idia considering my English level :shame:)


Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[GitHub] trafficserver issue #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread yatsukhnenko
Github user yatsukhnenko commented on the issue:

https://github.com/apache/trafficserver/pull/805
  
I added tests and created empty doc file(writing documentation is not a 
good idia considering my English level :shame:)


---
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-4583) CID 1021958: Null-pointer dereference after check

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> CID 1021958: Null-pointer dereference after check
> -
>
> Key: TS-4583
> URL: https://issues.apache.org/jira/browse/TS-4583
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, 
> before calling release_server_session(), which dereferences server_entry.



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


[GitHub] trafficserver issue #802: TS-4583: Null-pointer dereference after check

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/802
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/440/ 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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread atsci
Github user atsci commented on the issue:

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



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


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

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/798#discussion_r71084383
  
--- Diff: plugins/experimental/esi/esi.cc ---
@@ -61,6 +61,7 @@ struct OptionInfo {
 };
 
 static HandlerManager *gHandlerManager = NULL;
+static Utils::HeaderValueList gWhitelistCookies;
--- End diff --

I'm not familiar with the ESI plugin, but there's only one "config" ever? 
It sort of feels that the whitelist ought to be associated with the handler 
(config) no? Even if not supported now, maybe later you would want to?


Issue Time Tracking
---

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

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



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


[GitHub] trafficserver pull request #798: TS-4653: esi plugin - disable HTTP_COOKIE v...

2016-07-17 Thread zwoop
Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/798#discussion_r71084383
  
--- Diff: plugins/experimental/esi/esi.cc ---
@@ -61,6 +61,7 @@ struct OptionInfo {
 };
 
 static HandlerManager *gHandlerManager = NULL;
+static Utils::HeaderValueList gWhitelistCookies;
--- End diff --

I'm not familiar with the ESI plugin, but there's only one "config" ever? 
It sort of feels that the whitelist ought to be associated with the handler 
(config) no? Even if not supported now, maybe later you would want to?


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


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

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/798#discussion_r71084358
  
--- Diff: plugins/experimental/esi/lib/Variables.cc ---
@@ -357,9 +357,26 @@ Variables::_parseCookieString(const char *str, int 
str_len)
   AttributeList cookies;
   Utils::parseAttributes(str, str_len, cookies, ";,");
   for (AttributeList::iterator iter = cookies.begin(); iter != 
cookies.end(); ++iter) {
-_insert(_dict_data[HTTP_COOKIE], string(iter->name, iter->name_len), 
string(iter->value, iter->value_len));
-_debugLog(_debug_tag, "[%s] Inserted cookie with name [%.*s] and value 
[%.*s]", __FUNCTION__, iter->name_len, iter->name,
-  iter->value_len, iter->value);
+std::string v = iter->name;
+size_t eq = v.find("=");
+
+if (eq != std::string::npos) {
+  v = v.substr(0, eq);
+}
+
+bool found = false;
+for (Utils::HeaderValueList::iterator lz = _whitelistCookies.begin(); 
lz != _whitelistCookies.end(); ++lz) {
+  std::string c = *lz;
--- End diff --

Maybe this is the norm for the esi, but why create this intermediary 
std::string c? That seems inefficient and unnecessary ? Can't you just use the 
*lz ?


Issue Time Tracking
---

Worklog Id: (was: 25572)
Time Spent: 2.5h  (was: 2h 20m)

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



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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread atsci
Github user atsci commented on the issue:

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



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


[GitHub] trafficserver pull request #798: TS-4653: esi plugin - disable HTTP_COOKIE v...

2016-07-17 Thread zwoop
Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/798#discussion_r71084358
  
--- Diff: plugins/experimental/esi/lib/Variables.cc ---
@@ -357,9 +357,26 @@ Variables::_parseCookieString(const char *str, int 
str_len)
   AttributeList cookies;
   Utils::parseAttributes(str, str_len, cookies, ";,");
   for (AttributeList::iterator iter = cookies.begin(); iter != 
cookies.end(); ++iter) {
-_insert(_dict_data[HTTP_COOKIE], string(iter->name, iter->name_len), 
string(iter->value, iter->value_len));
-_debugLog(_debug_tag, "[%s] Inserted cookie with name [%.*s] and value 
[%.*s]", __FUNCTION__, iter->name_len, iter->name,
-  iter->value_len, iter->value);
+std::string v = iter->name;
+size_t eq = v.find("=");
+
+if (eq != std::string::npos) {
+  v = v.substr(0, eq);
+}
+
+bool found = false;
+for (Utils::HeaderValueList::iterator lz = _whitelistCookies.begin(); 
lz != _whitelistCookies.end(); ++lz) {
+  std::string c = *lz;
--- End diff --

Maybe this is the norm for the esi, but why create this intermediary 
std::string c? That seems inefficient and unnecessary ? Can't you just use the 
*lz ?


---
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-4583) CID 1021958: Null-pointer dereference after check

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> CID 1021958: Null-pointer dereference after check
> -
>
> Key: TS-4583
> URL: https://issues.apache.org/jira/browse/TS-4583
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, 
> before calling release_server_session(), which dereferences server_entry.



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


[GitHub] trafficserver issue #802: TS-4583: Null-pointer dereference after check

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/802
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/334/ 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-4583) CID 1021958: Null-pointer dereference after check

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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


Issue Time Tracking
---

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

> CID 1021958: Null-pointer dereference after check
> -
>
> Key: TS-4583
> URL: https://issues.apache.org/jira/browse/TS-4583
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, 
> before calling release_server_session(), which dereferences server_entry.



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


[GitHub] trafficserver issue #802: TS-4583: Null-pointer dereference after check

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/802
  
[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-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Work logged] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804#discussion_r71084262
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

I don't think the machine uuid can ever be NULL, but harmless to check I 
guess :).


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread atsci
Github user atsci commented on the issue:

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



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


[GitHub] trafficserver pull request #804: TS-4624: use the server UUID in the Via hea...

2016-07-17 Thread zwoop
Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/804#discussion_r71084262
  
--- Diff: proxy/http/HttpTransactHeaders.cc ---
@@ -750,12 +752,10 @@ 
HttpTransactHeaders::insert_via_header_in_request(HttpTransact::State *s, HTTPHd
   via_string += nstrcpy(via_string, s->http_config_param->proxy_hostname);
 
   *via_string++ = '[';
-  /* I thought we should use the transaction local outgoing IP address but
- that makes cycle detection (which is the point) unrealiable. We must
- use the same value every time to be sure.
-  */
-  memcpy(via_string, Machine::instance()->ip_hex_string, 
Machine::instance()->ip_hex_string_len);
-  via_string += Machine::instance()->ip_hex_string_len;
+  if (uuid != NULL) {
--- End diff --

I don't think the machine uuid can ever be NULL, but harmless to check I 
guess :).


---
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 #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/805
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/332/ 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-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
It's an inefficiency for starters (you go through a C-> C++ wrapper layer, 
for no good reason (remember, the public APIs are all C, whereas in the core, 
you can use all the C++ objects and methods directly).

In this case, it's marginal, but there are other places where it would be 
inefficient. And, it would add dependencies to the C-APIs in the C++ core which 
are undesirable in some cases.


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
It's an inefficiency for starters (you go through a C-> C++ wrapper layer, 
for no good reason (remember, the public APIs are all C, whereas in the core, 
you can use all the C++ objects and methods directly).

In this case, it's marginal, but there are other places where it would be 
inefficient. And, it would add dependencies to the C-APIs in the C++ core which 
are undesirable in some cases.


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Updated] (TS-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-4595:
--
Assignee: Pavlo Yatsukhnenko

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[jira] [Updated] (TS-4624) use the server UUID in the Via header

2016-07-17 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-4624:
--
Assignee: Pavlo Yatsukhnenko

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Updated] (TS-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-4595:
--
Fix Version/s: (was: sometime)
   7.0.0

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[jira] [Updated] (TS-4304) header_rewrite: There is no implementation of ConditionUrl::append_value for URL's

2016-07-17 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-4304:
--
Assignee: Pavlo Yatsukhnenko  (was: Leif Hedstrom)

> header_rewrite: There is no implementation of ConditionUrl::append_value for 
> URL's
> --
>
> Key: TS-4304
> URL: https://issues.apache.org/jira/browse/TS-4304
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Pavlo Yatsukhnenko
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The lack of implementation of ConditionUrl::append_value() means that we can 
> not use these are part of e.g. a set-header operand. I'm not sure why this is 
> not implemented, seems like it ought to be fairly straight forward.



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


[GitHub] trafficserver issue #806: TS-4304: implementation of ConditionUrl::append_va...

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/806
  
This is a good start, but it's missing a few things (I think at least, been 
a while since I looked at this). Look at how the eval() function is handling 
the different cases. But at least I think you need to

1) Support the remap vs transaction hook cases

2) Support the various qualifiers for each of those cases.


Now, while briefly looking at the eval() function, I see that it does not 
handle all qualifiers properly. I'm not sure what exactly happen here, but it's 
likely related to https://issues.apache.org/jira/browse/TS-4146 . Somewhere 
something went wrong, and instead of implementing the proper qualifiers, we 
added new operators for e.g. PATH etc. :-/.

I'm if you only make ::append_value() support the same features and 
qualifiers as the eval() method does today. And if so, just make a comment on 
TS-4146, reminding us that we also have to support more qualifiers (path etc.) 
in the append_value() method as well.

Cheers!


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
Don't quite understand why public API can't be used in internal code, but 
ok, changed code to `Machine::instance()->uuid.getString()`


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[jira] [Work logged] (TS-4304) header_rewrite: There is no implementation of ConditionUrl::append_value for URL's

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/806
  
This is a good start, but it's missing a few things (I think at least, been 
a while since I looked at this). Look at how the eval() function is handling 
the different cases. But at least I think you need to

1) Support the remap vs transaction hook cases

2) Support the various qualifiers for each of those cases.


Now, while briefly looking at the eval() function, I see that it does not 
handle all qualifiers properly. I'm not sure what exactly happen here, but it's 
likely related to https://issues.apache.org/jira/browse/TS-4146 . Somewhere 
something went wrong, and instead of implementing the proper qualifiers, we 
added new operators for e.g. PATH etc. :-/.

I'm if you only make ::append_value() support the same features and 
qualifiers as the eval() method does today. And if so, just make a comment on 
TS-4146, reminding us that we also have to support more qualifiers (path etc.) 
in the append_value() method as well.

Cheers!


Issue Time Tracking
---

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

> header_rewrite: There is no implementation of ConditionUrl::append_value for 
> URL's
> --
>
> Key: TS-4304
> URL: https://issues.apache.org/jira/browse/TS-4304
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The lack of implementation of ConditionUrl::append_value() means that we can 
> not use these are part of e.g. a set-header operand. I'm not sure why this is 
> not implemented, seems like it ought to be fairly straight forward.



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread yatsukhnenko
Github user yatsukhnenko commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
Don't quite understand why public API can't be used in internal code, but 
ok, changed code to `Machine::instance()->uuid.getString()`


---
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-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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


Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: sometime
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[GitHub] trafficserver issue #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

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


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


[GitHub] trafficserver issue #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/805
  
Also, please add some tests to proxy/InkAPITest.cc, see how the existing 
tests are done for e.g. TSInstallDirGet.


---
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-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/805
  
Also, please add some tests to proxy/InkAPITest.cc, see how the existing 
tests are done for e.g. TSInstallDirGet.


Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: sometime
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[jira] [Work logged] (TS-4595) Need a public API to get to RUNTIMEDIR

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/805
  
Cool. Can you add a documentation to this too? Either just add a new file, 
e.g.

doc/developer-guide/api/functions/TSRuntimeDirGet.en.rst

Or, my personal preference, merge all TS*DirGet() functions into one file, 
and document all those related functions in that one file. See for example 
doc/developer-guide/api/functions/TSUuidCreate.en.rst, and how we put all 
related functions in that one file.


Issue Time Tracking
---

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

> Need a public API to get to RUNTIMEDIR
> --
>
> Key: TS-4595
> URL: https://issues.apache.org/jira/browse/TS-4595
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: sometime
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are some cases where a plugin might want to get access to the 
> RUNTIMEDIR (var/trafficserver typically). Right now, there's no API that 
> exposes this, so we'd want to add this. Something similar to e.g. 
> TSConfigDirGet().



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


[GitHub] trafficserver issue #805: TS-4595: TSRuntimeDirGet

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/805
  
Cool. Can you add a documentation to this too? Either just add a new file, 
e.g.

doc/developer-guide/api/functions/TSRuntimeDirGet.en.rst

Or, my personal preference, merge all TS*DirGet() functions into one file, 
and document all those related functions in that one file. See for example 
doc/developer-guide/api/functions/TSUuidCreate.en.rst, and how we put all 
related functions in that one file.


---
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-4624) use the server UUID in the Via header

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/804
  
Almost, but not quite. :)  All APIs that are prefixed TS are the public 
APIs, and we don't use those in the internal code. Look at the log tags in 
logging that uses the internal APIs for the UUID. E.g. 

const char *uuid = (char *)Machine::instance()->uuid.getString();


Makes sense?


Issue Time Tracking
---

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

> use the server UUID in the Via header
> -
>
> Key: TS-4624
> URL: https://issues.apache.org/jira/browse/TS-4624
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [~zwoop] should we use the server UUID in the Via header?



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


[GitHub] trafficserver issue #804: TS-4624: use the server UUID in the Via header

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/804
  
Almost, but not quite. :)  All APIs that are prefixed TS are the public 
APIs, and we don't use those in the internal code. Look at the log tags in 
logging that uses the internal APIs for the UUID. E.g. 

const char *uuid = (char *)Machine::instance()->uuid.getString();


Makes sense?


---
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-4584) CID 1254818: Resource leak on file descriptor and allocated memory

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/803
  
Could we use the ats_scoped_obj here? Or some other smart ptr? I'm ok 
either way,  but maybe we should encourage these smart pointer patterns?

This might change memory management though (malloc/free vs new/delete) ? 
Don't go out of your way though if it's going to be really complex.


Issue Time Tracking
---

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

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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


[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Could we use the ats_scoped_obj here? Or some other smart ptr? I'm ok 
either way,  but maybe we should encourage these smart pointer patterns?

This might change memory management though (malloc/free vs new/delete) ? 
Don't go out of your way though if it's going to be really complex.


---
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-4304) header_rewrite: There is no implementation of ConditionUrl::append_value for URL's

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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

TS-4304: implementation of ConditionUrl::append_value



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

$ git pull https://github.com/yatsukhnenko/trafficserver TS-4304

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

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


commit e61fd46b9f6f08ef85ad9c13e2a3ac4fb8aabec5
Author: Pavlo Yatsukhnenko 
Date:   2016-07-17T14:40:35Z

TS-4304: implementation of ConditionUrl::append_value




Issue Time Tracking
---

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

> header_rewrite: There is no implementation of ConditionUrl::append_value for 
> URL's
> --
>
> Key: TS-4304
> URL: https://issues.apache.org/jira/browse/TS-4304
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The lack of implementation of ConditionUrl::append_value() means that we can 
> not use these are part of e.g. a set-header operand. I'm not sure why this is 
> not implemented, seems like it ought to be fairly straight forward.



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


[GitHub] trafficserver pull request #806: TS-4304: implementation of ConditionUrl::ap...

2016-07-17 Thread yatsukhnenko
GitHub user yatsukhnenko opened a pull request:

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

TS-4304: implementation of ConditionUrl::append_value



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

$ git pull https://github.com/yatsukhnenko/trafficserver TS-4304

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

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


commit e61fd46b9f6f08ef85ad9c13e2a3ac4fb8aabec5
Author: Pavlo Yatsukhnenko 
Date:   2016-07-17T14:40:35Z

TS-4304: implementation of ConditionUrl::append_value




---
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-4584) CID 1254818: Resource leak on file descriptor and allocated memory

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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


[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/437/ 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-4584) CID 1254818: Resource leak on file descriptor and allocated memory

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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


Issue Time Tracking
---

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

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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


[jira] [Work logged] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

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



Issue Time Tracking
---

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

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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


[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

2016-07-17 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/331/ 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 #803: TS-4584: Resource leak, CID 1254818 and 1254809

2016-07-17 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
add to whitelist


---
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-4584) CID 1254818: Resource leak on file descriptor and allocated memory

2016-07-17 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/trafficserver/pull/803
  
add to whitelist


Issue Time Tracking
---

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

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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


  1   2   >