[jira] [Commented] (TS-3546) Force global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594346#comment-14594346
]
ASF subversion and git services commented on TS-3546:
-
Commit 95dd7fdf87dd88c6b43484507576abac794976f7 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=95dd7fd ]
TS-3546: Force global plugin registration with TSPluginRegister API and remove
version information
Fixed problem with where to call Fatal when a plugin didn't register
> Force global plugin registration with TSPluginRegister API and remove version
> information
> -
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3546) For global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594345#comment-14594345
]
ASF subversion and git services commented on TS-3546:
-
Commit b7e60e4869b91ef07928126c6b3324fede1998ae in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b7e60e4 ]
Revert "TS-3546: For global plugin registration with TSPluginRegister API and
remove version information"
This reverts commit 5ee9b92c34810ef442fbc34666e080a0f1a05fec.
> For global plugin registration with TSPluginRegister API and remove version
> information
> ---
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3546) Force global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3546:
---
Summary: Force global plugin registration with TSPluginRegister API and
remove version information (was: For global plugin registration with
TSPluginRegister API and remove version information)
> Force global plugin registration with TSPluginRegister API and remove version
> information
> -
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3546) For global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594343#comment-14594343
]
ASF subversion and git services commented on TS-3546:
-
Commit 5ee9b92c34810ef442fbc34666e080a0f1a05fec in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5ee9b92 ]
TS-3546: For global plugin registration with TSPluginRegister API and remove
version information
Fixed problem with where to call Fatal when a plugin didn't register
> For global plugin registration with TSPluginRegister API and remove version
> information
> ---
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3689) Remove libck
[ https://issues.apache.org/jira/browse/TS-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594301#comment-14594301 ] ASF subversion and git services commented on TS-3689: - Commit f00c51022fad00b2a9da34b25946386f3477a77e in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f00c510 ] TS-3689 Remove a file that lingered from CK > Remove libck > > > Key: TS-3689 > URL: https://issues.apache.org/jira/browse/TS-3689 > Project: Traffic Server > Issue Type: Improvement > Components: CK >Reporter: Leif Hedstrom >Assignee: Phil Sorber > Fix For: 6.0.0 > > > Since we can't get ck to function as it is, the decision has been made to > 1) Remove CK > 2) Fork CK on github (??) as CK++. > 3) Subtree the CK++ fork. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2150) Add Milestone log tags
[
https://issues.apache.org/jira/browse/TS-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594245#comment-14594245
]
Leif Hedstrom commented on TS-2150:
---
I haven't looked at the code, but we should make the new tags follow existing
naming conventions. E.g msdiff does not sound right, msd seems better, or msdms
(we tend to use ms to indicate milliseconds).
> Add Milestone log tags
> --
>
> Key: TS-2150
> URL: https://issues.apache.org/jira/browse/TS-2150
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Leif Hedstrom
>Assignee: John Rushford
> Fix For: sometime
>
>
> We have a notion of milestones in the core, and plugin APIs
> (TSHttpTxnMilestoneGet() ). It'd be useful to expose these milestone timers
> as a log tag, something like:
> {code}
> %<{UA_BEGIN}mtms>
> {code}
> mtms is just an example / suggestion, "MilestoneTimeMilliSecond", we can make
> it whatever we like.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3647) Add support for changing transaction overrideable config vars to CPP API
[
https://issues.apache.org/jira/browse/TS-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594195#comment-14594195
]
Alan M. Carroll commented on TS-3647:
-
As part of this fix the CPP API example plugins were updated to do the required
plugin registration.
> Add support for changing transaction overrideable config vars to CPP API
>
>
> Key: TS-3647
> URL: https://issues.apache.org/jira/browse/TS-3647
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Syeda Persia Aziz
> Labels: newbie++
> Fix For: 6.0.0
>
>
> The CPP API should support the equivalent of the following C API functions.
> {code}
> TSHttpTxnConfigIntSet
> TSHttpTxnConfigIntGet
> TSHttpTxnConfigFloatSet
> TSHttpTxnConfigFloatGet
> TSHttpTxnConfigStringSet
> TSHttpTxnConfigStringGet
> TSHttpTxnConfigFind
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3647) Add support for changing transaction overrideable config vars to CPP API
[
https://issues.apache.org/jira/browse/TS-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594191#comment-14594191
]
Alan M. Carroll commented on TS-3647:
-
This closes #214
> Add support for changing transaction overrideable config vars to CPP API
>
>
> Key: TS-3647
> URL: https://issues.apache.org/jira/browse/TS-3647
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Syeda Persia Aziz
> Labels: newbie++
> Fix For: 6.0.0
>
>
> The CPP API should support the equivalent of the following C API functions.
> {code}
> TSHttpTxnConfigIntSet
> TSHttpTxnConfigIntGet
> TSHttpTxnConfigFloatSet
> TSHttpTxnConfigFloatGet
> TSHttpTxnConfigStringSet
> TSHttpTxnConfigStringGet
> TSHttpTxnConfigFind
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3647) Add support for changing transaction overrideable config vars to CPP API
[
https://issues.apache.org/jira/browse/TS-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594190#comment-14594190
]
ASF subversion and git services commented on TS-3647:
-
Commit 93986440fdeff51bd4140fb6f4fb1e0eaf58a84f in trafficserver's branch
refs/heads/master from [~persiaAziz]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9398644 ]
TS-3647: CPP API for overridable configs. Fixup CPP example plugins to do
plugin init.
> Add support for changing transaction overrideable config vars to CPP API
>
>
> Key: TS-3647
> URL: https://issues.apache.org/jira/browse/TS-3647
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Syeda Persia Aziz
> Labels: newbie++
> Fix For: 6.1.0
>
>
> The CPP API should support the equivalent of the following C API functions.
> {code}
> TSHttpTxnConfigIntSet
> TSHttpTxnConfigIntGet
> TSHttpTxnConfigFloatSet
> TSHttpTxnConfigFloatGet
> TSHttpTxnConfigStringSet
> TSHttpTxnConfigStringGet
> TSHttpTxnConfigFind
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594125#comment-14594125
]
Susan Hinrichs commented on TS-3136:
And because you cannot have too much fun playing with data, here is the
negotiated cipher table subtotaled by type of cipher
|Cipher Group|% 6/19 list|% 6/18 list|% 5.x default|
|non-PFS block cipher |6.89| 6.86|0.48|
|GCM|35.69 |35.64 |35.79|
|PFS CBC|57.42| 57.5| 40.56|
|RC4|0| 0| 23.18|
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594073#comment-14594073
]
Susan Hinrichs edited comment on TS-3136 at 6/19/15 11:15 PM:
--
I spent today running experiments with a variety of cipher_suite strings.
Based on feedback from my previous suggestion and these experiments, my latest
suggested default cipher_suite list is below (which I referred to as the 6/19
list in the comment above).
{code}
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:AES256-GCM-SHA384:AES128-GCM-SHA256:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
I think it is a good trade off of security, performance, availability, and
reliability for a good out-of-the-box experience.
My final experiment involved three boxes in the same pod. One running with the
list above (6/19 list). One running the list suggested yesterday (6/18 list).
One running the 5.x default.
There was a little bit of CPU difference. The experiment ran for 100 wall
clock minutes. The CPU time for each scenario was
|Scenario|CPU Time|
|6/19 list|130 minutes|
|6/18 list|152 minutes|
|5.x default|180 minutes|
The summary of negotiated protocols
|Cipher |% list 6/19| % list 6/18|% 5.x list|
|ECDHE-RSA-AES256-GCM-SHA384|0.01 |4.79| 0.02|
|ECDHE-ECDSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDHE-RSA-AES256-SHA384|0 |30.43| 0|
|ECDHE-ECDSA-AES256-SHA384 |0| 0| 0|
|ECDHE-RSA-AES256-SHA |0| 26.92| 0|
|ECDHE-ECDSA-AES256-SHA |0| 0| 0|
|AES256-GCM-SHA384 |0.32| 0.31| 0|
|AES256-SHA256 |0 |0.16 |0|
|AES256-SHA |0 |5.07| 0|
|ECDHE-RSA-AES128-GCM-SHA256|35.68 |30.85 |35.77|
|ECDHE-ECDSA-AES128-GCM-SHA256 |0 |0 |0|
|ECDHE-RSA-AES128-SHA256|0 |0 |31.71|
|ECDHE-ECDSA-AES128-SHA256 |0 |0 |0|
|ECDHE-RSA-AES128-SHA |57.42 |0.15| 8.85|
|ECDHE-ECDSA-AES128-SHA |0 |0 |0|
|ECDHE-RSA-DES-CBC3-SHA |0 |0 |0|
|ECDHE-ECDSA-DES-CBC3-SHA |0 |0 |0|
|AES128-GCM-SHA256 |0 |0 |0.42|
|AES128-SHA256 |0 |0 |0|
|DES-CBC3-SHA |0.79 |0.79 |0|
|ECDHE-RSA-RC4-SHA |0| 0 |16.65|
|ECDHE-ECDSA-RC4-SHA|0 |0 |0|
|RC4-SHA|0 |0 |6.53|
|RC4-MD5|0 |0 |0|
was (Author: shinrich):
I spent today running experiments with a variety of cipher_suite strings.
Based on feedback from my previous suggestion and these experiments, my latest
suggested default cipher_suite list is below (which I referred to as the 6/19
list in the comment above).
{code}
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:AES256-GCM-SHA384:AES128-GCM-SHA256:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
I think it is a good trade off of security, performance, availability, and
reliability for a good out-of-the-box experience.
My final experiment involved three boxes in the same pod. One running with the
list above (6/19 list). One running the list suggested yesterday (6/18 list).
One running the 5.x default.
There was a little bit of CPU difference. The experiment ran for 100 wall
clock minutes. The CPU time for each scenario was
|Scenario|CPU Time|
|6/19 list|130 minutes|
|6/18 list|152 minutes|
|5.x default|180 minutes|
The summary of negotiated protocols
|Cipher |% list 6/19| % list 6/18|% 5.x list|
|ECDHE-RSA-AES256-GCM-SHA384|0.01 |4.79| 0.02|
|ECDHE-ECDSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDHE-RSA-AES256-SHA384|0 |30.43| 0|
|ECDHE-ECDSA-AES256-SHA384 |0| 0| 0|
|ECDHE-RSA-AES256-SHA |0| 26.92| 0|
|ECDHE-ECDSA-AES256-SHA |0| 0| 0|
|ECDH-RSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDH-ECDSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDH-RSA-AES256-SHA384 |0 |0 |0|
|ECDH-ECDSA-AES256-SHA384 |0 |0 |0|
|ECDH-RSA-AES256-SHA|0 |0 |0|
|ECDH-ECDSA-AES256-SHA |0 |0 |0|
|AES256-GCM-SHA384 |0
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594077#comment-14594077
]
Susan Hinrichs commented on TS-3136:
For reference, here is the 5.x default cipher suite list
{code}
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA:RC4-MD5:AES128-SHA:AES256-SHA:DES-CBC3-SHA!SRP:!DSS:!PSK:!aNULL:!eNULL:!SSLv2
{code}
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594073#comment-14594073
]
Susan Hinrichs edited comment on TS-3136 at 6/19/15 11:02 PM:
--
I spent today running experiments with a variety of cipher_suite strings.
Based on feedback from my previous suggestion and these experiments, my latest
suggested default cipher_suite list is below (which I referred to as the 6/19
list in the comment above).
{code}
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:AES256-GCM-SHA384:AES128-GCM-SHA256:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
I think it is a good trade off of security, performance, availability, and
reliability for a good out-of-the-box experience.
My final experiment involved three boxes in the same pod. One running with the
list above (6/19 list). One running the list suggested yesterday (6/18 list).
One running the 5.x default.
There was a little bit of CPU difference. The experiment ran for 100 wall
clock minutes. The CPU time for each scenario was
|Scenario|CPU Time|
|6/19 list|130 minutes|
|6/18 list|152 minutes|
|5.x default|180 minutes|
The summary of negotiated protocols
|Cipher |% list 6/19| % list 6/18|% 5.x list|
|ECDHE-RSA-AES256-GCM-SHA384|0.01 |4.79| 0.02|
|ECDHE-ECDSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDHE-RSA-AES256-SHA384|0 |30.43| 0|
|ECDHE-ECDSA-AES256-SHA384 |0| 0| 0|
|ECDHE-RSA-AES256-SHA |0| 26.92| 0|
|ECDHE-ECDSA-AES256-SHA |0| 0| 0|
|ECDH-RSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDH-ECDSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDH-RSA-AES256-SHA384 |0 |0 |0|
|ECDH-ECDSA-AES256-SHA384 |0 |0 |0|
|ECDH-RSA-AES256-SHA|0 |0 |0|
|ECDH-ECDSA-AES256-SHA |0 |0 |0|
|AES256-GCM-SHA384 |0.32| 0.31| 0|
|AES256-SHA256 |0 |0.16 |0|
|AES256-SHA |0 |5.07| 0|
|ECDHE-RSA-AES128-GCM-SHA256|35.68 |30.85 |35.77|
|ECDHE-ECDSA-AES128-GCM-SHA256 |0 |0 |0|
|ECDHE-RSA-AES128-SHA256|0 |0 |31.71|
|ECDHE-ECDSA-AES128-SHA256 |0 |0 |0|
|ECDHE-RSA-AES128-SHA |57.42 |0.15| 8.85|
|ECDHE-ECDSA-AES128-SHA |0 |0 |0|
|ECDHE-RSA-DES-CBC3-SHA |0 |0 |0|
|ECDHE-ECDSA-DES-CBC3-SHA |0 |0 |0|
|ECDH-RSA-AES128-GCM-SHA256 |0 |0 |0|
|ECDH-ECDSA-AES128-GCM-SHA256 |0 |0 |0|
|ECDH-RSA-AES128-SHA256 |0 |0 |0|
|ECDH-ECDSA-AES128-SHA256 |0 |0 |0|
|ECDH-RSA-AES128-SHA|0 |0 |0|
|ECDH-ECDSA-AES128-SHA |0 |0 |0|
|AES128-GCM-SHA256 |0 |0 |0.42|
|AES128-SHA256 |0 |0 |0|
|DES-CBC3-SHA |0.79 |0.79 |0|
|ECDHE-RSA-RC4-SHA |0| 0 |16.65|
|ECDHE-ECDSA-RC4-SHA|0 |0 |0|
|ECDH-RSA-RC4-SHA |0 |0 |0|
|ECDH-ECDSA-RC4-SHA |0 |0 |0|
|RC4-SHA|0 |0 |6.53|
|RC4-MD5|0 |0 |0|
was (Author: shinrich):
I spent today running experiments with a variety of cipher_suite strings.
Based on feedback from my previous suggestion and these experiments, my latest
suggested default cipher_suite list is below (which I referred to as the 6/19
list in the comment above).
{code}
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:AES256-GCM-SHA384:AES128-GCM-SHA256:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
I think it is a good trade off of security, availability, and reliability for a
good out-of-the-box experience.
My final experiment involved three boxes in the same pod. One running with the
list above (6/19 list). One running the list suggested yesterday (6/18 list).
One running the 5.x default.
There was a little bit of CPU difference. The experiment ran for 100 wall
clock minutes. The CPU time for each scenario was
|Scenario|CPU Time|
|6/19 list|130 minutes|
|6/18 list|152 minutes|
|5.x default|180 minutes|
The summary of negotiated protocols
|Cipher |
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594073#comment-14594073
]
Susan Hinrichs commented on TS-3136:
I spent today running experiments with a variety of cipher_suite strings.
Based on feedback from my previous suggestion and these experiments, my latest
suggested default cipher_suite list is below (which I referred to as the 6/19
list in the comment above).
{code}
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:AES256-GCM-SHA384:AES128-GCM-SHA256:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
I think it is a good trade off of security, availability, and reliability for a
good out-of-the-box experience.
My final experiment involved three boxes in the same pod. One running with the
list above (6/19 list). One running the list suggested yesterday (6/18 list).
One running the 5.x default.
There was a little bit of CPU difference. The experiment ran for 100 wall
clock minutes. The CPU time for each scenario was
|Scenario|CPU Time|
|6/19 list|130 minutes|
|6/18 list|152 minutes|
|5.x default|180 minutes|
The summary of negotiated protocols
|Cipher |% list 6/19| % list 6/18|% 5.x list|
|ECDHE-RSA-AES256-GCM-SHA384|0.01 |4.79| 0.02|
|ECDHE-ECDSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDHE-RSA-AES256-SHA384|0 |30.43| 0|
|ECDHE-ECDSA-AES256-SHA384 |0| 0| 0|
|ECDHE-RSA-AES256-SHA |0| 26.92| 0|
|ECDHE-ECDSA-AES256-SHA |0| 0| 0|
|ECDH-RSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDH-ECDSA-AES256-GCM-SHA384 |0 |0 |0|
|ECDH-RSA-AES256-SHA384 |0 |0 |0|
|ECDH-ECDSA-AES256-SHA384 |0 |0 |0|
|ECDH-RSA-AES256-SHA|0 |0 |0|
|ECDH-ECDSA-AES256-SHA |0 |0 |0|
|AES256-GCM-SHA384 |0.32| 0.31| 0|
|AES256-SHA256 |0 |0.16 |0|
|AES256-SHA |0 |5.07| 0|
|ECDHE-RSA-AES128-GCM-SHA256|35.68 |30.85 |35.77|
|ECDHE-ECDSA-AES128-GCM-SHA256 |0 |0 |0|
|ECDHE-RSA-AES128-SHA256|0 |0 |31.71|
|ECDHE-ECDSA-AES128-SHA256 |0 |0 |0|
|ECDHE-RSA-AES128-SHA |57.42 |0.15| 8.85|
|ECDHE-ECDSA-AES128-SHA |0 |0 |0|
|ECDHE-RSA-DES-CBC3-SHA |0 |0 |0|
|ECDHE-ECDSA-DES-CBC3-SHA |0 |0 |0|
|ECDH-RSA-AES128-GCM-SHA256 |0 |0 |0|
|ECDH-ECDSA-AES128-GCM-SHA256 |0 |0 |0|
|ECDH-RSA-AES128-SHA256 |0 |0 |0|
|ECDH-ECDSA-AES128-SHA256 |0 |0 |0|
|ECDH-RSA-AES128-SHA|0 |0 |0|
|ECDH-ECDSA-AES128-SHA |0 |0 |0|
|AES128-GCM-SHA256 |0 |0 |0.42|
|AES128-SHA256 |0 |0 |0|
|DES-CBC3-SHA |0.79 |0.79 |0|
|ECDHE-RSA-RC4-SHA |0| 0 |16.65|
|ECDHE-ECDSA-RC4-SHA|0 |0 |0|
|ECDH-RSA-RC4-SHA |0 |0 |0|
|ECDH-ECDSA-RC4-SHA |0 |0 |0|
|RC4-SHA|0 |0 |6.53|
|RC4-MD5|0 |0 |0|
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA3
[jira] [Resolved] (TS-3546) For global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-3546.
Resolution: Fixed
> For global plugin registration with TSPluginRegister API and remove version
> information
> ---
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3651) Eliminate proxy.config.http.share_server_sessions
[ https://issues.apache.org/jira/browse/TS-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594042#comment-14594042 ] ASF subversion and git services commented on TS-3651: - Commit 6d0f65a671c8e1440d8b0d5d6051f17052218b77 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6d0f65a ] TS-3651: Update documents to remove references to old server session sharing. Make sharing pool not overridable. > Eliminate proxy.config.http.share_server_sessions > - > > Key: TS-3651 > URL: https://issues.apache.org/jira/browse/TS-3651 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll >Priority: Critical > Labels: Incompatible > Fix For: 6.0.0 > > > We deprecated proxy.config.http.share_server_sessions in v5.x, in favor of a > set of more powerful configuration options. As such, it's time to remove the > old configuration for 6.0.0. This is inline with our normal practice of > 1) Deprecate something in version > 2) Remove that something in version + 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3546) For global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594035#comment-14594035
]
ASF subversion and git services commented on TS-3546:
-
Commit 8b4930e3bd5bd8a11819500b3cc5a3db9cc95d57 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8b4930e ]
TS-3546: For global plugin registration with TSPluginRegister API and remove
version information
Fixed problem with info not being defined in custom_redirect
> For global plugin registration with TSPluginRegister API and remove version
> information
> ---
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2150) Add Milestone log tags
[
https://issues.apache.org/jira/browse/TS-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594033#comment-14594033
]
John Rushford commented on TS-2150:
---
I pulled, built and tested Francois's changes and tested adding a couple of
milestones using the 'ms' and 'msdiff' tag. It looks good. I'll run some more
testing.
> Add Milestone log tags
> --
>
> Key: TS-2150
> URL: https://issues.apache.org/jira/browse/TS-2150
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Leif Hedstrom
>Assignee: John Rushford
> Fix For: sometime
>
>
> We have a notion of milestones in the core, and plugin APIs
> (TSHttpTxnMilestoneGet() ). It'd be useful to expose these milestone timers
> as a log tag, something like:
> {code}
> %<{UA_BEGIN}mtms>
> {code}
> mtms is just an example / suggestion, "MilestoneTimeMilliSecond", we can make
> it whatever we like.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594017#comment-14594017
]
Susan Hinrichs edited comment on TS-3136 at 6/19/15 9:55 PM:
-
I ran an experiment to estimate the impact of DHE on our traffic set. I set up
2048 bit dhparams file and inserted the DHE params ciphers right in front of
the non PFS ciphers. The following cipher percentages changed
|Cipher|6/19 list w/o DHE %|6/19 list with DHE %|
|DHE-RSA-AES128-SHA|0|4.12|
|AES128-SHA|5.78|0|
|AES256-SHA|0|1.28|
These don't all add up to equal exchanges. The other ciphers had small shifts
one way or the other. Even with DHE there are still a small percentage of non
PFS ciphers that sneak through. I did these test in series, so these aren't
the end-all be-all numbers. I just wanted to get some idea on the scale of the
impact. So broadly speaking by introducing DHE most of the non-PFS ciphers get
shifted over to DHE.
However, I would still argue that we should not include DHE in the default
cipher list. Most of the major sites do not offer DHE. We've had a major ATS
deployer experience an increase in SSL errors that went away when DHE was
removed. If you don't install a good DHParam, the DHE protocol can be hacked.
Therefore, for a default stance, I think an ATS deployment will operate more
securely and with less stability risk if DHE is not included in the
cipher_suites list.
was (Author: shinrich):
I ran an experiment to estimate the impact of DHE on our traffic set. I set up
2048 bit dhparams file and inserted the DHE params ciphers right in front of
the non PFS ciphers. The following cipher percentages changed
|Cipher|6/19 list w/o DHE %|6/19 list with DHE %|
|DHE-RSA-AES128-SHA|0|4.12|
|AES128-SHA|5.78|0|
|AES256-SHA|0|1.28|
These don't all add up to equal exchanges. The other ciphers had small shifts
one way or the other. Even with DHE there are still a small percentage of CBC
ciphers that sneak through. I did these test in series, so these aren't the
end-all be-all numbers. I just wanted to get some idea on the scale of the
impact. So broadly speaking by introducing DHE most of the non-PFS ciphers get
shifted over to DHE.
However, I would still argue that we should not include DHE in the default
cipher list. Most of the major sites do not offer DHE. We've had a major ATS
deployer experience an increase in SSL errors that went away when DHE was
removed. If you don't install a good DHParam, the DHE protocol can be hacked.
Therefore, for a default stance, I think an ATS deployment will operate more
securely and with less stability risk if DHE is not included in the
cipher_suites list.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594017#comment-14594017
]
Susan Hinrichs commented on TS-3136:
I ran an experiment to estimate the impact of DHE on our traffic set. I set up
2048 bit dhparams file and inserted the DHE params ciphers right in front of
the non PFS ciphers. The following cipher percentages changed
|_.Cipher|_.6/19 list w/o DHE %|_.6/19 list with DHE %|
|DHE-RSA-AES128-SHA|0|4.12|
|AES128-SHA|5.78|0|
|AES256-SHA|0|1.28|
These don't all add up to equal exchanges. The other ciphers had small shifts
one way or the other. Even with DHE there are still a small percentage of CBC
ciphers that sneak through. I did these test in series, so these aren't the
end-all be-all numbers. I just wanted to get some idea on the scale of the
impact. So broadly speaking by introducing DHE most of the non-PFS ciphers get
shifted over to DHE.
However, I would still argue that we should not include DHE in the default
cipher list. Most of the major sites do not offer DHE. We've had a major ATS
deployer experience an increase in SSL errors that went away when DHE was
removed. If you don't install a good DHParam, the DHE protocol can be hacked.
Therefore, for a default stance, I think an ATS deployment will operate more
securely and with less stability risk if DHE is not included in the
cipher_suites list.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594017#comment-14594017
]
Susan Hinrichs edited comment on TS-3136 at 6/19/15 9:54 PM:
-
I ran an experiment to estimate the impact of DHE on our traffic set. I set up
2048 bit dhparams file and inserted the DHE params ciphers right in front of
the non PFS ciphers. The following cipher percentages changed
|Cipher|6/19 list w/o DHE %|6/19 list with DHE %|
|DHE-RSA-AES128-SHA|0|4.12|
|AES128-SHA|5.78|0|
|AES256-SHA|0|1.28|
These don't all add up to equal exchanges. The other ciphers had small shifts
one way or the other. Even with DHE there are still a small percentage of CBC
ciphers that sneak through. I did these test in series, so these aren't the
end-all be-all numbers. I just wanted to get some idea on the scale of the
impact. So broadly speaking by introducing DHE most of the non-PFS ciphers get
shifted over to DHE.
However, I would still argue that we should not include DHE in the default
cipher list. Most of the major sites do not offer DHE. We've had a major ATS
deployer experience an increase in SSL errors that went away when DHE was
removed. If you don't install a good DHParam, the DHE protocol can be hacked.
Therefore, for a default stance, I think an ATS deployment will operate more
securely and with less stability risk if DHE is not included in the
cipher_suites list.
was (Author: shinrich):
I ran an experiment to estimate the impact of DHE on our traffic set. I set up
2048 bit dhparams file and inserted the DHE params ciphers right in front of
the non PFS ciphers. The following cipher percentages changed
|_.Cipher|_.6/19 list w/o DHE %|_.6/19 list with DHE %|
|DHE-RSA-AES128-SHA|0|4.12|
|AES128-SHA|5.78|0|
|AES256-SHA|0|1.28|
These don't all add up to equal exchanges. The other ciphers had small shifts
one way or the other. Even with DHE there are still a small percentage of CBC
ciphers that sneak through. I did these test in series, so these aren't the
end-all be-all numbers. I just wanted to get some idea on the scale of the
impact. So broadly speaking by introducing DHE most of the non-PFS ciphers get
shifted over to DHE.
However, I would still argue that we should not include DHE in the default
cipher list. Most of the major sites do not offer DHE. We've had a major ATS
deployer experience an increase in SSL errors that went away when DHE was
removed. If you don't install a good DHParam, the DHE protocol can be hacked.
Therefore, for a default stance, I think an ATS deployment will operate more
securely and with less stability risk if DHE is not included in the
cipher_suites list.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3546) For global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594008#comment-14594008
]
ASF subversion and git services commented on TS-3546:
-
Commit a68557a842c6f8d282a3144f7b58a813dccb0b38 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a68557a ]
TS-3546: For global plugin registration with TSPluginRegister API and remove
version information
> For global plugin registration with TSPluginRegister API and remove version
> information
> ---
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2978) Reorder member variables in HttpSM State
[ https://issues.apache.org/jira/browse/TS-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593955#comment-14593955 ] ASF GitHub Bot commented on TS-2978: Github user danobi commented on the pull request: https://github.com/apache/trafficserver/pull/231#issuecomment-113644090 Packed a little more. Now down to 4056B. pahole results [here](http://pastebin.com/rutZmEN7) > Reorder member variables in HttpSM State > > > Key: TS-2978 > URL: https://issues.apache.org/jira/browse/TS-2978 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Daniel Xu > Labels: newbie > Fix For: sometime > > > I think we can reduce its size by reordering for example the booleans such > that we don't have to pad so much ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3546) For global plugin registration with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3546:
---
Summary: For global plugin registration with TSPluginRegister API and
remove version information (was: For plugin registration for global plugins
with TSPluginRegister API and remove version information)
> For global plugin registration with TSPluginRegister API and remove version
> information
> ---
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3546) For plugin registration for global plugins with TSPluginRegister API and remove version information
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3546:
---
Summary: For plugin registration for global plugins with TSPluginRegister
API and remove version information (was: Remove TSPluginRegister API or make
the version checking work)
> For plugin registration for global plugins with TSPluginRegister API and
> remove version information
> ---
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3707) The default for proxy.config.hostdb.host_file.path should be NULL
[
https://issues.apache.org/jira/browse/TS-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593900#comment-14593900
]
ASF subversion and git services commented on TS-3707:
-
Commit ba792a96aa7d81be82ec7f61aca53114e54dcf21 in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ba792a9 ]
TS-3707 clang-format (and fix comment in experimental.h)
> The default for proxy.config.hostdb.host_file.path should be NULL
> -
>
> Key: TS-3707
> URL: https://issues.apache.org/jira/browse/TS-3707
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Labels: yahoo
> Fix For: 6.0.0
>
>
> It was an error for this to be set, it should be {{NULL}} (disabled) by
> default and only used if explicitly enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3679) Remove TSHttpCntlType
[ https://issues.apache.org/jira/browse/TS-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3679. --- Resolution: Won't Fix Fix Version/s: (was: 6.0.0) > Remove TSHttpCntlType > - > > Key: TS-3679 > URL: https://issues.apache.org/jira/browse/TS-3679 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > > This is an old (obsolete) enum / type for the MIXT content types (mms over > HTTP). This is not something we support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3679) Remove TSHttpCntlType
[ https://issues.apache.org/jira/browse/TS-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593896#comment-14593896 ] Leif Hedstrom commented on TS-3679: --- It's possible the documentation here is just weird, not sure this is directly MIXT related. Basically, this API can be used to "control" some HTTP behavior, such as turning off logging. > Remove TSHttpCntlType > - > > Key: TS-3679 > URL: https://issues.apache.org/jira/browse/TS-3679 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > > This is an old (obsolete) enum / type for the MIXT content types (mms over > HTTP). This is not something we support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3270) Eliminate the TSCfgContext*() public APIs
[ https://issues.apache.org/jira/browse/TS-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593889#comment-14593889 ] Leif Hedstrom commented on TS-3270: --- I still think we should remove this, which means removing all of CfgContextManager.cc and the public APIs. But, moving out to 7.0.0 for now. > Eliminate the TSCfgContext*() public APIs > - > > Key: TS-3270 > URL: https://issues.apache.org/jira/browse/TS-3270 > Project: Traffic Server > Issue Type: Improvement > Components: Management API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Blocker > Labels: compatibility > Fix For: 7.0.0 > > > There's a slew of APIs in the public mgmt APIs that I think we should remove, > for three reasons: > 1) We no longer have a web UI, and these were built for that I'm fairly > certain. > 2) We're hopefully switching to some better config system in the not to > distant future, where all the different config formats are unified into > something coherent. > 3) We don't know if they work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3270) Eliminate the TSCfgContext*() public APIs
[ https://issues.apache.org/jira/browse/TS-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3270: -- Fix Version/s: (was: 6.0.0) 7.0.0 > Eliminate the TSCfgContext*() public APIs > - > > Key: TS-3270 > URL: https://issues.apache.org/jira/browse/TS-3270 > Project: Traffic Server > Issue Type: Improvement > Components: Management API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Blocker > Labels: compatibility > Fix For: 7.0.0 > > > There's a slew of APIs in the public mgmt APIs that I think we should remove, > for three reasons: > 1) We no longer have a web UI, and these were built for that I'm fairly > certain. > 2) We're hopefully switching to some better config system in the not to > distant future, where all the different config formats are unified into > something coherent. > 3) We don't know if they work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1795) Check that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593862#comment-14593862 ] ASF subversion and git services commented on TS-1795: - Commit 5b6eb8fb9234768f86d7909a1c1e16a5c95a4d88 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5b6eb8f ] TS-1795 Update docs and defaults to be in sync with RecordsConfig.cc > Check that records.config stays in sync > --- > > Key: TS-1795 > URL: https://issues.apache.org/jira/browse/TS-1795 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 6.0.0 > > > We should integrate the script from TS-1789 into the build and make sure that > records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-1795) Check that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1795. --- Resolution: Fixed > Check that records.config stays in sync > --- > > Key: TS-1795 > URL: https://issues.apache.org/jira/browse/TS-1795 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 6.0.0 > > > We should integrate the script from TS-1789 into the build and make sure that > records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3644) Remove CHANGES file from git
[
https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593839#comment-14593839
]
Phil Sorber commented on TS-3644:
-
The file has been removed from master. It will remain in older release
branches, and of course always in git history.
For the time being, RM's will pull a text formatted copy of the release notes
from JIRA and place them into their respective release branches so that a file
is still shipped with release tarballs and available in git.
Eventually (soon I hope) we will get a more automated process with JIRA REST
API's to do this.
> Remove CHANGES file from git
>
>
> Key: TS-3644
> URL: https://issues.apache.org/jira/browse/TS-3644
> Project: Traffic Server
> Issue Type: Task
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>Priority: Critical
> Fix For: 6.0.0
>
>
> This will be replaced with our online release notes in JIRA + a new step that
> is part of {{make rel}} that uses the JIRA REST API to pull a text version of
> the JIRA release notes into a CHANGES file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3644) Remove CHANGES file from git
[
https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593836#comment-14593836
]
ASF subversion and git services commented on TS-3644:
-
Commit 6ebc926ce81e70735487004a7bb67a68499cedf3 in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6ebc926 ]
TS-3644: Remove CHANGES file from git
> Remove CHANGES file from git
>
>
> Key: TS-3644
> URL: https://issues.apache.org/jira/browse/TS-3644
> Project: Traffic Server
> Issue Type: Task
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>Priority: Critical
> Fix For: 6.0.0
>
>
> This will be replaced with our online release notes in JIRA + a new step that
> is part of {{make rel}} that uses the JIRA REST API to pull a text version of
> the JIRA release notes into a CHANGES file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593806#comment-14593806
]
Eric Sproul commented on TS-3486:
-
Additionally, here's a `bt full` output (thanks [~psudaemon]!)
{noformat}
(gdb) bt full
#0 0x008009d7 in operator IOBufferBlock* (this=0x16218ed0) at
../../lib/ts/Ptr.h:300
No locals.
#1 first_write_block (this=0x16218ec0) at
../../iocore/eventsystem/I_IOBuffer.h:926
No locals.
#2 read_from_net (nh=0x2921760, vc=0x19445740, thread=) at
UnixNetVConnection.cc:275
b =
buf = @0x19445880: {mbuf = 0x16218ec0, entry = 0x0}
toread =
total_read =
r = 0
lock = {m = {m_ptr = 0x13cbe790}, lock_acquired = true}
rattempted =
__FUNCTION__ = "read_from_net"
s = 0x19445858
mutex = 0xfc9150
ntodo = 9223372036854775807
niov =
tiovec = {{iov_base = 0x159bc0a7, iov_len = 3929}, {iov_base =
0xbc7a000, iov_len = 32768}, {iov_base = 0xdd7ffd4a8e40, iov_len =
8270580}, {iov_base = 0x32, iov_len = 428876640}, {
iov_base = 0xdd7ffd4a8e40, iov_len = 18446706140541555064},
{iov_base = 0x0, iov_len = 18883}, {iov_base = 0x1, iov_len = 2487}, {iov_base
= 0x0, iov_len = 8324443}, {
iov_base = 0xdd7ffd4a8e40, iov_len = 8372923}, {iov_base = 0x0,
iov_len = 386230828}, {iov_base = 0xdd7ffd4a8e00, iov_len =
18446706140542042283}, {iov_base = 0x0,
iov_len = 57310352}, {iov_base = 0x0, iov_len = 386230816},
{iov_base = 0x2921760, iov_len = 1434694902351034537}, {iov_base =
0xdd7ffd4a8e40, iov_len = 18446706140541555235}, {
iov_base = 0xdd7ffd4a8e40, iov_len = 16594640}}
#3 0x007f0d17 in NetHandler::mainNetEvent (this=0x2921760,
event=, e=) at UnixNet.cc:546
epd =
pd = 0x4bc1010
retval =
nget = 1
__FUNCTION__ = "mainNetEvent"
poll_timeout = 318363216
vc =
ptimeout = {tv_sec = 0, tv_nsec = 1000}
#4 0x00821e40 in handleEvent (data=0x36a7cf0, event=5, this=) at I_Continuation.h:145
No locals.
#5 process_event (e=0x36a7cf0, this=0x291e010, calling_code=)
at UnixEThread.cc:128
c_temp =
lock = {m = {m_ptr = 0xfc8010}, lock_acquired = true}
calling_code = 5
#6 EThread::execute (this=0x291e010) at UnixEThread.cc:252
done_one =
e =
NegativeQueue =
next_time = 1434694895853026566
#7 0x008205fa in spawn_thread_internal (a=0x36a2a50) at Thread.cc:85
p = 0x36a2a50
#8 0xdd7fff070dba in _thrp_setup () from /lib/64/libc.so.1
No symbol table info available.
#9 0xdd7fff0710d0 in ?? () from /lib/64/libc.so.1
No symbol table info available.
#10 0x in ?? ()
No symbol table info available.
(gdb)
{noformat}
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #1
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593784#comment-14593784
]
Eric Sproul commented on TS-3486:
-
I guess I'm used to debuggers like mdb and dbx that put you in the faulted
thread from the start...
>From dbx I determined it was thread/LWP 26 that segfaulted, AND I grabbed the
>source while I was at it, so...
{noformat}
(gdb) thread 26
[Switching to thread 26 (LWP26)]
#0 0x008009d7 in operator IOBufferBlock* (this=0x16218ed0) at
../../lib/ts/Ptr.h:300
300 operator T *() const { return (m_ptr); }
(gdb) bt
#0 0x008009d7 in operator IOBufferBlock* (this=0x16218ed0) at
../../lib/ts/Ptr.h:300
#1 first_write_block (this=0x16218ec0) at
../../iocore/eventsystem/I_IOBuffer.h:926
#2 read_from_net (nh=0x2921760, vc=0x19445740, thread=) at
UnixNetVConnection.cc:275
#3 0x007f0d17 in NetHandler::mainNetEvent (this=0x2921760,
event=, e=) at UnixNet.cc:546
#4 0x00821e40 in handleEvent (data=0x36a7cf0, event=5, this=) at I_Continuation.h:145
#5 process_event (e=0x36a7cf0, this=0x291e010, calling_code=)
at UnixEThread.cc:128
#6 EThread::execute (this=0x291e010) at UnixEThread.cc:252
#7 0x008205fa in spawn_thread_internal (a=0x36a2a50) at Thread.cc:85
#8 0xdd7fff070dba in _thrp_setup () from /lib/64/libc.so.1
#9 0xdd7fff0710d0 in ?? () from /lib/64/libc.so.1
#10 0x in ?? ()
{noformat}
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_actio
[jira] [Comment Edited] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593733#comment-14593733
]
Eric Sproul edited comment on TS-3486 at 6/19/15 6:20 PM:
--
I realize now that the previous post was erroneous; I don't think that's the
faulting thread. I'm working on getting the right one.
[Edited]
Maybe it's correct after all. [~shinrich] if you think I've screwed something
up, let me know and I'll dig deeper.
was (Author: esproul):
I realize now that the previous post was erroneous; I don't think that's the
faulting thread. I'm working on getting the right one.
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM:
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593733#comment-14593733
]
Eric Sproul commented on TS-3486:
-
I realize now that the previous post was erroneous; I don't think that's the
faulting thread. I'm working on getting the right one.
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #29 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #30 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #31 0x00
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593717#comment-14593717
]
Eric Sproul commented on TS-3486:
-
[~shinrich] I see; gdb is sometimes wonky on illumos, but appears to have
worked well enough here:
{noformat}
(gdb) bt
#0 0xdd7fff07758a in _portfs () from /lib/64/libc.so.1
#1 0xdd7ffeff1223 in port_getn () from /lib/64/libc.so.1
#2 0x007f0bad in NetHandler::mainNetEvent (this=0x1137760,
event=, e=) at UnixNet.cc:472
#3 0x00821e40 in handleEvent (data=0x36a8e30, event=5, this=) at I_Continuation.h:145
#4 process_event (e=0x36a8e30, this=0x1134010, calling_code=)
at UnixEThread.cc:128
#5 EThread::execute (this=0x1134010) at UnixEThread.cc:252
#6 0x00824d0b in main ()
{noformat}
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593687#comment-14593687
]
Susan Hinrichs commented on TS-3486:
Could be due to some inlining.
Maybe just bt will get you line numbers down the stack?
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #29 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #30 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #31 0x2ba11844215d in service_from_this (con
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593671#comment-14593671
]
Eric Sproul commented on TS-3486:
-
[~shinrich] well this is odd, but possibly a C++ism...
My instruction pointer is 0x008009d7, but addr2line puts me in a
header?!?
{noformat}
# gaddr2line -e /opt/circonus/bin/traffic_server 0x008009d7
/tmp/build_esproul/trafficserver-5.3.0/iocore/net/../../lib/ts/Ptr.h:300
{noformat}
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #29 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
>
[jira] [Resolved] (TS-3496) Should we retune proxy.config.cache.mutex_retry_delay ?
[ https://issues.apache.org/jira/browse/TS-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3496. --- Resolution: Won't Fix Fix Version/s: (was: 6.0.0) I tested this at 10, and it makes it worse. > Should we retune proxy.config.cache.mutex_retry_delay ? > --- > > Key: TS-3496 > URL: https://issues.apache.org/jira/browse/TS-3496 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Configuration >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > > I'm starting to wonder that I might have done a boo-boo, and set this default > too short? Should we bump proxy.config.cache.mutex_retry_delay from 2 to 10 > by default? [~amc] > I'm working on a different patch too, making more hardcoded defines > configurable, which also introduces a feature to normalize these retry delays > based on the number of ticks the system has (100 on Linux, 128 on FreeBSD). > So we could auto-scale this to the closest multiplier of these (so, 10 on > Linux, 8 on FreeBSD). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3691) traffic_crashlog messages when running traffic_server -R 1
[
https://issues.apache.org/jira/browse/TS-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3691:
Fix Version/s: (was: 6.0.0)
6.1.0
> traffic_crashlog messages when running traffic_server -R 1
> --
>
> Key: TS-3691
> URL: https://issues.apache.org/jira/browse/TS-3691
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> When I run the regressions (-R 1), I get the following output:
> {code}
> REGRESSION_RESULT PARENTSELECTION: PASSED
> REGRESSION_TEST DONE: PASSED
> root@loki 132/0 # [Jun 14 22:31:48.574] {0x2b3658a84200} NOTE: crashlog
> started, target=18881, debug=false syslog=true, uid=0 euid=0
> [connect] ERROR (main_socket_fd 6): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: failed to intialize
> management API: [5] Error establishing socket connection.
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 128 expected
> signal info bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 936 expected
> thread context bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: logging to 0x22e7c20
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: readlink failed with No such
> file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} ERROR: wrote crash log to
> /opt/ats/var/log/trafficserver/crash-2015-06-14-223148.log
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3691) traffic_crashlog messages when running traffic_server -R 1
[
https://issues.apache.org/jira/browse/TS-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3691:
Assignee: (was: Leif Hedstrom)
> traffic_crashlog messages when running traffic_server -R 1
> --
>
> Key: TS-3691
> URL: https://issues.apache.org/jira/browse/TS-3691
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 6.1.0
>
>
> When I run the regressions (-R 1), I get the following output:
> {code}
> REGRESSION_RESULT PARENTSELECTION: PASSED
> REGRESSION_TEST DONE: PASSED
> root@loki 132/0 # [Jun 14 22:31:48.574] {0x2b3658a84200} NOTE: crashlog
> started, target=18881, debug=false syslog=true, uid=0 euid=0
> [connect] ERROR (main_socket_fd 6): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: failed to intialize
> management API: [5] Error establishing socket connection.
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 128 expected
> signal info bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 936 expected
> thread context bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: logging to 0x22e7c20
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: readlink failed with No such
> file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} ERROR: wrote crash log to
> /opt/ats/var/log/trafficserver/crash-2015-06-14-223148.log
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TS-3669) ☂ Critical issues for v6.0.0 release
[ https://issues.apache.org/jira/browse/TS-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reopened TS-3669: - Assignee: (was: Leif Hedstrom) > ☂ Critical issues for v6.0.0 release > > > Key: TS-3669 > URL: https://issues.apache.org/jira/browse/TS-3669 > Project: Traffic Server > Issue Type: Task > Components: Build >Reporter: Leif Hedstrom > > This is an umbrella ticket for all Jira issues that we need to have resolved > before a v6.0.0 branching event. Please update this with a Link marking your > 6.0.0 issues as blocking this Jira. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3669) ☂ Critical issues for v6.0.0 release
[ https://issues.apache.org/jira/browse/TS-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-3669. --- Resolution: Invalid > ☂ Critical issues for v6.0.0 release > > > Key: TS-3669 > URL: https://issues.apache.org/jira/browse/TS-3669 > Project: Traffic Server > Issue Type: Task > Components: Build >Reporter: Leif Hedstrom > > This is an umbrella ticket for all Jira issues that we need to have resolved > before a v6.0.0 branching event. Please update this with a Link marking your > 6.0.0 issues as blocking this Jira. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3691) traffic_crashlog messages when running traffic_server -R 1
[
https://issues.apache.org/jira/browse/TS-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593656#comment-14593656
]
Leif Hedstrom commented on TS-3691:
---
It seems to only happen on Fedora 22. And no, there's no crash.
> traffic_crashlog messages when running traffic_server -R 1
> --
>
> Key: TS-3691
> URL: https://issues.apache.org/jira/browse/TS-3691
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 6.1.0
>
>
> When I run the regressions (-R 1), I get the following output:
> {code}
> REGRESSION_RESULT PARENTSELECTION: PASSED
> REGRESSION_TEST DONE: PASSED
> root@loki 132/0 # [Jun 14 22:31:48.574] {0x2b3658a84200} NOTE: crashlog
> started, target=18881, debug=false syslog=true, uid=0 euid=0
> [connect] ERROR (main_socket_fd 6): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: failed to intialize
> management API: [5] Error establishing socket connection.
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 128 expected
> signal info bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 936 expected
> thread context bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: logging to 0x22e7c20
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: readlink failed with No such
> file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} ERROR: wrote crash log to
> /opt/ats/var/log/trafficserver/crash-2015-06-14-223148.log
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h
[ https://issues.apache.org/jira/browse/TS-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3681: Fix Version/s: (was: 6.0.0) 6.1.0 > Promote TSHrtime APIs to ts.h /apidefs.h > > > Key: TS-3681 > URL: https://issues.apache.org/jira/browse/TS-3681 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Time to move these from experimental to ts/ts.h / apidefs.h -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h
[ https://issues.apache.org/jira/browse/TS-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3681: Labels: (was: compatibility) > Promote TSHrtime APIs to ts.h /apidefs.h > > > Key: TS-3681 > URL: https://issues.apache.org/jira/browse/TS-3681 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Time to move these from experimental to ts/ts.h / apidefs.h -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h
[ https://issues.apache.org/jira/browse/TS-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3681: Assignee: Sudheer Vinukonda (was: Leif Hedstrom) > Promote TSHrtime APIs to ts.h /apidefs.h > > > Key: TS-3681 > URL: https://issues.apache.org/jira/browse/TS-3681 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Time to move these from experimental to ts/ts.h / apidefs.h -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3669) ☂ Critical issues for v6.0.0 release
[ https://issues.apache.org/jira/browse/TS-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-3669. --- Resolution: Fixed Fix Version/s: (was: 6.0.0) > ☂ Critical issues for v6.0.0 release > > > Key: TS-3669 > URL: https://issues.apache.org/jira/browse/TS-3669 > Project: Traffic Server > Issue Type: Task > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > > This is an umbrella ticket for all Jira issues that we need to have resolved > before a v6.0.0 branching event. Please update this with a Link marking your > 6.0.0 issues as blocking this Jira. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3645) After TS-3033, some traffic_line commands result in "requested command failed"
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593653#comment-14593653
]
Phil Sorber commented on TS-3645:
-
Is this applicable to traffic_ctl as well?
> After TS-3033, some traffic_line commands result in "requested command failed"
> --
>
> Key: TS-3645
> URL: https://issues.apache.org/jira/browse/TS-3645
> Project: Traffic Server
> Issue Type: Bug
> Components: Management API
>Affects Versions: 5.3.0, 6.0.0
> Environment: RHEL 6.x, CentOS 6.x (on x86_64)
>Reporter: Dimitry Andric
> Fix For: 6.1.0
>
>
> I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
> noticed was that certain traffic_line commands started printing "requested
> command failed". For example:
> {noformat}
> # trafficserver start
> Starting Apache Traffic Server:[ OK ]
> # traffic_line --status
> Proxy -- on
> # traffic_line --shutdown
> error: the requested command failed: [11] Invalid parameters passed into
> function call.
> # traffic_line --startup
> error: the requested command failed: [11] Invalid parameters passed into
> function call.
> {noformat}
> Interestingly, even if the --shutdown command gives such an error message,
> the diags.log file still shows that the server has shut down:
> {noformat}
> [May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
> [ProcessManager::processEventQueue] Shutdown msg received, exiting
> {noformat}
> and the --status command also finds the same:
> {noformat}
> # traffic_line --status
> Proxy -- off
> {noformat}
> Similar for the --startup command: though it gives the same error message,
> the command seems to have actually worked.
> I did some bisecting to find where this was introduced, and ended up at
> [commit
> 355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
> (TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
> {{traffic_line --shutdown}} and {{traffic_line --startup}} work without
> printing any error; after the commit, they both start printing "requested
> command failed".
> If I look at all the work done in TS-3033, and the particular change in
> [commit
> 355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
> I would guess that some parts of the code are disagreeing about the number
> of parameters for the PROXY_STATE_GET message.
> Alternatively, there may be some sort of issue in the management API and/or
> marshalling code, where a PROXY_STATE_GET message with two parameters gets
> "cut off" in some way, possibly because the server is just shutting down at
> that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3645) After TS-3033, some traffic_line commands result in "requested command failed"
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3645:
Fix Version/s: (was: 6.0.0)
6.1.0
> After TS-3033, some traffic_line commands result in "requested command failed"
> --
>
> Key: TS-3645
> URL: https://issues.apache.org/jira/browse/TS-3645
> Project: Traffic Server
> Issue Type: Bug
> Components: Management API
>Affects Versions: 5.3.0, 6.0.0
> Environment: RHEL 6.x, CentOS 6.x (on x86_64)
>Reporter: Dimitry Andric
> Fix For: 6.1.0
>
>
> I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
> noticed was that certain traffic_line commands started printing "requested
> command failed". For example:
> {noformat}
> # trafficserver start
> Starting Apache Traffic Server:[ OK ]
> # traffic_line --status
> Proxy -- on
> # traffic_line --shutdown
> error: the requested command failed: [11] Invalid parameters passed into
> function call.
> # traffic_line --startup
> error: the requested command failed: [11] Invalid parameters passed into
> function call.
> {noformat}
> Interestingly, even if the --shutdown command gives such an error message,
> the diags.log file still shows that the server has shut down:
> {noformat}
> [May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
> [ProcessManager::processEventQueue] Shutdown msg received, exiting
> {noformat}
> and the --status command also finds the same:
> {noformat}
> # traffic_line --status
> Proxy -- off
> {noformat}
> Similar for the --startup command: though it gives the same error message,
> the command seems to have actually worked.
> I did some bisecting to find where this was introduced, and ended up at
> [commit
> 355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
> (TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
> {{traffic_line --shutdown}} and {{traffic_line --startup}} work without
> printing any error; after the commit, they both start printing "requested
> command failed".
> If I look at all the work done in TS-3033, and the particular change in
> [commit
> 355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
> I would guess that some parts of the code are disagreeing about the number
> of parameters for the PROXY_STATE_GET message.
> Alternatively, there may be some sort of issue in the management API and/or
> marshalling code, where a PROXY_STATE_GET message with two parameters gets
> "cut off" in some way, possibly because the server is just shutting down at
> that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3487) Cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold
[
https://issues.apache.org/jira/browse/TS-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3487:
---
Summary: Cannot override
proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST
methold (was: cannot override
proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST
methold)
> Cannot override proxy.config.http.transaction_no_activity_timeout_in per
> remap rule for POST methold
>
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
> Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING
> http_cs|http_ss|inactivity.*|socket
> {noformat}
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_remap_config():
> s = get_socket()
> log.info('start test per remap config...')
> try:
> # before remap
> s.send(url2)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(11) # < per remap config
> s.send(body1)
> time.sleep(13) # < per remap config
> s.send(body2)
> log.info('test per remap config: pass!')
> except IOError:
> log.info('test per remap config: fail!')
> response = s.recv(4096)
> print response
> if __name__ == '__main__':
> test_global_config()
> test_per_remap_config()
> {code}
> {{test_global_config()}} would pass, but {{test_per_remap_config()}} fails.
> {{proxy.config.http.transaction_no_activity_timeout_in}} in per remap rule
> does not works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3644) Remove CHANGES file from git
[
https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber reassigned TS-3644:
---
Assignee: Phil Sorber (was: Crystal Qian)
> Remove CHANGES file from git
>
>
> Key: TS-3644
> URL: https://issues.apache.org/jira/browse/TS-3644
> Project: Traffic Server
> Issue Type: Task
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>Priority: Critical
> Fix For: 6.0.0
>
>
> This will be replaced with our online release notes in JIRA + a new step that
> is part of {{make rel}} that uses the JIRA REST API to pull a text version of
> the JIRA release notes into a CHANGES file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3625) Some statistics not being gathered
[ https://issues.apache.org/jira/browse/TS-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3625: Assignee: Leif Hedstrom (was: Bryan Call) > Some statistics not being gathered > -- > > Key: TS-3625 > URL: https://issues.apache.org/jira/browse/TS-3625 > Project: Traffic Server > Issue Type: Bug > Components: Metrics >Reporter: Jon Sime >Assignee: Leif Hedstrom > Labels: compatibility > Fix For: 6.0.0 > > > The following statistics appear to not have any data collected for them in > recent versions of TS, instead only emitting a zero value. The list was put > together by examining the stats_over_http output on a production instance > which receives enough varied traffic that it should, in theory at least, > cause most implemented statistics to go non-zero. > proxy.node.cache.contents.num_docs > proxy.node.cache_hit_mem_ratio_avg_10s_int_pct > proxy.node.cache_hit_mem_ratio_int_pct > proxy.node.current_cache_connections > proxy.node.dns.lookup_avg_time_ms > proxy.node.dns.lookups_per_second > proxy.node.dns.total_dns_lookups > proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct > proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct > proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct > proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct > proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct > proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct > proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct > proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct > proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct > proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct > proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct > proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct > proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct > proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct > proxy.node.log.bytes_flush_to_disk > proxy.node.log.bytes_lost_before_flush_to_disk > proxy.node.log.bytes_lost_before_preproc > proxy.node.log.bytes_lost_before_sent_to_network > proxy.node.log.bytes_lost_before_written_to_disk > proxy.node.log.bytes_received_from_network > proxy.node.log.bytes_received_from_network_avg_10s > proxy.node.log.bytes_sent_to_network > proxy.node.log.bytes_sent_to_network_avg_10s > proxy.node.log.bytes_written_to_disk > proxy.node.log.event_log_access_aggr > proxy.node.log.event_log_access_fail > proxy.node.log.event_log_access_full > proxy.node.log.event_log_access_ok > proxy.node.log.event_log_access_skip > proxy.node.log.event_log_error_aggr > proxy.node.log.event_log_error_fail > proxy.node.log.event_log_error_full > proxy.node.log.event_log_error_ok > proxy.node.log.event_log_error_skip > proxy.node.log.num_flush_to_disk > proxy.node.log.num_lost_before_flush_to_disk > proxy.node.log.num_lost_before_sent_to_network > proxy.node.log.num_received_from_network > proxy.node.log.num_sent_to_network > proxy.process.cache.directory_collision > proxy.process.cache.evacuate.active > proxy.process.cache.evacuate.failure > proxy.process.cache.evacuate.success > proxy.process.cache.frags_per_doc.1 > proxy.process.cache.frags_per_doc.2 > proxy.process.cache.frags_per_doc.3+ > proxy.process.cache.gc_bytes_evacuated > proxy.process.cache.gc_frags_evacuated > proxy.process.cache.hdr_marshal_bytes > proxy.process.cache.hdr_marshals > proxy.process.cache.lookup.active > proxy.process.cache.lookup.failure > proxy.process.cache.lookup.success > proxy.process.cache.percent_full > proxy.process.cache.pread_count > proxy.process.cache.read_busy.failure > proxy.process.cache.read_busy.success > proxy.process.cache.remove.active > proxy.process.cache.remove.failure > proxy.process.cache.remove.success > proxy.process.cache.scan.active > proxy.process.cache.scan.failure > proxy.process.cache.scan.success > proxy.process.cache.volume_0.directory_collision > proxy.process.cache.volume_0.evacuate.active > proxy.process.cache.volume_0.evacuate.failure > proxy.process.cache.volume_0.evacuate.success > proxy.process.cache.volume_0.frags_per_doc.1 > proxy.process.cache.volume_0.frags_per_doc.2 > proxy.process.cache.volume_0.frags_per_doc.3+ > proxy.process.cache.volume_0.gc_bytes_evacuated > proxy.process.cache.volume_0.gc_frags_evacuated > proxy.process.cache.volume_0.hdr_marshal_bytes > proxy.process.cache.volume_0.hdr_marshals > proxy.process.cache.volume_0.lookup.active > proxy.process.cache.volume_0.lookup.failure > proxy.process.cache.volume_0.lookup.success > proxy.process.cache.volume_0.pread_count > proxy.process.cache.volume_0.remove.active > proxy.process.cache.volume_0.remove.failure > proxy.pro
[jira] [Commented] (TS-2978) Reorder member variables in HttpSM State
[ https://issues.apache.org/jira/browse/TS-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593633#comment-14593633 ] ASF GitHub Bot commented on TS-2978: Github user danobi commented on the pull request: https://github.com/apache/trafficserver/pull/231#issuecomment-113575571 pahole results for [unpacked](http://pastebin.com/WwLFSrrG) pahole results for [packed](http://pastebin.com/Cr6jtZac) Although it looks like there's another 200B we can squeeze out, I'm not sure if scrambling up all the variable groupings is worth it. I'll spend some more time trying to get some free bytes today. > Reorder member variables in HttpSM State > > > Key: TS-2978 > URL: https://issues.apache.org/jira/browse/TS-2978 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Daniel Xu > Labels: newbie > Fix For: sometime > > > I think we can reduce its size by reordering for example the booleans such > that we don't have to pad so much ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3642: Fix Version/s: (was: 6.0.0) 5.3.1 > proxy.config.http.share_server_sessions not working > --- > > Key: TS-3642 > URL: https://issues.apache.org/jira/browse/TS-3642 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Affects Versions: 5.3.0 >Reporter: David Carlin >Assignee: Phil Sorber > Fix For: 5.3.1 > > > Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no > longer works. Saw a 10-15x increase in origin connections; there appears to > be some reuse, I am seeing approximately 1.2-1.3 requests per origin > connection. > Setting "proxy.config.http.server_session_sharing.pool = global" restored > expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3642: Backport to Version: 5.3.1 > proxy.config.http.share_server_sessions not working > --- > > Key: TS-3642 > URL: https://issues.apache.org/jira/browse/TS-3642 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Affects Versions: 5.3.0 >Reporter: David Carlin >Assignee: Phil Sorber > Fix For: 5.3.1 > > > Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no > longer works. Saw a 10-15x increase in origin connections; there appears to > be some reuse, I am seeing approximately 1.2-1.3 requests per origin > connection. > Setting "proxy.config.http.server_session_sharing.pool = global" restored > expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3641) Drupal Auth does not seem to work with HTTP/2
[ https://issues.apache.org/jira/browse/TS-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3641: Fix Version/s: (was: 6.0.0) 6.1.0 > Drupal Auth does not seem to work with HTTP/2 > - > > Key: TS-3641 > URL: https://issues.apache.org/jira/browse/TS-3641 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Fix For: 6.1.0 > > > Using latest chrome, when authenticating to a Drupal site behind ATS, it > fails to authenticate. It silently seems to just ignore the auth, and moves > along unauthenticated. It's possible this is similar to TS-3640, but the > "fix" from that Jira does not resolve the HTTP/2 issues. > In fact, this problem exists all the way back to 5.3.0, so the fix here would > also be a back port for 5.3.1 (or 5.3.2). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593620#comment-14593620
]
Susan Hinrichs commented on TS-3486:
[~esproul] a line number in read_from_net would be helpful.
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #29 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #30 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #31 0x2ba11844215d in service_from_this (contp=,
> event=, edata=0x2aaa
[jira] [Updated] (TS-3430) Why cpu 100% on a occasion?
[ https://issues.apache.org/jira/browse/TS-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3430: Fix Version/s: (was: 6.0.0) 6.1.0 > Why cpu 100% on a occasion? > --- > > Key: TS-3430 > URL: https://issues.apache.org/jira/browse/TS-3430 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Zhaonanli >Assignee: Bryan Call > Fix For: 6.1.0 > > > trafficserver 4.2.2; Centos 6.5 64bit; 32G mem. > 1. top: > Cpu0 : 99.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st > Cpu1 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu2 : 99.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st > Cpu3 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu4 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu5 : 99.0%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu6 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu7 : 99.0%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu8 : 99.0%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu9 : 99.0%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu10 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu11 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu12 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu13 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu14 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu15 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 32819596k total, 32507016k used, 312580k free, 325852k buffers > Swap: 16777212k total,25276k used, 16751936k free, 11826164k cached > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 21089 traffics 20 0 22.2g 18g 29m R 100.1 58.9 17:20.61 [ET_NET 0] > > 21091 traffics 20 0 22.2g 18g 29m R 100.1 58.9 17:11.08 [ET_NET 1] > all thread is 100%. > 2. perf top: > 58.50% traffic_server [.] LogObject::_checkout_write(unsigned > long*, unsigned long) > 34.01% traffic_server [.] bool > ink_atomic_cas<__int128>(__int128 volatile*, __int128, __int128) > is log questions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3277) Core durring ssl handshake
[
https://issues.apache.org/jira/browse/TS-3277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3277:
Assignee: Bryan Call
> Core durring ssl handshake
> --
>
> Key: TS-3277
> URL: https://issues.apache.org/jira/browse/TS-3277
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> Running 5.2.0 RC4:
> {code}
> (gdb) bt full
> #0 0x003bae4758a3 in ?? () from /usr/lib64/libcrypto.so.10
> No symbol table info available.
> #1 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #2 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #3 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #4 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #5 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #6 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #7 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #8 0xca62c1d6ca62c1d6 in ?? ()
> No symbol table info available.
> #9 0x003bae7df7d9 in ?? () from /usr/lib64/libcrypto.so.10
> No symbol table info available.
> #10 0x2b87e3249600 in ?? ()
> No symbol table info available.
> #11 0x0026 in ?? () at P_CacheArray.h:157
> No symbol table info available.
> ---Type to continue, or q to quit---
> #12 0x003bae472d27 in SHA1_Update () from /usr/lib64/libcrypto.so.10
> No symbol table info available.
> #13 0x003bae4e6254 in ?? () from /usr/lib64/libcrypto.so.10
> No symbol table info available.
> #14 0x003bae830bb3 in ssl23_connect () from /usr/lib64/libssl.so.10
> No symbol table info available.
> #15 0x0074877c in SSLConnect (ssl=0x2b87e27f6130) at SSLUtils.cc:1937
> ret = 0
> #16 0x0073fe60 in SSLNetVConnection::sslClientHandShakeEvent (
> this=0x2b88706bca90, err=@0x2b8698503af8) at SSLNetVConnection.cc:1080
> __func__ = "sslClientHandShakeEvent"
> ssl_error = 2301
> #17 0x0073f58c in SSLNetVConnection::sslStartHandShake (
> this=0x2b88706bca90, event=1, err=@0x2b8698503af8)
> at SSLNetVConnection.cc:886
> __func__ = "sslStartHandShake"
> #18 0x00753150 in write_to_net_io (nh=0x2b8691f56ad0,
> vc=0x2b88706bca90, thread=0x2b8691f53010) at UnixNetVConnection.cc:376
> err = -1846202352
> ret = 38197360
> buf = @0x740777
> wattempted = 2644
> lock = {m = {m_ptr = 0x2b86d812a4a0}, lock_acquired = true}
> towrite = 1
> ---Type to continue, or q to quit---
> signalled = 10
> total_written = 47856974376976
> r = 47856974376976
> s = 0x2b88706bcc08
> mutex = 0x2c59e30
> ntodo = 47857081006960
> needs = 0
> #19 0x0075300e in write_to_net (nh=0x2b8691f56ad0, vc=0x2b88706bca90,
> thread=0x2b8691f53010) at UnixNetVConnection.cc:353
> mutex = 0x2c59e30
> #20 0x0074c779 in NetHandler::mainNetEvent (this=0x2b8691f56ad0,
> event=5, e=0x25a2f30) at UnixNet.cc:415
> epd = 0x2b8870121990
> pd = 0x2b8699ec8010
> __func__ = "mainNetEvent"
> poll_timeout = 0
> vc = 0x2b88706bca90
> #21 0x00502f98 in Continuation::handleEvent (this=0x2b8691f56ad0,
> event=5, data=0x25a2f30) at ../iocore/eventsystem/I_Continuation.h:146
> No locals.
> #22 0x0077330e in EThread::process_event (this=0x2b8691f53010,
> e=0x25a2f30, calling_code=5) at UnixEThread.cc:144
> c_temp = 0x2b8691f56ad0
> lock = {m = {m_ptr = 0x307be70}, lock_acquired = true}
> ---Type to continue, or q to quit---
> #23 0x00773818 in EThread::execute (this=0x2b8691f53010)
> at UnixEThread.cc:268
> done_one = false
> e = 0x25a2f30
> NegativeQueue = {> = {head = 0x0},
> tail = 0x0}
> next_time = 1420578155814685026
> #24 0x007728c9 in spawn_thread_internal (a=0x2d296d0) at Thread.cc:88
> p = 0x2d296d0
> #25 0x2b85ddb4d851 in start_thread () from /lib64/libpthread.so.0
> No symbol table info available.
> #26 0x0033522e890d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3133) Logging NOTE filling up diags.log
[
https://issues.apache.org/jira/browse/TS-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3133:
Fix Version/s: (was: 6.0.0)
6.1.0
> Logging NOTE filling up diags.log
> -
>
> Key: TS-3133
> URL: https://issues.apache.org/jira/browse/TS-3133
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> In our production systems, we have proxy.config.log.log_buffer_size set to
> the default value of 9216. However, we do see some very large URLs resulting
> in larger log entries (about 26k bytes long). This basically results in the
> warnings like the below from ATS (going into diags.log). This is good, but,
> the problem is that, these WARNING messages alone fill up/flood the diags.log
> pretty fast (which itself is not rotated right now - refer TS-306). The
> correct solution to this is to increase the log buffers, which we are
> implementing, but, it might be nice to not flood the diags.log with the below
> WARNINGs as that might result in losing/missing out on other
> critical/important WARNINGs. We are thinking of implementing some sort of
> throttling on these kind of WARNINGs (for e.g. 1 in every 1000 entries along
> with a count of how many times the log was not displayed).
> Please provide comments/suggestions.
> {code}
> [Oct 10 18:04:13.300] Server {0x2ad39283f700} NOTE: Skipping the current log
> entry for squid.blog because its size (11000) exceeds the maximum payload
> space
> in a log buffer
> [Oct 10 19:13:53.190] Server {0x2b1ccec45700} NOTE: Traffic Server is skipping
> the current log entry because its size exceeds the maximum line (entry) size
> for an ascii log buffer
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2383) Strange errors / warnings from make install related to man pages
[
https://issues.apache.org/jira/browse/TS-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2383:
Fix Version/s: (was: 6.0.0)
6.1.0
> Strange errors / warnings from make install related to man pages
>
>
> Key: TS-2383
> URL: https://issues.apache.org/jira/browse/TS-2383
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Documentation
>Reporter: Leif Hedstrom
>Assignee: Jon Sime
> Fix For: 6.1.0
>
>
> I get
> {code}
> traffic_cop.8 { } None:None: WARNING: No definition found for configuration
> variable 'proxy.config.cop.linux_min_memfree_kb'
> None:None: WARNING: file reference target not found: /tmp/traffic_cop.trace
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1883) SSL origin connections do not support connection timeouts
[
https://issues.apache.org/jira/browse/TS-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-1883:
Assignee: (was: Bryan Call)
> SSL 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
> Fix For: 6.1.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
>
> &t_state.current.server->addr.sa,// addr + port
>&opt);
> } 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 == &t_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
>
> &t_state.current.server->addr.sa,// addr + port
> connect_timeout, &opt);
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1883) SSL origin connections do not support connection timeouts
[
https://issues.apache.org/jira/browse/TS-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-1883:
Fix Version/s: (was: 6.0.0)
6.1.0
> SSL 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: Bryan Call
> Fix For: 6.1.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
>
> &t_state.current.server->addr.sa,// addr + port
>&opt);
> } 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 == &t_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
>
> &t_state.current.server->addr.sa,// addr + port
> connect_timeout, &opt);
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1438) Cache inspector should add trailing slash to CI URL
[
https://issues.apache.org/jira/browse/TS-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-1438:
Fix Version/s: (was: 6.0.0)
6.1.0
> Cache inspector should add trailing slash to CI URL
> ---
>
> Key: TS-1438
> URL: https://issues.apache.org/jira/browse/TS-1438
> Project: Traffic Server
> Issue Type: Bug
> Components: Web UI
>Affects Versions: 3.3.0
> Environment: FreeBSD 9.0
>Reporter: Daniel Gruno
>Assignee: Meera Mosale Nataraja
>Priority: Trivial
> Labels: cache, inspector, webui
> Fix For: 6.1.0
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> When setting up the Cache Inspector as described by the docs
> (http://trafficserver.apache.org/docs/trunk/admin/configuring-cache/index.en.html
> ), an URL snafooey occurs.
> In remap.config I have set:
> map http://dallas.awesomelysecure.org/myCI http://{cache} @action=allow
> When accessing /myCI, I do get the cache inspector, but because it fails to
> add a trailing slash, the links are all broken, pointing to f.x. /lookup_url
> instead of /myCI/lookup_url.
> This could be solved by checking if a trailing slash exists, and if not,
> issuing a 301 redirect to /myCI/.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1795) heck that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1795: Summary: heck that records.config stays in sync (was: check that records.config stays in sync) > heck that records.config stays in sync > -- > > Key: TS-1795 > URL: https://issues.apache.org/jira/browse/TS-1795 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 6.0.0 > > > We should integrate the script from TS-1789 into the build and make sure that > records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1795) check that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1795: Assignee: Leif Hedstrom (was: David Carlin) > check that records.config stays in sync > --- > > Key: TS-1795 > URL: https://issues.apache.org/jira/browse/TS-1795 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 6.0.0 > > > We should integrate the script from TS-1789 into the build and make sure that > records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1795) Check that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1795: Summary: Check that records.config stays in sync (was: heck that records.config stays in sync) > Check that records.config stays in sync > --- > > Key: TS-1795 > URL: https://issues.apache.org/jira/browse/TS-1795 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 6.0.0 > > > We should integrate the script from TS-1789 into the build and make sure that > records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1409) Add webdav methods to ip allow/quick filter
[ https://issues.apache.org/jira/browse/TS-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1409: Fix Version/s: (was: 6.0.0) 6.1.0 > Add webdav methods to ip allow/quick filter > --- > > Key: TS-1409 > URL: https://issues.apache.org/jira/browse/TS-1409 > Project: Traffic Server > Issue Type: Bug > Components: Security >Affects Versions: 3.2.0 >Reporter: Bryan Call >Assignee: Meera Mosale Nataraja > Labels: newbie > Fix For: 6.1.0 > > > I know of PROPFIND and REPORT should be added. There might need to be more > added. > HTTP Extensions for Distributed Authoring -- WEBDAV > http://www.ietf.org/rfc/rfc2518.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1007) SSN Close called before TXN Close
[ https://issues.apache.org/jira/browse/TS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1007: Assignee: Alan M. Carroll > SSN Close called before TXN Close > - > > Key: TS-1007 > URL: https://issues.apache.org/jira/browse/TS-1007 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Nick Kew >Assignee: Alan M. Carroll > Labels: incompatible > Fix For: 6.0.0 > > > Where a plugin implements both SSN_CLOSE_HOOK and TXN_CLOSE_HOOK, the > SSN_CLOSE_HOOK is called first of the two. This messes up normal cleanups! > Details: > Register a SSN_START event globally > In the SSN START, add a TXN_START and a SSN_CLOSE > In the TXN START, add a TXN_CLOSE > Stepping through, I see the order of events actually called, for the simple > case of a one-off HTTP request with no keepalive: > SSN_START > TXN_START > SSN_END > TXN_END > Whoops, SSN_END cleaned up the SSN context, leaving dangling pointers in the > TXN! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-829: --- Assignee: (was: Bryan Call) > socks stats cleanup - some stats are registered, but not used > - > > Key: TS-829 > URL: https://issues.apache.org/jira/browse/TS-829 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.0.0 >Reporter: Bryan Call >Priority: Minor > Labels: incompatible > Fix For: 7.0.0 > > > From reviewing TS-818 I noticed that the stats that were being double > resisted are not used. Some cleanup work should be done for the socks stats. > Stats that are registered, but not used in the code: > [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc > "proxy.process.socks.connections_successful", > "proxy.process.socks.connections_unsuccessful", > "proxy.process.socks.connections_currently_open", > These stats are used some tests, so maybe they should be added back into the > code. > [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match > proxy.process.socks.connections_ * > iocore/net/Net.cc > mgmt/api/remote/APITestCliRemote.cc > test/plugin/test-mgmt/test-mgmt.c > I did however see these stats being used: > [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * > proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-829: --- Fix Version/s: (was: 6.0.0) 7.0.0 > socks stats cleanup - some stats are registered, but not used > - > > Key: TS-829 > URL: https://issues.apache.org/jira/browse/TS-829 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.0.0 >Reporter: Bryan Call >Assignee: Bryan Call >Priority: Minor > Labels: incompatible > Fix For: 7.0.0 > > > From reviewing TS-818 I noticed that the stats that were being double > resisted are not used. Some cleanup work should be done for the socks stats. > Stats that are registered, but not used in the code: > [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc > "proxy.process.socks.connections_successful", > "proxy.process.socks.connections_unsuccessful", > "proxy.process.socks.connections_currently_open", > These stats are used some tests, so maybe they should be added back into the > code. > [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match > proxy.process.socks.connections_ * > iocore/net/Net.cc > mgmt/api/remote/APITestCliRemote.cc > test/plugin/test-mgmt/test-mgmt.c > I did however see these stats being used: > [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * > proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-829: --- Issue Type: Improvement (was: Bug) > socks stats cleanup - some stats are registered, but not used > - > > Key: TS-829 > URL: https://issues.apache.org/jira/browse/TS-829 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.0.0 >Reporter: Bryan Call >Assignee: Bryan Call >Priority: Minor > Labels: incompatible > Fix For: 7.0.0 > > > From reviewing TS-818 I noticed that the stats that were being double > resisted are not used. Some cleanup work should be done for the socks stats. > Stats that are registered, but not used in the code: > [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc > "proxy.process.socks.connections_successful", > "proxy.process.socks.connections_unsuccessful", > "proxy.process.socks.connections_currently_open", > These stats are used some tests, so maybe they should be added back into the > code. > [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match > proxy.process.socks.connections_ * > iocore/net/Net.cc > mgmt/api/remote/APITestCliRemote.cc > test/plugin/test-mgmt/test-mgmt.c > I did however see these stats being used: > [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * > proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-518: -- Fix Version/s: (was: 6.0.0) 6.1.0 > Close UA connection early if the origin sent Connection close:, there's a bad > Content-Length header, and the UA connection has Keep-Alive. > -- > > Key: TS-518 > URL: https://issues.apache.org/jira/browse/TS-518 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Fix For: 6.1.0 > > > In a very special case, we could improve the user experience by forcefully > closing the connection early. The case is > 1) The origin server sends a Content-Length: header that is wrong, where the > CL: value exceeds the actually body size. > 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 > without keep-alive. > 3) The client (and TS) uses Keep-Alive to the UA. > In this case, we can end up stalling the UA until either the UA or the TS > connection times out. It might make sense to prematurely disconnect the > client when this case is detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593573#comment-14593573
]
Susan Hinrichs commented on TS-3136:
It looks like we have around 5% hitting non-PFS protocols.
I'll add an experiment to set a dh params file (to actually activate the DHE
protocols) and see how much of that 5% we can convert to DHE protocols.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3546) Remove TSPluginRegister API or make the version checking work
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3546:
Description:
IRC discussion about it:
{code}
[09:29:39] <@bcall>why do we want plugins to register?
[09:30:06] <@jpeach> afaik historically it's always been a requirement
[09:30:30] <@bcall>I don't think so
[09:30:33] <@jpeach> imho there should be a way for plugin to fail at
startup
[09:30:53] <@jpeach> if register does nothing useful then we should just
remove it
[09:31:46] <@bcall>it was used for API version checking from what I
remember
[09:31:52] <@jpeach> but registration creates internal info that could be
used for something interesting
[09:31:54] <@bcall>and I never did it in my plugins
[09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
[09:32:52] <@jpeach> heh
[09:32:54] <@bcall>it is helpful for 3rd party plugins - vender, email, etc
[09:33:13] <@bcall>and api version checking
[09:33:14] <@jpeach> that information never goes anywhere
[09:33:20] <@bcall>I can see the merit of the version checking
[09:33:21] <@jpeach> the version checking does nothing
[09:33:28] <@bcall>even better :)
[09:33:40] <@jpeach> sounds like you should nuke it for 6.0
[09:34:09] <@bcall>I will file a bug
{code}
was:
IRC discussion about it:
{code}
09:29:39] <@bcall> why do we want plugins to register?
[09:30:06] <@jpeach> afaik historically it's always been a requirement
[09:30:30] <@bcall>I don't think so
[09:30:33] <@jpeach> imho there should be a way for plugin to fail at
startup
[09:30:53] <@jpeach> if register does nothing useful then we should just
remove it
[09:31:46] <@bcall>it was used for API version checking from what I
remember
[09:31:52] <@jpeach> but registration creates internal info that could be
used for something interesting
[09:31:54] <@bcall>and I never did it in my plugins
[09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
[09:32:52] <@jpeach> heh
[09:32:54] <@bcall>it is helpful for 3rd party plugins - vender, email, etc
[09:33:13] <@bcall>and api version checking
[09:33:14] <@jpeach> that information never goes anywhere
[09:33:20] <@bcall>I can see the merit of the version checking
[09:33:21] <@jpeach> the version checking does nothing
[09:33:28] <@bcall>even better :)
[09:33:40] <@jpeach> sounds like you should nuke it for 6.0
[09:34:09] <@bcall>I will file a bug
{code}
> Remove TSPluginRegister API or make the version checking work
> -
>
> Key: TS-3546
> URL: https://issues.apache.org/jira/browse/TS-3546
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> IRC discussion about it:
> {code}
> [09:29:39] <@bcall> why do we want plugins to register?
> [09:30:06] <@jpeach> afaik historically it's always been a requirement
> [09:30:30] <@bcall> I don't think so
> [09:30:33] <@jpeach> imho there should be a way for plugin to fail at
> startup
> [09:30:53] <@jpeach> if register does nothing useful then we should just
> remove it
> [09:31:46] <@bcall> it was used for API version checking from what I
> remember
> [09:31:52] <@jpeach> but registration creates internal info that could be
> used for something interesting
> [09:31:54] <@bcall> and I never did it in my plugins
> [09:32:18] <@sudheerv> fwiw, i think i didn't either ;)
> [09:32:52] <@jpeach> heh
> [09:32:54] <@bcall> it is helpful for 3rd party plugins - vender, email, etc
> [09:33:13] <@bcall> and api version checking
> [09:33:14] <@jpeach> that information never goes anywhere
> [09:33:20] <@bcall> I can see the merit of the version checking
> [09:33:21] <@jpeach> the version checking does nothing
> [09:33:28] <@bcall> even better :)
> [09:33:40] <@jpeach> sounds like you should nuke it for 6.0
> [09:34:09] <@bcall> I will file a bug
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3697) Fix frame type array check for http/2 is invalid
[ https://issues.apache.org/jira/browse/TS-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593550#comment-14593550 ] Phil Sorber commented on TS-3697: - Should this be backported to 5.3.x? > Fix frame type array check for http/2 is invalid > > > Key: TS-3697 > URL: https://issues.apache.org/jira/browse/TS-3697 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 6.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593528#comment-14593528
]
Ivan Ristic commented on TS-3136:
-
[~shinrich] the value of keeping DHE around is to use for fallback for clients
that don't support ECDHE. If you don't have DHE, such clients would use the RSA
key exchange instead, leaving their traffic without forward secrecy. Because
the support for ECDHE is widespread, only a small number of clients would be
affected by the removal of DHE, but it's difficult to know exactly how much,
given that everyone's user profile is slightly different. In your example
above, I think that would be below 1%. At that rate, you might argue that the
RSA key exchange is acceptable. For what it's worth, Google doesn't use DHE on
their servers.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593519#comment-14593519
]
Ivan Ristic commented on TS-3136:
-
That's great, thanks! By the way, if ATS is currently using fixed 1024-bit DH
parameters, chances are that all its DH traffic can be passively decrypted by a
state-level attacker. This was the recent Logjam discovery. If you do decide to
stay with 1024 bits, the only reasonably safe approach is to generate
per-server DH parameters during installation. Although it's best to transition
to 2048-bit parameters, you should be aware that Java command line clients
can't handle anything above 1024 bits.
There is also a performance penalty associated with increasing DH parameters to
2048 bits, but, judging from your numbers, DHE would almost never be used.
Actually, after a closer look, it doesn't seem that you have
EDH-RSA-DES-CBC3-SHA in your proposed configuration. If you add it just before
DES-CBC3-SHA, it's possible that the clients currently using 3DES would use
this cipher suite instead.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3246) TSHttpTxnRedirectUrlSet support POST
[ https://issues.apache.org/jira/browse/TS-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-3246: Assignee: Susan Hinrichs (was: Alan M. Carroll) > TSHttpTxnRedirectUrlSet support POST > > > Key: TS-3246 > URL: https://issues.apache.org/jira/browse/TS-3246 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Daniel Vitor Morilha >Assignee: Susan Hinrichs > Fix For: sometime > > > Make TSHttpTxnRedirectUrlSet support POST payloads. It currently sends the > payload only for the first origin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593518#comment-14593518
]
Susan Hinrichs commented on TS-3136:
TS-3624 is the bug Igor filed suggesting that we autogenerate DH parameters
periodically. Don't think we want to do that for 6.0 at this point.
The way it currently stands, unless you specify a dhparams file, no dhparams is
registered, so the DHE ciphers won't be negotiated (which explains why my
measurements had no DHE ciphers). At one point in 5.2/5.3 we registered a 2048
bit DH param from RFC 5114, but that messed things up for [~briang] so the
change was backed out and the param is only set if the user specifies it via a
file.
In my opinion for 6.0, we should either:
* Remove DHE from the list of default ciphers
* Re-introduce an auto-generated DH param so the DHE ciphers might get
negotiated.
>From a lazy developer's perspective I'd vote for just removing DHE from the
>list. It looks like ECDHE is pretty prevalent. Is there big value for
>keeping DHE in the defaults?
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3246) TSHttpTxnRedirectUrlSet support POST
[ https://issues.apache.org/jira/browse/TS-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-3246: --- Assignee: Alan M. Carroll > TSHttpTxnRedirectUrlSet support POST > > > Key: TS-3246 > URL: https://issues.apache.org/jira/browse/TS-3246 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Daniel Vitor Morilha >Assignee: Alan M. Carroll > Fix For: sometime > > > Make TSHttpTxnRedirectUrlSet support POST payloads. It currently sends the > payload only for the first origin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593501#comment-14593501
]
Eric Sproul commented on TS-3486:
-
[~shinrich] We had to disable our Backtrace crash logger because the way it is
implemented it breaks service management (meaning the service won't
stop/restart properly). I do have core files. Once it started crashing, there
were 5 crashes in about 8 hours, but we've gone about 9 hours now with no
crashes.
I can't share the core file but I can try to extract whatever you need; I'm not
all that good with a debugger though so no promises. :)
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM::state_api_callou
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593493#comment-14593493
]
Susan Hinrichs commented on TS-3486:
Bummer. It looks like we still have a freed netvc lingering in the event
processing queue.
[~bettydreamit] and [~esproul] is the crash frequency lower? [~esproul] do you
have some trace information on your crash?
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #29 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #30 0x004d7a1b in TSHttpTxnR
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593477#comment-14593477
]
Susan Hinrichs commented on TS-3136:
[~jeaglesham] and [~ivanr] thanks for your comments.
Looking back at the performance numbers that [~davet] did last year, the AES128
vs AES256 performance numbers are consistent with yours Ivan. I'm really
surprised that SHA256 vs SHA would have such a big performance impact. Since
SHA has been broken so long, I just had a knee jerk reaction against it. But I
think you make a good argument that SHA is good enough in that case.
You do bring up a good point about the dhparams. We do provide a means to set
your own, but I think the default is the 1024 bit one, which is no good these
days. [~bcall] what do you think about setting a 2048 bit DHParam by default?
I think [~i.galic] filed a bug on dh params a while back. I'll review the
current state of things.
Since this string is supposed to be reasonable for at least the coming year,
adding ChaCha seems quite reasonable.
I think doing the additional test that you suggest is a good idea. I'll see if
ops will give me two or three machines so I can compare my proposed string from
yesterday, an updated string based on your comments, and potentially the 5.x
default cipher string.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3486) Segfault in do_io_write with plugin (??)
[
https://issues.apache.org/jira/browse/TS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593433#comment-14593433
]
Eric Sproul commented on TS-3486:
-
We saw some crashes overnight as well, but they are different from the previous
ones. All the stacks look like this:
{noformat}
read_from_net(NetHandler*, UnixNetVConnection*, EThread*)+0x2d7()
NetHandler::mainNetEvent+0x1f7()
EThread::execute+0x8d0()
spawn_thread_internal(void*)+0x4a()
libc.so.1`_thrp_setup+0x8a(dd7ffecdc280)
libc.so.1`_lwp_start()
{noformat}
So, possibly something else. Didn't see any open issues that looked related.
> Segfault in do_io_write with plugin (??)
>
>
> Key: TS-3486
> URL: https://issues.apache.org/jira/browse/TS-3486
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Qiang Li
>Assignee: Phil Sorber
> Labels: crash
> Fix For: sometime
>
> Attachments: ts3486-ptrace.txt.gz
>
>
> {code}
> (gdb) bt
> #0 0x005bdb8b in HttpServerSession::do_io_write (this= optimized out>, c=0x2aaadccc4bf0, nbytes=576, buf=0x2aaafc2ffee8, owner=false)
> at HttpServerSession.cc:104
> #1 0x005acc1d in HttpSM::setup_server_send_request
> (this=0x2aaadccc4bf0) at HttpSM.cc:5686
> #2 0x005b3f85 in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1520
> #3 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1455
> #4 0x005b980b in HttpSM::state_api_callback (this=0x2aaadccc4bf0,
> event=6, data=0x0) at HttpSM.cc:1275
> #5 0x004d7a1b in TSHttpTxnReenable (txnp=0x2aaadccc4bf0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
> #6 0x2ba118441c89 in cachefun (contp=, event= optimized out>, edata=0x2aaadccc4bf0) at main.cpp:1876
> #7 0x005b4466 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=, data=) at HttpSM.cc:1381
> #8 0x005b627d in HttpSM::do_http_server_open (this=0x2aaadccc4bf0,
> raw=) at HttpSM.cc:4639
> #9 0x005baa04 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:7021
> #10 0x005b25a3 in HttpSM::state_cache_open_write
> (this=0x2aaadccc4bf0, event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2442
> #11 0x005b5b28 in HttpSM::main_handler (this=0x2aaadccc4bf0,
> event=1108, data=0x2aab1c3b6800) at HttpSM.cc:2554
> #12 0x0059338a in handleEvent (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at
> ../../iocore/eventsystem/I_Continuation.h:145
> #13 HttpCacheSM::state_cache_open_write (this=0x2aaadccc6618, event= optimized out>, data=0x2aab1c3b6800) at HttpCacheSM.cc:167
> #14 0x00697223 in handleEvent (this=0x2aab1c3b6800, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:145
> #15 CacheVC::callcont (this=0x2aab1c3b6800, event=) at
> ../../iocore/cache/P_CacheInternal.h:662
> #16 0x00715940 in Cache::open_write (this=,
> cont=, key=0x2ba0ff762d70, info=,
> apin_in_cache=46914401429576, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aaadd281078
> "www.mifangba.comhttpapi.phpwww.mifangba.comhttp://www.mifangba.com/api.php?op=count&id=4&modelid=12";,
> host_len=16) at CacheWrite.cc:1788
> #17 0x006e5765 in open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
> P_CacheInternal.h:1093
> #18 CacheProcessor::open_write (this=,
> cont=0x2aaadccc6618, expected_size=, url=0x2aaadccc5310,
> cluster_cache_local=, request=,
> old_info=0x0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3622
> #19 0x005936f0 in HttpCacheSM::open_write (this=0x2aaadccc6618,
> url=, request=, old_info= optimized out>,
> pin_in_cache=, retry=,
> allow_multiple=false) at HttpCacheSM.cc:298
> #20 0x005a022e in HttpSM::do_cache_prepare_action
> (this=0x2aaadccc4bf0, c_sm=0x2aaadccc6618, object_read_info=0x0, retry=true,
> allow_multiple=false) at HttpSM.cc:4511
> #21 0x005babd9 in do_cache_prepare_write (this=0x2aaadccc4bf0) at
> HttpSM.cc:4436
> #22 HttpSM::set_next_state (this=0x2aaadccc4bf0) at HttpSM.cc:7098
> #23 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #24 0x005b45f8 in HttpSM::state_api_callout (this=0x2aaadccc4bf0,
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x005ba712 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6876
> #26 0x005ba702 in HttpSM::set_next_state (this=0x2aaadccc4bf0) at
> HttpSM.cc:6919
> #27 0x005b3f5f in HttpSM::handle_api_return (this=0x2aaadccc4bf0) at
> HttpSM.cc:1517
> #28 0x005b45f8 in HttpSM::state_api_callout (t
[jira] [Comment Edited] (TS-3136) Change default TLS cipher suites
[ https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593193#comment-14593193 ] Ivan Ristic edited comment on TS-3136 at 6/19/15 8:42 AM: -- I think the proposed cipher suite selection is pretty good in terms of security, but it can be improved for performance. Here are my suggestions: - Prefer AES128 over AES256. The latter is about 8% slower (for bulk transfers, not handshakes) but no better for security. In fact, some believe that AES128 is stronger. - Prefer SHA non-GCM suites over SHA256 and SHA384. Non-GCM suites that use SHA256 and SHA384 are _much_ slower over those that use SHA. I never measured the difference for SHA384, but SHA256 suites are twice as slow (bulk tranfers, not handshakes) as their SHA counterparts. At the same time, there is no measurable security advantage. Non-GCM suites use hash functions for integrity validation in tandem with HMAC and there are no known practical attacks against them. - Additionally, SHA256 and SHA384 introduce additional transport overhead (increasing the size of each TLS record), because these hashes are substantially larger. - Side note: despite the same suffix (e.g., SHA256 and SHA384), GCM suites don't use these hash functions in the same way as non-GCM suites. For that reason, they're not slow. In fact, they're the fastest suites currently available. If you're curious, in the names of GCM suites, the SHA256/SHA384 prefix denotes the hashing function used by the protocol's pseudorandom function (PRF). - Please make sure that your DH parameters are at least 2048 bits. I don't know if this isn't the case at the moment, but 1024-bit parameters are very common and yet weak. - If you want to be at the cutting edge of TLS performance, consider adding support for ChaCha20-Poly1305 suites. These are not yet supported by OpenSSL, but they will be soon. LibreSSL supports them natively. CloudFlare maintain an OpenSSL fork that adds support. ChaCha20 suites are strong and provide better performance for mobile users... Chrome has been using them extensively. You should test, but it may be that simply adding the ChaCha20 suites by name to your configuration is enough when ATS is running against a library that supports them. There's a catch when it comes to suite ordering: for desktop users ChaCha20 should be below GCM suites; for mobile users, ChaCha20 should come first. I believe the OpenSSL patch handles this. When you look at CloudFlare's suite configuration https://www.ssllabs.com/ssltest/analyze.html?d=cloudflare.com you can see that the ChaCha20 suites are at the end. I believe that OpenSSL detects mobile users somehow and selects a ChaCha20 suite even though they're nominally at the bottom. I haven't tested this myself. [~shinrich] to be absolely sure about any performance degradation, is it possible that you disconnect two servers from the persistent session storage? Leave one server with the original cipher suite configuration and try the new configuration the other. Source: Bulletproof SSL and TLS, chapter 9. (I am the author.) Disclaimer: all benchmarks performed on servers that support AES-NI hardware acceleration. was (Author: ivanr): I think the proposed cipher suite selection is pretty good in terms of security, but it can be improved for performance. Here are my suggestions: - Prefer AES128 over AES256. The latter is about 8% slower (for bulk transfers, not handshakes) but no better for security. In fact, some believe that AES128 is stronger. - Prefer SHA non-GCM suites over SHA256 and SHA384. Non-GCM suites that use SHA256 and SHA384 are _much_ slower over those that use SHA. I never measured the difference for SHA384, but SHA256 suites are twice as slow (bulk tranfers, not handshakes) as their SHA counterparts. At the same time, there is no measurable security advantage. Non-GCM suites use hash functions for integrity validation in tandem with HMAC and there are no known practical attacks against them. - Additionally, SHA256 and SHA384 introduce additional transport overhead (per each TLS record), because these hashes are substantially larger. - Side note: despite the same suffix (e.g., SHA256 and SHA384), GCM suites don't use these hash functions in the same way as non-GCM suites. For that reason, they're not slow. In fact, they're the fastest suites currently available. If you're curious, in the names of GCM suites, the SHA256/SHA384 prefix denotes the hashing function used by the protocol's pseudorandom function (PRF). - Please make sure that your DH parameters are at least 2048 bits. I don't know if this isn't the case at the moment, but 1024-bit parameters are very common and yet weak. - If you want to be at the cutting edge of TLS performance, consider adding support for ChaCha20-Poly1305 suites. These are not yet supported by Op
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593193#comment-14593193
]
Ivan Ristic commented on TS-3136:
-
I think the proposed cipher suite selection is pretty good in terms of
security, but it can be improved for performance. Here are my suggestions:
- Prefer AES128 over AES256. The latter is about 8% slower (for bulk transfers,
not handshakes) but no better for security. In fact, some believe that AES128
is stronger.
- Prefer SHA non-GCM suites over SHA256 and SHA384. Non-GCM suites that use
SHA256 and SHA384 are _much_ slower over those that use SHA. I never measured
the difference for SHA384, but SHA256 suites are twice as slow (bulk tranfers,
not handshakes) as their SHA counterparts. At the same time, there is no
measurable security advantage. Non-GCM suites use hash functions for integrity
validation in tandem with HMAC and there are no known practical attacks against
them.
- Additionally, SHA256 and SHA384 introduce additional transport overhead (per
each TLS record), because these hashes are substantially larger.
- Side note: despite the same suffix (e.g., SHA256 and SHA384), GCM suites
don't use these hash functions in the same way as non-GCM suites. For that
reason, they're not slow. In fact, they're the fastest suites currently
available. If you're curious, in the names of GCM suites, the SHA256/SHA384
prefix denotes the hashing function used by the protocol's pseudorandom
function (PRF).
- Please make sure that your DH parameters are at least 2048 bits. I don't know
if this isn't the case at the moment, but 1024-bit parameters are very common
and yet weak.
- If you want to be at the cutting edge of TLS performance, consider adding
support for ChaCha20-Poly1305 suites. These are not yet supported by OpenSSL,
but they will be soon. LibreSSL supports them natively. CloudFlare maintain an
OpenSSL fork that adds support. ChaCha20 suites are strong and provide better
performance for mobile users... Chrome has been using them extensively. You
should test, but it may be that simply adding the ChaCha20 suites by name to
your configuration is enough when ATS is running against a library that
supports them. There's a catch when it comes to suite ordering: for desktop
users ChaCha20 should be below GCM suites; for mobile users, ChaCha20 should
come first. I believe the OpenSSL patch handles this. When you look at
CloudFlare's suite configuration
https://www.ssllabs.com/ssltest/analyze.html?d=cloudflare.com&s=198.41.214.163
you can see that the ChaCha20 suites are at the end. I believe that OpenSSL
detects mobile users somehow and selects a ChaCha20 suite even though they're
nominally at the bottom. I haven't tested this myself.
[~shinrich] to be absolely sure about any performance degradation, is it
possible that you disconnect two servers from the persistent session storage?
Leave one server with the original cipher suite configuration and try the new
configuration the other.
Source: Bulletproof SSL and TLS, chapter 9. (I am the author.) Disclaimer: all
benchmarks performed on servers that support AES-NI hardware acceleration.
> Change default TLS cipher suites
>
>
> Key: TS-3136
> URL: https://issues.apache.org/jira/browse/TS-3136
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: compatibility
> Fix For: 6.0.0
>
>
> In TS-3135 [~i.galic] suggested:
> {quote}
> also, recommendations for a safer ciphersuite:
> SSLCipherSuite
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
>
> from https://cipherli.st/
> {quote}
> [~jacksontj] had responded with:
> {quote}
> [~i.galic] That cipher quite is geared towards security, but doesn't support
> quite a few older clients. I'd recommend we use the suite from mozilla
> (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
> which is a good mix of security and compatibility:
> {code}
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-
