[jira] [Comment Edited] (TS-3365) Enable C99 by default
[ https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584932#comment-14584932 ] Leif Hedstrom edited comment on TS-3365 at 6/14/15 4:42 AM: Yeah, but that's not true for all platforms. RHEL6 is default -std=gnu89. was (Author: zwoop): Yeah, but that's not true for all platforms. RHEL6 is default -std=gnu-89. Enable C99 by default - Key: TS-3365 URL: https://issues.apache.org/jira/browse/TS-3365 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: compatibility Fix For: 6.0.0 We already took the plunge with using bool from C99, so we should enable C99 on the CFLAGS. So, -std=c99. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3365) Enable C99 by default
[ https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584932#comment-14584932 ] Leif Hedstrom commented on TS-3365: --- Yeah, but that's not true for all platforms. RHEL6 is default -std=gnu-89. Enable C99 by default - Key: TS-3365 URL: https://issues.apache.org/jira/browse/TS-3365 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: compatibility Fix For: 6.0.0 We already took the plunge with using bool from C99, so we should enable C99 on the CFLAGS. So, -std=c99. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3609) Upstream cert validation error triggers connection retry
[ https://issues.apache.org/jira/browse/TS-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-3609: Fix Version/s: sometime Upstream cert validation error triggers connection retry Key: TS-3609 URL: https://issues.apache.org/jira/browse/TS-3609 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Uri Shachar Assignee: Uri Shachar Fix For: sometime When we fail the validation of upstream SSL certificate we treat it as a regular connection failure and retry with the same SSL parameters -- even though there's no reason to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3609) Upstream cert validation error triggers connection retry
[ https://issues.apache.org/jira/browse/TS-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-3609: Fix Version/s: (was: 6.0.0) Upstream cert validation error triggers connection retry Key: TS-3609 URL: https://issues.apache.org/jira/browse/TS-3609 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Uri Shachar Assignee: Uri Shachar Fix For: sometime When we fail the validation of upstream SSL certificate we treat it as a regular connection failure and retry with the same SSL parameters -- even though there's no reason to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3365) Enable C99 by default
[ https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-3365. - Resolution: Invalid Enable C99 by default - Key: TS-3365 URL: https://issues.apache.org/jira/browse/TS-3365 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: compatibility Fix For: 6.0.0 We already took the plunge with using bool from C99, so we should enable C99 on the CFLAGS. So, -std=c99. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3609) Upstream cert validation error triggers connection retry
[ https://issues.apache.org/jira/browse/TS-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-3609: Fix Version/s: (was: sometime) 6.1.0 Upstream cert validation error triggers connection retry Key: TS-3609 URL: https://issues.apache.org/jira/browse/TS-3609 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Uri Shachar Assignee: Uri Shachar Fix For: 6.1.0 When we fail the validation of upstream SSL certificate we treat it as a regular connection failure and retry with the same SSL parameters -- even though there's no reason to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584606#comment-14584606 ] ASF GitHub Bot commented on TS-1125: Github user ffcai commented on the pull request: https://github.com/apache/trafficserver/pull/216#issuecomment-111710928 OK, looking forward to @zwoop 's comments. If this is not accept, we'd have to ask some intercept plugin for adding another 100 continue hack in its own logic. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff, TS-1125.diff, ts1125.diff, ts1125.diff, ts1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3477) Determine thread affinity defaults automatically based on hwloc
[
https://issues.apache.org/jira/browse/TS-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber resolved TS-3477.
-
Resolution: Implemented
Determine thread affinity defaults automatically based on hwloc
---
Key: TS-3477
URL: https://issues.apache.org/jira/browse/TS-3477
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Sudheer Vinukonda
Assignee: Phil Sorber
Fix For: 6.0.0
{{proxy.config.exec_thread.affinity}} allows to configure the thread affinity
depending on the system configuration.
https://docs.trafficserver.apache.org/en/latest/reference/configuration/records.config.en.html#proxy-config-exec-thread-affinity
It would be nice if ATS can default automatically to the appropriate setting
based on the configuration from hwloc to reduce unnecessary complexity for an
end user configuring ATS.
[~zwoop] suggests to default to {{2 - assign threads to sockets}}, if there's
more than one NUMA node and {{0 - assign threads to machine}}, if not.
{code}
zwoop
8:38 if you have more than one NUMA node, probably default to 2, otherwise,
default to 0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-3136:
--
Assignee: Susan Hinrichs (was: Syeda Persia Aziz)
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-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584679#comment-14584679
]
ASF subversion and git services commented on TS-3282:
-
Commit a0ab3023cd9481c30856fb9e3dd1521fc1db96e3 in trafficserver's branch
refs/heads/master from [~portl4t]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a0ab302 ]
TS-3282: Add mp4 streaming plugin
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Assignee: Phil Sorber
Fix For: 6.0.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584680#comment-14584680
]
ASF subversion and git services commented on TS-3282:
-
Commit 2c3f87907131ff21bb1831acd12901b57003696d in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2c3f879 ]
TS-3282: Add to CHANGES and clang-format
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Assignee: Phil Sorber
Fix For: 6.0.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3477) Determine thread affinity defaults automatically based on hwloc
[
https://issues.apache.org/jira/browse/TS-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584653#comment-14584653
]
ASF subversion and git services commented on TS-3477:
-
Commit 56a32d10f5d3e649c22dfc01d585100c58e8e377 in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=56a32d1 ]
TS-3477: Change the default thread affinity to 1 (NUMA node)
Determine thread affinity defaults automatically based on hwloc
---
Key: TS-3477
URL: https://issues.apache.org/jira/browse/TS-3477
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Sudheer Vinukonda
Assignee: Phil Sorber
Fix For: 6.0.0
{{proxy.config.exec_thread.affinity}} allows to configure the thread affinity
depending on the system configuration.
https://docs.trafficserver.apache.org/en/latest/reference/configuration/records.config.en.html#proxy-config-exec-thread-affinity
It would be nice if ATS can default automatically to the appropriate setting
based on the configuration from hwloc to reduce unnecessary complexity for an
end user configuring ATS.
[~zwoop] suggests to default to {{2 - assign threads to sockets}}, if there's
more than one NUMA node and {{0 - assign threads to machine}}, if not.
{code}
zwoop
8:38 if you have more than one NUMA node, probably default to 2, otherwise,
default to 0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3477) Determine thread affinity defaults automatically based on hwloc
[
https://issues.apache.org/jira/browse/TS-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584652#comment-14584652
]
Phil Sorber commented on TS-3477:
-
I think it should be 1 as well.
Determine thread affinity defaults automatically based on hwloc
---
Key: TS-3477
URL: https://issues.apache.org/jira/browse/TS-3477
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Sudheer Vinukonda
Assignee: Phil Sorber
Fix For: 6.0.0
{{proxy.config.exec_thread.affinity}} allows to configure the thread affinity
depending on the system configuration.
https://docs.trafficserver.apache.org/en/latest/reference/configuration/records.config.en.html#proxy-config-exec-thread-affinity
It would be nice if ATS can default automatically to the appropriate setting
based on the configuration from hwloc to reduce unnecessary complexity for an
end user configuring ATS.
[~zwoop] suggests to default to {{2 - assign threads to sockets}}, if there's
more than one NUMA node and {{0 - assign threads to machine}}, if not.
{code}
zwoop
8:38 if you have more than one NUMA node, probably default to 2, otherwise,
default to 0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584794#comment-14584794
]
ASF subversion and git services commented on TS-3282:
-
Commit fc9868148dfc9a150aac14004de2d0a2b69057ab in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fc98681 ]
TS-3282: Remove dead store/increment
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Assignee: Phil Sorber
Fix For: 6.0.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584816#comment-14584816
]
Phil Sorber commented on TS-3282:
-
[~portl4t], can you take a look at the latest clang-analyzer report for your
plugin? I fixed the dead store/increment, but the other bug is less straight
forward and I don't want to do something that changes the behavior of the
plugin.
https://ci.trafficserver.apache.org/files/clang-analyzer/
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Assignee: Phil Sorber
Fix For: 6.0.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3365) Enable C99 by default
[
https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584839#comment-14584839
]
Phil Sorber commented on TS-3365:
-
From the Docs: [https://gcc.gnu.org/onlinedocs/gcc/Standards.html]
{noformat}
The default, if no C language dialect options are given, is -std=gnu11.
{noformat}
{noformat}
The default, if no C++ language dialect options are given, is -std=gnu++98.
{noformat}
Does that mean this bug is moot? I don't see us using -std= anywhere in CFLAGS.
Enable C99 by default
-
Key: TS-3365
URL: https://issues.apache.org/jira/browse/TS-3365
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Phil Sorber
Labels: compatibility
Fix For: 6.0.0
We already took the plunge with using bool from C99, so we should enable
C99 on the CFLAGS.
So, -std=c99.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3365) Enable C99 by default
[
https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584841#comment-14584841
]
Phil Sorber commented on TS-3365:
-
Also: [http://clang.llvm.org/compatibility.html#c]
{noformat}
By default, Clang builds C code in GNU C11 mode...
{noformat}
Enable C99 by default
-
Key: TS-3365
URL: https://issues.apache.org/jira/browse/TS-3365
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Phil Sorber
Labels: compatibility
Fix For: 6.0.0
We already took the plunge with using bool from C99, so we should enable
C99 on the CFLAGS.
So, -std=c99.
--
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-tabpanelfocusedCommentId=14584864#comment-14584864 ] Phil Sorber commented on TS-3689: - The commit for this is 025a45505447b7c6d86bec84903cb5be2d93fa95 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] [Resolved] (TS-3689) Remove libck
[ https://issues.apache.org/jira/browse/TS-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-3689. - Resolution: Done So sad to see you go... 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)
