[jira] [Created] (TS-3329) ATS shouldn't start if SSL is configured and certificate can't be loaded
kang li created TS-3329:
---
Summary: ATS shouldn't start if SSL is configured and certificate
can't be loaded
Key: TS-3329
URL: https://issues.apache.org/jira/browse/TS-3329
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: kang li
requirement by [~dcarlin]:
{quote}
It seems ATS will start up even if the certificate file isn't present.
ATS settings in records.config:
CONFIG proxy.config.ssl.server.cert_chain.filename STRING digicert.pem
CONFIG proxy.config.ssl.server.cert.path STRING conf/yts/ssl
ATS settings in ssl_multicert.config:
dest_ip=* ssl_cert_name=ycpi_ssl_cert.pem
What happened was that this volume /home/y/conf/yts/ssl wasn't mounted - so the
SSL cert and chain cert were inaccessible. ATS started anyways just returning
errors on 443. Healthchecks were served on port 80 via HTTP, so it appeared to
that the site was OK.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3329) ATS shouldn't start if SSL is configured and certificate can't be loaded
[
https://issues.apache.org/jira/browse/TS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-3329:
---
Assignee: kang li
ATS shouldn't start if SSL is configured and certificate can't be loaded
Key: TS-3329
URL: https://issues.apache.org/jira/browse/TS-3329
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: kang li
Assignee: kang li
Attachments: patch.diff
requirement by [~dcarlin]:
{quote}
It seems ATS will start up even if the certificate file isn't present.
ATS settings in records.config:
CONFIG proxy.config.ssl.server.cert_chain.filename STRING digicert.pem
CONFIG proxy.config.ssl.server.cert.path STRING conf/yts/ssl
ATS settings in ssl_multicert.config:
dest_ip=* ssl_cert_name=ycpi_ssl_cert.pem
What happened was that this volume /home/y/conf/yts/ssl wasn't mounted - so
the
SSL cert and chain cert were inaccessible. ATS started anyways just
returning
errors on 443. Healthchecks were served on port 80 via HTTP, so it appeared
to that the site was OK.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3329) ATS shouldn't start if SSL is configured and certificate can't be loaded
[
https://issues.apache.org/jira/browse/TS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kang li updated TS-3329:
Attachment: patch.diff
Just exit when ATS load SSL certificate failure.
ATS shouldn't start if SSL is configured and certificate can't be loaded
Key: TS-3329
URL: https://issues.apache.org/jira/browse/TS-3329
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: kang li
Attachments: patch.diff
requirement by [~dcarlin]:
{quote}
It seems ATS will start up even if the certificate file isn't present.
ATS settings in records.config:
CONFIG proxy.config.ssl.server.cert_chain.filename STRING digicert.pem
CONFIG proxy.config.ssl.server.cert.path STRING conf/yts/ssl
ATS settings in ssl_multicert.config:
dest_ip=* ssl_cert_name=ycpi_ssl_cert.pem
What happened was that this volume /home/y/conf/yts/ssl wasn't mounted - so
the
SSL cert and chain cert were inaccessible. ATS started anyways just
returning
errors on 443. Healthchecks were served on port 80 via HTTP, so it appeared
to that the site was OK.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3119) Add option to support SO_LINGER to origin server
[ https://issues.apache.org/jira/browse/TS-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293903#comment-14293903 ] Bryan Call commented on TS-3119: Git commit history: commit e5069f1b6249bcd62f5bf1a425ed16926ac2bbba Author: Kang Li kan...@yahoo-inc.com Date: Wed Oct 29 17:04:03 2014 -0700 TS-3119: add SO_LINGER socket option support The timeout should be 0 if we turn on SO_LINGER option as we are using non-blocking socket. I have tried a non-zero timeout, but the setsockopt failed. If we add a new sock option static unit32_t const SOCK_OPT_LINGER_ON = 4; Then we could configure proxy.config.net.sock_option_flag_in proxy.config.net.sock_option_flag_out to make client connection or server connection LINGER for 0 ms if needed. Add option to support SO_LINGER to origin server Key: TS-3119 URL: https://issues.apache.org/jira/browse/TS-3119 Project: Traffic Server Issue Type: New Feature Components: Network Reporter: kang li Assignee: James Peach Fix For: 5.2.0 Attachments: add_so_linger_as_option.diff, linger.diff When install ATS and apache in the same box to do SSL termination. We saw port exhaustion, performance drop and request missing through ATS. Before migration we are using stunnel to do SSL termination. There were no such problem. After investigation we found add SO_LINGER option to origin could resolve these problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3119) Add option to support SO_LINGER to origin server
[ https://issues.apache.org/jira/browse/TS-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293901#comment-14293901 ] ASF subversion and git services commented on TS-3119: - Commit a465af20e24029cf42b69a6f2d1479805543552a in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a465af2 ] TS-3119: Added documentation for SO_LINGER Add option to support SO_LINGER to origin server Key: TS-3119 URL: https://issues.apache.org/jira/browse/TS-3119 Project: Traffic Server Issue Type: New Feature Components: Network Reporter: kang li Assignee: James Peach Fix For: 5.2.0 Attachments: add_so_linger_as_option.diff, linger.diff When install ATS and apache in the same box to do SSL termination. We saw port exhaustion, performance drop and request missing through ATS. Before migration we are using stunnel to do SSL termination. There were no such problem. After investigation we found add SO_LINGER option to origin could resolve these problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3330) Several broken stats
[ https://issues.apache.org/jira/browse/TS-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294018#comment-14294018 ] ASF subversion and git services commented on TS-3330: - Commit 30606a9106b15132c04744e0d268b040e444cead in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=30606a9 ] TS-3330: update changes Several broken stats Key: TS-3330 URL: https://issues.apache.org/jira/browse/TS-3330 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.3.0 We found that a few stats aren't properly incremented, patch incoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3330) Several broken stats
[ https://issues.apache.org/jira/browse/TS-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-3330: - Fix Version/s: 5.3.0 Several broken stats Key: TS-3330 URL: https://issues.apache.org/jira/browse/TS-3330 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Reporter: Brian Geffon Fix For: 5.3.0 We found that a few stats aren't properly incremented, patch incoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3330) Several broken stats
Brian Geffon created TS-3330: Summary: Several broken stats Key: TS-3330 URL: https://issues.apache.org/jira/browse/TS-3330 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Reporter: Brian Geffon We found that a few stats aren't properly incremented, patch incoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
[
https://issues.apache.org/jira/browse/TS-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294007#comment-14294007
]
ASF subversion and git services commented on TS-3326:
-
Commit 9a9c4519e3442febf9e160683fa69b6970d9a67b in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9a9c451 ]
TS-3326 Better comments, and make the default in release builds be the same as
our default configuration
proxy.config.http.send_http11_requests not applied when hostdb lookup is not
performed
--
Key: TS-3326
URL: https://issues.apache.org/jira/browse/TS-3326
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.2.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.3.0
The setting {{proxy.config.http.send_http11_requests}} determines what http
version is used in sending outgoing requests. However, this setting is not
applied when dns/hostdb lookup is skipped (for e.g, when using the TS API
{{TSHttpTxnServerAddrSet}}). This causes problems since the default version
in the code used is v0.9 at the moment. See the jira TS-3327 that proposes to
change the default to an invalid value (e.g 0.0) in 6.0 and TS-3328 that
tracks the need for a new/modified TS API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
[
https://issues.apache.org/jira/browse/TS-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294009#comment-14294009
]
ASF subversion and git services commented on TS-3326:
-
Commit 37f0fd013a45d5f5e56535d307122f55aaaf0c81 in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=37f0fd0 ]
TS-3326 Slightly better comment
proxy.config.http.send_http11_requests not applied when hostdb lookup is not
performed
--
Key: TS-3326
URL: https://issues.apache.org/jira/browse/TS-3326
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.2.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.3.0
The setting {{proxy.config.http.send_http11_requests}} determines what http
version is used in sending outgoing requests. However, this setting is not
applied when dns/hostdb lookup is skipped (for e.g, when using the TS API
{{TSHttpTxnServerAddrSet}}). This causes problems since the default version
in the code used is v0.9 at the moment. See the jira TS-3327 that proposes to
change the default to an invalid value (e.g 0.0) in 6.0 and TS-3328 that
tracks the need for a new/modified TS API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3330) Several broken stats
[ https://issues.apache.org/jira/browse/TS-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294017#comment-14294017 ] ASF subversion and git services commented on TS-3330: - Commit bf213732cf98ccf1b53750e3fdc57230144c1e41 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bf21373 ] TS-3330: Several broken stats Several broken stats Key: TS-3330 URL: https://issues.apache.org/jira/browse/TS-3330 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.3.0 We found that a few stats aren't properly incremented, patch incoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294173#comment-14294173 ] Susan Hinrichs commented on TS-2480: The issue is that information about the connections should not be keyed by the SSL_CTX, because the SSL_CTX might change later. It looks like Wei Sun was adding indirection in his patch. In implementing TS-3006, we also changed the lookup structure point to a data structure that includes the SSL_CTX rather than the SSL_CTX directly. This means we can add other data like whether the object should be blind tunneled. We could also add the ticket information here. Rather than pulling up the key information by indexing via a SSL_CTX that might have changed, we can pull up the key information by IP address which should be consistent I assume that the ticket information can only be specified by IP address in the SSL_multicert file. Since the ticket callback could be processed before the SNI callback, it doesn't seem that you would always have access to the server name at this point. Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Wei Sun Assignee: Susan Hinrichs Labels: review Fix For: 5.3.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-2480 started by Susan Hinrichs. -- Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Wei Sun Assignee: Susan Hinrichs Labels: review Fix For: 5.3.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3287) Coverity fixes for v5.3.0 by zwoop
[ https://issues.apache.org/jira/browse/TS-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294290#comment-14294290 ] ASF subversion and git services commented on TS-3287: - Commit 5893c89ddc51d07c782253c7802073784a1ce7c9 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5893c89 ] TS-3287: fix broken HdrTest data Coverity CID #1196441 Coverity fixes for v5.3.0 by zwoop -- Key: TS-3287 URL: https://issues.apache.org/jira/browse/TS-3287 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.0 This is my JIRA for Coverity commits for v5.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3331) negative responses cached even when headers indicate otherwise
William Bardwell created TS-3331: Summary: negative responses cached even when headers indicate otherwise Key: TS-3331 URL: https://issues.apache.org/jira/browse/TS-3331 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Negative type status codes get cached even when there are Cache-Control: no-store or the like headers and positive caching would be paying attention to that. So the fix is to apply response headers (and general caching config) to negative caching choices too. My patch might fix [TS-2633] 406 negative responses being cached for too long -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
[
https://issues.apache.org/jira/browse/TS-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-3326.
---
Resolution: Fixed
proxy.config.http.send_http11_requests not applied when hostdb lookup is not
performed
--
Key: TS-3326
URL: https://issues.apache.org/jira/browse/TS-3326
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.2.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.3.0
The setting {{proxy.config.http.send_http11_requests}} determines what http
version is used in sending outgoing requests. However, this setting is not
applied when dns/hostdb lookup is skipped (for e.g, when using the TS API
{{TSHttpTxnServerAddrSet}}). This causes problems since the default version
in the code used is v0.9 at the moment. See the jira TS-3327 that proposes to
change the default to an invalid value (e.g 0.0) in 6.0 and TS-3328 that
tracks the need for a new/modified TS API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3331) negative responses cached even when headers indicate otherwise
[ https://issues.apache.org/jira/browse/TS-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3331: - Fix Version/s: 5.3.0 negative responses cached even when headers indicate otherwise -- Key: TS-3331 URL: https://issues.apache.org/jira/browse/TS-3331 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 Negative type status codes get cached even when there are Cache-Control: no-store or the like headers and positive caching would be paying attention to that. So the fix is to apply response headers (and general caching config) to negative caching choices too. My patch might fix [TS-2633] 406 negative responses being cached for too long -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3323) Cache scan will stop early if any empty volumes
[ https://issues.apache.org/jira/browse/TS-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-3323. Resolution: Fixed Cache scan will stop early if any empty volumes --- Key: TS-3323 URL: https://issues.apache.org/jira/browse/TS-3323 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 Cache scans will stop early if there are any volumes with nothing in them (no directory entries.) It needs to just skip to the next volume. (Also the optimizations to the scanning are not strict enough about what is a valid directory entry.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3333) TOS settings do not apply to IPv6 connections
[ https://issues.apache.org/jira/browse/TS-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-: --- Assignee: Phil Sorber TOS settings do not apply to IPv6 connections - Key: TS- URL: https://issues.apache.org/jira/browse/TS- Project: Traffic Server Issue Type: Bug Components: Network Reporter: Phil Sorber Assignee: Phil Sorber TOS settings only take effect when dealing with IPv4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294308#comment-14294308 ] ASF subversion and git services commented on TS-153: Commit c53eb2e011b271db672c299b8fa4049be210ce4b in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c53eb2e ] TS-153: Fixed typo on method name Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.3.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3330) Several broken stats
[ https://issues.apache.org/jira/browse/TS-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-3330. -- Resolution: Fixed Several broken stats Key: TS-3330 URL: https://issues.apache.org/jira/browse/TS-3330 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.3.0 We found that a few stats aren't properly incremented, patch incoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3332) header_rewrite set-conn-dscp does not work in remap
Phil Sorber created TS-3332: --- Summary: header_rewrite set-conn-dscp does not work in remap Key: TS-3332 URL: https://issues.apache.org/jira/browse/TS-3332 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Phil Sorber the set-conn-dscp operator only works in global plugins and not in remap ones. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3333) TOS settings do not apply to IPv6 connections
Phil Sorber created TS-: --- Summary: TOS settings do not apply to IPv6 connections Key: TS- URL: https://issues.apache.org/jira/browse/TS- Project: Traffic Server Issue Type: Bug Components: Network Reporter: Phil Sorber TOS settings only take effect when dealing with IPv4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3333) TOS settings do not apply to IPv6 connections
[ https://issues.apache.org/jira/browse/TS-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-: Fix Version/s: 5.3.0 TOS settings do not apply to IPv6 connections - Key: TS- URL: https://issues.apache.org/jira/browse/TS- Project: Traffic Server Issue Type: Bug Components: Network Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.3.0 TOS settings only take effect when dealing with IPv4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3332) header_rewrite set-conn-dscp does not work in remap
[ https://issues.apache.org/jira/browse/TS-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-3332: --- Assignee: Phil Sorber header_rewrite set-conn-dscp does not work in remap --- Key: TS-3332 URL: https://issues.apache.org/jira/browse/TS-3332 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Phil Sorber Assignee: Phil Sorber the set-conn-dscp operator only works in global plugins and not in remap ones. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3333) TOS settings do not apply to IPv6 connections
[ https://issues.apache.org/jira/browse/TS-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294440#comment-14294440 ] ASF subversion and git services commented on TS-: - Commit 6ef00b89a65ed876e0abf07ec0fd32d0fac7eda2 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6ef00b8 ] TS-: Enable TOS settings on IPv6 connections TOS settings do not apply to IPv6 connections - Key: TS- URL: https://issues.apache.org/jira/browse/TS- Project: Traffic Server Issue Type: Bug Components: Network Reporter: Phil Sorber Assignee: Phil Sorber TOS settings only take effect when dealing with IPv4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3332) header_rewrite set-conn-dscp does not work in remap
[ https://issues.apache.org/jira/browse/TS-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294439#comment-14294439 ] ASF subversion and git services commented on TS-3332: - Commit 138269ee2f585de819a3924d30d42508a0513cb2 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=138269e ] TS-3332: Allow set-conn-dscp to work in remap header_rewrite set-conn-dscp does not work in remap --- Key: TS-3332 URL: https://issues.apache.org/jira/browse/TS-3332 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Phil Sorber Assignee: Phil Sorber the set-conn-dscp operator only works in global plugins and not in remap ones. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3332) header_rewrite set-conn-dscp does not work in remap
[ https://issues.apache.org/jira/browse/TS-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3332: Fix Version/s: 5.3.0 header_rewrite set-conn-dscp does not work in remap --- Key: TS-3332 URL: https://issues.apache.org/jira/browse/TS-3332 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.3.0 the set-conn-dscp operator only works in global plugins and not in remap ones. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3287) Coverity fixes for v5.3.0 by zwoop
[ https://issues.apache.org/jira/browse/TS-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293725#comment-14293725 ] ASF subversion and git services commented on TS-3287: - Commit e3c7e1aa586c672fc014478b8c79b99528cc57ba in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e3c7e1a ] TS-3287 Remove some more dead code, this should eventually die completely Coverity fixes for v5.3.0 by zwoop -- Key: TS-3287 URL: https://issues.apache.org/jira/browse/TS-3287 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.0 This is my JIRA for Coverity commits for v5.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
[
https://issues.apache.org/jira/browse/TS-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293721#comment-14293721
]
ASF subversion and git services commented on TS-3326:
-
Commit 4f5e3f0b05f6f9e7de9aaa89b7e73e0ef39c4a6f in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4f5e3f0 ]
[TS-3326]: check client req version for hostdb lookup when config says so
proxy.config.http.send_http11_requests not applied when hostdb lookup is not
performed
--
Key: TS-3326
URL: https://issues.apache.org/jira/browse/TS-3326
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.2.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.3.0
The setting {{proxy.config.http.send_http11_requests}} determines what http
version is used in sending outgoing requests. However, this setting is not
applied when dns/hostdb lookup is skipped (for e.g, when using the TS API
{{TSHttpTxnServerAddrSet}}). This causes problems since the default version
in the code used is v0.9 at the moment. See the jira TS-3327 that proposes to
change the default to an invalid value (e.g 0.0) in 6.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3329) ATS shouldn't start if SSL is configured and certificate can't be loaded
[
https://issues.apache.org/jira/browse/TS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293800#comment-14293800
]
James Peach commented on TS-3329:
-
I disagree with this. I think that we certainly should be tolerant of SSL
failures. SSL loading failures will log an error; perhaps they should throw an
alert as well.
ATS shouldn't start if SSL is configured and certificate can't be loaded
Key: TS-3329
URL: https://issues.apache.org/jira/browse/TS-3329
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: kang li
Assignee: kang li
Attachments: patch.diff
requirement by [~dcarlin]:
{quote}
It seems ATS will start up even if the certificate file isn't present.
ATS settings in records.config:
CONFIG proxy.config.ssl.server.cert_chain.filename STRING digicert.pem
CONFIG proxy.config.ssl.server.cert.path STRING conf/yts/ssl
ATS settings in ssl_multicert.config:
dest_ip=* ssl_cert_name=ycpi_ssl_cert.pem
What happened was that this volume /home/y/conf/yts/ssl wasn't mounted - so
the
SSL cert and chain cert were inaccessible. ATS started anyways just
returning
errors on 443. Healthchecks were served on port 80 via HTTP, so it appeared
to that the site was OK.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
[
https://issues.apache.org/jira/browse/TS-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3326:
--
Description: The setting {{proxy.config.http.send_http11_requests}}
determines what http version is used in sending outgoing requests. However,
this setting is not applied when dns/hostdb lookup is skipped (for e.g, when
using the TS API {{TSHttpTxnServerAddrSet}}). This causes problems since the
default version in the code used is v0.9 at the moment. See the jira TS-3327
that proposes to change the default to an invalid value (e.g 0.0) in 6.0 and
TS-3328 that tracks the need for a new/modified TS API. (was: The setting
{{proxy.config.http.send_http11_requests}} determines what http version is used
in sending outgoing requests. However, this setting is not applied when
dns/hostdb lookup is skipped (for e.g, when using the TS API
{{TSHttpTxnServerAddrSet}}). This causes problems since the default version in
the code used is v0.9 at the moment. See the jira TS-3327 that proposes to
change the default to an invalid value (e.g 0.0) in 6.0)
proxy.config.http.send_http11_requests not applied when hostdb lookup is not
performed
--
Key: TS-3326
URL: https://issues.apache.org/jira/browse/TS-3326
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.2.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.3.0
The setting {{proxy.config.http.send_http11_requests}} determines what http
version is used in sending outgoing requests. However, this setting is not
applied when dns/hostdb lookup is skipped (for e.g, when using the TS API
{{TSHttpTxnServerAddrSet}}). This causes problems since the default version
in the code used is v0.9 at the moment. See the jira TS-3327 that proposes to
change the default to an invalid value (e.g 0.0) in 6.0 and TS-3328 that
tracks the need for a new/modified TS API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3327) change the default http version in the source to an invalid version
[ https://issues.apache.org/jira/browse/TS-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3327: -- Description: This jira is opened to track the proposal to change the default http version in the code to an invalid value instead of 0.9. Also refer TS-3326 and TS-3328 for some related changes. (was: This jira is opened to track the proposal to change the default http version in the code to an invalid value instead of 0.9. Also refer TS-3326 for some related changes.) change the default http version in the source to an invalid version --- Key: TS-3327 URL: https://issues.apache.org/jira/browse/TS-3327 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Sudheer Vinukonda Fix For: 6.0.0 This jira is opened to track the proposal to change the default http version in the code to an invalid value instead of 0.9. Also refer TS-3326 and TS-3328 for some related changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3334) Restore proxy.config.proxy_name to something reasonable default value
[ https://issues.apache.org/jira/browse/TS-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3334: -- Backport to Version: 5.2.1 Restore proxy.config.proxy_name to something reasonable default value - Key: TS-3334 URL: https://issues.apache.org/jira/browse/TS-3334 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.0 As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the *hostname* from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3334) Restore proxy.config.proxy_name to something reasonable default value
Leif Hedstrom created TS-3334: - Summary: Restore proxy.config.proxy_name to something reasonable default value Key: TS-3334 URL: https://issues.apache.org/jira/browse/TS-3334 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the localhost from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3334) Restore proxy.config.proxy_name to something reasonable default value
[ https://issues.apache.org/jira/browse/TS-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3334: -- Description: As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the *the_hostname* from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. was: As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the localhost from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. Restore proxy.config.proxy_name to something reasonable default value - Key: TS-3334 URL: https://issues.apache.org/jira/browse/TS-3334 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.0 As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the *the_hostname* from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3334) Restore proxy.config.proxy_name to something reasonable default value
[ https://issues.apache.org/jira/browse/TS-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3334: -- Description: As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the *hostname* from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. was: As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the *the_hostname* from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. Restore proxy.config.proxy_name to something reasonable default value - Key: TS-3334 URL: https://issues.apache.org/jira/browse/TS-3334 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.0 As of somewhere between 5.1.x and 5.2.x, we eliminated proxy.config.proxy_name from records.config.in. It used to be set to the build machine name, but now we default to the one in RecordsConfig.cc (which is proxy_name). I'd like to suggest we do one of two things (please voice your opinion): 1) Restore the proxy.config.proxy_name into records.config.in, with the old setting (@buildmachine@). 2) Use the *hostname* from the Machine object. This is basically gethostname(). I think I prefer #2, but I'm also open for other suggestions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
