[jira] [Closed] (TS-1245) proxy.config.http.connect_ports does not accept '*'
[ https://issues.apache.org/jira/browse/TS-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming closed TS-1245. - Resolution: Fixed proxy.config.http.connect_ports does not accept '*' --- Key: TS-1245 URL: https://issues.apache.org/jira/browse/TS-1245 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.3 Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Minor Fix For: 3.1.4 you can not set proxy.config.http.connect_ports to '*' by traffic_line, due to: ^[[:digit:][:space:]]+$ hopes we can fix it -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1252) stats summary in cluster not working?
Zhao Yongming created TS-1252:
-
Summary: stats summary in cluster not working?
Key: TS-1252
URL: https://issues.apache.org/jira/browse/TS-1252
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Stats
Affects Versions: 3.1.4
Environment: cluster mode 1, git master
Reporter: Zhao Yongming
here is some stats with evil result, we all know that most stats with
proxy.process.cluster prefix have no result at all.
{code}
proxy.process.cluster.open_delays=-4411607530454032024
proxy.process.cluster.control_messages_avg_send_time=-72.902885
proxy.process.cluster.open_delay_time=-2494.564697
proxy.process.cluster.rmt_cache_callback_time=-747.036865
proxy.process.cluster.local_connection_time=-15.002351
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270278#comment-13270278
]
Zhao Yongming commented on TS-612:
--
I think we should implement the same function as mod_ssl in httpd:
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslpassphrasedialog
that is what we need, maybe we can steal some codes from mod_ssl :D
ATS does not allow password protected certificates
--
Key: TS-612
URL: https://issues.apache.org/jira/browse/TS-612
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Affects Versions: 3.0.0
Environment: Any
Reporter: Igor Galić
Fix For: 3.3.0
Create a (self-signed) certificate with a password that is non-empty. {cat
server.key server.crt server.pem} and configure it as
{CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
The result will be:
{noformat}
Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
---
Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
2010 at 12:58:34)
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
var/log/trafficserver/diags.log
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
diags config
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
clustering disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
cache disks specified in etc/trafficserver/storage.config: cache disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
clustering disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
unable to open cache disk(s): Cache Disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
ERROR: Cannot use server private key file.
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting
password:pem_lib.c:105:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password
read:pem_lib.c:406:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM
lib:ssl_rsa.c:669:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
ERROR: Can't initialize the SSL library, disabling SSL termination!.
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging
initialized[7], logging_mode = 3
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic
server running
{noformat}
A first -- ugly -- shot would be to at least have a password field in the
configuration.
In the end something taking the input of an external program or from a file
would be more desirable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1253) Vmap or Virtual IP Address Configuration is broken
Zhao Yongming created TS-1253:
-
Summary: Vmap or Virtual IP Address Configuration is broken
Key: TS-1253
URL: https://issues.apache.org/jira/browse/TS-1253
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.4
Reporter: Zhao Yongming
Fix For: 3.3.0
Virtual IP Address Configuration, config file vaddrs.config is known to be
broken:
missing vip_config, which is designed to be a dedicated binary to config
Virtual IPs
{code}
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::Vmap] Added cluster
interface 'em1' real ip: '115.238.23.57' to known interfaces
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::Vmap] Added
interface 'lo' real ip: '127.0.0.1' to known interfaces
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::VMap] Already added
interface 'em1'. Not adding for real IP '115.238.23.57'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
Adding virtual address '192.168.0.199' interface: 'lo' sub-interface-id '0'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
Interface 'lo' marked as having potential virtual ips
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
Adding virtual address '192.168.0.99' interface: 'lo' sub-interface-id '1'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::downAddr] Bringing
down addr: '192.168.0.199'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::downAddr] Bringing
down addr: '192.168.0.99'
{code}
confusing:
1, I think in most case we do need Virtual IP, do we need to management in TS
manager?
2, do we need to write a dedicate vip_config file? maybe we need to script it?
3, we need more cleanup in the codes, IE: remove the windows mess :D
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1253) Vmap or Virtual IP Address Configuration is broken
[
https://issues.apache.org/jira/browse/TS-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270326#comment-13270326
]
Zhao Yongming commented on TS-1253:
---
4, the vip_config will need to set SUID, can we handle it inline if we have
some libcap tweak?
Vmap or Virtual IP Address Configuration is broken
--
Key: TS-1253
URL: https://issues.apache.org/jira/browse/TS-1253
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.4
Reporter: Zhao Yongming
Fix For: 3.3.0
Virtual IP Address Configuration, config file vaddrs.config is known to be
broken:
missing vip_config, which is designed to be a dedicated binary to config
Virtual IPs
{code}
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::Vmap] Added
cluster interface 'em1' real ip: '115.238.23.57' to known interfaces
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::Vmap] Added
interface 'lo' real ip: '127.0.0.1' to known interfaces
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::VMap] Already
added interface 'em1'. Not adding for real IP '115.238.23.57'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
Adding virtual address '192.168.0.199' interface: 'lo' sub-interface-id '0'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
Interface 'lo' marked as having potential virtual ips
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::lt_readAListFile]
Adding virtual address '192.168.0.99' interface: 'lo' sub-interface-id '1'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::downAddr]
Bringing down addr: '192.168.0.199'
[May 8 16:18:13.908] Manager {0x7f3c9e4247e0} NOTE: [VMap::downAddr]
Bringing down addr: '192.168.0.99'
{code}
confusing:
1, I think in most case we do need Virtual IP, do we need to management in TS
manager?
2, do we need to write a dedicate vip_config file? maybe we need to script it?
3, we need more cleanup in the codes, IE: remove the windows mess :D
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1249) More Traffic Server ESI plugin issues
[ https://issues.apache.org/jira/browse/TS-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270337#comment-13270337 ] Kit Chan commented on TS-1249: -- There aren't much differences at all. The ESI Plugin does not work with 3.1.4 (main tree) because of similar problems mentioned in the Description here. The only difference is that TSFetchUrl is no longer asking for ip and port as parameters in 3.1.4 (as opposed to that in 3.0.4) I have forked the plugin code and checkin changes that will make the plugin work with TS 3.0.4 I will attach a git diff that will make the code work with TS 3.1.4 here. We can clean up the code even more since we are not doing a internal POST any more to cache an intermediate version of the ESI template. More Traffic Server ESI plugin issues - Key: TS-1249 URL: https://issues.apache.org/jira/browse/TS-1249 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.0.4 Reporter: Kit Chan Attachments: git.dff, ts3.1.4.git.diff Is the current ESI plugin actually working? I saw TS 1103 and it is closed so I thought it is working. When I tried to compile it and make it work with traffic server 3.0.4, I got some problems. Even when i manage to compile it, the runtime is not actually working, too. So i decided to try to fix it. Here are the list of problems I find and fix. 1) Some if statements are checking whether the TS functions are returning 0 or not but actually we should check against TS_SUCCESS or TS_ERROR 2) TSFetchUrl is still requiring ip and port as parameters so we need to pass them in 3) VConnWrite() should use INT64_MAX instead of INT_MAX. This is causing the ESI template with ESI include to return with a 2^32 -1 content legnth and causing the client to hang till timeout. 4) There is a mechanism to cache a parsed version of ESI template through a POST request internally but I find it hard to get it working. I can't get my ESI template with a valid cache control header to get properly cached in ats (which is somewhat useful to what i do). So I try to disable that. My fixes for #4 is quite hacky and there are actually lots of things we don't need if we don't do the internal POST request. The plugin seems to work well. I tested with ESI try/attempt/except syntax in my ESI response. I tested with multiple ESI includes. I tested with cache control header added for the ESI response so that I get the ESI Response cached in ats and subsequent requests will simply get the ESI response from cache instead of OS server. Gzip is also working, too. Any comments or reviews? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1249) More Traffic Server ESI plugin issues
[ https://issues.apache.org/jira/browse/TS-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan updated TS-1249: - Attachment: ts3.1.4.git.diff git diff for the ESI plugin to make it work with TS 3.1.4 (main tree) More Traffic Server ESI plugin issues - Key: TS-1249 URL: https://issues.apache.org/jira/browse/TS-1249 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.0.4 Reporter: Kit Chan Attachments: git.dff, ts3.1.4.git.diff Is the current ESI plugin actually working? I saw TS 1103 and it is closed so I thought it is working. When I tried to compile it and make it work with traffic server 3.0.4, I got some problems. Even when i manage to compile it, the runtime is not actually working, too. So i decided to try to fix it. Here are the list of problems I find and fix. 1) Some if statements are checking whether the TS functions are returning 0 or not but actually we should check against TS_SUCCESS or TS_ERROR 2) TSFetchUrl is still requiring ip and port as parameters so we need to pass them in 3) VConnWrite() should use INT64_MAX instead of INT_MAX. This is causing the ESI template with ESI include to return with a 2^32 -1 content legnth and causing the client to hang till timeout. 4) There is a mechanism to cache a parsed version of ESI template through a POST request internally but I find it hard to get it working. I can't get my ESI template with a valid cache control header to get properly cached in ats (which is somewhat useful to what i do). So I try to disable that. My fixes for #4 is quite hacky and there are actually lots of things we don't need if we don't do the internal POST request. The plugin seems to work well. I tested with ESI try/attempt/except syntax in my ESI response. I tested with multiple ESI includes. I tested with cache control header added for the ESI response so that I get the ESI Response cached in ats and subsequent requests will simply get the ESI response from cache instead of OS server. Gzip is also working, too. Any comments or reviews? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1254) Using TSMimeHdrFieldDestroy after TSMimeHdrFieldRemove asserts when using --enable-debug
B Wyatt created TS-1254:
---
Summary: Using TSMimeHdrFieldDestroy after TSMimeHdrFieldRemove
asserts when using --enable-debug
Key: TS-1254
URL: https://issues.apache.org/jira/browse/TS-1254
Project: Traffic Server
Issue Type: Bug
Components: MIME
Reporter: B Wyatt
Priority: Minor
ts.h indicates that if you wish to destroy a removed header you should call
TSMimeHdrFieldDestroy and TSHandleMLocRelease, however when --enable-debug is
passed to configure the following assert is hit:
{noformat}FATAL: MIME.cc:1496: failed assert `field-is_live()`{noformat}
it seems that this assert would trip for any call to mime_hdr_field_delete if
the field was previously detached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1240) Debug assert triggered in LogBuffer.cc:209
[
https://issues.apache.org/jira/browse/TS-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1240:
--
Fix Version/s: (was: 3.1.4)
3.1.5
I can not reproduce this, so moving out to v3.1.5 for now. If anyone can
provide details how to reproduce it (it's obviously only going to trigger in a
debug build), please let me know.
Debug assert triggered in LogBuffer.cc:209
--
Key: TS-1240
URL: https://issues.apache.org/jira/browse/TS-1240
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.4
Reporter: Leif Hedstrom
Fix For: 3.1.5
From John:
{code}
[May 1 09:08:44.746] Server {0x77fce800} NOTE: traffic server running
FATAL: LogBuffer.cc:209: failed assert `m_unaligned_buffer`
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server - STACK
TRACE:
/home/jplevyak/projects/ts/ts-2/lib/ts/.libs/libtsutil.so.3(ink_fatal+0xa3)[0x77bae4a5]
/home/jplevyak/projects/ts/ts-2/lib/ts/.libs/libtsutil.so.3(_ink_assert+0x3c)[0x77bad47c]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x35)[0x5d3a53]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN9LogObject15_checkout_writeEPmm+0x41)[0x5eef75]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x4cb)[0x5ef5b9]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN16LogObjectManager3logEP9LogAccess+0x4a)[0x5daab4]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN3Log6accessEP9LogAccess+0x235)[0x5d97f9]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN6HttpSM12update_statsEv+0x204)[0x579872]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN6HttpSM9kill_thisEv+0x31d)[0x579525]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x337)[0x56cec1]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x72)[0x4e2450]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x14c)[0x5b24aa]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x72)[0x4e2450]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server[0x6bb9d1]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server[0x6bbafa]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x6fa)[0x6bcaaf]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_Z12write_to_netP10NetHandlerP18UnixNetVConnectionP14PollDescriptorP7EThread+0x7d)[0x6bc3b3]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6e6)[0x6b8828]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x72)[0x4e2450]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x111)[0x6dde7f]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0x431)[0x6de42b]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server[0x6dd0bc]
/lib64/libpthread.so.0(+0x7d90)[0x77676d90]
/lib64/libc.so.6(clone+0x6d)[0x754f9f5d]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1238) RAM cache hit rate unexpectedly low
[ https://issues.apache.org/jira/browse/TS-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270768#comment-13270768 ] Leif Hedstrom commented on TS-1238: --- Is this committed and fixed on trunk? Or are we pending more changes? I'm trying to get a handle on 3.1.4 release, so we can get a 3.2 release out soon... RAM cache hit rate unexpectedly low --- Key: TS-1238 URL: https://issues.apache.org/jira/browse/TS-1238 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.3 Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.4 Attachments: TS-1238-jp-1.patch The RAM cache is not getting the expected hit rate. Looks like there are a couple issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1255) Add more overridable records.config configurations
Leif Hedstrom created TS-1255:
-
Summary: Add more overridable records.config configurations
Key: TS-1255
URL: https://issues.apache.org/jira/browse/TS-1255
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.0
We should examine at least the following configs, and see which ones can (or
can not) be moved to be overridable:
{code}
MgmtInt server_max_connections;
MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought to
be overridable, but difficult right now.
char *proxy_request_via_string;
int proxy_request_via_string_len;
char *proxy_response_via_string;
int proxy_response_via_string_len;
MgmtInt origin_server_pipeline;
MgmtInt user_agent_pipeline;
MgmtInt transaction_active_timeout_in;
MgmtInt accept_no_activity_timeout;
MgmtInt background_fill_active_timeout;
MgmtFloat background_fill_threshold;
MgmtInt parent_connect_attempts;
MgmtInt per_parent_connect_attempts;
MgmtInt parent_connect_timeout;
MgmtByte insert_age_in_response;
MgmtByte avoid_content_spoofing;
MgmtByte enable_http_stats;
MgmtInt max_cache_open_write_retries;
MgmtByte cache_enable_default_vary_headers;
MgmtByte cache_when_to_add_no_cache_to_msie_requests;
MgmtByte cache_range_lookup;
MgmtInt request_hdr_max_size;
MgmtInt response_hdr_max_size;
MgmtByte push_method_enabled;
MgmtByte referer_filter_enabled;
MgmtByte referer_format_redirect;
MgmtByte accept_encoding_filter_enabled;
// WTF!!! Bool ???
/// Accept connections on foreign addresses.
bool client_transparency_enabled;
/// Use client address to connect to origin server.
bool server_transparency_enabled;
MgmtByte negative_revalidating_enabled;
MgmtInt negative_revalidating_lifetime;
MgmtByte ignore_accept_mismatch;
MgmtByte ignore_accept_language_mismatch;
MgmtByte ignore_accept_encoding_mismatch;
MgmtByte ignore_accept_charset_mismatch;
// Optimize gzip alternates //
MgmtByte normalize_ae_gzip;
{code}
Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
just get 3.1.4/3.2 done sooner rather than later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1181) TSHttpTxnConfigInt* don't look right with MgmtByte fields in OverridableHttpConfigParams
[
https://issues.apache.org/jira/browse/TS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1181.
---
Resolution: Fixed
I believe / hope this is fixed with the changes below. William, can you please
take a look, and reopen this bug if there's still a problem.
{code}
commit 3cf51ee61a11ce69632ef8bf6bddef01236355b9
Author: Leif Hedstrom zw...@apache.org
AuthorDate: Tue May 8 13:43:30 2012 -0600
Commit: Leif Hedstrom zw...@apache.org
CommitDate: Tue May 8 13:47:57 2012 -0600
TS-1181 Reorder some struct members, to make all byte configs near each
other (less padding)
commit f6fefd4c9ace2a2b6f9eb9c9a8da7e2f995eb7e6
Author: Leif Hedstrom zw...@apache.org
AuthorDate: Mon May 7 20:30:36 2012 -0600
Commit: Leif Hedstrom zw...@apache.org
CommitDate: Tue May 8 13:47:57 2012 -0600
TS-1181 Make the overridable configs work properly with byte configs.
{code}
TSHttpTxnConfigInt* don't look right with MgmtByte fields in
OverridableHttpConfigParams
Key: TS-1181
URL: https://issues.apache.org/jira/browse/TS-1181
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.0.4
Reporter: William Bardwell
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.1.4
TSHttpTxnConfigIntSet and Get use _conf_to_memberp to get a pointer to
various fields, and then access it as a 32bit int. But many of the fields
are now bytes. A fix would be to make _conf_to_memberp return the type
properly, and make TSHttpTxnConfigInt* access the field as the proper size.
I saw valgrind complaining about uninitialized data from the code (which is
probably because of padding in the structure, since it is cleared a field at
a time), but there are probably much worse effects around reading and writing
unrelated fields.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1181) TSHttpTxnConfigInt* don't look right with MgmtByte fields in OverridableHttpConfigParams
[ https://issues.apache.org/jira/browse/TS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270783#comment-13270783 ] William Bardwell commented on TS-1181: -- Those changes look good to me. TSHttpTxnConfigInt* don't look right with MgmtByte fields in OverridableHttpConfigParams Key: TS-1181 URL: https://issues.apache.org/jira/browse/TS-1181 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.4 Reporter: William Bardwell Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 TSHttpTxnConfigIntSet and Get use _conf_to_memberp to get a pointer to various fields, and then access it as a 32bit int. But many of the fields are now bytes. A fix would be to make _conf_to_memberp return the type properly, and make TSHttpTxnConfigInt* access the field as the proper size. I saw valgrind complaining about uninitialized data from the code (which is probably because of padding in the structure, since it is cleared a field at a time), but there are probably much worse effects around reading and writing unrelated fields. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1238) RAM cache hit rate unexpectedly low
[ https://issues.apache.org/jira/browse/TS-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271042#comment-13271042 ] John Plevyak commented on TS-1238: -- It isn't committed. Bryan was going to try it out. It changes one of the defaults (probably for the better) for RAM caching, but I wanted to give him a chance to take a look. I'll see if I can figure it out myself as well. It should be a very safe change. RAM cache hit rate unexpectedly low --- Key: TS-1238 URL: https://issues.apache.org/jira/browse/TS-1238 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.3 Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.4 Attachments: TS-1238-jp-1.patch The RAM cache is not getting the expected hit rate. Looks like there are a couple issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
