[jira] [Updated] (TS-2218) create a standard way of getting the plugin configuration directory
[ https://issues.apache.org/jira/browse/TS-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2218: -- Fix Version/s: 4.1.0 create a standard way of getting the plugin configuration directory --- Key: TS-2218 URL: https://issues.apache.org/jira/browse/TS-2218 Project: Traffic Server Issue Type: Improvement Components: Configuration, Plugins Reporter: Bryan Call Fix For: 4.1.0 Currently some plugins use TSPluginDirGet() (/usr/local/libexec/trafficserver) and some have hard coded paths for getting the directory where the config files are set. I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in config.layout and is /usr/local/etc by default) as the default base directory for the plugin configuration. Under this directory people will have their config file or a sub directory if there are a lot of config files for a plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/) There will be an API to get the plugin config directory called TSPluginConfigDir() and this will by default pass back sysconfdir/trafficserver/plugins/. All plugins will use this API to get the configuration directory. There will also be a records.config option to override the default plugin config directory. This option will be called proxy.config.plugin.plugin_config_dir. This option will be set to NULL by default and the API will assume sysconfdir/trafficsever/plugins by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2218) create a standard way of getting the plugin configuration directory
Bryan Call created TS-2218: -- Summary: create a standard way of getting the plugin configuration directory Key: TS-2218 URL: https://issues.apache.org/jira/browse/TS-2218 Project: Traffic Server Issue Type: Improvement Components: Configuration, Plugins Reporter: Bryan Call Currently some plugins use TSPluginDirGet() (/usr/local/libexec/trafficserver) and some have hard coded paths for getting the directory where the config files are set. I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in config.layout and is /usr/local/etc by default) as the default base directory for the plugin configuration. Under this directory people will have their config file or a sub directory if there are a lot of config files for a plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/) There will be an API to get the plugin config directory called TSPluginConfigDir() and this will by default pass back sysconfdir/trafficserver/plugins/. All plugins will use this API to get the configuration directory. There will also be a records.config option to override the default plugin config directory. This option will be called proxy.config.plugin.plugin_config_dir. This option will be set to NULL by default and the API will assume sysconfdir/trafficsever/plugins by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2217) remove the option to turn off body factory - setting it to 0 will result in empty responses
[ https://issues.apache.org/jira/browse/TS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2217: --- Backport to Version: 4.0.2 remove the option to turn off body factory - setting it to 0 will result in empty responses --- Key: TS-2217 URL: https://issues.apache.org/jira/browse/TS-2217 Project: Traffic Server Issue Type: Bug Components: Configuration, Core Reporter: Bryan Call Fix For: 4.1.0 When setting proxy.config.body_factory.enable_customizations to 0 clients will get empty responses when errors occur, such as remap rule not found. The option 0 should be remove as a valid option. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1952) plugin.config is no reload-able
[ https://issues.apache.org/jira/browse/TS-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1952: -- Fix Version/s: (was: sometime) plugin.config is no reload-able --- Key: TS-1952 URL: https://issues.apache.org/jira/browse/TS-1952 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Zhao Yongming plugin.config is monitored by manager, but there is no call back for plugin.config reload, that is the basic requirement for plugins to be reloadable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1677) header_filter should first look in sysconfdir for its config file
[
https://issues.apache.org/jira/browse/TS-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766179#comment-13766179
]
Leif Hedstrom commented on TS-1677:
---
This should be solved generically, as with TS-2218. I'd suggest we close this
one as a dup of TS-2218 (if you do, then remove the Fix version for this one).
header_filter should first look in sysconfdir for its config file
-
Key: TS-1677
URL: https://issues.apache.org/jira/browse/TS-1677
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Assignee: James Peach
Fix For: 4.2.0
When {{header_filter}} plugin gets a relative config-file, it should look for
it in our {{sysconfdir}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1952) plugin.config is no reload-able
[ https://issues.apache.org/jira/browse/TS-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1952. --- Resolution: Duplicate Marking this as duplicate of TS-2015, I think they are the same. plugin.config is no reload-able --- Key: TS-1952 URL: https://issues.apache.org/jira/browse/TS-1952 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Zhao Yongming plugin.config is monitored by manager, but there is no call back for plugin.config reload, that is the basic requirement for plugins to be reloadable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2014) Add an API to register a plugin config file to monitor
[ https://issues.apache.org/jira/browse/TS-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2014: --- Component/s: Configuration Add an API to register a plugin config file to monitor -- Key: TS-2014 URL: https://issues.apache.org/jira/browse/TS-2014 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Phil Sorber Labels: C Fix For: 4.2.0 We have an API that triggers an event when a config changes (TSMgmtUpdateRegister) but it is only for core configs. The suggestion was made to allow a plugin to register its config file and be notified of changes upon a traffic_line -x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2014) Add an API to register a plugin config file to monitor
[ https://issues.apache.org/jira/browse/TS-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2014: --- Component/s: Plugins Add an API to register a plugin config file to monitor -- Key: TS-2014 URL: https://issues.apache.org/jira/browse/TS-2014 Project: Traffic Server Issue Type: New Feature Components: Configuration, Plugins Reporter: Phil Sorber Labels: C Fix For: 4.2.0 We have an API that triggers an event when a config changes (TSMgmtUpdateRegister) but it is only for core configs. The suggestion was made to allow a plugin to register its config file and be notified of changes upon a traffic_line -x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2144) traffic_server crashes when clearing cache
[
https://issues.apache.org/jira/browse/TS-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2144:
--
Fix Version/s: (was: 5.0.0)
4.1.0
Assignee: Leif Hedstrom
traffic_server crashes when clearing cache
--
Key: TS-2144
URL: https://issues.apache.org/jira/browse/TS-2144
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 4.1.0
I've been clearing the cache on a few non production hosts more often than
usual to test some config/plugin changes. Running traffic_server -Cclear
after stopping ATS occasionally results in the following. Running it again
will clear the cache.
{noformat}
# traffic_server -Cclear
[TrafficServer] using root directory '/home/y'
*** glibc detected *** traffic_server: realloc(): invalid pointer:
0x7f593f432010 ***
=== Backtrace: =
/lib64/libc.so.6[0x3895e753c6]
/lib64/libc.so.6(realloc+0x2e2)[0x3895e7b182]
/home/y/lib64/libtsutil.so.3(ats_realloc+0x9)[0x7f5942d4df19]
traffic_server(_Z25RecMessageMarshal_ReallocP13RecMessageHdrPK9RecRecord+0x97)[0x699177]
traffic_server(_Z17send_push_messagev+0x8b)[0x69599b]
traffic_server(_ZN9sync_cont4syncEiP5Event+0x3b)[0x69aceb]
traffic_server(_ZN7EThread7executeEv+0xc90)[0x6a4100]
traffic_server[0x6a1dca]
/lib64/libpthread.so.0(+0x3896207851)[0x7f5942554851]
/lib64/libc.so.6(clone+0x6d)[0x3895ee76dd]
=== Memory map:
0040-0075 r-xp fd:00 2795238
/home/y/bin64/traffic_server
0094f000-00963000 rw-p 0034f000 fd:00 2795238
/home/y/bin64/traffic_server
00963000-00f5b000 rw-p 00:00 0
012c6000-013e7000 rw-p 00:00 0
[heap]
3036a0-3036a15000 r-xp fd:01 238064
/lib64/libz.so.1.2.3
3036a15000-3036c14000 ---p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036c14000-3036c15000 r--p 00014000 fd:01 238064
/lib64/libz.so.1.2.3
3036c15000-3036c16000 rw-p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036e0-3036f73000 r-xp fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3036f73000-3037173000 ---p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037173000-303718c000 r--p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
303718c000-3037196000 rw-p 0018c000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037196000-303719a000 rw-p 00:00 0
303760-3037747000 r-xp fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037747000-3037946000 ---p 00147000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037946000-303795 rw-p 00146000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
303795-3037951000 rw-p 00:00 0
3037a0-3037a27000 r-xp fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037a27000-3037c27000 ---p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037c27000-3037c28000 rw-p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
389560-389562 r-xp fd:01 238023
/lib64/ld-2.12.so
389581f000-389582 r--p 0001f000 fd:01 238023
/lib64/ld-2.12.so
389582-3895821000 rw-p 0002 fd:01 238023
/lib64/ld-2.12.so
3895821000-3895822000 rw-p 00:00 0
3895a0-3895a02000 r-xp fd:01 238026
/lib64/libdl-2.12.so
3895a02000-3895c02000 ---p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c02000-3895c03000 r--p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c03000-3895c04000 rw-p 3000 fd:01 238026
/lib64/libdl-2.12.so
3895e0-3895f89000 r-xp fd:01 238024
/lib64/libc-2.12.so
3895f89000-3896188000 ---p 00189000 fd:01 238024
/lib64/libc-2.12.so
3896188000-389618c000 r--p 00188000 fd:01 238024
/lib64/libc-2.12.so
389618c000-389618d000 rw-p 0018c000 fd:01 238024
/lib64/libc-2.12.so
389618d000-3896192000 rw-p 00:00 0
389620-3896319000 r-xp fd:01 53667
/usr/lib64/libtcl8.5.so
3896319000-3896519000 ---p 00119000 fd:01 53667
/usr/lib64/libtcl8.5.so
3896519000-3896529000 rw-p 00119000 fd:01 53667
[jira] [Created] (TS-2219) TrafficServer only use one file if more files located in the same disk configured in storage.config
xiongzongtao created TS-2219: Summary: TrafficServer only use one file if more files located in the same disk configured in storage.config Key: TS-2219 URL: https://issues.apache.org/jira/browse/TS-2219 Project: Traffic Server Issue Type: Bug Reporter: xiongzongtao for example, 1. create two files with size 1G bytes on the same disk: -rw-rw-rw- 1 zongtao zongtao 1073741824 Sep 11 16:01 cache0.db -rw-rw-rw- 1 zongtao zongtao 1073741824 Sep 13 10:56 cache1.db 2. configure in storage.config as the following: /data2/cache0.db 1G /data2/cache1.db 1G 3. set debug on and add tags cache_init only cache1.db is initialized, cache0.db is not inited -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2220) add proxy.config.http.insert_client_ip
Zhao Yongming created TS-2220: - Summary: add proxy.config.http.insert_client_ip Key: TS-2220 URL: https://issues.apache.org/jira/browse/TS-2220 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Zhao Yongming this is for V4 branch changes, add the new proxy.config.http.insert_client_ip. we should name proxy.config.http.anonymize_insert_client_ip as 'proxy.config.http.insert_request_client_ip' or just 'proxy.config.http.insert_client_ip' and the current implement of the insert client ip works only if the client request do not have a 'Client-ip' header, but sometimes we need to replace it even if someone send us a fake 'Client-ip': proxy.config.http.insert_client_ip INT 1 When disabled(0), do nothing. When enabled (1), Traffic Server inserts Client-IP headers to retain the client IP address, if there is no such headers. When forced (2), Traffic Server inserts Client-IP, or replace the origin Client-IP header if it is already there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2220) add proxy.config.http.insert_client_ip
[ https://issues.apache.org/jira/browse/TS-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-2220: -- Affects Version/s: 4.0.1 Fix Version/s: 4.1.0 add proxy.config.http.insert_client_ip -- Key: TS-2220 URL: https://issues.apache.org/jira/browse/TS-2220 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 4.0.1 Reporter: Zhao Yongming Fix For: 4.1.0 this is for V4 branch changes, add the new proxy.config.http.insert_client_ip. we should name proxy.config.http.anonymize_insert_client_ip as 'proxy.config.http.insert_request_client_ip' or just 'proxy.config.http.insert_client_ip' and the current implement of the insert client ip works only if the client request do not have a 'Client-ip' header, but sometimes we need to replace it even if someone send us a fake 'Client-ip': proxy.config.http.insert_client_ip INT 1 When disabled(0), do nothing. When enabled (1), Traffic Server inserts Client-IP headers to retain the client IP address, if there is no such headers. When forced (2), Traffic Server inserts Client-IP, or replace the origin Client-IP header if it is already there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2221) remove proxy.config.http.anonymize_insert_client_ip
Zhao Yongming created TS-2221: - Summary: remove proxy.config.http.anonymize_insert_client_ip Key: TS-2221 URL: https://issues.apache.org/jira/browse/TS-2221 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Zhao Yongming this is for V5 branch changes, we should proxy.config.http.anonymize_insert_client_ip, as it is replaced by proxy.config.http.insert_client_ip. we should name proxy.config.http.anonymize_insert_client_ip as 'proxy.config.http.insert_request_client_ip' or just 'proxy.config.http.insert_client_ip' and the current implement of the insert client ip works only if the client request do not have a 'Client-ip' header, but sometimes we need to replace it even if someone send us a fake 'Client-ip': proxy.config.http.insert_client_ip INT 1 When disabled(0), do nothing. When enabled (1), Traffic Server inserts Client-IP headers to retain the client IP address, if there is no such headers. When forced (2), Traffic Server inserts Client-IP, or replace the origin Client-IP header if it is already there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2221) remove proxy.config.http.anonymize_insert_client_ip
[ https://issues.apache.org/jira/browse/TS-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-2221: -- Fix Version/s: 5.0.0 remove proxy.config.http.anonymize_insert_client_ip --- Key: TS-2221 URL: https://issues.apache.org/jira/browse/TS-2221 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Zhao Yongming Fix For: 5.0.0 this is for V5 branch changes, we should proxy.config.http.anonymize_insert_client_ip, as it is replaced by proxy.config.http.insert_client_ip. we should name proxy.config.http.anonymize_insert_client_ip as 'proxy.config.http.insert_request_client_ip' or just 'proxy.config.http.insert_client_ip' and the current implement of the insert client ip works only if the client request do not have a 'Client-ip' header, but sometimes we need to replace it even if someone send us a fake 'Client-ip': proxy.config.http.insert_client_ip INT 1 When disabled(0), do nothing. When enabled (1), Traffic Server inserts Client-IP headers to retain the client IP address, if there is no such headers. When forced (2), Traffic Server inserts Client-IP, or replace the origin Client-IP header if it is already there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2213) Body log tags have a default value of 0, should they be -1 now?
Leif Hedstrom created TS-2213: - Summary: Body log tags have a default value of 0, should they be -1 now? Key: TS-2213 URL: https://issues.apache.org/jira/browse/TS-2213 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Leif Hedstrom In our logging tags that provides a value for the body length, we default to 0 in the absence of a value. This is somewhat bad now, because we actually supports caching objects with a zero length body. Hence, it's not distinguishable between a zero length body entry, or one where we couldn't retrieve a body length (for whatever reason). I'm wondering if we should change all the defaults for all byte counts in logging from 0 to -1? This would be an incompatible change, so marking this for v5.0.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2211) SSL client connections hang and a aborted due to inactivity
[ https://issues.apache.org/jira/browse/TS-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766573#comment-13766573 ] Alan M. Carroll commented on TS-2211: - My interpretation - the NetVC socket level logic reads the data from the origin socket. It then signals down the VC chain that data is ready. This arrives at the HttpTunnel logic which passes it on from producer (origin socket) to consumer (client VC). The client VC then calls reenable on the VIO but, because the VIO is marked as enabled, nothing is done. As noted, this indicates the VIO was unscheduled / disabled while be left in a marked state. I think it likely that it was unmarked correctly and then, in the SSL logic, marked as enabled without really being enabled. The SSL logic does a lot of mucking about with scheduling VCs and playing with the enable marks. Given this does not happen in the non-SSL case, that seems a strong case. The key trigger is that data is read from the origin socket, and then written to the client socket before more data from the origin arrives, that is the SSL logic executes the case that it wants to write to the client socket but no data is available. SSL client connections hang and a aborted due to inactivity --- Key: TS-2211 URL: https://issues.apache.org/jira/browse/TS-2211 Project: Traffic Server Issue Type: Bug Components: HTTP, SSL Reporter: Theo Schlossnagle Fix For: 4.1.0 Test setup: ATS in reverse proxy mode. Terminating SSL for clients, remap to non-SSL for origin. Origin delays 10s before sending any data (including headers), then dumps a non-chunked response (Content-Length) of about 3Mbytes. Over slow client connections, the client session freezes mid download (around 256k in my tests)... hangs until the inactivity timer fires and snips all the connections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1869) Multiple cache lines in storage.config are ignored.
[ https://issues.apache.org/jira/browse/TS-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1869: --- Assignee: Alan M. Carroll Multiple cache lines in storage.config are ignored. --- Key: TS-1869 URL: https://issues.apache.org/jira/browse/TS-1869 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: A Fix For: 5.0.0 Using on-filesystem cache entries, and adding more than one line simply has no effect, only the last one seems to be used. It works fine for raw devices though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2144) traffic_server crashes when clearing cache
[
https://issues.apache.org/jira/browse/TS-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2144.
---
Resolution: Fixed
Fixed by moving out the RecordsConfig and remap processors to not start if
we're running a command line utility such as -Cclear.
traffic_server crashes when clearing cache
--
Key: TS-2144
URL: https://issues.apache.org/jira/browse/TS-2144
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 4.1.0
I've been clearing the cache on a few non production hosts more often than
usual to test some config/plugin changes. Running traffic_server -Cclear
after stopping ATS occasionally results in the following. Running it again
will clear the cache.
{noformat}
# traffic_server -Cclear
[TrafficServer] using root directory '/home/y'
*** glibc detected *** traffic_server: realloc(): invalid pointer:
0x7f593f432010 ***
=== Backtrace: =
/lib64/libc.so.6[0x3895e753c6]
/lib64/libc.so.6(realloc+0x2e2)[0x3895e7b182]
/home/y/lib64/libtsutil.so.3(ats_realloc+0x9)[0x7f5942d4df19]
traffic_server(_Z25RecMessageMarshal_ReallocP13RecMessageHdrPK9RecRecord+0x97)[0x699177]
traffic_server(_Z17send_push_messagev+0x8b)[0x69599b]
traffic_server(_ZN9sync_cont4syncEiP5Event+0x3b)[0x69aceb]
traffic_server(_ZN7EThread7executeEv+0xc90)[0x6a4100]
traffic_server[0x6a1dca]
/lib64/libpthread.so.0(+0x3896207851)[0x7f5942554851]
/lib64/libc.so.6(clone+0x6d)[0x3895ee76dd]
=== Memory map:
0040-0075 r-xp fd:00 2795238
/home/y/bin64/traffic_server
0094f000-00963000 rw-p 0034f000 fd:00 2795238
/home/y/bin64/traffic_server
00963000-00f5b000 rw-p 00:00 0
012c6000-013e7000 rw-p 00:00 0
[heap]
3036a0-3036a15000 r-xp fd:01 238064
/lib64/libz.so.1.2.3
3036a15000-3036c14000 ---p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036c14000-3036c15000 r--p 00014000 fd:01 238064
/lib64/libz.so.1.2.3
3036c15000-3036c16000 rw-p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036e0-3036f73000 r-xp fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3036f73000-3037173000 ---p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037173000-303718c000 r--p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
303718c000-3037196000 rw-p 0018c000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037196000-303719a000 rw-p 00:00 0
303760-3037747000 r-xp fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037747000-3037946000 ---p 00147000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037946000-303795 rw-p 00146000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
303795-3037951000 rw-p 00:00 0
3037a0-3037a27000 r-xp fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037a27000-3037c27000 ---p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037c27000-3037c28000 rw-p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
389560-389562 r-xp fd:01 238023
/lib64/ld-2.12.so
389581f000-389582 r--p 0001f000 fd:01 238023
/lib64/ld-2.12.so
389582-3895821000 rw-p 0002 fd:01 238023
/lib64/ld-2.12.so
3895821000-3895822000 rw-p 00:00 0
3895a0-3895a02000 r-xp fd:01 238026
/lib64/libdl-2.12.so
3895a02000-3895c02000 ---p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c02000-3895c03000 r--p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c03000-3895c04000 rw-p 3000 fd:01 238026
/lib64/libdl-2.12.so
3895e0-3895f89000 r-xp fd:01 238024
/lib64/libc-2.12.so
3895f89000-3896188000 ---p 00189000 fd:01 238024
/lib64/libc-2.12.so
3896188000-389618c000 r--p 00188000 fd:01 238024
/lib64/libc-2.12.so
389618c000-389618d000 rw-p 0018c000 fd:01 238024
/lib64/libc-2.12.so
389618d000-3896192000 rw-p 00:00 0
389620-3896319000 r-xp fd:01 53667
/usr/lib64/libtcl8.5.so
3896319000-3896519000 ---p 00119000 fd:01 53667
/usr/lib64/libtcl8.5.so
[jira] [Commented] (TS-2144) traffic_server crashes when clearing cache
[
https://issues.apache.org/jira/browse/TS-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766620#comment-13766620
]
ASF subversion and git services commented on TS-2144:
-
Commit b5edc06aaf1395429100e3f548d3c0c1fbc2a2e0 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b5edc06 ]
TS-2144 Avoid race on e.g. -Cclear which would crash the process
traffic_server crashes when clearing cache
--
Key: TS-2144
URL: https://issues.apache.org/jira/browse/TS-2144
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 4.1.0
I've been clearing the cache on a few non production hosts more often than
usual to test some config/plugin changes. Running traffic_server -Cclear
after stopping ATS occasionally results in the following. Running it again
will clear the cache.
{noformat}
# traffic_server -Cclear
[TrafficServer] using root directory '/home/y'
*** glibc detected *** traffic_server: realloc(): invalid pointer:
0x7f593f432010 ***
=== Backtrace: =
/lib64/libc.so.6[0x3895e753c6]
/lib64/libc.so.6(realloc+0x2e2)[0x3895e7b182]
/home/y/lib64/libtsutil.so.3(ats_realloc+0x9)[0x7f5942d4df19]
traffic_server(_Z25RecMessageMarshal_ReallocP13RecMessageHdrPK9RecRecord+0x97)[0x699177]
traffic_server(_Z17send_push_messagev+0x8b)[0x69599b]
traffic_server(_ZN9sync_cont4syncEiP5Event+0x3b)[0x69aceb]
traffic_server(_ZN7EThread7executeEv+0xc90)[0x6a4100]
traffic_server[0x6a1dca]
/lib64/libpthread.so.0(+0x3896207851)[0x7f5942554851]
/lib64/libc.so.6(clone+0x6d)[0x3895ee76dd]
=== Memory map:
0040-0075 r-xp fd:00 2795238
/home/y/bin64/traffic_server
0094f000-00963000 rw-p 0034f000 fd:00 2795238
/home/y/bin64/traffic_server
00963000-00f5b000 rw-p 00:00 0
012c6000-013e7000 rw-p 00:00 0
[heap]
3036a0-3036a15000 r-xp fd:01 238064
/lib64/libz.so.1.2.3
3036a15000-3036c14000 ---p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036c14000-3036c15000 r--p 00014000 fd:01 238064
/lib64/libz.so.1.2.3
3036c15000-3036c16000 rw-p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036e0-3036f73000 r-xp fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3036f73000-3037173000 ---p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037173000-303718c000 r--p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
303718c000-3037196000 rw-p 0018c000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037196000-303719a000 rw-p 00:00 0
303760-3037747000 r-xp fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037747000-3037946000 ---p 00147000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037946000-303795 rw-p 00146000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
303795-3037951000 rw-p 00:00 0
3037a0-3037a27000 r-xp fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037a27000-3037c27000 ---p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037c27000-3037c28000 rw-p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
389560-389562 r-xp fd:01 238023
/lib64/ld-2.12.so
389581f000-389582 r--p 0001f000 fd:01 238023
/lib64/ld-2.12.so
389582-3895821000 rw-p 0002 fd:01 238023
/lib64/ld-2.12.so
3895821000-3895822000 rw-p 00:00 0
3895a0-3895a02000 r-xp fd:01 238026
/lib64/libdl-2.12.so
3895a02000-3895c02000 ---p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c02000-3895c03000 r--p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c03000-3895c04000 rw-p 3000 fd:01 238026
/lib64/libdl-2.12.so
3895e0-3895f89000 r-xp fd:01 238024
/lib64/libc-2.12.so
3895f89000-3896188000 ---p 00189000 fd:01 238024
/lib64/libc-2.12.so
3896188000-389618c000 r--p 00188000 fd:01 238024
/lib64/libc-2.12.so
389618c000-389618d000 rw-p 0018c000 fd:01 238024
/lib64/libc-2.12.so
389618d000-3896192000 rw-p 00:00 0
389620-3896319000 r-xp
[jira] [Commented] (TS-2144) traffic_server crashes when clearing cache
[
https://issues.apache.org/jira/browse/TS-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766619#comment-13766619
]
ASF subversion and git services commented on TS-2144:
-
Commit f3fa606a0801d22357edfc724152aab60e7d7d07 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f3fa606 ]
Added TS-2144.
traffic_server crashes when clearing cache
--
Key: TS-2144
URL: https://issues.apache.org/jira/browse/TS-2144
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 4.1.0
I've been clearing the cache on a few non production hosts more often than
usual to test some config/plugin changes. Running traffic_server -Cclear
after stopping ATS occasionally results in the following. Running it again
will clear the cache.
{noformat}
# traffic_server -Cclear
[TrafficServer] using root directory '/home/y'
*** glibc detected *** traffic_server: realloc(): invalid pointer:
0x7f593f432010 ***
=== Backtrace: =
/lib64/libc.so.6[0x3895e753c6]
/lib64/libc.so.6(realloc+0x2e2)[0x3895e7b182]
/home/y/lib64/libtsutil.so.3(ats_realloc+0x9)[0x7f5942d4df19]
traffic_server(_Z25RecMessageMarshal_ReallocP13RecMessageHdrPK9RecRecord+0x97)[0x699177]
traffic_server(_Z17send_push_messagev+0x8b)[0x69599b]
traffic_server(_ZN9sync_cont4syncEiP5Event+0x3b)[0x69aceb]
traffic_server(_ZN7EThread7executeEv+0xc90)[0x6a4100]
traffic_server[0x6a1dca]
/lib64/libpthread.so.0(+0x3896207851)[0x7f5942554851]
/lib64/libc.so.6(clone+0x6d)[0x3895ee76dd]
=== Memory map:
0040-0075 r-xp fd:00 2795238
/home/y/bin64/traffic_server
0094f000-00963000 rw-p 0034f000 fd:00 2795238
/home/y/bin64/traffic_server
00963000-00f5b000 rw-p 00:00 0
012c6000-013e7000 rw-p 00:00 0
[heap]
3036a0-3036a15000 r-xp fd:01 238064
/lib64/libz.so.1.2.3
3036a15000-3036c14000 ---p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036c14000-3036c15000 r--p 00014000 fd:01 238064
/lib64/libz.so.1.2.3
3036c15000-3036c16000 rw-p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036e0-3036f73000 r-xp fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3036f73000-3037173000 ---p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037173000-303718c000 r--p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
303718c000-3037196000 rw-p 0018c000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037196000-303719a000 rw-p 00:00 0
303760-3037747000 r-xp fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037747000-3037946000 ---p 00147000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037946000-303795 rw-p 00146000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
303795-3037951000 rw-p 00:00 0
3037a0-3037a27000 r-xp fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037a27000-3037c27000 ---p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037c27000-3037c28000 rw-p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
389560-389562 r-xp fd:01 238023
/lib64/ld-2.12.so
389581f000-389582 r--p 0001f000 fd:01 238023
/lib64/ld-2.12.so
389582-3895821000 rw-p 0002 fd:01 238023
/lib64/ld-2.12.so
3895821000-3895822000 rw-p 00:00 0
3895a0-3895a02000 r-xp fd:01 238026
/lib64/libdl-2.12.so
3895a02000-3895c02000 ---p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c02000-3895c03000 r--p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c03000-3895c04000 rw-p 3000 fd:01 238026
/lib64/libdl-2.12.so
3895e0-3895f89000 r-xp fd:01 238024
/lib64/libc-2.12.so
3895f89000-3896188000 ---p 00189000 fd:01 238024
/lib64/libc-2.12.so
3896188000-389618c000 r--p 00188000 fd:01 238024
/lib64/libc-2.12.so
389618c000-389618d000 rw-p 0018c000 fd:01 238024
/lib64/libc-2.12.so
389618d000-3896192000 rw-p 00:00 0
389620-3896319000 r-xp fd:01 53667
[jira] [Commented] (TS-1869) Multiple cache lines in storage.config are ignored.
[ https://issues.apache.org/jira/browse/TS-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766589#comment-13766589 ] Alan M. Carroll commented on TS-1869: - The root is that the disk array in Store is really a two dimensional varying width array. Each Span instance in the array is also the head of an internally linked list. The Store initialization groups Span instances for the same physical device in to these lists but the cache initialization logic ignores the list. This works out for physical (raw) devices but for file storage units only one for each device is used. You can in fact have more than one file entry, it is that each entry must be on a different device or (roughly equivalent) under different mount points. There are other issues that make this a bit tricky to fix. The investigation is ongoing. Multiple cache lines in storage.config are ignored. --- Key: TS-1869 URL: https://issues.apache.org/jira/browse/TS-1869 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: A Fix For: 5.0.0 Using on-filesystem cache entries, and adding more than one line simply has no effect, only the last one seems to be used. It works fine for raw devices though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2224) We leave an .../etc/trafficserver/snapshots directory behind, empty
Leif Hedstrom created TS-2224: - Summary: We leave an .../etc/trafficserver/snapshots directory behind, empty Key: TS-2224 URL: https://issues.apache.org/jira/browse/TS-2224 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Snapshots goes into the .../var/trafficserver directory, yet we still have make install create this writeable directory under etc/trafficserver. We should fix / remove this. At the same time, lets make sure the records.config configuration for snapshots dir actually works as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2224) We leave an .../etc/trafficserver/snapshots directory behind, empty
[ https://issues.apache.org/jira/browse/TS-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2224: -- Fix Version/s: 4.1.0 Assignee: Leif Hedstrom We leave an .../etc/trafficserver/snapshots directory behind, empty --- Key: TS-2224 URL: https://issues.apache.org/jira/browse/TS-2224 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 4.1.0 Snapshots goes into the .../var/trafficserver directory, yet we still have make install create this writeable directory under etc/trafficserver. We should fix / remove this. At the same time, lets make sure the records.config configuration for snapshots dir actually works as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2223) Incorrect timezone offset when using %cqtn
Adam Twardowski created TS-2223:
---
Summary: Incorrect timezone offset when using %cqtn
Key: TS-2223
URL: https://issues.apache.org/jira/browse/TS-2223
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Adam Twardowski
My logs are showing the incorrect timezone offset for EDT (Eastern Daylight
time). ATS logs are showing -0500 when it should be -0400. Apache returns the
correct timezone.
ATS:
{code}
13/Sep/2013:13:08:36 -0500...
{code}
Apache:
{code}
[13/Sep/2013:13:07:59 -0400]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2225) Add line/record id to traffic_logcat
Ask Bjørn Hansen created TS-2225: Summary: Add line/record id to traffic_logcat Key: TS-2225 URL: https://issues.apache.org/jira/browse/TS-2225 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Ask Bjørn Hansen For tailing the binary log it'll be useful with a concept roughly equivalent to line number in a text file. traffic_logcat will optionally output this and then have a feature to say start following from line/record X. The record id a numeric increment for the particular log file or the request ID (if/when that's available). The immediate objective is for log readers to continue reading from where they last read if they're restarted.  -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2217) remove the option to turn off body factory - setting it to 0 will result in empty responses
[ https://issues.apache.org/jira/browse/TS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766529#comment-13766529 ] Leif Hedstrom commented on TS-2217: --- Bryan: Can you add something to https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v4.0 please ? This is an issue for people upgrading to v4.0.x, so we should document it properly. Thanks! remove the option to turn off body factory - setting it to 0 will result in empty responses --- Key: TS-2217 URL: https://issues.apache.org/jira/browse/TS-2217 Project: Traffic Server Issue Type: Bug Components: Configuration, Core Reporter: Bryan Call Fix For: 4.1.0 When setting proxy.config.body_factory.enable_customizations to 0 clients will get empty responses when errors occur, such as remap rule not found. The option 0 should be remove as a valid option. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2219) TrafficServer only use one file if more files located in the same disk configured in storage.config
[ https://issues.apache.org/jira/browse/TS-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2219. --- Resolution: Duplicate This is a duplicate of TS-1869. TrafficServer only use one file if more files located in the same disk configured in storage.config Key: TS-2219 URL: https://issues.apache.org/jira/browse/TS-2219 Project: Traffic Server Issue Type: Bug Reporter: xiongzongtao for example, 1. create two files with size 1G bytes on the same disk: -rw-rw-rw- 1 zongtao zongtao 1073741824 Sep 11 16:01 cache0.db -rw-rw-rw- 1 zongtao zongtao 1073741824 Sep 13 10:56 cache1.db 2. configure in storage.config as the following: /data2/cache0.db 1G /data2/cache1.db 1G 3. set debug on and add tags cache_init only cache1.db is initialized, cache0.db is not inited -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2226) header_rewrite ought to have a set-filter operator
Leif Hedstrom created TS-2226: - Summary: header_rewrite ought to have a set-filter operator Key: TS-2226 URL: https://issues.apache.org/jira/browse/TS-2226 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Right now, the expectation is that if you really want to set a header, you have to do rm-header Foo-Header add-header Foo-Header bar Lame. The examples even has a set-header line, but there's no code for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2227) Make header_rewrite load all pparam's as config files
Leif Hedstrom created TS-2227:
-
Summary: Make header_rewrite load all pparam's as config files
Key: TS-2227
URL: https://issues.apache.org/jira/browse/TS-2227
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: Leif Hedstrom
Particularly in a remap rule, it'd be useful to do concatenation of config
files, e.g.
{code}
… @plugin=header_rewrite.so @pparam=set-cache-control.config
@pparam=set-id-tag.config ...
{code}
This allows certain portions of a config to be shared across multiple remap
rules for example.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2227) Make header_rewrite load all pparam's as config files
[
https://issues.apache.org/jira/browse/TS-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2227:
--
Fix Version/s: 4.1.0
Make header_rewrite load all pparam's as config files
-
Key: TS-2227
URL: https://issues.apache.org/jira/browse/TS-2227
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: Leif Hedstrom
Fix For: 4.1.0
Particularly in a remap rule, it'd be useful to do concatenation of config
files, e.g.
{code}
… @plugin=header_rewrite.so @pparam=set-cache-control.config
@pparam=set-id-tag.config ...
{code}
This allows certain portions of a config to be shared across multiple remap
rules for example.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2226) header_rewrite ought to have a set-header operator
[ https://issues.apache.org/jira/browse/TS-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2226: -- Fix Version/s: 4.1.0 Summary: header_rewrite ought to have a set-header operator (was: header_rewrite ought to have a set-filter operator) header_rewrite ought to have a set-header operator -- Key: TS-2226 URL: https://issues.apache.org/jira/browse/TS-2226 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Fix For: 4.1.0 Right now, the expectation is that if you really want to set a header, you have to do rm-header Foo-Header add-header Foo-Header bar Lame. The examples even has a set-header line, but there's no code for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2228) Allow header_rewrite to set overridable configurations
Leif Hedstrom created TS-2228:
-
Summary: Allow header_rewrite to set overridable configurations
Key: TS-2228
URL: https://issues.apache.org/jira/browse/TS-2228
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: Leif Hedstrom
It'd be swell to be able to do e.g.
cond %{READ_REQUEST_HDR_HOOK} [AND]
cond %{CLIENT-HEADER:Foo-bar} =1
set-config proxy.config.http.insert_response_via_str 1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2229) header_filter should be deprecated, header_rewrite is a superset of functionality
Bryan Call created TS-2229: -- Summary: header_filter should be deprecated, header_rewrite is a superset of functionality Key: TS-2229 URL: https://issues.apache.org/jira/browse/TS-2229 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Bryan Call header_filter should be deprecated and removed in the next major release. header_rewrite is a superset of header_filter's functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2229) header_filter should be deprecated, header_rewrite is a superset of functionality
[ https://issues.apache.org/jira/browse/TS-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2229: --- Fix Version/s: 5.0.0 header_filter should be deprecated, header_rewrite is a superset of functionality - Key: TS-2229 URL: https://issues.apache.org/jira/browse/TS-2229 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Bryan Call Fix For: 5.0.0 header_filter should be deprecated and removed in the next major release. header_rewrite is a superset of header_filter's functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2228) Allow header_rewrite to set overridable configurations
[
https://issues.apache.org/jira/browse/TS-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2228:
--
Fix Version/s: 4.1.0
Assignee: Leif Hedstrom
Allow header_rewrite to set overridable configurations
---
Key: TS-2228
URL: https://issues.apache.org/jira/browse/TS-2228
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 4.1.0
It'd be swell to be able to do e.g.
cond %{READ_REQUEST_HDR_HOOK} [AND]
cond %{CLIENT-HEADER:Foo-bar} =1
set-config proxy.config.http.insert_response_via_str 1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2229) header_filter should be deprecated, header_rewrite is a superset of functionality
[ https://issues.apache.org/jira/browse/TS-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2229: - Assignee: Bryan Call header_filter should be deprecated, header_rewrite is a superset of functionality - Key: TS-2229 URL: https://issues.apache.org/jira/browse/TS-2229 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 header_filter should be deprecated and removed in the next major release. header_rewrite is a superset of header_filter's functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2229) header_filter should be deprecated, header_rewrite is a superset of functionality
[ https://issues.apache.org/jira/browse/TS-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13767184#comment-13767184 ] Leif Hedstrom commented on TS-2229: --- Probably wait committing this until closer to 5.0.0 release, up but to you. header_filter should be deprecated, header_rewrite is a superset of functionality - Key: TS-2229 URL: https://issues.apache.org/jira/browse/TS-2229 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 header_filter should be deprecated and removed in the next major release. header_rewrite is a superset of header_filter's functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2229) header_filter should be deprecated, header_rewrite is a superset of functionality
[ https://issues.apache.org/jira/browse/TS-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13767224#comment-13767224 ] Leif Hedstrom commented on TS-2229: --- Maybe we should have a header_filter - header_rewrite conversion script as well? header_filter should be deprecated, header_rewrite is a superset of functionality - Key: TS-2229 URL: https://issues.apache.org/jira/browse/TS-2229 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 header_filter should be deprecated and removed in the next major release. header_rewrite is a superset of header_filter's functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2230) header_rewrite should support the same hook-management that header_filter does for remap rules
[ https://issues.apache.org/jira/browse/TS-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2230: - Assignee: Leif Hedstrom header_rewrite should support the same hook-management that header_filter does for remap rules -- Key: TS-2230 URL: https://issues.apache.org/jira/browse/TS-2230 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 4.1.0 In header_filter, you can use the per-remap rules, yet specify that a rule should apply to a specific hook. We should try to support the same in header_rewrite This requires that we also allow header_rewrite to be invoked without a global configuration. This is to allow the support for only remap.config use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2230) header_rewrite should support the same hook-management that header_filter does for remap rules
[ https://issues.apache.org/jira/browse/TS-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2230: -- Fix Version/s: 4.1.0 header_rewrite should support the same hook-management that header_filter does for remap rules -- Key: TS-2230 URL: https://issues.apache.org/jira/browse/TS-2230 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Fix For: 4.1.0 In header_filter, you can use the per-remap rules, yet specify that a rule should apply to a specific hook. We should try to support the same in header_rewrite This requires that we also allow header_rewrite to be invoked without a global configuration. This is to allow the support for only remap.config use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2230) header_rewrite should support the same hook-management that header_filter does for remap rules
Leif Hedstrom created TS-2230: - Summary: header_rewrite should support the same hook-management that header_filter does for remap rules Key: TS-2230 URL: https://issues.apache.org/jira/browse/TS-2230 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom In header_filter, you can use the per-remap rules, yet specify that a rule should apply to a specific hook. We should try to support the same in header_rewrite This requires that we also allow header_rewrite to be invoked without a global configuration. This is to allow the support for only remap.config use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2231) header_rewrite uses boost regexes, we should switch to PCRE
Leif Hedstrom created TS-2231: - Summary: header_rewrite uses boost regexes, we should switch to PCRE Key: TS-2231 URL: https://issues.apache.org/jira/browse/TS-2231 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom It makes no sense to have another regex format, lets unify everything on PCRE. Also, while we're at it, lets get rid of BOOST entirely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
