[jira] [Updated] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3105: --- Attachment: ts-3105-master-4.patch ts-3105-master-4.patch contain the previous two fixes against the master branch > Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on > 5.1 and beyond > > > Key: TS-3105 > URL: https://issues.apache.org/jira/browse/TS-3105 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: ts-3073-and-3084-and-3105-against-510.patch, > ts-3105-master-4.patch, ts-3105-master-6.patch > > > These two patches were run in a production environment on top of 5.0.1 > without problem for several weeks. Now running with these patches on top of > 5.1 causes either an assert or a segfault. Another person has reported the > same segfault when running master in a production environment. > In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than > a terminal state which is expected. I'm assuming either we are being > directed into the terminal state from a connection that terminates too > quickly. Or an event has hung around for too long and is being executed > against the state machine after it has been recycled. > The event is HTTP_TUNNEL_EVENT_DONE > The assert stack trace is > FATAL: HttpSM.cc:2632: failed assert `0` > /z/bin/traffic_server - STACK TRACE: > /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] > /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] > /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] > /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] > /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] > /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, > EThread*)+0x136e)[0x721d1e] > /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] > /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] > The segfault stack trace is > /z/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] > /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, > HttpTunnelConsumer*)+0x122)[0x591462] > /z/bin/traffic_server(HttpTunnel::consumer_handler(int, > HttpTunnelConsumer*)+0x9e)[0x5dd15e] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] > /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, > Event*)+0x3f0)[0x725190] > /z/bin/traffic_server(InactivityCop::check_inactivity(int, > Event*)+0x275)[0x716b75] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034] > /lib64/libc.so.6(clone+0x6d)[0x2abccde1475d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195374#comment-14195374 ] Susan Hinrichs commented on TS-3105: Fixed another problem last Friday. This error was a direct result of the fix for TS-3084 (or TS-3073). The problem was exhibited by a series of posts with keep-alives. post 1 is sort and the response is in the first packet and already in the buffer by the time the tunnel starts processing. Post 2 uses the same connection as post 1. The problem was in HttpTunnel::producer_run. The original logic would set half_close_flag on the connection because there was no more data to fetch. But this is not accurate, since there may be further transactions sharing this same connection. Fixed this by not setting the half_close_flag in this case, and defensively adding a line to clear the half_close flag in new_transaction. Need to move these fixes to the master patch. > Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on > 5.1 and beyond > > > Key: TS-3105 > URL: https://issues.apache.org/jira/browse/TS-3105 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: ts-3073-and-3084-and-3105-against-510.patch, > ts-3105-master-6.patch > > > These two patches were run in a production environment on top of 5.0.1 > without problem for several weeks. Now running with these patches on top of > 5.1 causes either an assert or a segfault. Another person has reported the > same segfault when running master in a production environment. > In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than > a terminal state which is expected. I'm assuming either we are being > directed into the terminal state from a connection that terminates too > quickly. Or an event has hung around for too long and is being executed > against the state machine after it has been recycled. > The event is HTTP_TUNNEL_EVENT_DONE > The assert stack trace is > FATAL: HttpSM.cc:2632: failed assert `0` > /z/bin/traffic_server - STACK TRACE: > /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] > /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] > /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] > /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] > /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] > /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, > EThread*)+0x136e)[0x721d1e] > /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] > /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] > The segfault stack trace is > /z/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] > /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, > HttpTunnelConsumer*)+0x122)[0x591462] > /z/bin/traffic_server(HttpTunnel::consumer_handler(int, > HttpTunnelConsumer*)+0x9e)[0x5dd15e] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] > /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, > Event*)+0x3f0)[0x725190] > /z/bin/traffic_server(InactivityCop::check_inactivity(int, > Event*)+0x275)[0x716b75] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034] > /lib64/libc.so.6(clone+0x6d)[0x2abccde1475d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195298#comment-14195298 ] Susan Hinrichs edited comment on TS-3105 at 11/3/14 11:35 PM: -- Last Friday while working on the patches for 5.1, ran into the following issues. VC_EVENT_EOS was being delivered to consumer_handler in some cases during a post workload. It looks like there were two cases for this. 1. The consumer's associated VC is for the HttpServerSession. The post response is very short (one packet) . It is delivered before the second server response tunnel is set up. Since there is no producer matching the VC, the event is instead delivered to the consumer for the first tunnel . Fixed this by changing the do_io_read in HttpSM::attach_server_session to read no bytes. This is sufficient to redirect error and timeout events to the new VC handler, but it won't start reading anything until the server response tunnel is in place and a second do_io_read is issued in HttpSM::setup_server_read_response_header. With this change the events from the second tunnel will be delivered to the second tunnel's producer. Was able to see this failure case by doing POST-based filed uploads against test.websafedeposit.net. Didn't fail everytime, but frequently enough to debug. While poking around in this logic, noticed that the call to do_io_read in HttpSM::attach_client_session was passing a length of 0, but a non-null buffer. Changed the third argument to NULL. 2. In the second case, a RESET is performed and is delivered as a VC_EVENT_EOS I was exercising this by sending a Reset on the client side. This means that the EOS delivered to the consumer_handler should indeed be treated as an error case. Exercised this by writing a test client that issues a RESET after part of the post. Need to move these fixes to the master patch. was (Author: shinrich): Last Friday while working on the patches for 5.1, ran into the following issues. VC_EVENT_EOS was being delivered to consumer_handler in some cases during a post workload. It looks like there were two cases for this. 1. The consumer's associated VC is for the HttpServerSession. The post response is very short (one packet) . It is delivered before the second server response tunnel is set up. Since there is no producer matching the VC, the event is instead delivered to the consumer for the first tunnel . Fixed this by changing the do_io_read in HttpSM::attach_server_session to read no bytes. This is sufficient to redirect error and timeout events to the new VC handler, but it won't start reading anything until the server response tunnel is in place and a second do_io_read is issued in HttpSM::setup_server_read_response_header. With this change the events from the second tunnel will be delivered to the second tunnel's producer. While poking around in this logic, noticed that the call to do_io_read in HttpSM::attach_client_session was passing a length of 0, but a non-null buffer. Changed the third argument to NULL. 2. In the second case, a RESET is performed and is delivered as a VC_EVENT_EOS I was exercising this by sending a Reset on the client side. This means that the EOS delivered to the consumer_handler should indeed be treated as an error case. > Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on > 5.1 and beyond > > > Key: TS-3105 > URL: https://issues.apache.org/jira/browse/TS-3105 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: ts-3073-and-3084-and-3105-against-510.patch, > ts-3105-master-6.patch > > > These two patches were run in a production environment on top of 5.0.1 > without problem for several weeks. Now running with these patches on top of > 5.1 causes either an assert or a segfault. Another person has reported the > same segfault when running master in a production environment. > In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than > a terminal state which is expected. I'm assuming either we are being > directed into the terminal state from a connection that terminates too > quickly. Or an event has hung around for too long and is being executed > against the state machine after it has been recycled. > The event is HTTP_TUNNEL_EVENT_DONE > The assert stack trace is > FATAL: HttpSM.cc:2632: failed assert `0` > /z/bin/traffic_server - STACK TRACE: > /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] > /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] > /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] > /z/
[jira] [Commented] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195298#comment-14195298 ] Susan Hinrichs commented on TS-3105: Last Friday while working on the patches for 5.1, ran into the following issues. VC_EVENT_EOS was being delivered to consumer_handler in some cases during a post workload. It looks like there were two cases for this. 1. The consumer's associated VC is for the HttpServerSession. The post response is very short (one packet) . It is delivered before the second server response tunnel is set up. Since there is no producer matching the VC, the event is instead delivered to the consumer for the first tunnel . Fixed this by changing the do_io_read in HttpSM::attach_server_session to read no bytes. This is sufficient to redirect error and timeout events to the new VC handler, but it won't start reading anything until the server response tunnel is in place and a second do_io_read is issued in HttpSM::setup_server_read_response_header. With this change the events from the second tunnel will be delivered to the second tunnel's producer. While poking around in this logic, noticed that the call to do_io_read in HttpSM::attach_client_session was passing a length of 0, but a non-null buffer. Changed the third argument to NULL. 2. In the second case, a RESET is performed and is delivered as a VC_EVENT_EOS I was exercising this by sending a Reset on the client side. This means that the EOS delivered to the consumer_handler should indeed be treated as an error case. > Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on > 5.1 and beyond > > > Key: TS-3105 > URL: https://issues.apache.org/jira/browse/TS-3105 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: ts-3073-and-3084-and-3105-against-510.patch, > ts-3105-master-6.patch > > > These two patches were run in a production environment on top of 5.0.1 > without problem for several weeks. Now running with these patches on top of > 5.1 causes either an assert or a segfault. Another person has reported the > same segfault when running master in a production environment. > In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than > a terminal state which is expected. I'm assuming either we are being > directed into the terminal state from a connection that terminates too > quickly. Or an event has hung around for too long and is being executed > against the state machine after it has been recycled. > The event is HTTP_TUNNEL_EVENT_DONE > The assert stack trace is > FATAL: HttpSM.cc:2632: failed assert `0` > /z/bin/traffic_server - STACK TRACE: > /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] > /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] > /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] > /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] > /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] > /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, > EThread*)+0x136e)[0x721d1e] > /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] > /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] > The segfault stack trace is > /z/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] > /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, > HttpTunnelConsumer*)+0x122)[0x591462] > /z/bin/traffic_server(HttpTunnel::consumer_handler(int, > HttpTunnelConsumer*)+0x9e)[0x5dd15e] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] > /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, > Event*)+0x3f0)[0x725190] > /z/bin/traffic_server(InactivityCop::check_inactivity(int, > Event*)+0x275)[0x716b75] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034] > /lib64/libc.so.6(clone+0x6d)[0x2abccde1475d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189535#comment-14189535 ] Susan Hinrichs edited comment on TS-3105 at 11/3/14 9:44 PM: - ts-3105-master-6 Trying to prevent tunnel_handler_ua from being called twice. Update: This patch has been run in a production environment for 3 hours so far. The key change between this patch and the previous patch was a change in HttpTunnel::consumer_handler. In the case of a "final" event (e.g. write complete, eos, error, timeout), the original code was setting the final callback to execute, but this caused assertion failures in HttpSM::tunnel_handler_post_or_put() if p->handler_state was 0. Earlier versions of the patch would avoid setting the callback flag if p->handler_state was 0. This avoided the assert, but apparently caused the state machine to leak. This patch updated the logic to set the p->handler_state flag if it was not already set. It chooses a value based on the event and the c->vc_type. was (Author: shinrich): ts-3105-master-6 Trying to prevent tunnel_handler_ua from being called twice. Update: This patch has been run in a production environment for 3 hours so far. The key change between this patch and the previous patch was a changed in HttpTunnel::consumer_handler. In the case of a "final" event (e.g. write complete, eos, error, timeout), the original code was setting the final callback to execute, but this caused assertion failures in HttpSM::tunnel_handler_post_or_put() if p->handler_state was 0. Earlier versions of the patch would avoid setting the callback flag if p->handler_state was 0. This avoided the assert, but apparently caused the state machine to leak. This patch updated the logic to set the p->handler_state flag if it was not already set. It chooses a value based on the event and the c->vc_type. > Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on > 5.1 and beyond > > > Key: TS-3105 > URL: https://issues.apache.org/jira/browse/TS-3105 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: ts-3073-and-3084-and-3105-against-510.patch, > ts-3105-master-6.patch > > > These two patches were run in a production environment on top of 5.0.1 > without problem for several weeks. Now running with these patches on top of > 5.1 causes either an assert or a segfault. Another person has reported the > same segfault when running master in a production environment. > In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than > a terminal state which is expected. I'm assuming either we are being > directed into the terminal state from a connection that terminates too > quickly. Or an event has hung around for too long and is being executed > against the state machine after it has been recycled. > The event is HTTP_TUNNEL_EVENT_DONE > The assert stack trace is > FATAL: HttpSM.cc:2632: failed assert `0` > /z/bin/traffic_server - STACK TRACE: > /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] > /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] > /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] > /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] > /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] > /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, > EThread*)+0x136e)[0x721d1e] > /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] > /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] > The segfault stack trace is > /z/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] > /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, > HttpTunnelConsumer*)+0x122)[0x591462] > /z/bin/traffic_server(HttpTunnel::consumer_handler(int, > HttpTunnelConsumer*)+0x9e)[0x5dd15e] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] > /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, > Event*)+0x3f0)[0x725190] > /z/bin/traffic_server(InactivityCop::check_inactivity(int, > Event*)+0x275)[0x716b75] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread
[jira] [Updated] (TS-3135) Disable SSLv3 by default
[
https://issues.apache.org/jira/browse/TS-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-3135:
Fix Version/s: 5.1.1
> Disable SSLv3 by default
>
>
> Key: TS-3135
> URL: https://issues.apache.org/jira/browse/TS-3135
> Project: Traffic Server
> Issue Type: Improvement
> Components: Security, SSL
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 5.1.1, 5.2.0
>
>
> In response to
> http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
> we should consider changing the default in RecordsConfig.cc:
> {code}
> gmt/RecordsConfig.cc b/mgmt/RecordsConfig.cc
> index 0146cf9..2f78e31 100644
> --- a/mgmt/RecordsConfig.cc
> +++ b/mgmt/RecordsConfig.cc
> @@ -1224,7 +1224,7 @@ RecordElement RecordsConfig[] = {
>,
>{RECT_CONFIG, "proxy.config.ssl.SSLv2", RECD_INT, "0", RECU_RESTART_TS,
> RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
>,
> - {RECT_CONFIG, "proxy.config.ssl.SSLv3", RECD_INT, "1", RECU_RESTART_TS,
> RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> + {RECT_CONFIG, "proxy.config.ssl.SSLv3", RECD_INT, "0", RECU_RESTART_TS,
> RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
>,
>{RECT_CONFIG, "proxy.config.ssl.TLSv1", RECD_INT, "1", RECU_RESTART_TS,
> RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
>,
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2677) CONNECT method with remap messes up the scheme
[ https://issues.apache.org/jira/browse/TS-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2677: Fix Version/s: 5.1.1 > CONNECT method with remap messes up the scheme > -- > > Key: TS-2677 > URL: https://issues.apache.org/jira/browse/TS-2677 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0, 5.1.1 > > > If you use CONNECT, yet want to apply remaps, it'll modify the scheme. This > seems to mess up various things internally, such that the requests are not > properly tunneled. It seems nonsensical to allow medications to the scheme > (since the client expects e.g. HTTPS, mapping it to anything else would > likely make the client misbehave). This would be the easiest solution, and > makes internal states (debug, logging etc.) behave as expected. > The other option is make the scheme irrelevant to the "core", but not sure > what other side effects that might have ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3163) Support proxy.config.net.sock_x_out on outbound connections created by TSNetConnect
[
https://issues.apache.org/jira/browse/TS-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3163:
Issue Type: Improvement (was: Bug)
> Support proxy.config.net.sock_x_out on outbound connections created by
> TSNetConnect
> ---
>
> Key: TS-3163
> URL: https://issues.apache.org/jira/browse/TS-3163
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Wei Sun
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.2.0
>
>
> Our customers use {{TSNetConnect}} to initiate outbound connections in their
> plugin, it looks weird to them the TCP configurations don't work as expected.
> I think it would be better to keep consistency with the way how ATS internal
> creates new connections and apply {{proxy.config.net.sock_*_out}}
> configurations to the connections created by TSNetConnect as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3163) Support proxy.config.net.sock_x_out on outbound connections created by TSNetConnect
[
https://issues.apache.org/jira/browse/TS-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3163:
Priority: Minor (was: Major)
Fix Version/s: 5.2.0
Assignee: James Peach
> Support proxy.config.net.sock_x_out on outbound connections created by
> TSNetConnect
> ---
>
> Key: TS-3163
> URL: https://issues.apache.org/jira/browse/TS-3163
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Wei Sun
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.2.0
>
>
> Our customers use {{TSNetConnect}} to initiate outbound connections in their
> plugin, it looks weird to them the TCP configurations don't work as expected.
> I think it would be better to keep consistency with the way how ATS internal
> creates new connections and apply {{proxy.config.net.sock_*_out}}
> configurations to the connections created by TSNetConnect as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2682) Add per remap configuration / activation to background_fetch
[ https://issues.apache.org/jira/browse/TS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194612#comment-14194612 ] Sudheer Vinukonda commented on TS-2682: --- Hi [~zwoop] : This jira actually tracks the per remap activation support for background_fetch plugin - the initial commit on this jira had a bug that [~seri] ran into and reported here. That bug has now been confirmed to be resolved. Since, the per-remap support is now available, I will mark the jira as Resolved shortly. Thank you! > Add per remap configuration / activation to background_fetch > > > Key: TS-2682 > URL: https://issues.apache.org/jira/browse/TS-2682 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3163) Support proxy.config.net.sock_x_out on outbound connections created by TSNetConnect
[
https://issues.apache.org/jira/browse/TS-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194462#comment-14194462
]
Wei Sun edited comment on TS-3163 at 11/3/14 11:58 AM:
---
The diff makes changes in API implementation, please let me know if API review
process is needed.
was (Author: sunwei):
The diff changes API implementation, please let me know if API review process
is need.
> Support proxy.config.net.sock_x_out on outbound connections created by
> TSNetConnect
> ---
>
> Key: TS-3163
> URL: https://issues.apache.org/jira/browse/TS-3163
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Wei Sun
>
> Our customers use {{TSNetConnect}} to initiate outbound connections in their
> plugin, it looks weird to them the TCP configurations don't work as expected.
> I think it would be better to keep consistency with the way how ATS internal
> creates new connections and apply {{proxy.config.net.sock_*_out}}
> configurations to the connections created by TSNetConnect as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3163) Support proxy.config.net.sock_x_out on outbound connections created by TSNetConnect
[
https://issues.apache.org/jira/browse/TS-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194462#comment-14194462
]
Wei Sun commented on TS-3163:
-
The diff changes API implementation, please let me know if API review process
is need.
> Support proxy.config.net.sock_x_out on outbound connections created by
> TSNetConnect
> ---
>
> Key: TS-3163
> URL: https://issues.apache.org/jira/browse/TS-3163
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Wei Sun
>
> Our customers use {{TSNetConnect}} to initiate outbound connections in their
> plugin, it looks weird to them the TCP configurations don't work as expected.
> I think it would be better to keep consistency with the way how ATS internal
> creates new connections and apply {{proxy.config.net.sock_*_out}}
> configurations to the connections created by TSNetConnect as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3163) Support proxy.config.net.sock_x_out on outbound connections created by TSNetConnect
[
https://issues.apache.org/jira/browse/TS-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194453#comment-14194453
]
ASF GitHub Bot commented on TS-3163:
GitHub user suenway opened a pull request:
https://github.com/apache/trafficserver/pull/136
TS-3163 Apply socket configurations to outbound conns created by
TSNetConnect
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/yahoo/trafficserver TS-3163
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/136.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #136
commit 8d1d1582da02811f59cc4bad9c40f7c02ceb7ecf
Author: sunwei
Date: 2014-11-02T00:45:04Z
TS-3163 Apply socket configurations to outbound connections created by
TSNetConnect
> Support proxy.config.net.sock_x_out on outbound connections created by
> TSNetConnect
> ---
>
> Key: TS-3163
> URL: https://issues.apache.org/jira/browse/TS-3163
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Wei Sun
>
> Our customers use {{TSNetConnect}} to initiate outbound connections in their
> plugin, it looks weird to them the TCP configurations don't work as expected.
> I think it would be better to keep consistency with the way how ATS internal
> creates new connections and apply {{proxy.config.net.sock_*_out}}
> configurations to the connections created by TSNetConnect as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3163) Support proxy.config.net.sock_x_out on outbound connections created by TSNetConnect
Wei Sun created TS-3163:
---
Summary: Support proxy.config.net.sock_x_out on outbound
connections created by TSNetConnect
Key: TS-3163
URL: https://issues.apache.org/jira/browse/TS-3163
Project: Traffic Server
Issue Type: Bug
Reporter: Wei Sun
Our customers use {{TSNetConnect}} to initiate outbound connections in their
plugin, it looks weird to them the TCP configurations don't work as expected. I
think it would be better to keep consistency with the way how ATS internal
creates new connections and apply {{proxy.config.net.sock_*_out}}
configurations to the connections created by TSNetConnect as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
