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

[jenkins]

See 


Changes:

[James Peach] Add a script to generate a test coverage report.

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

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

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

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

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

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

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

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

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

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

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

[jira] [Work logged] (TS-4657) SNI hook sends hook ID for events

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> SNI hook sends hook ID for events
> -
>
> Key: TS-4657
> URL: https://issues.apache.org/jira/browse/TS-4657
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> If you use the {{TS_SSL_SNI_HOOK}} hook, it will send {{TS_SSL_SNI_HOOK}} 
> values as the event. {{TS_SSL_SNI_HOOK}} is not a valid {{TSEvent}} value.
> It is also weird that {{TS_SSL_SNI_HOOK}} and {{TS_SSL_CERT_HOOK}} have the 
> same value. One of these ought to be redundant.



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

[GitHub] trafficserver issue #977: TS-4657: SNI hook sends hook ID for events

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/977
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/615/ 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-4657) SNI hook sends hook ID for events

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> SNI hook sends hook ID for events
> -
>
> Key: TS-4657
> URL: https://issues.apache.org/jira/browse/TS-4657
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If you use the {{TS_SSL_SNI_HOOK}} hook, it will send {{TS_SSL_SNI_HOOK}} 
> values as the event. {{TS_SSL_SNI_HOOK}} is not a valid {{TSEvent}} value.
> It is also weird that {{TS_SSL_SNI_HOOK}} and {{TS_SSL_CERT_HOOK}} have the 
> same value. One of these ought to be redundant.



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

[GitHub] trafficserver issue #977: TS-4657: SNI hook sends hook ID for events

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Updated] (TS-4454) iobuffer readers are being cleared

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-4454:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> iobuffer readers are being cleared
> --
>
> Key: TS-4454
> URL: https://issues.apache.org/jira/browse/TS-4454
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> A generalization of TS-.  [~calavera] and [~oknet] both reported crashes 
> from trying to deallocate iobuffer readers that had already been cleared.  
> These crashes were in 6.2.0 and 6.0.x.  [~calavera] provided a fix to null 
> check the immediate problem reported in TS-.  But it was generally agreed 
> that this is probably a symptom of an iobuffer that had been freed and 
> reallocated during the lifetime of the transaction.  Filing this bug to track 
> the broader issue.



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

[jira] [Commented] (TS-4454) iobuffer readers are being cleared

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4454:


Pushing this back.  I haven't seen this recently and I don't have a fix in hand 
for 7.0.0.

> iobuffer readers are being cleared
> --
>
> Key: TS-4454
> URL: https://issues.apache.org/jira/browse/TS-4454
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> A generalization of TS-.  [~calavera] and [~oknet] both reported crashes 
> from trying to deallocate iobuffer readers that had already been cleared.  
> These crashes were in 6.2.0 and 6.0.x.  [~calavera] provided a fix to null 
> check the immediate problem reported in TS-.  But it was generally agreed 
> that this is probably a symptom of an iobuffer that had been freed and 
> reallocated during the lifetime of the transaction.  Filing this bug to track 
> the broader issue.



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

[jira] [Work logged] (TS-4657) SNI hook sends hook ID for events

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4657: SNI hook sends hook ID for events



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

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

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

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






Issue Time Tracking
---

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

> SNI hook sends hook ID for events
> -
>
> Key: TS-4657
> URL: https://issues.apache.org/jira/browse/TS-4657
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If you use the {{TS_SSL_SNI_HOOK}} hook, it will send {{TS_SSL_SNI_HOOK}} 
> values as the event. {{TS_SSL_SNI_HOOK}} is not a valid {{TSEvent}} value.
> It is also weird that {{TS_SSL_SNI_HOOK}} and {{TS_SSL_CERT_HOOK}} have the 
> same value. One of these ought to be redundant.



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

[GitHub] trafficserver pull request #977: TS-4657: SNI hook sends hook ID for events

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4657: SNI hook sends hook ID for events



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

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

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

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






---
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-4658) Why is TSSslVConnOp API?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Why is TSSslVConnOp API?
> 
>
> Key: TS-4658
> URL: https://issues.apache.org/jira/browse/TS-4658
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL, TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{TSSslVConnOp}} is not used in any APIs; it is basically an internal flag to 
> determine whether the core should terminate a TLS session or not. Let's 
> remove it from API and make it internal to {{SSLNetVConnection}}.



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

[GitHub] trafficserver issue #976: TS-4658: Why is TSSslVConnOp API?

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/976
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/718/ 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 #976: TS-4658: Why is TSSslVConnOp API?

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/976
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/614/ 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-4658) Why is TSSslVConnOp API?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Why is TSSslVConnOp API?
> 
>
> Key: TS-4658
> URL: https://issues.apache.org/jira/browse/TS-4658
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL, TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {{TSSslVConnOp}} is not used in any APIs; it is basically an internal flag to 
> determine whether the core should terminate a TLS session or not. Let's 
> remove it from API and make it internal to {{SSLNetVConnection}}.



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

[jira] [Work logged] (TS-4658) Why is TSSslVConnOp API?

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4658: Why is TSSslVConnOp API?

Pulled TSSslVConnOp from plugin header file and docs.  Added it back in 
internally.

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

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

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

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


commit f560d00dd207ec50774df7ba5627c3b1e515f59d
Author: Susan Hinrichs 
Date:   2016-09-07T03:03:37Z

TS-4658: Why is TSSslVConnOp API?




Issue Time Tracking
---

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

> Why is TSSslVConnOp API?
> 
>
> Key: TS-4658
> URL: https://issues.apache.org/jira/browse/TS-4658
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL, TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{TSSslVConnOp}} is not used in any APIs; it is basically an internal flag to 
> determine whether the core should terminate a TLS session or not. Let's 
> remove it from API and make it internal to {{SSLNetVConnection}}.



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

[GitHub] trafficserver pull request #976: TS-4658: Why is TSSslVConnOp API?

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4658: Why is TSSslVConnOp API?

Pulled TSSslVConnOp from plugin header file and docs.  Added it back in 
internally.

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

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

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

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


commit f560d00dd207ec50774df7ba5627c3b1e515f59d
Author: Susan Hinrichs 
Date:   2016-09-07T03:03:37Z

TS-4658: Why is TSSslVConnOp API?




---
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-4769) TSSslServerContextCreate always returns null

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #975: TS-4769: TSSslServerContextCreate always returns n...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/975
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/717/ 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 #975: TS-4769: TSSslServerContextCreate always returns n...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/975
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/613/ 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-4769) TSSslServerContextCreate always returns null

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4769: TSSslServerContextCreate always returns null

Activated the regression test created by @jpeach.

@biilmann let me know if this PR works for you.  Basically used the 
sslMultCertSettings argument as a indicator of whether we expected 
SSLInitServerContext to be a fully specified context at the end or not.

The volume of changes looks worse in the diff than reality.  Most of the 
changes in SSLInitServerContext are indentation changes.  I add an outer check 
on whether sslMultCertSettings is NULL or not.

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

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

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

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






Issue Time Tracking
---

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

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



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

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

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4769: TSSslServerContextCreate always returns null

Activated the regression test created by @jpeach.

@biilmann let me know if this PR works for you.  Basically used the 
sslMultCertSettings argument as a indicator of whether we expected 
SSLInitServerContext to be a fully specified context at the end or not.

The volume of changes looks worse in the diff than reality.  Most of the 
changes in SSLInitServerContext are indentation changes.  I add an outer check 
on whether sslMultCertSettings is NULL or not.

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

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

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

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






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

[jira] [Commented] (TS-4098) Remap filtering isn't working to only allow certain methods

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4098:
-

I think that's expected. If you have those two rules and probe both with "curl 
-X NOTGET" that is the result expected - the NOTGET rule lets it through and 
the origin replies with a 400, while the other rule locally denies because it's 
not GET.

Bryan's case seems to be the difference between a well known string ("WKS") and 
not. The rule behaves as expected for non-GET methods if they are WKS but 
doesn't prevent non-WKS methods.

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



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

[jira] [Work logged] (TS-3785) List --command options in traffic_server usage information

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 07/Sep/16 01:14
Start Date: 07/Sep/16 01:14
Worklog Time Spent: 10m 
  Work Description: GitHub user alyssaq opened a pull request:

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

TS-3785 List --command options in traffic_server usage information

[TS-3785](https://issues.apache.org/jira/browse/TS-3785)

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

$ git pull https://github.com/alyssaq/trafficserver TS-3785

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

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


commit be90d64cb50f970754d6c9c4a54e4bd975d9f552
Author: alyssaq 
Date:   2016-06-24T17:27:29Z

TS-3785 List --command options in traffic_server usage information




Issue Time Tracking
---

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

> List --command options in traffic_server usage information
> --
>
> Key: TS-3785
> URL: https://issues.apache.org/jira/browse/TS-3785
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 5.3.0
>Reporter: David Carlin
>Assignee: Alyssa Quek
>Priority: Minor
>  Labels: newbie, yahoo
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please update traffic_server --help (-h) output to show all the possible 
> options for the --command (-C) option.
> For example, there is currently no way to know -Cverify_config exists.



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

[GitHub] trafficserver pull request #974: TS-3785 List --command options in traffic_s...

[alyssaq]

GitHub user alyssaq opened a pull request:

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

TS-3785 List --command options in traffic_server usage information

[TS-3785](https://issues.apache.org/jira/browse/TS-3785)

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

$ git pull https://github.com/alyssaq/trafficserver TS-3785

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

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


commit be90d64cb50f970754d6c9c4a54e4bd975d9f552
Author: alyssaq 
Date:   2016-06-24T17:27:29Z

TS-3785 List --command options in traffic_server usage information




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

[jira] [Work logged] (TS-4026) Remove clustering feature in 7.0.0 release

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/966
  
Looked over the code and I didn't see a problem.  I applied the patches and 
it passed unit tests and regression.


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #966: TS-4026: Remove Clustering

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/966
  
Looked over the code and I didn't see a problem.  I applied the patches and 
it passed unit tests and regression.


---
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-4820) ParseRules::ink_tolower_buffer seems to be broken

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ParseRules::ink_tolower_buffer seems to be broken
> -
>
> Key: TS-4820
> URL: https://issues.apache.org/jira/browse/TS-4820
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This function doesn't seem to be used.  
> It tries to be clever about unrolling the character copy loop to do word 
> aligned assignments.  However, its calculation about the number of characters 
> to assign to get the pointer to be word aligned is wrong (fpad).
> The assignment in the code is 
> {code}
> uintptr_t fpad  = 4 - ((uintptr_t)ptr & 3);
> {code}
> I think it should be 
> {code}
> uintptr_t fpad  = ((uintptr_t)ptr & 3);
> {code}
> I tried using this function while addressing the lower case cert name lookup 
> bug, but it didn't work.  It only copied the first 8 of 14 characters. 
> I grepped the code base and it seems that this function is not used anywhere.
> I would suggest just removing the ink_tolower_buffer function.  I think 
> compilers are clever enough these days to do the unrolling if it makes sense.



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

[GitHub] trafficserver issue #973: TS-4820: ParseRules::ink_tolower_buffer seems to b...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/973
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/716/ 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-4820) ParseRules::ink_tolower_buffer seems to be broken

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ParseRules::ink_tolower_buffer seems to be broken
> -
>
> Key: TS-4820
> URL: https://issues.apache.org/jira/browse/TS-4820
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This function doesn't seem to be used.  
> It tries to be clever about unrolling the character copy loop to do word 
> aligned assignments.  However, its calculation about the number of characters 
> to assign to get the pointer to be word aligned is wrong (fpad).
> The assignment in the code is 
> {code}
> uintptr_t fpad  = 4 - ((uintptr_t)ptr & 3);
> {code}
> I think it should be 
> {code}
> uintptr_t fpad  = ((uintptr_t)ptr & 3);
> {code}
> I tried using this function while addressing the lower case cert name lookup 
> bug, but it didn't work.  It only copied the first 8 of 14 characters. 
> I grepped the code base and it seems that this function is not used anywhere.
> I would suggest just removing the ink_tolower_buffer function.  I think 
> compilers are clever enough these days to do the unrolling if it makes sense.



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

[GitHub] trafficserver issue #973: TS-4820: ParseRules::ink_tolower_buffer seems to b...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/973
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/612/ 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 #973: TS-4820: ParseRules::ink_tolower_buffer see...

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4820:  ParseRules::ink_tolower_buffer seems to be broken



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

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

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

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


commit df841f398ef4a174b7b3d00218fc4fd71a202a54
Author: Susan Hinrichs 
Date:   2016-09-07T00:40:17Z

TS-4820:  ParseRules::ink_tolower_buffer seems to be broken




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

[jira] [Work logged] (TS-4820) ParseRules::ink_tolower_buffer seems to be broken

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4820:  ParseRules::ink_tolower_buffer seems to be broken



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

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

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

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


commit df841f398ef4a174b7b3d00218fc4fd71a202a54
Author: Susan Hinrichs 
Date:   2016-09-07T00:40:17Z

TS-4820:  ParseRules::ink_tolower_buffer seems to be broken




Issue Time Tracking
---

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

> ParseRules::ink_tolower_buffer seems to be broken
> -
>
> Key: TS-4820
> URL: https://issues.apache.org/jira/browse/TS-4820
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This function doesn't seem to be used.  
> It tries to be clever about unrolling the character copy loop to do word 
> aligned assignments.  However, its calculation about the number of characters 
> to assign to get the pointer to be word aligned is wrong (fpad).
> The assignment in the code is 
> {code}
> uintptr_t fpad  = 4 - ((uintptr_t)ptr & 3);
> {code}
> I think it should be 
> {code}
> uintptr_t fpad  = ((uintptr_t)ptr & 3);
> {code}
> I tried using this function while addressing the lower case cert name lookup 
> bug, but it didn't work.  It only copied the first 8 of 14 characters. 
> I grepped the code base and it seems that this function is not used anywhere.
> I would suggest just removing the ink_tolower_buffer function.  I think 
> compilers are clever enough these days to do the unrolling if it makes sense.



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

[jira] [Work logged] (TS-4459) Force domain names in cert to lower on insert into lookup tree

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Force domain names in cert to lower on insert into lookup tree
> --
>
> Key: TS-4459
> URL: https://issues.apache.org/jira/browse/TS-4459
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Steven Feltner
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We have certs from a legacy system that were issued with mixed case domain 
> names.  We are migrating this older product over to ATS and found that domain 
> names need to be lower cased before being inserted in the lookup table.
> I will be submitting  a pull request to resolve this issue.



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

[GitHub] trafficserver issue #972: TS-4459: Force domain names in cert to be lowercas...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/972
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/611/ 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-4459) Force domain names in cert to lower on insert into lookup tree

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4459: Force domain names in cert to be lowercase for lookup tree.

@reveller's original code went away.  I think this is in the spirit of the 
original.  I added regression tests to exercise the mixed case comparisons.

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

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

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

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


commit 12ab6b1f05c16416bc378af568f583b2147325d8
Author: Susan Hinrichs 
Date:   2016-09-06T23:03:32Z

TS-4459: Force domain names in cert to be lowercase for lookup tree.




Issue Time Tracking
---

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

> Force domain names in cert to lower on insert into lookup tree
> --
>
> Key: TS-4459
> URL: https://issues.apache.org/jira/browse/TS-4459
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Steven Feltner
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have certs from a legacy system that were issued with mixed case domain 
> names.  We are migrating this older product over to ATS and found that domain 
> names need to be lower cased before being inserted in the lookup table.
> I will be submitting  a pull request to resolve this issue.



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

[jira] [Commented] (TS-4152) Build failure when curses is not available

[Jason Kenny (JIRA)]

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

Jason Kenny commented on TS-4152:
-

Ignore previous comments. I did not process this correctly. This is about not 
having ncurses installed and getting a build failure. I was under the 
understanding that it was and it did not link.

I looked more into this and there seems to be a bug in AX_WITH_CURSES in which 
it prints that warning but does not set ax_cv_curses to no ( it stays a yes 
value)

I have a fix to address this, will update once pull request is done

> Build failure when curses is not available
> --
>
> Key: TS-4152
> URL: https://issues.apache.org/jira/browse/TS-4152
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Jason Kenny
>  Labels: newbie
> Fix For: 7.0.0
>
>
> On Centos6 w/ devtoolset-3:
> {code}
> checking for NcursesW wide-character library... yes
> checking for working ncursesw/curses.h... no
> checking for working ncursesw.h... no
> checking for working ncurses.h... no
> configure: WARNING: could not find a working ncursesw/curses.h, ncursesw.h or 
> ncurses.h
> ...
> Making all in traffic_top
> make[2]: Entering directory 
> `/home/vagrant/trafficserver-6.1.0/cmd/traffic_top'
>   CXX  traffic_top.o
> traffic_top.cc:51:2: error: #error "SysV or X/Open-compatible Curses header 
> file required"
>  #error "SysV or X/Open-compatible Curses header file required"
> {code}
> The build is not supposed to try to build {{traffic_top}} if ncurses is not 
> available.



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

[jira] [Assigned] (TS-4820) ParseRules::ink_tolower_buffer seems to be broken

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-4820:
--

Assignee: Susan Hinrichs

> ParseRules::ink_tolower_buffer seems to be broken
> -
>
> Key: TS-4820
> URL: https://issues.apache.org/jira/browse/TS-4820
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> This function doesn't seem to be used.  
> It tries to be clever about unrolling the character copy loop to do word 
> aligned assignments.  However, its calculation about the number of characters 
> to assign to get the pointer to be word aligned is wrong (fpad).
> The assignment in the code is 
> {code}
> uintptr_t fpad  = 4 - ((uintptr_t)ptr & 3);
> {code}
> I think it should be 
> {code}
> uintptr_t fpad  = ((uintptr_t)ptr & 3);
> {code}
> I tried using this function while addressing the lower case cert name lookup 
> bug, but it didn't work.  It only copied the first 8 of 14 characters. 
> I grepped the code base and it seems that this function is not used anywhere.
> I would suggest just removing the ink_tolower_buffer function.  I think 
> compilers are clever enough these days to do the unrolling if it makes sense.



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

[jira] [Resolved] (TS-4818) Ensure the plugin tag is set on the HttpSM.

[James Peach (JIRA)]

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

James Peach resolved TS-4818.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 7.0.0

> Ensure the plugin tag is set on the HttpSM.
> ---
>
> Key: TS-4818
> URL: https://issues.apache.org/jira/browse/TS-4818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
> TS-4694.



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

[jira] [Created] (TS-4820) ParseRules::ink_tolower_buffer seems to be broken

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-4820:
--

 Summary: ParseRules::ink_tolower_buffer seems to be broken
 Key: TS-4820
 URL: https://issues.apache.org/jira/browse/TS-4820
 Project: Traffic Server
  Issue Type: Bug
Reporter: Susan Hinrichs


This function doesn't seem to be used.  

It tries to be clever about unrolling the character copy loop to do word 
aligned assignments.  However, its calculation about the number of characters 
to assign to get the pointer to be word aligned is wrong (fpad).

The assignment in the code is 
{code}
uintptr_t fpad  = 4 - ((uintptr_t)ptr & 3);
{code}

I think it should be 
{code}
uintptr_t fpad  = ((uintptr_t)ptr & 3);
{code}

I tried using this function while addressing the lower case cert name lookup 
bug, but it didn't work.  It only copied the first 8 of 14 characters. 

I grepped the code base and it seems that this function is not used anywhere.

I would suggest just removing the ink_tolower_buffer function.  I think 
compilers are clever enough these days to do the unrolling if it makes sense.



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

[jira] [Updated] (TS-4820) ParseRules::ink_tolower_buffer seems to be broken

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-4820:
---
Fix Version/s: 7.0.0

> ParseRules::ink_tolower_buffer seems to be broken
> -
>
> Key: TS-4820
> URL: https://issues.apache.org/jira/browse/TS-4820
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> This function doesn't seem to be used.  
> It tries to be clever about unrolling the character copy loop to do word 
> aligned assignments.  However, its calculation about the number of characters 
> to assign to get the pointer to be word aligned is wrong (fpad).
> The assignment in the code is 
> {code}
> uintptr_t fpad  = 4 - ((uintptr_t)ptr & 3);
> {code}
> I think it should be 
> {code}
> uintptr_t fpad  = ((uintptr_t)ptr & 3);
> {code}
> I tried using this function while addressing the lower case cert name lookup 
> bug, but it didn't work.  It only copied the first 8 of 14 characters. 
> I grepped the code base and it seems that this function is not used anywhere.
> I would suggest just removing the ink_tolower_buffer function.  I think 
> compilers are clever enough these days to do the unrolling if it makes sense.



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

[jira] [Updated] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-4819:
--
Description:  I found this when using the python "requests" library to 
generate HTTP requests to test the ATS. The request method of this library 
generates incorrect message body (i.e., does not follow the standard format) if 
both Content-Length and chunked encoding are specified. ATS can handle requests 
with these two fields being specified. It is the wrong format of the chunk that 
makes the ATS crash. The test program to reproduce the issue is attached. If 
the Content-Length is  removed from the header, then the library generates the 
correct format and ATS responds correctly. Ideally, content-length and chunked 
encoding should not be specified together  (was:  I found this when using the 
python "requests" library to generate HTTP requests to test the ATS. The 
request method of this library generates incorrect message body (i.e. does not 
follow the standard format) if both Content-Length and chunked encoding are 
specified. ATS can handle requests with these two fields being specified. It is 
the wrong format of the chunk that makes the ATS crash. The test program to 
reproduce the issue is attached. If the Content-Length is  removed from the 
header, then the library generates the correct format and ATS responds 
correctly. Ideally, content-length and chunked encoding should not be specified 
together)

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Syeda Persia Aziz
> Attachments: test_post.py
>
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e., does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. The test program to reproduce the issue is 
> attached. If the Content-Length is  removed from the header, then the library 
> generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



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

[jira] [Updated] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-4819:
--
Description:  I found this when using the python "requests" library to 
generate HTTP requests to test the ATS. The request method of this library 
generates incorrect message body (i.e. does not follow the standard format) if 
both Content-Length and chunked encoding are specified. ATS can handle requests 
with these two fields being specified. It is the wrong format of the chunk that 
makes the ATS crash. The test program to reproduce the issue is attached. If 
the Content-Length is  removed from the header, then the library generates the 
correct format and ATS responds correctly. Ideally, content-length and chunked 
encoding should not be specified together  (was:  I found this when using the 
python "requests" library to generate HTTP requests to test the ATS. The 
request method of this library generates incorrect message body (i.e. does not 
follow the standard format) if both Content-Length and chunked encoding are 
specified. ATS can handle requests with these two fields being specified. It is 
the wrong format of the chunk that makes the ATS crash.  If the Content-Length 
is  removed from the header, then the library generates the correct format and 
ATS responds correctly. Ideally, content-length and chunked encoding should not 
be specified together)

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Syeda Persia Aziz
> Attachments: test_post.py
>
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e. does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. The test program to reproduce the issue is 
> attached. If the Content-Length is  removed from the header, then the library 
> generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



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

[jira] [Updated] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-4819:
--
Attachment: test_post.py

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Syeda Persia Aziz
> Attachments: test_post.py
>
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e. does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash.  If the Content-Length is  removed from the header, 
> then the library generates the correct format and ATS responds correctly. 
> Ideally, content-length and chunked encoding should not be specified together



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

[jira] [Commented] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz commented on TS-4819:
---

## Test program
import gevent
import socket
import requests
import os
from threading import Thread
import sys
bSTOP = False
def handleResponse(response,*args, **kwargs):
print(response.status_code)

def gen():
yield 'pforpersia,champaignurbana'.encode('utf-8')
yield 'there'.encode('utf-8')

def txn_replay():
try:
request_session = requests.Session()
hostname = "127.0.0.1"
port = "8080"
request_session.proxies =  {"http": "http://{0}:{1}".format(hostname, 
port)}
hdr = {'content-type': 'application/json', 'User-Agent': 'YMobile/1.0 
(com.yahoo.mobile.client.android.mail/5.7.1; Android/6.0.1; MMB29K; zenltetmo; 
samsung; SM-G928T; 5.0; 2560x1440;)'
, 'Content-MD5':'5f4308e950ab4d7188e96ddf740855ec', 'Content-Length':'20'}
response = request_session.post('http://blabla.com/blabla', 
headers=hdr, stream=True, data=gen())
except UnicodeEncodeError as e:
print("UnicodeEncodeError exception")

except requests.exceptions.ContentDecodingError as e:
print("ContentDecodingError",e)
except:
e=sys.exc_info()
print("ERROR in requests: ",e)

def main():
txn_replay()

if __name__ == '__main__':
main()

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Syeda Persia Aziz
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e. does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. This problem can be reproduced using the python 
> file attached. If the Content-Length is  removed from the header, then the 
> library generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



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

[jira] [Issue Comment Deleted] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-4819:
--
Comment: was deleted

(was: ## Test program
import gevent
import socket
import requests
import os
from threading import Thread
import sys
bSTOP = False
def handleResponse(response,*args, **kwargs):
print(response.status_code)

def gen():
yield 'pforpersia,champaignurbana'.encode('utf-8')
yield 'there'.encode('utf-8')

def txn_replay():
try:
request_session = requests.Session()
hostname = "127.0.0.1"
port = "8080"
request_session.proxies =  {"http": "http://{0}:{1}".format(hostname, 
port)}
hdr = {'content-type': 'application/json', 'User-Agent': 'YMobile/1.0 
(com.yahoo.mobile.client.android.mail/5.7.1; Android/6.0.1; MMB29K; zenltetmo; 
samsung; SM-G928T; 5.0; 2560x1440;)'
, 'Content-MD5':'5f4308e950ab4d7188e96ddf740855ec', 'Content-Length':'20'}
response = request_session.post('http://blabla.com/blabla', 
headers=hdr, stream=True, data=gen())
except UnicodeEncodeError as e:
print("UnicodeEncodeError exception")

except requests.exceptions.ContentDecodingError as e:
print("ContentDecodingError",e)
except:
e=sys.exc_info()
print("ERROR in requests: ",e)

def main():
txn_replay()

if __name__ == '__main__':
main())

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Syeda Persia Aziz
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e. does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. This problem can be reproduced using the python 
> file attached. If the Content-Length is  removed from the header, then the 
> library generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



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

[jira] [Updated] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-4819:
--
Description:  I found this when using the python "requests" library to 
generate HTTP requests to test the ATS. The request method of this library 
generates incorrect message body (i.e. does not follow the standard format) if 
both Content-Length and chunked encoding are specified. ATS can handle requests 
with these two fields being specified. It is the wrong format of the chunk that 
makes the ATS crash.  If the Content-Length is  removed from the header, then 
the library generates the correct format and ATS responds correctly. Ideally, 
content-length and chunked encoding should not be specified together  (was:  I 
found this when using the python "requests" library to generate HTTP requests 
to test the ATS. The request method of this library generates incorrect message 
body (i.e. does not follow the standard format) if both Content-Length and 
chunked encoding are specified. ATS can handle requests with these two fields 
being specified. It is the wrong format of the chunk that makes the ATS crash. 
This problem can be reproduced using the python file attached. If the 
Content-Length is  removed from the header, then the library generates the 
correct format and ATS responds correctly. Ideally, content-length and chunked 
encoding should not be specified together)

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Syeda Persia Aziz
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e. does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash.  If the Content-Length is  removed from the header, 
> then the library generates the correct format and ATS responds correctly. 
> Ideally, content-length and chunked encoding should not be specified together



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

[jira] [Commented] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz commented on TS-4819:
---

(gdb) bt
#0  0x0055a532 in ProxyClientTransaction::get_half_close_flag 
(this=0x7fffec27be40) at http/../ProxyClientTransaction.h:78
#1  0x005f3cdf in HttpSM::do_setup_post_tunnel (this=0x7fffd0cce1e0, 
to_vc_type=HTTP_SERVER_VC) at HttpSM.cc:5621
#2  0x005e5434 in HttpSM::state_send_server_request_header 
(this=0x7fffd0cce1e0, event=103, data=0x7fffb8018b90) at HttpSM.cc:1995
#3  0x005e7e00 in HttpSM::main_handler (this=0x7fffd0cce1e0, event=103, 
data=0x7fffb8018b90) at HttpSM.cc:2658
#4  0x005100f2 in Continuation::handleEvent (this=0x7fffd0cce1e0, 
event=103, data=0x7fffb8018b90) at ../iocore/eventsystem/I_Continuation.h:153
#5  0x00799b17 in write_signal_and_update (event=103, 
vc=0x7fffb8018a00) at UnixNetVConnection.cc:184
#6  0x00799d22 in write_signal_done (event=103, nh=0x74ecdcd0, 
vc=0x7fffb8018a00) at UnixNetVConnection.cc:226
#7  0x0079b19e in write_to_net_io (nh=0x74ecdcd0, 
vc=0x7fffb8018a00, thread=0x74eca010) at UnixNetVConnection.cc:566
#8  0x0079a91d in write_to_net (nh=0x74ecdcd0, vc=0x7fffb8018a00, 
thread=0x74eca010) at UnixNetVConnection.cc:423
#9  0x00791802 in NetHandler::mainNetEvent (this=0x74ecdcd0, 
event=5, e=0x1192d00) at UnixNet.cc:530
#10 0x005100f2 in Continuation::handleEvent (this=0x74ecdcd0, 
event=5, data=0x1192d00) at ../iocore/eventsystem/I_Continuation.h:153
#11 0x007bd88b in EThread::process_event (this=0x74eca010, 
e=0x1192d00, calling_code=5) at UnixEThread.cc:148
#12 0x007bde8e in EThread::execute (this=0x74eca010) at 
UnixEThread.cc:275
#13 0x007bce30 in spawn_thread_internal (a=0x114bab0) at Thread.cc:86
#14 0x76a5c6fa in start_thread (arg=0x74ac5700) at 
pthread_create.c:333
#15 0x75cedb5d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109


> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Syeda Persia Aziz
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e. does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. This problem can be reproduced using the python 
> file attached. If the Content-Length is  removed from the header, then the 
> library generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



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

[jira] [Created] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-4819:
-

 Summary: ATS-6.2.x crashes if the message-body of a chunk is not 
correctly formatted
 Key: TS-4819
 URL: https://issues.apache.org/jira/browse/TS-4819
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Syeda Persia Aziz


 I found this when using the python "requests" library to generate HTTP 
requests to test the ATS. The request method of this library generates 
incorrect message body (i.e. does not follow the standard format) if both 
Content-Length and chunked encoding are specified. ATS can handle requests with 
these two fields being specified. It is the wrong format of the chunk that 
makes the ATS crash. This problem can be reproduced using the python file 
attached. If the Content-Length is  removed from the header, then the library 
generates the correct format and ATS responds correctly. Ideally, 
content-length and chunked encoding should not be specified together



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

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[Gancho Tenev (JIRA)]

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

Gancho Tenev commented on TS-4334:
--

[~jamesf], I am sorry if I did not make my idea/example clear enough!

I was proposing not to use {{cache_range_requests}} plugin at all and use 
{{cachekey}} plugin as your central place of cache key manipulation and then by 
using the {{header_rewrite}} plugin to implement the rest of the logic done by 
the {{cache_range_requests}} (adding/removing the Range header at different 
hooks).

The end result should be practically the same as using {{cache_range_requests}} 
plugin but achieved by using more generic plugins (tested it) instead of 
hacking into {{cache_range_requests}} which seems pretty specialized and less 
configurable.

I was wondering if this would work for you.

Please let me know, I would gladly help you if any problems/concerns. 

Cheers!

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



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

[jira] [Work logged] (TS-1882) ATS doesn't warn about unknown config items

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[GitHub] trafficserver issue #971: TS-1882: Check for unrecognized configuration valu...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/971
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/714/ 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 #971: TS-1882: Check for unrecognized configurati...

[jpeach]

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

https://github.com/apache/trafficserver/pull/971#discussion_r77714260
  
--- Diff: proxy/Main.cc ---
@@ -476,6 +476,18 @@ check_config_directories(void)
   }
 }
 
+namespace {
+  // Values with names that have this prefix are exempted from being 
considered "unrecognized".
+  const char PLUGIN_CONFIG_RECORD_PREFIX[] = "proxy.config.plugin.";
--- End diff --

This is a big assumption. I have internal plugins that use configuration 
values that are not in this namespace.


---
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-1882) ATS doesn't warn about unknown config items

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Sep/16 20:40
Start Date: 06/Sep/16 20:40
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/971#discussion_r77714260
  
--- Diff: proxy/Main.cc ---
@@ -476,6 +476,18 @@ check_config_directories(void)
   }
 }
 
+namespace {
+  // Values with names that have this prefix are exempted from being 
considered "unrecognized".
+  const char PLUGIN_CONFIG_RECORD_PREFIX[] = "proxy.config.plugin.";
--- End diff --

This is a big assumption. I have internal plugins that use configuration 
values that are not in this namespace.


Issue Time Tracking
---

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

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[jira] [Work logged] (TS-4818) Ensure the plugin tag is set on the HttpSM.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/970
  
Ship it. This just restores code that was in 6.2.x that should not have 
been removed.


Issue Time Tracking
---

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

> Ensure the plugin tag is set on the HttpSM.
> ---
>
> Key: TS-4818
> URL: https://issues.apache.org/jira/browse/TS-4818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
> TS-4694.



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

[GitHub] trafficserver issue #971: TS-1882: Check for unrecognized configuration valu...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/971
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/610/ 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 #970: TS-4818: Ensure the plugin tag is set on the HttpS...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/970
  
Ship it. This just restores code that was in 6.2.x that should not have 
been removed.


---
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 #970: TS-4818: Ensure the plugin tag is set on th...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-1882) ATS doesn't warn about unknown config items

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[jira] [Work logged] (TS-4818) Ensure the plugin tag is set on the HttpSM.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/970
  
Verified that the background requests from the ``stale_while_revalidate`` 
plugin now get a legitimate entry when using the ``%`` log field.


Issue Time Tracking
---

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

> Ensure the plugin tag is set on the HttpSM.
> ---
>
> Key: TS-4818
> URL: https://issues.apache.org/jira/browse/TS-4818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
> TS-4694.



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

[GitHub] trafficserver issue #970: TS-4818: Ensure the plugin tag is set on the HttpS...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/970
  
I know it's used in Yahoo! internally for similar reasons, to post process 
logs for actions of specific plugins.


---
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-4818) Ensure the plugin tag is set on the HttpSM.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/970
  
I know it's used in Yahoo! internally for similar reasons, to post process 
logs for actions of specific plugins.


Issue Time Tracking
---

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

> Ensure the plugin tag is set on the HttpSM.
> ---
>
> Key: TS-4818
> URL: https://issues.apache.org/jira/browse/TS-4818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
> TS-4694.



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

[GitHub] trafficserver issue #970: TS-4818: Ensure the plugin tag is set on the HttpS...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/970
  
Verified that the background requests from the ``stale_while_revalidate`` 
plugin now get a legitimate entry when using the ``%`` log field.


---
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-1882) ATS doesn't warn about unknown config items

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Sep/16 20:35
Start Date: 06/Sep/16 20:35
Worklog Time Spent: 10m 
  Work Description: GitHub user SolidWallOfCode opened a pull request:

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

TS-1882: Check for unrecognized configuration values.



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

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-1882

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

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


commit 3e15966e7fd99242d2bdec0a20fb3966b81d959f
Author: Alan M. Carroll 
Date:   2016-09-06T20:34:21Z

TS-1882: Check for unrecognized configuration values.




Issue Time Tracking
---

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

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[GitHub] trafficserver pull request #971: TS-1882: Check for unrecognized configurati...

[SolidWallOfCode]

GitHub user SolidWallOfCode opened a pull request:

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

TS-1882: Check for unrecognized configuration values.



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

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-1882

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

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


commit 3e15966e7fd99242d2bdec0a20fb3966b81d959f
Author: Alan M. Carroll 
Date:   2016-09-06T20:34:21Z

TS-1882: Check for unrecognized configuration values.




---
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-4818) Ensure the plugin tag is set on the HttpSM.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Ensure the plugin tag is set on the HttpSM.
> ---
>
> Key: TS-4818
> URL: https://issues.apache.org/jira/browse/TS-4818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
> TS-4694.



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

[GitHub] trafficserver issue #970: TS-4818: Ensure the plugin tag is set on the HttpS...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/970
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/609/ 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-4818) Ensure the plugin tag is set on the HttpSM.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Ensure the plugin tag is set on the HttpSM.
> ---
>
> Key: TS-4818
> URL: https://issues.apache.org/jira/browse/TS-4818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
> TS-4694.



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

[GitHub] trafficserver issue #970: TS-4818: Ensure the plugin tag is set on the HttpS...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/970
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/713/ 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 #942: TS 4263: Global key block configurable via Records...

[persiaAziz]

Github user persiaAziz commented on the issue:

https://github.com/apache/trafficserver/pull/942
  
If the ticket key file has a keyblock which is less than 48 bytes, then the 
assertion statement in ssl_callback_session_ticket(..) will fail. This is the 
current logic. One thing that confuses is that we create random ticket keys if 
the filename of key is NULL but fail on assertion if the keyblock is NULL. 
Can't we make a new random keyblock in such case? @shinrich @jpeach @zwoop 


---
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-4818) Ensure the plugin tag is set on the HttpSM.

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4818: Ensure the plugin tag is set on the HttpSM.

Unless we copy the plugin information when creating the proxy
transaction, the % logging field always emits "*".

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

$ git pull https://github.com/jpeach/trafficserver fix/4818

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

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


commit 44122b014d38a6ed8a79164321f3470bce9d766b
Author: James Peach 
Date:   2016-09-06T20:09:10Z

TS-4818: Ensure the plugin tag is set on the HttpSM.

Unless we copy the plugin information when creating the proxy
transaction, the % logging field always emits "*".




Issue Time Tracking
---

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

> Ensure the plugin tag is set on the HttpSM.
> ---
>
> Key: TS-4818
> URL: https://issues.apache.org/jira/browse/TS-4818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
> TS-4694.



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

[GitHub] trafficserver pull request #970: TS-4818: Ensure the plugin tag is set on th...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4818: Ensure the plugin tag is set on the HttpSM.

Unless we copy the plugin information when creating the proxy
transaction, the % logging field always emits "*".

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

$ git pull https://github.com/jpeach/trafficserver fix/4818

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

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


commit 44122b014d38a6ed8a79164321f3470bce9d766b
Author: James Peach 
Date:   2016-09-06T20:09:10Z

TS-4818: Ensure the plugin tag is set on the HttpSM.

Unless we copy the plugin information when creating the proxy
transaction, the % logging field always emits "*".




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

[jira] [Resolved] (TS-4800) Fix logging.config reloading.

[James Peach (JIRA)]

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

James Peach resolved TS-4800.
-
Resolution: Fixed

> Fix logging.config reloading.
> -
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[jira] [Work started] (TS-4800) Fix logging.config reloading.

[James Peach (JIRA)]

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

Work on TS-4800 started by James Peach.
---
> Fix logging.config reloading.
> -
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[jira] [Work logged] (TS-4800) Fix logging.config reloading.

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Fix logging.config reloading.
> -
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[jira] [Created] (TS-4818) Ensure the plugin tag is set on the HttpSM.

[James Peach (JIRA)]

James Peach created TS-4818:
---

 Summary: Ensure the plugin tag is set on the HttpSM.
 Key: TS-4818
 URL: https://issues.apache.org/jira/browse/TS-4818
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Logging
Reporter: James Peach


The {{pitag}} logging field always emits {{"*"}}. This is a regression from 
TS-4694.



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

[GitHub] trafficserver pull request #969: TS-4800: Fix logging.config reloading.

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4800) Fix logging.config reloading.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Fix logging.config reloading.
> -
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[GitHub] trafficserver issue #969: TS-4800: Fix logging.config reloading.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/969
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/712/ 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-4800) Fix logging.config reloading.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Fix logging.config reloading.
> -
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[GitHub] trafficserver issue #969: TS-4800: Fix logging.config reloading.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/969
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/608/ 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-4796) ATS not closing origin connections on first RST from client

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28220)
Time Spent: 4h 50m  (was: 4h 40m)

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/607/ 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-4796) ATS not closing origin connections on first RST from client

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Resolved] (TS-4665) Http2 not terminating stream with short chunked response

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4665.

Resolution: Fixed

> Http2 not terminating stream with short chunked response
> 
>
> Key: TS-4665
> URL: https://issues.apache.org/jira/browse/TS-4665
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We saw this in production.  The origin returned the chunked response 
> immediately and it was all delivered with the header to the Http2Stream 
> logic.  It didn't set the END_STREAM flag and the stream wasn't closed until 
> the timeout triggered.
> Fixing this required some additional checks to avoid shutdown race conditions.



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

[jira] [Updated] (TS-4665) Http2 not terminating stream with short chunked response

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-4665:
---
Backport to Version: 6.2.2

> Http2 not terminating stream with short chunked response
> 
>
> Key: TS-4665
> URL: https://issues.apache.org/jira/browse/TS-4665
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We saw this in production.  The origin returned the chunked response 
> immediately and it was all delivered with the header to the Http2Stream 
> logic.  It didn't set the END_STREAM flag and the stream wasn't closed until 
> the timeout triggered.
> Fixing this required some additional checks to avoid shutdown race conditions.



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

[jira] [Updated] (TS-4800) Fix logging.config reloading.

[James Peach (JIRA)]

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

James Peach updated TS-4800:

Summary: Fix logging.config reloading.  (was: Verify that reloading 
logging.config works.)

> Fix logging.config reloading.
> -
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[jira] [Assigned] (TS-4800) Fix logging.config reloading.

[James Peach (JIRA)]

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

James Peach reassigned TS-4800:
---

Assignee: James Peach

> Fix logging.config reloading.
> -
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[GitHub] trafficserver pull request #888: TS-4665: Http2 not terminating stream with ...

[shinrich]

Github user shinrich closed the pull request at:

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


---
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-4665) Http2 not terminating stream with short chunked response

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Http2 not terminating stream with short chunked response
> 
>
> Key: TS-4665
> URL: https://issues.apache.org/jira/browse/TS-4665
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We saw this in production.  The origin returned the chunked response 
> immediately and it was all delivered with the header to the Http2Stream 
> logic.  It didn't set the END_STREAM flag and the stream wasn't closed until 
> the timeout triggered.
> Fixing this required some additional checks to avoid shutdown race conditions.



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

[jira] [Work logged] (TS-4800) Verify that reloading logging.config works.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Sep/16 19:16
Start Date: 06/Sep/16 19:16
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

TS-4800: Fix logging.config reloading.

We were still listening for reconfiguration events on the old XML
log file record. Fix logging.config reload by listening on the
correct record name.

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

$ git pull https://github.com/jpeach/trafficserver fix/4800

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

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


commit 424d6abbb4dcfc05352083feb07b0e9f5c90
Author: James Peach 
Date:   2016-09-06T19:11:45Z

TS-4800: Fix logging.config reloading.

We were still listening for reconfiguration events on the old XML
log file record. Fix logging.config reload by listening on the
correct record name.




Issue Time Tracking
---

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

> Verify that reloading logging.config works.
> ---
>
> Key: TS-4800
> URL: https://issues.apache.org/jira/browse/TS-4800
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Seen in my dev environment:
> {noformat}
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:54:46.884] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::internalUpdate] Link failed : Operation not permitted
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: '[TrafficManager] Configuration File Update Failed: Operation 
> not permitted'
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: 
> [Rollback::checkForUserUpdate] Failed to roll changed user file 
> logging.config: System Call Error
> [Aug 30 23:55:07.406] Manager {0x7fa0c82b6700} NOTE: User has changed config 
> file logging.config
> {noformat}
> Seems like reloading is not working correctly.



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

[GitHub] trafficserver pull request #969: TS-4800: Fix logging.config reloading.

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4800: Fix logging.config reloading.

We were still listening for reconfiguration events on the old XML
log file record. Fix logging.config reload by listening on the
correct record name.

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

$ git pull https://github.com/jpeach/trafficserver fix/4800

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

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


commit 424d6abbb4dcfc05352083feb07b0e9f5c90
Author: James Peach 
Date:   2016-09-06T19:11:45Z

TS-4800: Fix logging.config reloading.

We were still listening for reconfiguration events on the old XML
log file record. Fix logging.config reload by listening on the
correct record name.




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

[jira] [Work logged] (TS-3046) Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle 
> SSL connections
> 
>
> Key: TS-3046
> URL: https://issues.apache.org/jira/browse/TS-3046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>Priority: Blocker
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This bug is a follow up on completely phasing out ET_SSL threads (refer 
> TS-2574 and TS-3045). 



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

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/606/ 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-4796) ATS not closing origin connections on first RST from client

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[jira] [Work logged] (TS-3046) Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle 
> SSL connections
> 
>
> Key: TS-3046
> URL: https://issues.apache.org/jira/browse/TS-3046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>Priority: Blocker
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This bug is a follow up on completely phasing out ET_SSL threads (refer 
> TS-2574 and TS-3045). 



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

[GitHub] trafficserver issue #968: TS-3046: Phase out proxy.config.ssl.number.threads...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/968
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/605/ 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 #968: TS-3046: Phase out proxy.config.ssl.number.threads...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/968
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/710/ 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-4796) ATS not closing origin connections on first RST from client

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Sep/16 19:13
Start Date: 06/Sep/16 19:13
Worklog Time Spent: 10m 
  Work Description: Github user jacksontj commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/947#discussion_r77699771
  
--- Diff: iocore/net/UnixNet.cc ---
@@ -542,7 +555,14 @@ NetHandler::mainNetEvent(int event, Event *e)
   close_UnixNetVConnection(vc, trigger_event->ethread);
 else if (vc->write.enabled && vc->write.triggered)
   write_to_net(this, vc, trigger_event->ethread);
-else if (!vc->write.enabled) {
+else if (vc->write.error) {
+  int err = 0, errlen = sizeof(int);
+  if (getsockopt(vc->con.fd, SOL_SOCKET, SO_ERROR, , (socklen_t 
*)) == -1) {
+err = errno;
+  }
+  if (err != EAGAIN && err != EINTR)
+vc->writeSignalError(this, err);
+} else if (!vc->write.enabled) {
--- End diff --

Done :)


Issue Time Tracking
---

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

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[jira] [Resolved] (TS-1883) TLS origin connections do not support connection timeouts

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-1883.

Resolution: Not A Problem

> TLS origin connections do not support connection timeouts
> -
>
> Key: TS-1883
> URL: https://issues.apache.org/jira/browse/TS-1883
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> In {{proxy/http/HttpSM.cc}}, we can see that origin connections do not 
> support timeouts if the scheme is HTTPS:
> {code}
> void
> HttpSM::do_http_server_open(bool raw)
> {
> ...
>   if (t_state.scheme == URL_WKSIDX_HTTPS) {
> DebugSM("http", "calling sslNetProcessor.connect_re");
> connect_action_handle = sslNetProcessor.connect_re(this,// state 
> machine
>
> _state.current.server->addr.sa,// addr + port
>);
>   } else {
> ...
>   // Setup the timeouts
>   // Set the inactivity timeout to the connect timeout so that we
>   //   we fail this server if it doesn't start sending the response
>   //   header
>   MgmtInt connect_timeout;
>   if (t_state.method == HTTP_WKSIDX_POST || t_state.method == 
> HTTP_WKSIDX_PUT) {
> connect_timeout = t_state.txn_conf->post_connect_attempts_timeout;
>   } else if (t_state.current.server == _state.parent_info) {
> connect_timeout = t_state.http_config_param->parent_connect_timeout;
>   } else {
> if (t_state.pCongestionEntry != NULL)
>   connect_timeout = t_state.pCongestionEntry->connect_timeout();
> else
>   connect_timeout = t_state.txn_conf->connect_attempts_timeout;
>   }
>   DebugSM("http", "calling netProcessor.connect_s");
>   connect_action_handle = netProcessor.connect_s(this,  // state 
> machine
>  
> _state.current.server->addr.sa,// addr + port
>  connect_timeout, );
> ...
>   }
> {code}



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