[jira] [Commented] (TS-3321) balancer plugin is not compatible with trafficserver
[
https://issues.apache.org/jira/browse/TS-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292013#comment-14292013
]
Leif Hedstrom commented on TS-3321:
---
As I explained in IRC, the only reason to make this a global plugin is if you
intend / wish to not have to use remap.config. I find that highly unlikely, and
odds are, quite possibly very insecure.
Lets not make this a global plugin :).
balancer plugin is not compatible with trafficserver
Key: TS-3321
URL: https://issues.apache.org/jira/browse/TS-3321
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Attachments:
0001-TS-3321-initialize-balancer.so-as-normal-plugin.patch
{code}
FATAL: unable to find TSPluginInit function in
'/usr/lib/trafficserver/modules/balancer.so':
/usr/lib/trafficserver/modules/balancer.so: undefined symbol: TSPluginInit
traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
traffic_server: Aborted (Signal sent by tkill() 5430 107)
traffic_server - STACK TRACE:
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
void*)+0x8e)[0x4a924e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b7169c5e340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x2b716a8c6cc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b716a8ca0d8]
/usr/lib/trafficserver/libtsutil.so.5(+0x245f9)[0x2b71687ca5f9]
/usr/lib/trafficserver/libtsutil.so.5(+0x246aa)[0x2b71687ca6aa]
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292012#comment-14292012
]
ASF subversion and git services commented on TS-1547:
-
Commit aea7efdcb2447d9e4bcc6139492eaa9514272782 in trafficserver's branch
refs/heads/master from [~wbardwel]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=aea7efd ]
TS-1547 in HTTPHdr::copy hdr ptr is error
Mark HTTPHdr slots that can't be usefully unmarshalled as empty.
I think you end up with these when a plugin is adding and removing
headers a lot.
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Alan M. Carroll
Labels: A, crash
Fix For: 5.3.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3323) Cache scan will stop early if any empty volumes
William Bardwell created TS-3323: Summary: 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 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] [Commented] (TS-3321) balancer plugin is not compatible with trafficserver
[
https://issues.apache.org/jira/browse/TS-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291997#comment-14291997
]
Leif Hedstrom commented on TS-3321:
---
No, that would not be enough. And honestly, I don't see a need for making this
a global plugin, it was not intended to do so. IMO, close this as invalid :).
balancer plugin is not compatible with trafficserver
Key: TS-3321
URL: https://issues.apache.org/jira/browse/TS-3321
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Attachments:
0001-TS-3321-initialize-balancer.so-as-normal-plugin.patch
{code}
FATAL: unable to find TSPluginInit function in
'/usr/lib/trafficserver/modules/balancer.so':
/usr/lib/trafficserver/modules/balancer.so: undefined symbol: TSPluginInit
traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
traffic_server: Aborted (Signal sent by tkill() 5430 107)
traffic_server - STACK TRACE:
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
void*)+0x8e)[0x4a924e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b7169c5e340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x2b716a8c6cc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b716a8ca0d8]
/usr/lib/trafficserver/libtsutil.so.5(+0x245f9)[0x2b71687ca5f9]
/usr/lib/trafficserver/libtsutil.so.5(+0x246aa)[0x2b71687ca6aa]
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3321) balancer plugin is not compatible with trafficserver
[
https://issues.apache.org/jira/browse/TS-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292014#comment-14292014
]
Igor Galić commented on TS-3321:
thanks! this stems from my confusion.
i assumed that *all* remap plugins also need to be loaded in plugin.config.
balancer plugin is not compatible with trafficserver
Key: TS-3321
URL: https://issues.apache.org/jira/browse/TS-3321
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Attachments:
0001-TS-3321-initialize-balancer.so-as-normal-plugin.patch
{code}
FATAL: unable to find TSPluginInit function in
'/usr/lib/trafficserver/modules/balancer.so':
/usr/lib/trafficserver/modules/balancer.so: undefined symbol: TSPluginInit
traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
traffic_server: Aborted (Signal sent by tkill() 5430 107)
traffic_server - STACK TRACE:
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
void*)+0x8e)[0x4a924e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b7169c5e340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x2b716a8c6cc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b716a8ca0d8]
/usr/lib/trafficserver/libtsutil.so.5(+0x245f9)[0x2b71687ca5f9]
/usr/lib/trafficserver/libtsutil.so.5(+0x246aa)[0x2b71687ca6aa]
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3324) If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created
William Bardwell created TS-3324: Summary: If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created Key: TS-3324 URL: https://issues.apache.org/jira/browse/TS-3324 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Several places that look for 'download complete' related events need to treat VC_EVENT_INACTIVITY_TIMEOUT as similar to EOS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292239#comment-14292239
]
ASF subversion and git services commented on TS-1547:
-
Commit fa172b4fc9579a3b85311178262c591dea7f9a5f in trafficserver's branch
refs/heads/master from [~wbardwel]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fa172b4 ]
TS-1547 in HTTPHdr::copy hdr ptr is error
Update CHANGES
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: William Bardwell
Labels: A, crash
Fix For: 5.3.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell closed TS-1547.
Resolution: Fixed
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: William Bardwell
Labels: A, crash
Fix For: 5.3.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3324) If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created
[ https://issues.apache.org/jira/browse/TS-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3324: - Fix Version/s: 5.3.0 If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created --- Key: TS-3324 URL: https://issues.apache.org/jira/browse/TS-3324 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 Several places that look for 'download complete' related events need to treat VC_EVENT_INACTIVITY_TIMEOUT as similar to EOS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
[ https://issues.apache.org/jira/browse/TS-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-3325: Assignee: William Bardwell TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash -- Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
William Bardwell created TS-3325: Summary: TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
[ https://issues.apache.org/jira/browse/TS-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292321#comment-14292321 ] William Bardwell commented on TS-3325: -- TS-2195 got rid of TSHttpTxnCacheLookupSkip().. TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash -- Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
[ https://issues.apache.org/jira/browse/TS-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3325: - Fix Version/s: 5.3.0 TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash -- Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-898) Fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-898: --- Fix Version/s: 4.2.3 Fix potential problems from coverity scan - Key: TS-898 URL: https://issues.apache.org/jira/browse/TS-898 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Environment: RHEL5 Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: 4.2.3, 5.2.0 Ran Coverity over the code and it reported 856 potential problems with the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2715) Compiler warning in ESI plugin
[ https://issues.apache.org/jira/browse/TS-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2715: Fix Version/s: 4.2.3 Compiler warning in ESI plugin -- Key: TS-2715 URL: https://issues.apache.org/jira/browse/TS-2715 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Trivial Fix For: 4.2.3, 5.0.0 lib/EsiGzip.cc:36:18: warning: unused variable 'GZIP_TRAILER_SIZE' [-Wunused-const-variable] static const int GZIP_TRAILER_SIZE = 8; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3262) Build failure using clang on Fedora 21
[
https://issues.apache.org/jira/browse/TS-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3262:
Fix Version/s: 4.2.3
Build failure using clang on Fedora 21
--
Key: TS-3262
URL: https://issues.apache.org/jira/browse/TS-3262
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Blocker
Fix For: 4.2.3, 5.2.0
{code}
../../proxy/CoreUtils.cc:266:22: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t offset2 = abs(vaddr - vadd);
^
../../proxy/CoreUtils.cc:266:22: note: use function 'std::abs' instead
intptr_t offset2 = abs(vaddr - vadd);
^~~
std::abs
../../proxy/CoreUtils.cc:305:19: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t off2 = abs(vadd - framep);
^
../../proxy/CoreUtils.cc:305:19: note: use function 'std::abs' instead
intptr_t off2 = abs(vadd - framep);
^~~
std::abs
../../proxy/CoreUtils.cc:348:19: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t off2 = abs(vadd - framep);
^
../../proxy/CoreUtils.cc:348:19: note: use function 'std::abs' instead
intptr_t off2 = abs(vadd - framep);
^~~
std::abs
../../proxy/CoreUtils.cc:652:20: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
int nto_copy = abs((char *) copy_start - free_start);
^
../../proxy/CoreUtils.cc:652:20: note: use function 'std::abs' instead
int nto_copy = abs((char *) copy_start - free_start);
^~~
std::abs
../../proxy/CoreUtils.cc:794:22: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t offset2 = abs(vaddr - vadd);
^
../../proxy/CoreUtils.cc:794:22: note: use function 'std::abs' instead
intptr_t offset2 = abs(vaddr - vadd);
^~~
std::abs
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3267) server request http version is 0.9
[ https://issues.apache.org/jira/browse/TS-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292838#comment-14292838 ] Qiang Li commented on TS-3267: -- same as https://issues.apache.org/jira/browse/TS-3326, so closed server request http version is 0.9 -- Key: TS-3267 URL: https://issues.apache.org/jira/browse/TS-3267 Project: Traffic Server Issue Type: Bug Reporter: Qiang Li Fix For: sometime http://www.test.com/test.mp4 is HIT_FRESH in cache In TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE event I use TSHttpTxnCacheLookupStatusSet api change cache status to HIT_STALE And use TSHttpTxnServerAddrSet api add a server addr Then the server request http version is 0.9(client request http version is 1.1) I find the code in this situation no dnslookup, so the http version no change to 1.1 anyone can help me, thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Comment Edited] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
On Jan 26, 2015, at 6:33 PM, Sudheer Vinukonda sudhe...@yahoo-inc.com wrote: Hmm, that's done via get_ka_info_from_host_db() which gets called from inside the OSDNSLookup() - but, I suppose I could do the extra checking also in get_ka_info_from_config()? Wouldn’t that make sense? Since you can avoid the hostdb lookup entirely? Also, the client request check should only happen if it’s set to SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB, not in any other case. — leif Thanks, Sudheer On Monday, January 26, 2015 4:42 PM, Leif Hedstrom zw...@apache.org wrote: I'm on a phone so hard to read the code, but where does it check the client request version in the :SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB case? If the client request is not http 1.1 there is no reason to do a HOSTDB lookup, right? -- Leif On Jan 26, 2015, at 5:07 PM, Sudheer Vinukonda (JIRA) j...@apache.org mailto:j...@apache.org wrote: :SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB
[jira] [Closed] (TS-3267) server request http version is 0.9
[ https://issues.apache.org/jira/browse/TS-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Li closed TS-3267. Resolution: Duplicate server request http version is 0.9 -- Key: TS-3267 URL: https://issues.apache.org/jira/browse/TS-3267 Project: Traffic Server Issue Type: Bug Reporter: Qiang Li Fix For: sometime http://www.test.com/test.mp4 is HIT_FRESH in cache In TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE event I use TSHttpTxnCacheLookupStatusSet api change cache status to HIT_STALE And use TSHttpTxnServerAddrSet api add a server addr Then the server request http version is 0.9(client request http version is 1.1) I find the code in this situation no dnslookup, so the http version no change to 1.1 anyone can help me, thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Comment Edited] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
Hmm, that's done via get_ka_info_from_host_db() which gets called from inside the OSDNSLookup() - but, I suppose I could do the extra checking also in get_ka_info_from_config()? Thanks, Sudheer On Monday, January 26, 2015 4:42 PM, Leif Hedstrom zw...@apache.org wrote: I'm on a phone so hard to read the code, but where does it check the client request version in the :SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB case? If the client request is not http 1.1 there is no reason to do a HOSTDB lookup, right? -- Leif On Jan 26, 2015, at 5:07 PM, Sudheer Vinukonda (JIRA) j...@apache.org wrote: :SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB
[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=14292693#comment-14292693
]
ASF subversion and git services commented on TS-3326:
-
Commit 0f6f84e7b0427a3f24d65d72c82171abf49cd763 in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0f6f84e ]
[TS-3326]: proxy.config.http.send_http11_requests not applied when hostdb
lookup is not performed
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] [Updated] (TS-3328) TS API for setting HTTP Version for a given origin
[
https://issues.apache.org/jira/browse/TS-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3328:
--
Fix Version/s: sometime
TS API for setting HTTP Version for a given origin
--
Key: TS-3328
URL: https://issues.apache.org/jira/browse/TS-3328
Project: Traffic Server
Issue Type: Improvement
Components: Core, Plugins
Reporter: Sudheer Vinukonda
Fix For: sometime
The existing TS API {{TSHttpHdrVersionSet}} allows to set http version of an
outgoing http request. However, this does only that (just update the version
field in the request). It doesn't necessarily use the updated version to
build the http request accordingly (for instance, if the http version of a
1.1 request is modified to 0.9 using this API, the request will still contain
the Host header. It doesn't remove the Host header, based on the version). It
would be desirable to have a TS API that can set the origin version and
influence the building of the request accordingly.
Below is an example of such API:
{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 1abdcbf..07809b2 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -5270,6 +5270,20 @@ TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr)
}
}
+TSReturnCode
+TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp, int ver)
+{
+ sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
+
+ HttpSM *sm = reinterpret_castHttpSM *(txnp);
+ HTTPVersion version(ver);
+ if (version != HTTPVersion(0, 0)) {
+sm-t_state.server_info.http_version = version;
+return TS_SUCCESS;
+ }
+ return TS_ERROR;
+}
+
void
TSHttpTxnClientIncomingPortSet(TSHttpTxn txnp, int port)
{
diff --git a/proxy/api/ts/ts.h b/proxy/api/ts/ts.h
index 4783b97..9a0e80c 100644
--- a/proxy/api/ts/ts.h
+++ b/proxy/api/ts/ts.h
@@ -1329,6 +1329,15 @@ extern C
tsapi TSReturnCode TSHttpTxnServerAddrSet(TSHttpTxn txnp,
struct sockaddr const* addr /**
Address for origin server. */
);
+ /** Set the outgoing server http version.
+
+ This must be invoked before the server request is sent.
+
+ @return @c TS_SUCCESS if the outgoing server http version is valid, @c
TS_ERROR otherwise.
+ */
+ tsapi TSReturnCode TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp,
+int ver /** http version for
outgoing server request. */
+);
/** Get the next hop address.
*
{code}
However, discussing this API on the IRC, [~zwoop] pointed out the
inconsistency/confusion this new API might bring in with the existing TS API
{{TSHttpHdrVersionSet}}. Specifically, the resultant behavior of a plugin
using both API is unpredictable depending on the hooks used. But, the need
for such an API is still there, so opening this jira to track that
requirement. The final solution may involve coming up with a single API that
can do both what the existing API does and the requirement to build the Http
request accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3328) TS API for setting HTTP Version for a given origin
[
https://issues.apache.org/jira/browse/TS-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3328:
--
Description:
The existing TS API {{TSHttpHdrVersionSet}} allows to set http version of an
outgoing http request. However, this does only that (just update the version
field in the request). It doesn't necessarily use the updated version to build
the http request accordingly (for instance, if the http version of a 1.1
request is modified to 0.9 using this API, the request will still contain the
Host header. It doesn't remove the Host header, based on the version). It would
be desirable to have a TS API that can set the origin version and influence the
building of the request accordingly. See also related jiras TS-3326 and TS-3327
Below is an example of such API:
{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 1abdcbf..07809b2 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -5270,6 +5270,20 @@ TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr)
}
}
+TSReturnCode
+TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp, int ver)
+{
+ sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
+
+ HttpSM *sm = reinterpret_castHttpSM *(txnp);
+ HTTPVersion version(ver);
+ if (version != HTTPVersion(0, 0)) {
+sm-t_state.server_info.http_version = version;
+return TS_SUCCESS;
+ }
+ return TS_ERROR;
+}
+
void
TSHttpTxnClientIncomingPortSet(TSHttpTxn txnp, int port)
{
diff --git a/proxy/api/ts/ts.h b/proxy/api/ts/ts.h
index 4783b97..9a0e80c 100644
--- a/proxy/api/ts/ts.h
+++ b/proxy/api/ts/ts.h
@@ -1329,6 +1329,15 @@ extern C
tsapi TSReturnCode TSHttpTxnServerAddrSet(TSHttpTxn txnp,
struct sockaddr const* addr /**
Address for origin server. */
);
+ /** Set the outgoing server http version.
+
+ This must be invoked before the server request is sent.
+
+ @return @c TS_SUCCESS if the outgoing server http version is valid, @c
TS_ERROR otherwise.
+ */
+ tsapi TSReturnCode TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp,
+int ver /** http version for
outgoing server request. */
+);
/** Get the next hop address.
*
{code}
However, discussing this API on the IRC, [~zwoop] pointed out the
inconsistency/confusion this new API might bring in with the existing TS API
{{TSHttpHdrVersionSet}}. Specifically, the resultant behavior of a plugin using
both API is unpredictable depending on the hooks used. But, the need for such
an API is still there, so opening this jira to track that requirement. The
final solution may involve coming up with a single API that can do both what
the existing API does and the requirement to build the Http request accordingly.
was:
The existing TS API {{TSHttpHdrVersionSet}} allows to set http version of an
outgoing http request. However, this does only that (just update the version
field in the request). It doesn't necessarily use the updated version to build
the http request accordingly (for instance, if the http version of a 1.1
request is modified to 0.9 using this API, the request will still contain the
Host header. It doesn't remove the Host header, based on the version). It would
be desirable to have a TS API that can set the origin version and influence the
building of the request accordingly.
Below is an example of such API:
{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 1abdcbf..07809b2 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -5270,6 +5270,20 @@ TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr)
}
}
+TSReturnCode
+TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp, int ver)
+{
+ sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
+
+ HttpSM *sm = reinterpret_castHttpSM *(txnp);
+ HTTPVersion version(ver);
+ if (version != HTTPVersion(0, 0)) {
+sm-t_state.server_info.http_version = version;
+return TS_SUCCESS;
+ }
+ return TS_ERROR;
+}
+
void
TSHttpTxnClientIncomingPortSet(TSHttpTxn txnp, int port)
{
diff --git a/proxy/api/ts/ts.h b/proxy/api/ts/ts.h
index 4783b97..9a0e80c 100644
--- a/proxy/api/ts/ts.h
+++ b/proxy/api/ts/ts.h
@@ -1329,6 +1329,15 @@ extern C
tsapi TSReturnCode TSHttpTxnServerAddrSet(TSHttpTxn txnp,
struct sockaddr const* addr /**
Address for origin server. */
);
+ /** Set the outgoing server http version.
+
+ This must be invoked before the server request is sent.
+
+ @return @c TS_SUCCESS if the outgoing server http version is valid, @c
TS_ERROR otherwise.
+ */
+ tsapi TSReturnCode TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp,
+int ver /** http version for
outgoing server request. */
+
Re: [jira] [Comment Edited] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
I'm on a phone so hard to read the code, but where does it check the client request version in the :SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB case? If the client request is not http 1.1 there is no reason to do a HOSTDB lookup, right? -- Leif On Jan 26, 2015, at 5:07 PM, Sudheer Vinukonda (JIRA) j...@apache.org wrote: :SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB
[jira] [Created] (TS-3321) balancer plugin is not compatible with trafficserver
Igor Galić created TS-3321:
--
Summary: balancer plugin is not compatible with trafficserver
Key: TS-3321
URL: https://issues.apache.org/jira/browse/TS-3321
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
{code}
FATAL: unable to find TSPluginInit function in
'/usr/lib/trafficserver/modules/balancer.so':
/usr/lib/trafficserver/modules/balancer.so: undefined symbol: TSPluginInit
traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*, int,
char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
traffic_server: Aborted (Signal sent by tkill() 5430 107)
traffic_server - STACK TRACE:
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
void*)+0x8e)[0x4a924e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b7169c5e340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x2b716a8c6cc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b716a8ca0d8]
/usr/lib/trafficserver/libtsutil.so.5(+0x245f9)[0x2b71687ca5f9]
/usr/lib/trafficserver/libtsutil.so.5(+0x246aa)[0x2b71687ca6aa]
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*, int,
char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3321) balancer plugin is not compatible with trafficserver
[
https://issues.apache.org/jira/browse/TS-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-3321:
---
Attachment: 0001-TS-3321-initialize-balancer.so-as-normal-plugin.patch
not sure this will be enough.
balancer plugin is not compatible with trafficserver
Key: TS-3321
URL: https://issues.apache.org/jira/browse/TS-3321
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Attachments:
0001-TS-3321-initialize-balancer.so-as-normal-plugin.patch
{code}
FATAL: unable to find TSPluginInit function in
'/usr/lib/trafficserver/modules/balancer.so':
/usr/lib/trafficserver/modules/balancer.so: undefined symbol: TSPluginInit
traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
traffic_server: Aborted (Signal sent by tkill() 5430 107)
traffic_server - STACK TRACE:
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
void*)+0x8e)[0x4a924e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b7169c5e340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x2b716a8c6cc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b716a8ca0d8]
/usr/lib/trafficserver/libtsutil.so.5(+0x245f9)[0x2b71687ca5f9]
/usr/lib/trafficserver/libtsutil.so.5(+0x246aa)[0x2b71687ca6aa]
/usr/lib/trafficserver/libtsutil.so.5(+0x15671)[0x2b71687bb671]
/usr/bin/traffic_server(Diags::error(DiagsLevel, char const*, char const*,
int, char const*, ...) const+0x7a)[0x49c03a]
/usr/bin/traffic_server(plugin_init()+0x657)[0x4dcab7]
/usr/bin/traffic_server(main+0xe47)[0x493ac7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b716a8b1ec5]
/usr/bin/traffic_server[0x499e1f]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3322) for a more stable build of plugins we should load them during test
Igor Galić created TS-3322:
--
Summary: for a more stable build of plugins we should load them
during test
Key: TS-3322
URL: https://issues.apache.org/jira/browse/TS-3322
Project: Traffic Server
Issue Type: Improvement
Components: Build, Plugins
Reporter: Igor Galić
currently we are building many (experimental) plugins without ever verifying if
they even load.
perhaps we should have a smoke test that starts ats with all (built) plugins in
{{plugin.config}}
a next step could be to actually test changed behaviour with remap plugins for
instance. but… baby steps ;)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3326) proxy.config.http.send_http11_requests not applied when hostdb lookup is not performed
Sudheer Vinukonda created TS-3326:
-
Summary: 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
Reporter: Sudheer Vinukonda
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- that proposes to change
the default to v1.1 in 6.0
--
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- that
proposes to change the default to an invalid value (e.g 0.0) in 6.0 (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- that proposes to change
the default to v1.1 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
Reporter: Sudheer Vinukonda
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- 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] [Created] (TS-3327) change the default http version in the source to an invalid version
Sudheer Vinukonda created TS-3327: - Summary: 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 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. -- 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 (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- 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
Reporter: Sudheer Vinukonda
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] [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 ] Bryan Call updated TS-3327: --- Fix Version/s: 5.3.0 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: 5.3.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 for some related changes. -- 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 ] Bryan Call updated TS-3327: --- Fix Version/s: (was: 5.3.0) 6.0.0 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 for some related changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (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=14292681#comment-14292681
]
Sudheer Vinukonda edited comment on TS-3326 at 1/27/15 12:07 AM:
-
Patch for this issue (tested by setting
{{proxy.config.http.send_http11_requests}} to both 1 (always http/11) and 2
(http/11 only if hostdb says so, which means perform a dns/hostdb lookup again):
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 24eab46..603b7ed 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2669,7 +2669,9 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
if (server_up || s-stale_icp_lookup) {
- if (!s-stale_icp_lookup !ats_is_ip(s-current.server-addr)) {
+ bool check_hostdb = get_ka_info_from_config(s, s-current.server);
+ if (!s-stale_icp_lookup (check_hostdb ||
!ats_is_ip(s-current.server-addr))) {
+ DebugTxn(http_trans, CacheOpenReadHit - doing hsotdb check);
//ink_release_assert(s-current.request_to == PARENT_PROXY ||
//s-http_config_param-no_dns_forward_to_parent != 0);
@@ -2695,6 +2697,7 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
}
+ DebugTxn(http_trans, CacheOpenReadHit - version %d,
s-current.server-http_version.m_version);
build_request(s, s-hdr_info.client_request,
s-hdr_info.server_request, s-current.server-http_version);
issue_revalidate(s);
@@ -4990,6 +4993,53 @@ HttpTransact::merge_warning_header(HTTPHdr*
cached_header, HTTPHdr* response_hea
}
}
+bool
+HttpTransact::get_ka_info_from_config(State *s, ConnectionAttributes
*server_info)
+{
+
+ // Set the keep-alive and version flags for later use //
+ // in request construction//
+ // this is also used when opening a connection to //
+ // the origin server, and search_keepalive_to(). //
+
+ bool check_hostdb = false;
+ if (server_info-http_version != HTTPVersion(0, 9)) {
+DebugTxn(http_trans, get_ka_info_from_config, version already set
server_info-http_version %d,
+server_info-http_version.m_version);
+return false;
+ }
+ switch (s-txn_conf-send_http11_requests) {
+ case HttpConfigParams::SEND_HTTP11_NEVER:
+server_info-http_version = HTTPVersion(1, 0);
+break;
+ case HttpConfigParams::SEND_HTTP11_ALWAYS:
+server_info-http_version = HTTPVersion(1, 1);
+break;
+ case HttpConfigParams::SEND_HTTP11_UPGRADE_HOSTDB:
+server_info-http_version = HTTPVersion(1, 0);
+check_hostdb = true;
+break;
+ default:
+ink_assert(0);
+// FALL THROUGH
+ case HttpConfigParams::SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB:
+server_info-http_version = HTTPVersion(1, 0);
+check_hostdb = true;
+break;
+ }
+ DebugTxn(http_trans, get_ka_info_from_config, server_info-http_version
%d, check_hostdb %d,
+server_info-http_version.m_version, check_hostdb);
+ /
+ // origin server keep_alive //
+ /
+ if (s-txn_conf-keep_alive_enabled_out) {
+server_info-keep_alive = HTTP_KEEPALIVE;
+ } else {
+server_info-keep_alive = HTTP_NO_KEEPALIVE;
+ }
+ return check_hostdb;
+}
+
diff --git a/proxy/http/HttpTransact.h b/proxy/http/HttpTransact.h
index fd8100c..121ec7d 100644
--- a/proxy/http/HttpTransact.h
+++ b/proxy/http/HttpTransact.h
@@ -1295,6 +1295,7 @@ public:
// Utility Methods
static void issue_revalidate(State* s);
+ static bool get_ka_info_from_config(State* s, ConnectionAttributes*
server_info);
static void get_ka_info_from_host_db(State* s, ConnectionAttributes*
server_info, ConnectionAttributes* client_info,
HostDBInfo* host_db_info);
static bool service_transaction_in_proxy_only_mode(State* s);
{code}
was (Author: sudheerv):
Patch for this issue (tested by setting
{{proxy.config.http.send_http11_requests}} to both 1 (always http/11) and 2
(http/11 only if hostdb says so):
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 24eab46..603b7ed 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2669,7 +2669,9 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
if (server_up || s-stale_icp_lookup) {
- if (!s-stale_icp_lookup !ats_is_ip(s-current.server-addr)) {
+ bool check_hostdb = get_ka_info_from_config(s, s-current.server);
+ if (!s-stale_icp_lookup (check_hostdb ||
!ats_is_ip(s-current.server-addr))) {
+ DebugTxn(http_trans, CacheOpenReadHit - doing hsotdb check);
//ink_release_assert(s-current.request_to == PARENT_PROXY ||
//s-http_config_param-no_dns_forward_to_parent != 0);
@@
[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:
--
Affects Version/s: 5.2.0
Fix Version/s: 5.3.0
Assignee: Sudheer Vinukonda
Patch for this issue (tested by setting
{{proxy.config.http.send_http11_requests}} to both 1 (always http/11) and 2
(http/11 only if hostdb says so):
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 24eab46..603b7ed 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2669,7 +2669,9 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
if (server_up || s-stale_icp_lookup) {
- if (!s-stale_icp_lookup !ats_is_ip(s-current.server-addr)) {
+ bool check_hostdb = get_ka_info_from_config(s, s-current.server);
+ if (!s-stale_icp_lookup (check_hostdb ||
!ats_is_ip(s-current.server-addr))) {
+ DebugTxn(http_trans, CacheOpenReadHit - doing hsotdb check);
//ink_release_assert(s-current.request_to == PARENT_PROXY ||
//s-http_config_param-no_dns_forward_to_parent != 0);
@@ -2695,6 +2697,7 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
}
+ DebugTxn(http_trans, CacheOpenReadHit - version %d,
s-current.server-http_version.m_version);
build_request(s, s-hdr_info.client_request,
s-hdr_info.server_request, s-current.server-http_version);
issue_revalidate(s);
@@ -4990,6 +4993,53 @@ HttpTransact::merge_warning_header(HTTPHdr*
cached_header, HTTPHdr* response_hea
}
}
+bool
+HttpTransact::get_ka_info_from_config(State *s, ConnectionAttributes
*server_info)
+{
+
+ // Set the keep-alive and version flags for later use //
+ // in request construction//
+ // this is also used when opening a connection to //
+ // the origin server, and search_keepalive_to(). //
+
+ bool check_hostdb = false;
+ if (server_info-http_version != HTTPVersion(0, 9)) {
+DebugTxn(http_trans, get_ka_info_from_config, version already set
server_info-http_version %d,
+server_info-http_version.m_version);
+return false;
+ }
+ switch (s-txn_conf-send_http11_requests) {
+ case HttpConfigParams::SEND_HTTP11_NEVER:
+server_info-http_version = HTTPVersion(1, 0);
+break;
+ case HttpConfigParams::SEND_HTTP11_ALWAYS:
+server_info-http_version = HTTPVersion(1, 1);
+break;
+ case HttpConfigParams::SEND_HTTP11_UPGRADE_HOSTDB:
+server_info-http_version = HTTPVersion(1, 0);
+check_hostdb = true;
+break;
+ default:
+ink_assert(0);
+// FALL THROUGH
+ case HttpConfigParams::SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB:
+server_info-http_version = HTTPVersion(1, 0);
+check_hostdb = true;
+break;
+ }
+ DebugTxn(http_trans, get_ka_info_from_config, server_info-http_version
%d, check_hostdb %d,
+server_info-http_version.m_version, check_hostdb);
+ /
+ // origin server keep_alive //
+ /
+ if (s-txn_conf-keep_alive_enabled_out) {
+server_info-keep_alive = HTTP_KEEPALIVE;
+ } else {
+server_info-keep_alive = HTTP_NO_KEEPALIVE;
+ }
+ return check_hostdb;
+}
+
diff --git a/proxy/http/HttpTransact.h b/proxy/http/HttpTransact.h
index fd8100c..121ec7d 100644
--- a/proxy/http/HttpTransact.h
+++ b/proxy/http/HttpTransact.h
@@ -1295,6 +1295,7 @@ public:
// Utility Methods
static void issue_revalidate(State* s);
+ static bool get_ka_info_from_config(State* s, ConnectionAttributes*
server_info);
static void get_ka_info_from_host_db(State* s, ConnectionAttributes*
server_info, ConnectionAttributes* client_info,
HostDBInfo* host_db_info);
static bool service_transaction_in_proxy_only_mode(State* s);
{code}
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
[jira] [Comment Edited] (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=14292681#comment-14292681
]
Sudheer Vinukonda edited comment on TS-3326 at 1/27/15 12:07 AM:
-
Patch for this issue (tested by setting
{{proxy.config.http.send_http11_requests}} to both 1 (always http/11) and 2
(http/11 only if hostdb says so, which means perform a dns/hostdb lookup):
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 24eab46..603b7ed 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2669,7 +2669,9 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
if (server_up || s-stale_icp_lookup) {
- if (!s-stale_icp_lookup !ats_is_ip(s-current.server-addr)) {
+ bool check_hostdb = get_ka_info_from_config(s, s-current.server);
+ if (!s-stale_icp_lookup (check_hostdb ||
!ats_is_ip(s-current.server-addr))) {
+ DebugTxn(http_trans, CacheOpenReadHit - doing hsotdb check);
//ink_release_assert(s-current.request_to == PARENT_PROXY ||
//s-http_config_param-no_dns_forward_to_parent != 0);
@@ -2695,6 +2697,7 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
}
+ DebugTxn(http_trans, CacheOpenReadHit - version %d,
s-current.server-http_version.m_version);
build_request(s, s-hdr_info.client_request,
s-hdr_info.server_request, s-current.server-http_version);
issue_revalidate(s);
@@ -4990,6 +4993,53 @@ HttpTransact::merge_warning_header(HTTPHdr*
cached_header, HTTPHdr* response_hea
}
}
+bool
+HttpTransact::get_ka_info_from_config(State *s, ConnectionAttributes
*server_info)
+{
+
+ // Set the keep-alive and version flags for later use //
+ // in request construction//
+ // this is also used when opening a connection to //
+ // the origin server, and search_keepalive_to(). //
+
+ bool check_hostdb = false;
+ if (server_info-http_version != HTTPVersion(0, 9)) {
+DebugTxn(http_trans, get_ka_info_from_config, version already set
server_info-http_version %d,
+server_info-http_version.m_version);
+return false;
+ }
+ switch (s-txn_conf-send_http11_requests) {
+ case HttpConfigParams::SEND_HTTP11_NEVER:
+server_info-http_version = HTTPVersion(1, 0);
+break;
+ case HttpConfigParams::SEND_HTTP11_ALWAYS:
+server_info-http_version = HTTPVersion(1, 1);
+break;
+ case HttpConfigParams::SEND_HTTP11_UPGRADE_HOSTDB:
+server_info-http_version = HTTPVersion(1, 0);
+check_hostdb = true;
+break;
+ default:
+ink_assert(0);
+// FALL THROUGH
+ case HttpConfigParams::SEND_HTTP11_IF_REQUEST_11_AND_HOSTDB:
+server_info-http_version = HTTPVersion(1, 0);
+check_hostdb = true;
+break;
+ }
+ DebugTxn(http_trans, get_ka_info_from_config, server_info-http_version
%d, check_hostdb %d,
+server_info-http_version.m_version, check_hostdb);
+ /
+ // origin server keep_alive //
+ /
+ if (s-txn_conf-keep_alive_enabled_out) {
+server_info-keep_alive = HTTP_KEEPALIVE;
+ } else {
+server_info-keep_alive = HTTP_NO_KEEPALIVE;
+ }
+ return check_hostdb;
+}
+
diff --git a/proxy/http/HttpTransact.h b/proxy/http/HttpTransact.h
index fd8100c..121ec7d 100644
--- a/proxy/http/HttpTransact.h
+++ b/proxy/http/HttpTransact.h
@@ -1295,6 +1295,7 @@ public:
// Utility Methods
static void issue_revalidate(State* s);
+ static bool get_ka_info_from_config(State* s, ConnectionAttributes*
server_info);
static void get_ka_info_from_host_db(State* s, ConnectionAttributes*
server_info, ConnectionAttributes* client_info,
HostDBInfo* host_db_info);
static bool service_transaction_in_proxy_only_mode(State* s);
{code}
was (Author: sudheerv):
Patch for this issue (tested by setting
{{proxy.config.http.send_http11_requests}} to both 1 (always http/11) and 2
(http/11 only if hostdb says so, which means perform a dns/hostdb lookup again):
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 24eab46..603b7ed 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2669,7 +2669,9 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
}
if (server_up || s-stale_icp_lookup) {
- if (!s-stale_icp_lookup !ats_is_ip(s-current.server-addr)) {
+ bool check_hostdb = get_ka_info_from_config(s, s-current.server);
+ if (!s-stale_icp_lookup (check_hostdb ||
!ats_is_ip(s-current.server-addr))) {
+ DebugTxn(http_trans, CacheOpenReadHit - doing hsotdb check);
//ink_release_assert(s-current.request_to == PARENT_PROXY ||
//
[jira] [Created] (TS-3328) TS API for setting HTTP Version for a given origin
Sudheer Vinukonda created TS-3328:
-
Summary: TS API for setting HTTP Version for a given origin
Key: TS-3328
URL: https://issues.apache.org/jira/browse/TS-3328
Project: Traffic Server
Issue Type: Improvement
Components: Core, Plugins
Reporter: Sudheer Vinukonda
The existing TS API {{TSHttpHdrVersionSet}} allows to set http version of an
outgoing http request. However, this does only that (just update the version
field in the request). It doesn't necessarily use the updated version to build
the http request accordingly (for instance, if the http version of a 1.1
request is modified to 0.9 using this API, the request will still contain the
Host header. It doesn't remove the Host header, based on the version). It would
be desirable to have a TS API that can set the origin version and influence the
building of the request accordingly.
Below is an example of such API:
{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 1abdcbf..07809b2 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -5270,6 +5270,20 @@ TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr)
}
}
+TSReturnCode
+TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp, int ver)
+{
+ sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
+
+ HttpSM *sm = reinterpret_castHttpSM *(txnp);
+ HTTPVersion version(ver);
+ if (version != HTTPVersion(0, 0)) {
+sm-t_state.server_info.http_version = version;
+return TS_SUCCESS;
+ }
+ return TS_ERROR;
+}
+
void
TSHttpTxnClientIncomingPortSet(TSHttpTxn txnp, int port)
{
diff --git a/proxy/api/ts/ts.h b/proxy/api/ts/ts.h
index 4783b97..9a0e80c 100644
--- a/proxy/api/ts/ts.h
+++ b/proxy/api/ts/ts.h
@@ -1329,6 +1329,15 @@ extern C
tsapi TSReturnCode TSHttpTxnServerAddrSet(TSHttpTxn txnp,
struct sockaddr const* addr /**
Address for origin server. */
);
+ /** Set the outgoing server http version.
+
+ This must be invoked before the server request is sent.
+
+ @return @c TS_SUCCESS if the outgoing server http version is valid, @c
TS_ERROR otherwise.
+ */
+ tsapi TSReturnCode TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp,
+int ver /** http version for
outgoing server request. */
+);
/** Get the next hop address.
*
{code}
However, discussing this API on the IRC, [~zwoop] pointed out the
inconsistency/confusion this new API might bring in with the existing TS API
{{TSHttpHdrVersionSet}}. Specifically, the resultant behavior of a plugin using
both API is unpredictable depending on the hooks used. But, the need for such
an API is still there, so opening this jira to track that requirement. The
final solution may involve coming up with a single API that can do both what
the existing API does and the requirement to build the Http request accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
