[jira] [Created] (TS-2705) master Crashes frequently
Faysal Banna created TS-2705: Summary: master Crashes frequently Key: TS-2705 URL: https://issues.apache.org/jira/browse/TS-2705 Project: Traffic Server Issue Type: Bug Components: Cache, Core, Lua Reporter: Faysal Banna Hi Guys I enabled ts_lua plugin and did experiment on my local computer all worked fine when i moved to the big machine hosting traffic i noticed that the ATS crashes most often (each 5 minutes almost ). i don't know the cause of it and can not confirm if its from the ts_lua stuff plugins enabled are ts_lua, cacheurl, header_rewrite, collapsed_connection anyhow here is the code i get in traffic.out NOTE: Traffic Server received Sig 11: Segmentation fault /usr/local/bin/traffic_server - STACK TRACE: /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2b16fe4fcbb0] /usr/local/bin/traffic_server(_ZN6HttpSM17tunnel_handler_uaEiP18HttpTunnelConsumer+0x31d)[0x51b30d] /usr/local/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x74)[0x56b704] /usr/local/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x108)[0x56d048] /usr/local/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0xf67)[0x68c4f7] /usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x681576] /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x9a3)[0x6af5a3] /usr/local/bin/traffic_server[0x6ae19a] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2b16fe4f4f6e] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b16ff2269cd] NOTE: Traffic Server received Sig 11: Segmentation fault /usr/local/bin/traffic_server - STACK TRACE: /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2ab35816abb0] /usr/local/bin/traffic_server(_Z20mime_field_value_getP9MIMEFieldPi+0x0)[0x5c7fd0] /usr/local/bin/traffic_server(_ZN12HttpTransact14build_responseEPNS_5StateEP7HTTPHdrS3_11HTTPVersion10HTTPStatusPKc+0x112)[0x54f892] /usr/local/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0x1e1)[0x55d7c1] /usr/local/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x147)[0x55ee67] /usr/local/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x56)[0x523466] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2c8)[0x52d7a8] /usr/local/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x82)[0x531f92] /usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4bea94] /usr/local/libexec/trafficserver/collapsed_connection.so(+0x3d05)[0x2ab361bc4d05] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x104)[0x52d5e4] /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x5ab)[0x53263b] /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2c8)[0x52d7a8] /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x5ab)[0x53263b] /usr/local/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x156)[0x52eda6] /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xbd)[0x52e2fd] /usr/local/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1c2)[0x510912] /usr/local/bin/traffic_server(_ZN7CacheVC8callcontEi+0x5b)[0x5f508b] /usr/local/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0xfba)[0x65cb3a] /usr/local/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x1c8)[0x63ab78] /usr/local/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x33)[0x5f3f83] /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x6b5de0] /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6f3)[0x6b6873] /usr/local/bin/traffic_server[0x6b571a] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2ab358162f6e] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ab358e949cd] much regards -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2584) failed assert transforming and caching negative response
[
https://issues.apache.org/jira/browse/TS-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963107#comment-13963107
]
ASF GitHub Bot commented on TS-2584:
Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/44#issuecomment-39865474
It seems to me there are two effecrive changes for this. The first minor
one is that the response can be set earlier in the method. The more concerning
one is that whether the response is set at all for negative caching. If the
info is valid on entry then it won't be, but if the entry isn't set then it
will be. Presumably the difference is that the transform is never valid on
entry. The big question is whether setting the response can be a problem.
failed assert transforming and caching negative response
Key: TS-2584
URL: https://issues.apache.org/jira/browse/TS-2584
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Jack Bates
Labels: Review
Fix For: 5.0.0
If negative caching is enabled and you transform a negative response (for
example a null transform) there is a failed assert in
HttpTransact::set_headers_for_cache_write()
{noformat}
FATAL: HttpTransact.cc:4811: failed assert
`cache_info-response_get()-valid()`
proxy/.libs/lt-traffic_server - STACK TRACE:
lib/ts/.libs/libtsutil.so.5(ink_fatal_die+0x0)[0xb77a6445]
lib/ts/.libs/libtsutil.so.5(+0x22269)[0xb77a5269]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0x1da)[0x81c0ae6]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x272)[0x81c0576]
proxy/.libs/lt-traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x78)[0x81a4b3e]
proxy/.libs/lt-traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0x196)[0x81926b0]
proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2df)[0x81969b5]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x27f)[0x815d81b]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x104)[0x8300692]
proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0xd6)[0x8300916]
proxy/.libs/lt-traffic_server[0x82ff569]
/lib/i686/cmov/libpthread.so.0(+0x5955)[0xb7467955]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb717f1de]
Aborted (core dumped)
{noformat}
HttpTransact::handle_transform_ready() passes s-cache_info.transform_store
to HttpTransact::set_headers_for_cache_write()
The -valid() test at the top of HttpTransact::set_headers_for_cache_write()
fails so -create() gets called.
{code}
if (!cache_info-valid()) {
cache_info-create();
}
{code}
(s-cache_info.transform_store-m_alt is NULL. I didn't look into why this
is, is it expected?)
Because s-negative_caching is true, cache_info-response_set(response)
doesn't get called, instead the assert fails.
{code}
if (!s-negative_caching)
cache_info-response_set(response);
else {
ink_assert(cache_info-response_get()-valid());
}
{code}
Assuming the cache_info-valid() test can fail and s-negative_caching can be
true at the same time, one possible solution is to fix the logic so
cache_info-response_set(response) gets called?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2705) master Crashes frequently
[
https://issues.apache.org/jira/browse/TS-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2705:
--
Description:
Hi Guys
I enabled ts_lua plugin and did experiment on my local computer all worked fine
when i moved to the big machine hosting traffic i noticed that the ATS crashes
most often (each 5 minutes almost ).
i don't know the cause of it and can not confirm if its from the ts_lua stuff
plugins enabled are ts_lua, cacheurl, header_rewrite, collapsed_connection
anyhow here is the code i get in traffic.out
{code}
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2b16fe4fcbb0]
/usr/local/bin/traffic_server(HttpSM::tunnel_handler_ua(int,
HttpTunnelConsumer*)+0x31d)[0x51b30d]
/usr/local/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x74)[0x56b704]
/usr/local/bin/traffic_server(HttpTunnel::main_handler(int,
void*)+0x108)[0x56d048]
/usr/local/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0xf67)[0x68c4f7]
/usr/local/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x286)[0x681576]
/usr/local/bin/traffic_server(EThread::execute()+0x9a3)[0x6af5a3]
/usr/local/bin/traffic_server[0x6ae19a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2b16fe4f4f6e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b16ff2269cd]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2ab35816abb0]
/usr/local/bin/traffic_server(mime_field_value_get(MIMEField*,
int*)+0x0)[0x5c7fd0]
/usr/local/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x112)[0x54f892]
/usr/local/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
HTTPWarningCode)+0x1e1)[0x55d7c1]
/usr/local/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x147)[0x55ee67]
/usr/local/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x56)[0x523466]
/usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x2c8)[0x52d7a8]
/usr/local/bin/traffic_server(HttpSM::state_api_callback(int,
void*)+0x82)[0x531f92]
/usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4bea94]
/usr/local/libexec/trafficserver/collapsed_connection.so(+0x3d05)[0x2ab361bc4d05]
/usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x104)[0x52d5e4]
/usr/local/bin/traffic_server(HttpSM::set_next_state()+0x5ab)[0x53263b]
/usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x2c8)[0x52d7a8]
/usr/local/bin/traffic_server(HttpSM::set_next_state()+0x5ab)[0x53263b]
/usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int,
void*)+0x156)[0x52eda6]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x52e2fd]
/usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
void*)+0x1c2)[0x510912]
/usr/local/bin/traffic_server(CacheVC::callcont(int)+0x5b)[0x5f508b]
/usr/local/bin/traffic_server(CacheVC::openReadStartHead(int,
Event*)+0xfba)[0x65cb3a]
/usr/local/bin/traffic_server(CacheVC::handleReadDone(int,
Event*)+0x1c8)[0x63ab78]
/usr/local/bin/traffic_server(AIOCallbackInternal::io_complete(int,
void*)+0x33)[0x5f3f83]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x150)[0x6b5de0]
/usr/local/bin/traffic_server(EThread::execute()+0x6f3)[0x6b6873]
/usr/local/bin/traffic_server[0x6b571a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2ab358162f6e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ab358e949cd]
{code}
much regards
was:
Hi Guys
I enabled ts_lua plugin and did experiment on my local computer all worked fine
when i moved to the big machine hosting traffic i noticed that the ATS crashes
most often (each 5 minutes almost ).
i don't know the cause of it and can not confirm if its from the ts_lua stuff
plugins enabled are ts_lua, cacheurl, header_rewrite, collapsed_connection
anyhow here is the code i get in traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2b16fe4fcbb0]
/usr/local/bin/traffic_server(_ZN6HttpSM17tunnel_handler_uaEiP18HttpTunnelConsumer+0x31d)[0x51b30d]
/usr/local/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnelConsumer+0x74)[0x56b704]
/usr/local/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x108)[0x56d048]
/usr/local/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0xf67)[0x68c4f7]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x681576]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x9a3)[0x6af5a3]
/usr/local/bin/traffic_server[0x6ae19a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2b16fe4f4f6e]
[jira] [Updated] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: (was: ts2650.diff) Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review Fix For: 5.0.0 Attachments: ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: ts2650.diff Updating the correct patch file.. Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review Fix For: 5.0.0 Attachments: ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963495#comment-13963495 ] ASF subversion and git services commented on TS-898: Commit dd608040b8c05cc54fba29e9fbec0f4987c6dfc5 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dd60804 ] TS-898: annotate intentional switch fallthrough Coverity #1021906 fix potential problems from coverity scan - Key: TS-898 URL: https://issues.apache.org/jira/browse/TS-898 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.0.0 Environment: RHEL5 Reporter: Bryan Call Fix For: sometime Ran Coverity over the code and it reported 856 potential problems with the code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2706) tcp_info plugin should load its config relative to SYSCONFDIR
James Peach created TS-2706:
---
Summary: tcp_info plugin should load its config relative to
SYSCONFDIR
Key: TS-2706
URL: https://issues.apache.org/jira/browse/TS-2706
Project: Traffic Server
Issue Type: Bug
Components: Packaging, Plugins
Reporter: James Peach
The {{tcp_info}} plugin loads it's configuration relative to the installation
prefix and hard-codes the intermediate paths. It should just use
{{TSConfigDirGet}} like all the other plugins.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2706) tcp_info plugin should load its config relative to SYSCONFDIR
[
https://issues.apache.org/jira/browse/TS-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2706:
Priority: Minor (was: Major)
Fix Version/s: 5.0.0
Assignee: James Peach
tcp_info plugin should load its config relative to SYSCONFDIR
-
Key: TS-2706
URL: https://issues.apache.org/jira/browse/TS-2706
Project: Traffic Server
Issue Type: Bug
Components: Packaging, Plugins
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 5.0.0
The {{tcp_info}} plugin loads it's configuration relative to the installation
prefix and hard-codes the intermediate paths. It should just use
{{TSConfigDirGet}} like all the other plugins.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963709#comment-13963709 ] portl4t commented on TS-2555: - Hi, all. I had add many features to ts-lua on https://github.com/portl4t/ts-lua. I don't know whether I should add these features to experimental/ts_lua. What's the progress of this issue now? Move existing lua plugin to plugins/deprecated and rename ts_lua to lua --- Key: TS-2555 URL: https://issues.apache.org/jira/browse/TS-2555 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.0.0 As suggested by Igor Galic in TS-2335, to avoid namespace pollution, we could move move the old Lua plugin to plugins/deprecated, and name this one lua again from the start. From what I gather, the consensus on the mailing list was to replace the old plugin with this one. Given that the old plugin was experimental, and we've decided that all bets regarding compatibility and stability are off in experimental, I'm fairly certain we can just do that. I'd move it, for easy reference into plugins/deprecated, remove it from the build, and once the new plugin has absorbed all of its features, remove it all together. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963714#comment-13963714 ] Leif Hedstrom commented on TS-2555: --- It'd be fine to make pull requests against ts-lua, until Kit gets a chance to close this one and deprecate the old Lua. I'm making an assumption here that there's not going to be an interest in merging the old Lua code into the new one? Move existing lua plugin to plugins/deprecated and rename ts_lua to lua --- Key: TS-2555 URL: https://issues.apache.org/jira/browse/TS-2555 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.0.0 As suggested by Igor Galic in TS-2335, to avoid namespace pollution, we could move move the old Lua plugin to plugins/deprecated, and name this one lua again from the start. From what I gather, the consensus on the mailing list was to replace the old plugin with this one. Given that the old plugin was experimental, and we've decided that all bets regarding compatibility and stability are off in experimental, I'm fairly certain we can just do that. I'd move it, for easy reference into plugins/deprecated, remove it from the build, and once the new plugin has absorbed all of its features, remove it all together. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2707) Migrate TSRedirectUrlSet/Get to TSHttpTxnRedirectUrlSet/Get
[
https://issues.apache.org/jira/browse/TS-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2707:
--
Labels: api-addition (was: )
Migrate TSRedirectUrlSet/Get to TSHttpTxnRedirectUrlSet/Get
---
Key: TS-2707
URL: https://issues.apache.org/jira/browse/TS-2707
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Labels: api-addition
Fix For: 5.0.0
From my Email:
So I’ve spent some more time on this, and instead of the above, I’d like to
propose the following:
1. We leave TSRedirectUrlSet() / Get() as is (as far as functionality goes).
This makes this proposal both API and binary compatible with v4.2.x.
2. We mark them as Deprecated, removing the old API in 6.0.0.
3. We add TSHttpTxnRedirectSet() / Get() , with the new string ownership as
described above. This naming convention is much better aligned with the rest
of our APIs.
I left the URL string lengths as int type for now, we’ll discuss at the
Summit about TS-2514, changing our usage of “int” to more appropriate size_t
etc.
Cheers,
— Leif
{code}
/**
This is a generalization of the TSHttpTxnFollowRedirect(), but gives finer
control over the behavior. Instead of using the Location: header for the
new
destination, this API takes the new URL as a parameter. Calling this API
transfers the ownership of the URL from the plugin to the core, so you
must
make sure it is heap allocated, and that you do not free it.
Calling this API implicitly also enables the Follow Redirect feature, so
there is no rason to call TSHttpTxnFollowRedirect() as well.
@param txnp the transaction pointer
@param url a heap allocated string with the URL
@param url_len the length of the URL
*/
tsapi void TSHttpTxnRedirectUrlSet(TSHttpTxn txnp, const char* url, int
url_len);
tsapi TS_DEPRECATED void TSRedirectUrlSet(TSHttpTxn txnp, const char* url,
const int url_len);
/**
Return the current (if set) redirection URL string. This is still owned
by the
core, and must not be free'd.
@param txnp the transaction pointer
@param url_len_ptr a pointer to where the URL length is to be stored
@return the url string
*/
tsapi const char* TSHttpTxnRedirectUrlGet(TSHttpTxn txnp, int* url_len_ptr);
tsapi TS_DEPRECATED const char* TSRedirectUrlGet(TSHttpTxn txnp, int*
url_len_ptr);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2707) Migrate TSRedirectUrlSet/Get to TSHttpTxnRedirectUrlSet/Get
[
https://issues.apache.org/jira/browse/TS-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2707:
-
Assignee: Leif Hedstrom
Migrate TSRedirectUrlSet/Get to TSHttpTxnRedirectUrlSet/Get
---
Key: TS-2707
URL: https://issues.apache.org/jira/browse/TS-2707
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: api-addition
Fix For: 5.0.0
From my Email:
So I’ve spent some more time on this, and instead of the above, I’d like to
propose the following:
1. We leave TSRedirectUrlSet() / Get() as is (as far as functionality goes).
This makes this proposal both API and binary compatible with v4.2.x.
2. We mark them as Deprecated, removing the old API in 6.0.0.
3. We add TSHttpTxnRedirectSet() / Get() , with the new string ownership as
described above. This naming convention is much better aligned with the rest
of our APIs.
I left the URL string lengths as int type for now, we’ll discuss at the
Summit about TS-2514, changing our usage of “int” to more appropriate size_t
etc.
Cheers,
— Leif
{code}
/**
This is a generalization of the TSHttpTxnFollowRedirect(), but gives finer
control over the behavior. Instead of using the Location: header for the
new
destination, this API takes the new URL as a parameter. Calling this API
transfers the ownership of the URL from the plugin to the core, so you
must
make sure it is heap allocated, and that you do not free it.
Calling this API implicitly also enables the Follow Redirect feature, so
there is no rason to call TSHttpTxnFollowRedirect() as well.
@param txnp the transaction pointer
@param url a heap allocated string with the URL
@param url_len the length of the URL
*/
tsapi void TSHttpTxnRedirectUrlSet(TSHttpTxn txnp, const char* url, int
url_len);
tsapi TS_DEPRECATED void TSRedirectUrlSet(TSHttpTxn txnp, const char* url,
const int url_len);
/**
Return the current (if set) redirection URL string. This is still owned
by the
core, and must not be free'd.
@param txnp the transaction pointer
@param url_len_ptr a pointer to where the URL length is to be stored
@return the url string
*/
tsapi const char* TSHttpTxnRedirectUrlGet(TSHttpTxn txnp, int* url_len_ptr);
tsapi TS_DEPRECATED const char* TSRedirectUrlGet(TSHttpTxn txnp, int*
url_len_ptr);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2707) Migrate TSRedirectUrlSet/Get to TSHttpTxnRedirectUrlSet/Get
Leif Hedstrom created TS-2707:
-
Summary: Migrate TSRedirectUrlSet/Get to
TSHttpTxnRedirectUrlSet/Get
Key: TS-2707
URL: https://issues.apache.org/jira/browse/TS-2707
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
From my Email:
So I’ve spent some more time on this, and instead of the above, I’d like to
propose the following:
1. We leave TSRedirectUrlSet() / Get() as is (as far as functionality goes).
This makes this proposal both API and binary compatible with v4.2.x.
2. We mark them as Deprecated, removing the old API in 6.0.0.
3. We add TSHttpTxnRedirectSet() / Get() , with the new string ownership as
described above. This naming convention is much better aligned with the rest of
our APIs.
I left the URL string lengths as int type for now, we’ll discuss at the Summit
about TS-2514, changing our usage of “int” to more appropriate size_t etc.
Cheers,
— Leif
{code}
/**
This is a generalization of the TSHttpTxnFollowRedirect(), but gives finer
control over the behavior. Instead of using the Location: header for the new
destination, this API takes the new URL as a parameter. Calling this API
transfers the ownership of the URL from the plugin to the core, so you must
make sure it is heap allocated, and that you do not free it.
Calling this API implicitly also enables the Follow Redirect feature, so
there is no rason to call TSHttpTxnFollowRedirect() as well.
@param txnp the transaction pointer
@param url a heap allocated string with the URL
@param url_len the length of the URL
*/
tsapi void TSHttpTxnRedirectUrlSet(TSHttpTxn txnp, const char* url, int
url_len);
tsapi TS_DEPRECATED void TSRedirectUrlSet(TSHttpTxn txnp, const char* url,
const int url_len);
/**
Return the current (if set) redirection URL string. This is still owned by
the
core, and must not be free'd.
@param txnp the transaction pointer
@param url_len_ptr a pointer to where the URL length is to be stored
@return the url string
*/
tsapi const char* TSHttpTxnRedirectUrlGet(TSHttpTxn txnp, int* url_len_ptr);
tsapi TS_DEPRECATED const char* TSRedirectUrlGet(TSHttpTxn txnp, int*
url_len_ptr);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963785#comment-13963785 ] Kit Chan commented on TS-2555: -- I have been making progress in listing the gaps of features between the two and make sure ts_lua will contain all of the functionality of the old Lua before deprecating it. And I will definitely ask that question in the mailing list before doing so. portl4t, I also have been paying attention to changes in your github repository. There are indeed a lot of functionality you have added. I think you can make pull requests against ts_lua as Leif suggested or file jira ticket with the patch. Either way is fine. I can help to review and merge it in. Thanks. Move existing lua plugin to plugins/deprecated and rename ts_lua to lua --- Key: TS-2555 URL: https://issues.apache.org/jira/browse/TS-2555 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.0.0 As suggested by Igor Galic in TS-2335, to avoid namespace pollution, we could move move the old Lua plugin to plugins/deprecated, and name this one lua again from the start. From what I gather, the consensus on the mailing list was to replace the old plugin with this one. Given that the old plugin was experimental, and we've decided that all bets regarding compatibility and stability are off in experimental, I'm fairly certain we can just do that. I'd move it, for easy reference into plugins/deprecated, remove it from the build, and once the new plugin has absorbed all of its features, remove it all together. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963791#comment-13963791 ] Leif Hedstrom commented on TS-2555: --- To minimize confusion right now, maybe we should turn off building the old plugin? Move existing lua plugin to plugins/deprecated and rename ts_lua to lua --- Key: TS-2555 URL: https://issues.apache.org/jira/browse/TS-2555 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.0.0 As suggested by Igor Galic in TS-2335, to avoid namespace pollution, we could move move the old Lua plugin to plugins/deprecated, and name this one lua again from the start. From what I gather, the consensus on the mailing list was to replace the old plugin with this one. Given that the old plugin was experimental, and we've decided that all bets regarding compatibility and stability are off in experimental, I'm fairly certain we can just do that. I'd move it, for easy reference into plugins/deprecated, remove it from the build, and once the new plugin has absorbed all of its features, remove it all together. -- This message was sent by Atlassian JIRA (v6.2#6252)
