[jira] [Closed] (TS-913) logging in collation client mode will report with incorrect space warning
[
https://issues.apache.org/jira/browse/TS-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-913.
Resolution: Fixed
logging in collation client mode will report with incorrect space warning
-
Key: TS-913
URL: https://issues.apache.org/jira/browse/TS-913
Project: Traffic Server
Issue Type: Improvement
Components: Documentation, Logging
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.1
when collation mode set to 2, you can get a WARNING in traffic.out when
server started:
{code}
WARNING: Access logging to local log directory suspended - configured space
allocation exhausted.
{code}
this is by far not the case, it should print something like:
{code}
NOTE: Access logging to local log directory suspended - remote collation is
activated
{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] [Updated] (TS-893) the prefetch function in codes need more love to show up
[ https://issues.apache.org/jira/browse/TS-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-893: - Fix Version/s: (was: 3.1.1) 3.1.2 Assignee: Zhao Yongming I have done some working on the target #1, for the config files, as the ugly RecCore usage and config file watching interface, there will need more long term tweak for better design for such a transform related in tree plugin. I will separate the job and setup more tickets for different target, I will take this issue as a key to cleanup all the related issues. the prefetch function in codes need more love to show up Key: TS-893 URL: https://issues.apache.org/jira/browse/TS-893 Project: Traffic Server Issue Type: Improvement Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.1.2 the prefetch function in proxy is a good solution when you really need to faster up your user download time, it can parse any allowed plean html file, get all resource tags out and do batch loading from OS. I am going to preload my site before we put it online, as it will get about 1 month to get the disk full and hit rate stable. it is a cool feature but it have the following issues: 1, the prefetch config file is not managed well. ie, it is not managed by cluster 2, the it does not any document in the admin guide or old pdf file. 3, prefetching just care plean html file, without compressing, should we do some decompressing? is that possible? hopes this is the starting of make prefetch really useful for some cutting edge situation. -- 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-830) traffic_line -r returns Variable Not Found, even if it's a permission issue
[
https://issues.apache.org/jira/browse/TS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-830.
--
Resolution: Fixed
traffic_line -r returns Variable Not Found, even if it's a permission issue
-
Key: TS-830
URL: https://issues.apache.org/jira/browse/TS-830
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.0, 2.1.9
Reporter: Igor Galić
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.1.1
Attachments: ts830.patch
Example:
{noformat}
i.galic@pheme ~ % /opt/bw/bin/traffic_line -r proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
1 i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
NULL
i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
{noformat}
I propose we tell the user, when it's actually a permission problem.
--
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-934) Proxy Mutex null pointer crash
[ https://issues.apache.org/jira/browse/TS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124201#comment-13124201 ] B Wyatt commented on TS-934: From the cores/callstacks I've seen this is the same issue as TS-857. Proxy Mutex null pointer crash -- Key: TS-934 URL: https://issues.apache.org/jira/browse/TS-934 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Debian 6.0.2 quadcore, forward transparent proxy. Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 3.1.1 Attachments: ts-934-patch.txt [Client report] We had the cache crash gracefully twice last night on a segfault. Both times the callstack produced by trafficserver's signal handler was: /usr/bin/traffic_server[0x529596] /lib/libpthread.so.0(+0xef60)[0x2ab09a897f60] [0x2ab09e7c0a10] usr/bin/traffic_server(HttpServerSession::do_io_close(int)+0xa8)[0x567a3c] /usr/bin/traffic_server(HttpVCTable::cleanup_entry(HttpVCTableEntry*)+0x4c)[0x56aff6] /usr/bin/traffic_server(HttpVCTable::cleanup_all()+0x64)[0x56b07a] /usr/bin/traffic_server(HttpSM::kill_this()+0x120)[0x57c226] /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x208)[0x571b28] /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x69)[0x4e4623] I went through the disassembly and the instruction that it is on in ::do_io_close is loading the value of diags (not dereferencing it) so it is unlikely that that through a segfault (unless this is some how in thread local storage and that is corrupt). The kernel message claimed that the instruction pointer was 0x4e438e which in this build is in ProxyMutexPtr::operator -() on the instruction that dereferences the object pointer to get the stored mutex pointer (bingo!), so it would seem that at some point we are dereferencing a null safe pointer. -- 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-962) typo of key name in logstats.cc
[
https://issues.apache.org/jira/browse/TS-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-962.
--
Resolution: Fixed
typo of key name in logstats.cc
---
Key: TS-962
URL: https://issues.apache.org/jira/browse/TS-962
Project: Traffic Server
Issue Type: Bug
Components: Stats
Affects Versions: 3.0.1
Reporter: Nick Berry
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.1.1
Attachments: logstats.cc-key_name_typo-patch
appears in trunk as well.
{code}
$ traffic_logstats -j
{ total: {
*snip*
error.conenct_failed : { req: 0, req_pct: 0.00, bytes: 0,
bytes_pct: 0.00 },
*snip*
},
}
{code}
error.connect_failed is misspelled.
--
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-959) ae filtering code need to get clean clever
[ https://issues.apache.org/jira/browse/TS-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-959: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. ae filtering code need to get clean clever Key: TS-959 URL: https://issues.apache.org/jira/browse/TS-959 Project: Traffic Server Issue Type: Improvement Components: Configuration, HTTP Affects Versions: 3.1.1 Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Minor Fix For: 3.1.3 I think the codes for aeua filter is ugly placed into httpconfig main.cc, and can not get live updated with traffic_line, that is not acceptable for our config system. the codes need to be move out into one dedicate file or at least get cleanup, and setup the callbacks for config file changes. -- 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-61) multiple do_io_pread on a CacheVConnection
[ https://issues.apache.org/jira/browse/TS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-61: Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. multiple do_io_pread on a CacheVConnection -- Key: TS-61 URL: https://issues.apache.org/jira/browse/TS-61 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.3 Attachments: pread-2.patch Original Estimate: 48h Remaining Estimate: 48h The current TS-46 patch includes do_io_pread support but allows only a single do_io_pread. In order to efficiently support range requests with multiple ranges it would be helpful to be able to do multiple do_io_pread's on a single open CacheVConnection. -- 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-803) Fix SOCKS breakage and allow for setting next-hop SOCKS
[
https://issues.apache.org/jira/browse/TS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-803:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
Fix SOCKS breakage and allow for setting next-hop SOCKS
---
Key: TS-803
URL: https://issues.apache.org/jira/browse/TS-803
Project: Traffic Server
Issue Type: New Feature
Components: Network
Environment: Wherever ATS might run
Reporter: M. Nunberg
Fix For: 3.1.3
Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7
unstable/git. There are some quirks here, and I'm not that sure any more what
this patch does exactly. However it:
1) Does fix SOCKS connections in general
2) Allows setting next-hop SOCKS proxy via the API
Problems:
See https://issues.apache.org/jira/browse/TS-802
This has no effect on connections which are drawn from the connection pool,
as it seems ATS currently doesn't maintain unique identities for peripheral
connection params (source IP, SOCKS etc); i.e. this only affects new TCP
connections to an OS.
diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h
tsgit217/iocore/net/I_NetVConnection.h
--- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0
+
+++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0
+
@@ -120,6 +120,13 @@
/// Version of SOCKS to use.
unsigned char socks_version;
+ struct {
+ unsigned int ip;
+ int port;
+ char *username;
+ char *password;
+ } socks_override;
+
int socket_recv_bufsize;
int socket_send_bufsize;
Only in tsgit217/iocore/net: Makefile
Only in tsgit217/iocore/net: Makefile.in
diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
--- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
+++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
@@ -126,7 +126,7 @@
unsigned char version;
bool write_done;
-
+ bool manual_parent_selection;
SocksAuthHandler auth_handler;
unsigned char socks_cmd;
@@ -145,7 +145,8 @@
SocksEntry():Continuation(NULL), netVConnection(0),
ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
-lerrno(0), timeout(0), version(5), write_done(false),
auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
+lerrno(0), timeout(0), version(5), write_done(false),
manual_parent_selection(false),
+auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
{
}
};
diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
--- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
+++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
@@ -73,7 +73,8 @@
nattempts = 0;
findServer();
- timeout = this_ethread()-schedule_in(this,
HRTIME_SECONDS(netProcessor.socks_conf_stuff-server_connect_timeout));
+// timeout = this_ethread()-schedule_in(this,
HRTIME_SECONDS(netProcessor.socks_conf_stuff-server_connect_timeout));
+ timeout = this_ethread()-schedule_in(this, HRTIME_SECONDS(5));
write_done = false;
}
@@ -81,6 +82,15 @@
SocksEntry::findServer()
{
nattempts++;
+ if(manual_parent_selection) {
+ if(nattempts 1) {
+ //Nullify IP and PORT
+ server_ip = -1;
+ server_port = 0;
+ }
+ Debug(mndebug(Socks), findServer() is a noop with manual socks
selection);
+ return;
+ }
#ifdef SOCKS_WITH_TS
if (nattempts == 1) {
@@ -187,7 +197,6 @@
}
Debug(Socks, Failed to connect to %u.%u.%u.%u:%d,
PRINT_IP(server_ip), server_port);
-
findServer();
if (server_ip == (uint32_t) - 1) {
diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc
tsgit217/iocore/net/UnixNetProcessor.cc
--- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0
+
+++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0
+
@@ -228,6 +228,11 @@
!socks_conf_stuff-ip_range.match(ip))
#endif
);
+ if(opt-socks_override.ip = 1) {
+ using_socks = true;
+ Debug(mndebug, trying to set using_socks to true);
+ }
+
SocksEntry *socksEntry = NULL;
#endif
NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
@@ -242,6 +247,16 @@
if (using_socks) {
Debug(Socks, Using Socks ip: %u.%u.%u.%u:%d\n, PRINT_IP(ip), port);
socksEntry = socksAllocator.alloc();
+
+if (opt-socks_override.ip) {
+//Needs to be done before socksEntry-init()
+socksEntry-server_ip = opt-socks_override.ip;
+socksEntry-server_port =
[jira] [Updated] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-898: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. fix potential problems from coverity scan - Key: TS-898 URL: https://issues.apache.org/jira/browse/TS-898 Project: Traffic Server Issue Type: Improvement Environment: RHEL5 Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.1.3 Ran Coverity over the code and it reported 856 potential problems with the 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] [Updated] (TS-254) Add TSEscapifyString() and TSUnescapifyString()
[ https://issues.apache.org/jira/browse/TS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-254: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Add TSEscapifyString() and TSUnescapifyString() Key: TS-254 URL: https://issues.apache.org/jira/browse/TS-254 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.3 It would be very convenient for plugin developers to have SDK APIs that allows for escaping and unescaping of strings. E.g. TSEscapifyString(http://www.ogre.com/ogre.png;) - http%3A%2F%2Fwww.ogre.com%2Fogre.png TSUnescapifyString(http%3A%2F%2Fwww.ogre.com%2Fogre.png) - http://www.ogre.com/ogre.png The unescapify string is fairly straight forward, but the escapify version might benefit from taking an (optional) table which describes what characters needs to be escaped (e.g. in in some cases you want a / to be escaped, but in others you do not). -- 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-858) traffic_server segmentation_fault when cache storage value is below 65M
[
https://issues.apache.org/jira/browse/TS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-858:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
traffic_server segmentation_fault when cache storage value is below 65M
---
Key: TS-858
URL: https://issues.apache.org/jira/browse/TS-858
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.0.0
Environment: Fedora 14
Reporter: Kevin Giles
Priority: Minor
Fix For: 3.1.3
specify the storage as var/trafficserver 64M in the storage.conf,
traffic_server will core dump upon launch, the following is the stack trace:
{noformat}
FATAL: Cache.cc:2293: failed assert `dpb dpb-len == (uint64_t)b`
traffic_server - STACK TRACE:
traffic_server(ink_fatal_va+0x8e)[0x82ef221]
traffic_server(ink_fatal+0x1e)[0x82ef252]
traffic_server(_ink_assert+0x90)[0x82eeb6c]
traffic_server(cplist_reconfigure()+0x2fd)[0x8283054]
traffic_server(CacheProcessor::diskInitialized()+0x19b)[0x827b7d1]
traffic_server(CacheDisk::openDone(int, void*)+0x40)[0x8291142]
traffic_server(CacheDisk::clearDone(int, void*)+0xcc)[0x8290eb2]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x2c)[0x82862c8]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(EThread::process_event(Event*, int)+0x10e)[0x82e83f2]
traffic_server(EThread::execute()+0xa6)[0x82e862a]
traffic_server[0x82e74b1]
/lib/libpthread.so.0[0x658e99]
/lib/libc.so.6(clone+0x5e)[0x59ed2e]
{noformat}
It will core dump everytime, if the cache size is set to 65M, traffic_server
will launch fine.
--
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-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-654: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Assignee: mohan_zl Fix For: 3.1.3 Attachments: HCUtil.cc, hc.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- 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-817) TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests
[ https://issues.apache.org/jira/browse/TS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-817: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests Key: TS-817 URL: https://issues.apache.org/jira/browse/TS-817 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 2.1.9, 2.1.8 Reporter: Naveen Labels: api-change, function Fix For: 3.1.3 The API calls TSFetchUrl/TSFetchPages do not work with HTTP/1.1 requests. The implementation seems to use the end of the connection to signal the user callback function, which is not the case on persistent connections. -- 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-17) Expose atomic abstractions via InkAPI
[ https://issues.apache.org/jira/browse/TS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-17: Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Expose atomic abstractions via InkAPI - Key: TS-17 URL: https://issues.apache.org/jira/browse/TS-17 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.3 With the changes being made to the atomic abstractions, we should take this opportunity to expose atomic APIs via InkAPI (InkAPI.h). Breaking API or binarby ABIs is not a problem. Doing this, will make it easier to use atomic instructions in plugins, and keep the plugins cross platform. -- 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-214) On Solaris, use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe)
[ https://issues.apache.org/jira/browse/TS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-214: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. On Solaris, use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe) - Key: TS-214 URL: https://issues.apache.org/jira/browse/TS-214 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Environment: OpenSolaris Reporter: John Plevyak Assignee: Theo Schlossnagle Fix For: 3.1.3 We should use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe). http://developers.sun.com/solaris/articles/event_completion.html -- 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-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-866: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Need way to clear contents of a cache entry --- Key: TS-866 URL: https://issues.apache.org/jira/browse/TS-866 Project: Traffic Server Issue Type: New Feature Components: Cache Affects Versions: 3.0.0 Reporter: William Bardwell Priority: Minor Fix For: 3.1.3 Attachments: cache_erase.diff I needed a way to clear a cache entry off of disk, not just forget about it. The worry was about if you got content on a server that was illegal or a privacy violation of some sort, we wanted a way to be able to tell customers that after this step there was no way that TS could serve the content again. The normal cache remove just clears the directory entry, but theoretically a bug could allow that data out in some way. This was not intended to prevent forensic analysis of the hardware being able to recover the data. And bugs in low level drivers or the kernel could theoretically allow data to survive due to block remapping or mis-management of disk caches. -- 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-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-612:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
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: 2.1.4
Environment: Any
Reporter: Igor Galić
Fix For: 3.1.3
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] [Updated] (TS-340) EC2 Updates/Testing/Building
[ https://issues.apache.org/jira/browse/TS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-340: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. EC2 Updates/Testing/Building Key: TS-340 URL: https://issues.apache.org/jira/browse/TS-340 Project: Traffic Server Issue Type: Bug Components: Build, Portability Affects Versions: 2.0.0a Environment: EC2 Reporter: Jason Giedymin Assignee: Jason Giedymin Priority: Minor Labels: AMI, EC2, Fedora, Ubuntu Fix For: 3.1.3 1.) More Lucid Testing 2.) Rebuild with latest ATS Release 3.) Seed to West, EU, Asia datacenters (20 Images in total, Fedora/Ubuntu9/Ubuntu10/32/64) -- 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-837) ATS fails to compile with gcc 4.6.1 with --enable-debug
[
https://issues.apache.org/jira/browse/TS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-837:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
ATS fails to compile with gcc 4.6.1 with --enable-debug
---
Key: TS-837
URL: https://issues.apache.org/jira/browse/TS-837
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.0, 3.0.0
Environment: Linux, Debian, Amd64 + GCC 4.6.1
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.1.3
Attachments: proxything.diff
{noformat}
In file included from ../../proxy/ControlMatcher.h:104:0,
from ../../proxy/ParentSelection.h:37,
from P_Socks.h:30,
from P_Net.h:106,
from Connection.cc:34:
../../proxy/hdrs/HTTP.h: In member function 'INK_MD5
HTTPInfo::object_key_get()':
../../proxy/hdrs/HTTP.h:1375:24: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
../../proxy/hdrs/HTTP.h: In member function 'int64_t
HTTPInfo::object_size_get()':
../../proxy/hdrs/HTTP.h:1405:24: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
../../proxy/hdrs/HTTP.h: In member function 'void
HTTPInfo::object_size_set(int64_t)':
../../proxy/hdrs/HTTP.h:1422:51: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
cc1plus: all warnings being treated as errors
*** [Connection.o] Error 1
make[2]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore'
make: *** [all-recursive] Error 1
{noformat}
--
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-893) the prefetch function in codes need more love to show up
[ https://issues.apache.org/jira/browse/TS-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-893: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. the prefetch function in codes need more love to show up Key: TS-893 URL: https://issues.apache.org/jira/browse/TS-893 Project: Traffic Server Issue Type: Improvement Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.1.3 the prefetch function in proxy is a good solution when you really need to faster up your user download time, it can parse any allowed plean html file, get all resource tags out and do batch loading from OS. I am going to preload my site before we put it online, as it will get about 1 month to get the disk full and hit rate stable. it is a cool feature but it have the following issues: 1, the prefetch config file is not managed well. ie, it is not managed by cluster 2, the it does not any document in the admin guide or old pdf file. 3, prefetching just care plean html file, without compressing, should we do some decompressing? is that possible? hopes this is the starting of make prefetch really useful for some cutting edge situation. -- 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-939) enhance DNS round robin functionality in ATS
[ https://issues.apache.org/jira/browse/TS-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-939: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. enhance DNS round robin functionality in ATS Key: TS-939 URL: https://issues.apache.org/jira/browse/TS-939 Project: Traffic Server Issue Type: New Feature Components: DNS Reporter: vijaya bhaskar mamidi Priority: Minor Fix For: 3.1.3 right now proxy.config.dns.round_robin_nameservers can only have two values # Enables (1) or disables (0) DNS server round-robin. CONFIG proxy.config.dns.round_robin_nameservers INT 1 enhance the above feature to have a third value (2). If the value is set to 2, it should do round robin and if ATS fails to connect to one of the IP tries to connect to other one if all the IPs are tried return a error to Client. -- 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-976) gzip.c plugin - working again + browser compatibility improvement
[ https://issues.apache.org/jira/browse/TS-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-976: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. gzip.c plugin - working again + browser compatibility improvement --- Key: TS-976 URL: https://issues.apache.org/jira/browse/TS-976 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.1.0 Reporter: Otto van der Schaaf Assignee: Igor Galić Fix For: 3.1.3 Attachments: gzip.diff I did some work on the gzip.c example plugin: -made it working again (current code failes on asserts from TSMimeHdrFieldValueStringGet), -made it compress using the same deflateinit2 call as mod_gzip, for better browser compatibility (ie 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] [Updated] (TS-32) Fix ICP
[ https://issues.apache.org/jira/browse/TS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-32: Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Fix ICP --- Key: TS-32 URL: https://issues.apache.org/jira/browse/TS-32 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Miles Libbey Fix For: 3.1.3 http://icp.ircache.net/ The ICP implementation in Traffic Server broke when epoll() was introduced. Its still an interesting and used feature in caches: - when a caching layer of several boxes are used ICP helps to reduce disparities when a client is not routed to the same cache on subsequent requests - after a restart, it can help reduce the time spent in a cold cache situation -- 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-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-829: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. socks stats cleanup - some stats are registered, but not used - Key: TS-829 URL: https://issues.apache.org/jira/browse/TS-829 Project: Traffic Server Issue Type: Bug Components: Network Affects Versions: 3.0.0 Reporter: Bryan Call Priority: Minor Fix For: 3.1.3 From reviewing TS-818 I noticed that the stats that were being double resisted are not used. Some cleanup work should be done for the socks stats. Stats that are registered, but not used in the code: [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc proxy.process.socks.connections_successful, proxy.process.socks.connections_unsuccessful, proxy.process.socks.connections_currently_open, These stats are used some tests, so maybe they should be added back into the code. [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match proxy.process.socks.connections_ * iocore/net/Net.cc mgmt/api/remote/APITestCliRemote.cc test/plugin/test-mgmt/test-mgmt.c I did however see these stats being used: [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ proxy/SocksProxy.cc: SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); proxy/SocksProxy.cc: SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- 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-343) The cache lookup and add operation use different key in plugin
[
https://issues.apache.org/jira/browse/TS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-343:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
The cache lookup and add operation use different key in plugin
--
Key: TS-343
URL: https://issues.apache.org/jira/browse/TS-343
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 2.0.0
Reporter: Flier Lu
Priority: Critical
Fix For: 3.1.3
I'm developing a cache plugin base on the redis,
http://code.google.com/p/rediscache/
The plugin could be loaded and hook the cache read/write operations
[May 9 16:25:05.012] Server {3079476928} NOTE: loading plugin
'libexec/trafficserver/redis_cache.so'
[May 9 16:25:05.014] Server {3079476928} DIAG: (cache_plugin)
[INKPluginInit] Starting redis cache plugin
But the cache lookup and add operation use different key, it seems use the
url as lookup key
[May 9 16:25:13.149] Server {3066555280} DEBUG: (cache_plugin)
[CacheProcessor::open_read] Cache hooks are set
[May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
[NewCacheVC::alloc] new B33B1EE0
[May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
[NewCacheVC::set_cache_http_hdr]
[May 9 16:25:13.153] Server {3066555280} DIAG: (cache_plugin) [cache_read]
[May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
[INKCacheKeyGet] vc get cache key
[May 9 16:25:13.158] Server {3066555280} DIAG: (cache_plugin) cache hitted
for key: http://www.baidu.com/ w/ 0 bytes value
[May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
[INKHttpCacheReenable] event id: 1133 data: 0 size: 0
[May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
[INKHttpCacheReenable] cache_lookup_complete
[May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
[INKHttpCacheReenable] open read failed
but store the cache item with a random MD5 as key
[May 9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin)
[NewCacheVC::handleWrite] event=1
[May 9 16:25:13.334] Server {3079476928} DIAG: (cache_plugin) [cache_write]
[May 9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin)
[INKCacheKeyGet] vc get cache key
[May 9 16:25:13.346] Server {3079476928} DIAG: (cache_plugin) put 3571 bytes
value to redis w/ 16 bytes key: 0xb33b1fb0
[May 9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin)
[INKHttpCacheReenable] event id: 1129 data: 0 size: 3571
[May 9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin)
[INKHttpCacheReenable] cache_write
I'm not sure whether it is a design issue or bug ? and the cache lookup
always has 0 size buffer ?
--
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-904) when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule
[ https://issues.apache.org/jira/browse/TS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-904: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule -- Key: TS-904 URL: https://issues.apache.org/jira/browse/TS-904 Project: Traffic Server Issue Type: New Feature Components: Logging Affects Versions: 3.1.0 Reporter: Zhao Yongming Priority: Minor Fix For: 3.1.3 the sampling is a global config in logging, we want to get it custom-able. -- 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-669) [GSoC2011] ATS does not support SSL in IPv6
[ https://issues.apache.org/jira/browse/TS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-669: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. [GSoC2011] ATS does not support SSL in IPv6 --- Key: TS-669 URL: https://issues.apache.org/jira/browse/TS-669 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: vijaya bhaskar mamidi Labels: gsoc2011, ipv6, ssl Fix For: 3.1.3 proxy.config.http.server_other_ports is used to support IPv6 but this only work for http ports and not secure ports. We should support IPv6 for secure ports as well. -- 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-110) Improve regex remap to allow substitutions in path field
[ https://issues.apache.org/jira/browse/TS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-110: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Improve regex remap to allow substitutions in path field Key: TS-110 URL: https://issues.apache.org/jira/browse/TS-110 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Manjesh Nilange Priority: Minor Fix For: 3.1.3 Currently, regex support covers only the host field of the remap rules. It'd be nice to extend this to allow substitutions into the path field as well. This will allow rules like: regex_map http://www.example-(.*).com/ http://real-example.com/$1 -- 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-946) Scheduling a continuation on all threads of a specific type
[ https://issues.apache.org/jira/browse/TS-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-946: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Scheduling a continuation on all threads of a specific type --- Key: TS-946 URL: https://issues.apache.org/jira/browse/TS-946 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Fix For: 3.1.3 It would be incredibly useful, both in the core and in plugin APIs, to be able to schedule a continuation to run on all threads of a specific type. E.g. in a plugin, something like TSAction TSContScheduleOnThreads(TSCont cont, TSThreadPool tp); This would be useful for e.g. setting up per-thread specifics from a plugin, but quite possibly also from the core. -- 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-362) Create packaging scripts for TrafficServer
[ https://issues.apache.org/jira/browse/TS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-362: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Create packaging scripts for TrafficServer -- Key: TS-362 URL: https://issues.apache.org/jira/browse/TS-362 Project: Traffic Server Issue Type: New Feature Components: Packaging Environment: Linux, Solaris Reporter: Mladen Turk Assignee: Mladen Turk Priority: Minor Fix For: 3.1.3 Original Estimate: 504h Remaining Estimate: 504h Create pkg directory build/pkg with sub-directories for rpm and pkg This will allow to create .rpm and Solaris .package.gz platform native installation packages -- 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-462) Support TLS Server Name Indication (SNI) negotiation
[ https://issues.apache.org/jira/browse/TS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-462: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Support TLS Server Name Indication (SNI) negotiation Key: TS-462 URL: https://issues.apache.org/jira/browse/TS-462 Project: Traffic Server Issue Type: New Feature Components: SSL Reporter: Leif Hedstrom Assignee: Igor Galić Priority: Minor Labels: ssl Fix For: 3.1.3 We should support TLS Server Name Indication (SNI). This would allow for well behaved TLS clients to negotiate the certificate, without requiring a new IP for every site / certificate used. -- 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-524) Have a single directive for HTTP ports
[ https://issues.apache.org/jira/browse/TS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-524: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Have a single directive for HTTP ports -- Key: TS-524 URL: https://issues.apache.org/jira/browse/TS-524 Project: Traffic Server Issue Type: Improvement Components: Configuration Affects Versions: 2.1.3 Environment: Any Reporter: Marcus Clyne Priority: Trivial Fix For: 3.1.3 Why have both proxy.config.http.server_port and proxy.config.http.server_other_ports as config options? Unless there is a good reason to have to options, it would probably be better to have a single config option. See also https://issues.apache.org/jira/browse/TS-523 -- 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-799) Have AdminClient.pm created from .in file
[ https://issues.apache.org/jira/browse/TS-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-799: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. Have AdminClient.pm created from .in file - Key: TS-799 URL: https://issues.apache.org/jira/browse/TS-799 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.0 Reporter: Igor Galić Priority: Trivial Fix For: 3.1.3 AdminClient.pm should be created from an .in file. @sockets_def = should be extended with @localstatedir@ on top. -- 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-940) Support altering the initial congestion window for inbound UA connections.
[ https://issues.apache.org/jira/browse/TS-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-940. -- Resolution: Fixed I'm closing this, since I think / assume this is completed? If not, please reopen (or open a followup bug). Support altering the initial congestion window for inbound UA connections. -- Key: TS-940 URL: https://issues.apache.org/jira/browse/TS-940 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.1.0 Reporter: Theo Schlossnagle Assignee: Theo Schlossnagle Priority: Minor Fix For: 3.1.1 Original Estimate: 24h Remaining Estimate: 24h http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-01 This is particularly useful for CDNs. We should allow traffic server to bump this on operating systems that support 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] [Updated] (TS-892) request for bulk setting in remap.config for refer filter
[
https://issues.apache.org/jira/browse/TS-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-892:
-
Fix Version/s: (was: 3.1.1)
3.1.2
Moving these to 3.1.2 for now. please move back if they will be worked on asap
for 3.1.1.
request for bulk setting in remap.config for refer filter
-
Key: TS-892
URL: https://issues.apache.org/jira/browse/TS-892
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, HTTP
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Labels: remap
Fix For: 3.1.2
when we put our TS online, we find out we are complex when handling squid's
default filter rule such as:
{code}
acl ctoc referer_regex -i XXXa\.com\/ XXXb\.com\/ XXXc\.com\/
http_access deny ctoc
{code}
we have to convert every map rule to map_with_referer, and get very ugly. if
we can get the referer filter config in the bulk way as IP based filter in
the remap.config, it will make the config file clear and clean
--
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-701) Remove mgmt/cli/script_configs.sh
[ https://issues.apache.org/jira/browse/TS-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-701: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Remove mgmt/cli/script_configs.sh - Key: TS-701 URL: https://issues.apache.org/jira/browse/TS-701 Project: Traffic Server Issue Type: Task Components: Cleanup Reporter: Igor Galić Priority: Trivial Fix For: 3.1.2 mgmt/cli/script_configs.sh is not used or useful, it should be removed. -- 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-523) [GSoC2011] Allow the use of multiple SSL ports
[ https://issues.apache.org/jira/browse/TS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-523: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. [GSoC2011] Allow the use of multiple SSL ports -- Key: TS-523 URL: https://issues.apache.org/jira/browse/TS-523 Project: Traffic Server Issue Type: New Feature Components: Configuration, SSL Affects Versions: 2.1.3 Reporter: Marcus Clyne Priority: Minor Labels: gsoc2011, ssl Fix For: 3.1.2 Currently proxy.config.ssl.server_port allows only one SSL port to be specified, and it appears that it is not possible to specify multiple ports for SSL like proxy.config.http.server_other_ports. It would make sense to have a single directive as a string for all SSL ports, rather than have two config options like HTTP ports (a separate ticket has been posted for that - see https://issues.apache.org/jira/browse/TS-524). -- 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-207) [Gsoc2011] FreeBSD: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-207: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. [Gsoc2011] FreeBSD: Add raw disk support for the cache -- Key: TS-207 URL: https://issues.apache.org/jira/browse/TS-207 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 2.1.0 Environment: FreeBSD Reporter: George Paul Assignee: Dan Mercer Labels: gsoc2011 Fix For: 3.1.2 Currently only a file cache is supported on FreeBSD. Raw Disk support should be added before 2.1 release. -George -- 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-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-346: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. ATS does not verify server certificate -- Key: TS-346 URL: https://issues.apache.org/jira/browse/TS-346 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: vijaya bhaskar mamidi Priority: Critical Fix For: 3.1.2 ATS does not verify the certificates correctly. -- 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-972) traffic_line should warn if a command didn't succeed
[
https://issues.apache.org/jira/browse/TS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-972:
-
Fix Version/s: (was: 3.1.1)
3.1.2
Moving these to 3.1.2 for now. please move back if they will be worked on asap
for 3.1.1.
traffic_line should warn if a command didn't succeed
Key: TS-972
URL: https://issues.apache.org/jira/browse/TS-972
Project: Traffic Server
Issue Type: Improvement
Components: Management API
Affects Versions: 3.1.0, 3.0.1
Reporter: Arno Toell
Fix For: 3.1.2
{{traffic_line}} is a handy tool to manage a traffic server instance. For
example it is possible to retrieve and set configuration settings through
command line like this:
{code}
root@wv-tmp2:/home/at# traffic_line -r proxy.config.http.server_port ; echo $?
81
0
{code}
However, some commans can be set, but aren't effective until the server is
restarted, despite of ATS offering the _-x_ option to flush configuration and
reread new settings:
{code}
root@wv-tmp2:/home/at# traffic_line -s proxy.config.http.server_port -v 80 ;
echo $?
0
root@wv-tmp2:/home/at# traffic_line -x ; echo $?
0
{code}
Trafficserver should possibly warn when setting such settings which aren't
effective until the server is restarted and leave with a non-zero exit status
for _-x_ in such cases.
Moreover {{traffic_line}} does not work at all if the manager is not running:
{code}
# traffic_line -r proxy.config.http.server_port ; echo $?
traffic_line: Variable Not Found
1
{code}
That's all right, but the error message shall be improved telling that. :)
--
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-208) OSX: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-208: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. OSX: Add raw disk support for the cache --- Key: TS-208 URL: https://issues.apache.org/jira/browse/TS-208 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 2.1.0 Environment: OSX(10.5,10.6) Reporter: George Paul Assignee: Dan Mercer Fix For: 3.1.2 Currently only a file cache is supported on OSX. It would be nice to have Raw Disk support before 2.1 release. -George -- 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-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-745: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1.2 Attachments: TS-ssd-2.patch, TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- 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-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-621: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.2 Attachments: TS-621_cluster_zero_size_objects.patch, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch -- 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-747) [GSoC2011] Add config option to disable SSL compression
[ https://issues.apache.org/jira/browse/TS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-747: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. [GSoC2011] Add config option to disable SSL compression --- Key: TS-747 URL: https://issues.apache.org/jira/browse/TS-747 Project: Traffic Server Issue Type: Improvement Components: Configuration, SSL Reporter: Igor Galić Priority: Minor Labels: gsoc2011, ssl Fix For: 3.1.2 A configuration Option should be added to allow the administrator to disable SSL compression CONFIG proxy.config.ssl.compression INT 1 To maintain compatibility it should default to '1' (on) -- 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-802) Unique KA pools for SOCKS/src IP parameters
[ https://issues.apache.org/jira/browse/TS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-802: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Unique KA pools for SOCKS/src IP parameters --- Key: TS-802 URL: https://issues.apache.org/jira/browse/TS-802 Project: Traffic Server Issue Type: Wish Components: HTTP Reporter: M. Nunberg Fix For: 3.1.2 From what I've observed, ATS' keepalive/connection cache only indexes by the OS server or next proxy server, but not by other types of connection/transport/socket parameters, specifically in my case, negotiated SOCKS connections and outgoing connections which are bound to a specific source IP Is it possible to have such functionality in the near future? Currently I've been forced to write my own 'KA gateway' which pretends to be an HTTP server (to which ATS can maintain unique connections) and have that do SOCKS/source ip bind()ing for me. -- 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-895) Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid (10.04)
[
https://issues.apache.org/jira/browse/TS-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-895:
-
Fix Version/s: (was: 3.1.1)
3.1.2
Moving these to 3.1.2 for now. please move back if they will be worked on asap
for 3.1.1.
Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid
(10.04)
---
Key: TS-895
URL: https://issues.apache.org/jira/browse/TS-895
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Environment: Ubuntu lucid (10.04) LTS, 64bit
Reporter: Brane F. Gračnar
Assignee: Alan M. Carroll
Fix For: 3.1.2
I'm unable to compile ATS 3.0.1 on my 64bit ubuntu lucid server.
Configure flags:
./configure --prefix=/usr --sysconfdir=/etc/trafficserver --enable-wccp
--enable-tproxy=auto --with-pic
make dies with the following error:
make[2]: Entering directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
/bin/bash ../../build/aux/ylwrap TsConfigGrammar.y y.tab.c TsConfigGrammar.c
y.tab.h TsConfigGrammar.h y.output TsConfigGrammar.output -- byacc -d -p
tsconfig
byacc: e - line 1 of
/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig/TsConfigGrammar.y, syntax
error
%code top {
^
make[2]: *** [TsConfigGrammar.c] Error 1
make[2]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib'
make: *** [all-recursive] Error 1
--
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-448) Provide the ability to bind to more than one interface
[ https://issues.apache.org/jira/browse/TS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-448: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Provide the ability to bind to more than one interface -- Key: TS-448 URL: https://issues.apache.org/jira/browse/TS-448 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 2.1.0 Reporter: Shaun McGinnity Priority: Minor Fix For: 3.1.2 If I am running Traffic Server on a machine with multiple interfaces I would like to able to bind to a subset of those interfaces. I can bind to all or one using proxy.local.incoming_ip_to_bind but can't bind to more than one, but not all. It would also be useful to be able to specify different listening ports per interface. -- 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-228) Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use long anywhere in TS
[ https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-228: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use long anywhere in TS Key: TS-228 URL: https://issues.apache.org/jira/browse/TS-228 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 2.1.0 Reporter: John Plevyak Assignee: John Plevyak Priority: Critical Fix For: 3.1.2 Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit. This is a potential can of worms which at the least is making records.snap incompatible but at worse could be the cause of other bugs. In any case we should not be using long in the TS code, but instead use either int which is always 32-bits or inkXXX of a particular size. -- 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-808) INACTIVE_TIMEOUT for *.channel.facebook.com
[ https://issues.apache.org/jira/browse/TS-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-808: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. INACTIVE_TIMEOUT for *.channel.facebook.com --- Key: TS-808 URL: https://issues.apache.org/jira/browse/TS-808 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.8 Environment: Linux 2.6.35.10 x86_64 Reporter: Alvin Alexander Priority: Critical Fix For: 3.1.2 error.log : 20110528.13h06m13s CONNECT:[5] could not connect [INACTIVE_TIMEOUT] to 66.220.151.83 for 'http://0.164.channel.facebook.com/x/324863553/1802403183/false/p_11790027719=1' 20110528.13h06m13s CONNECT:[6] could not connect [INACTIVE_TIMEOUT] to 66.220.151.76 for 'http://0.122.channel.facebook.com/x/461720327/101899065/false/p_1523748988=22' 20110528.13h06m13s CONNECT:[3] could not connect [INACTIVE_TIMEOUT] to 66.220.151.77 for 'http://0.128.channel.facebook.com/x/2800423340/1779706821/false/p_10277560566=6' -- 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-923) traffic_logstats: critical: cannot parse log files
[ https://issues.apache.org/jira/browse/TS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-923: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. traffic_logstats: critical: cannot parse log files -- Key: TS-923 URL: https://issues.apache.org/jira/browse/TS-923 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.0.1 Environment: Centos 5.6 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:12:36 EST 2009 x86_64 x86_64 x86_64 GNU/Linux Reporter: Hung Nguyen Fix For: 3.1.2 After running for about 3 days, traffic_logstats stop working with following error: traffic_logstats critical: can't parse log file I tried to set Logging to various parameter in record.config, but still cannot get traffic_logstats works. When this problem happens, TS uses less resource. In my setup, I use ram cache only. -- 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-841) Refactor SSL code to make it possible to perform NPN negotiation without entering the HTTP SM
[ https://issues.apache.org/jira/browse/TS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-841: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Refactor SSL code to make it possible to perform NPN negotiation without entering the HTTP SM - Key: TS-841 URL: https://issues.apache.org/jira/browse/TS-841 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Leif Hedstrom Fix For: 3.1.2 In order to make it possible to write protocol handlers like SPDY, we need to negotiate NPN protocol before entering the HTTP SM. -- 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-645) Hard restart in the mgmt APIs is totally busted
[ https://issues.apache.org/jira/browse/TS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-645: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Hard restart in the mgmt APIs is totally busted --- Key: TS-645 URL: https://issues.apache.org/jira/browse/TS-645 Project: Traffic Server Issue Type: Bug Components: Management API Reporter: Leif Hedstrom Fix For: 3.1.2 In CoreAPIRemote.cc, in HardRestart(), we assume to find some start / stop scripts that no longer exists: Layout::relative_to(start_path, sizeof(start_path), Layout::get()-bindir, start_traffic_server); Layout::relative_to(stop_path, sizeof(stop_path), Layout::get()-bindir, stop_traffic_server); I don't know if / when this would be used (probably only in the deprecated Web GUI at this point), but we should fix this. -- 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-709) proxy.config.output.logfile is not configurable
[ https://issues.apache.org/jira/browse/TS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-709: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. proxy.config.output.logfile is not configurable --- Key: TS-709 URL: https://issues.apache.org/jira/browse/TS-709 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Igor Galić Priority: Minor Fix For: 3.1.2 The code suggests that proxy.config.output.logfile can be set to stdout, stderr, syslog, diagslog or an arbitrary file (if relative, then relative to $logdir). Setting it however, has no effect, the debug output always goes to stderr. -- 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-767) Make the cluster interface configurable
[ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-767: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Make the cluster interface configurable --- Key: TS-767 URL: https://issues.apache.org/jira/browse/TS-767 Project: Traffic Server Issue Type: Improvement Components: Configuration, Network Affects Versions: 2.1.8 Reporter: Arno Toell Priority: Minor Fix For: 3.1.2 I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.- * -Disable the autoconfiguration port (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.- * Disable the reliable service port (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the autoconfiguration port. If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. * -The internal communication port (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.- n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765: 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers. -- 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-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-718:
-
Fix Version/s: (was: 3.1.1)
3.1.2
Moving these to 3.1.2 for now. please move back if they will be worked on asap
for 3.1.1.
can not reuse SSL connections on RHEL5/CentOS5
--
Key: TS-718
URL: https://issues.apache.org/jira/browse/TS-718
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.7
Environment: RHEL5 system with TS 2.1.6 2.1.7
compared with Apache httpd
Reporter: Zhao Yongming
Assignee: qianshi
Fix For: 3.1.2
Attachments: TS-718-v2.patch, TS-718.patch
when with apache httpd default mod_ssl:
{noformat}
[root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
21
CONNECTED(0003)
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify return:1
---
Certificate chain
0
s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
-END CERTIFICATE-
subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
No client certificate CA names sent
---
SSL handshake has read 1418 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Compression: 1 (zlib compression)
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol :
[jira] [Updated] (TS-242) Connect timeout doesn't reset until first byte is received from server
[ https://issues.apache.org/jira/browse/TS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-242: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. Connect timeout doesn't reset until first byte is received from server -- Key: TS-242 URL: https://issues.apache.org/jira/browse/TS-242 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Steve Jiang Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.2 proxy.config.http.connect_attempts_timeout proxy.config.http.parent_proxy.connect_attempts_timeout proxy.config.http.post_connect_attempts_timeout These timeouts are implemented with inactivity timeout on the netvc and don't behave as expected. If the connect succeeds (the remote server successfully accepted) but the remote server does not respond with any bytes within the timeout period, TS still treats it as a connect timeout. If retries are enabled and the origin server is slow to start sending responses (but not down), it will keep sending requests and closing the connection after getting no response within the connect timeout. -- 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-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-541: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. SplitDNS cleanup in project HostDBandDNS Key: TS-541 URL: https://issues.apache.org/jira/browse/TS-541 Project: Traffic Server Issue Type: Improvement Components: Cleanup, DNS Reporter: Zhao Yongming Priority: Minor Fix For: 3.1.2 Attachments: TS-541.patch as per https://cwiki.apache.org/confluence/display/TS/HostDBandDNS, we will need to cleanup SplitDNS, make it out of HostDB codes, merge with common dns processor. this may be another fix for TS-435. -- 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-768) [GSoc2011] content compression plugin (gzip plugin)
[ https://issues.apache.org/jira/browse/TS-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-768: - Fix Version/s: (was: 3.1.1) 3.1.2 Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1. [GSoc2011] content compression plugin (gzip plugin) --- Key: TS-768 URL: https://issues.apache.org/jira/browse/TS-768 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Igor Galić Labels: compression, gsoc2011, plugin Fix For: 3.1.2 Traffic Server needs a plugin which will allow administrators (of reverse proxies, chiefly) to configure a single point at which content compression happens, thereby reducing the pressure on the back-ends even more Gzipped content SHOULD be cachable. Furthermore it MUST conform to RFC 2616, as well as the upcoming httpbis: see e.g.: http://tools.ietf.org/id/draft-ietf-httpbis-p3-payload-14.txt -- 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-794) ssl session reuse can not pass sslswamp testing
[
https://issues.apache.org/jira/browse/TS-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-794:
-
Fix Version/s: (was: 3.1.1)
3.1.2
Moving these to 3.1.2 for now. please move back if they will be worked on asap
for 3.1.1.
ssl session reuse can not pass sslswamp testing
---
Key: TS-794
URL: https://issues.apache.org/jira/browse/TS-794
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.8
Environment: sslv3 tlsv1
Reporter: Zhao Yongming
Fix For: 3.1.2
When I testing from the patches from qianshi, for TS-718, the ssl session
resumption looks perfect, but still can not pass the sslswamp testing, it
looks like the second and later request will not be handled from the https
connection. it may be a issue for https handler, here is some information
testing from sslswamp:
{code}
[root@unknown-10-62-163-x ~]# sslswamp -connect IP:10.32.21.75:443 -num 1
-count 4 -session srrr -update 10 -request GET
https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg
HTTP/1.0\r\n\r\n -session_ids -nologo -expect 64000 -sslmeth tlsv1
No 'cacert' supplied, trying defaults ... '/usr/share/swamp/CA.pem' found.
no client cert provided, continuing anyway.
Certificate verification failed, probably a self-signed server cert *or*
the signing CA cert is not trusted by us (hint: use '-CAfile').
This message will only be printed once
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 0 failed, resumes(+1,-0) 0.01
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
240 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 3 failed, resumes(+3,-0) 0.00
ops/sec
{code}
the log from traffic.out:
{code}
[May 20 18:30:59.544] Manager {140339380279072} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '10'
[May 20 18:30:59.544] Manager {140339380279072} NOTE: [Alarms::signalAlarm]
Server Process born
[May 20 18:31:00.564] {47816222021376} STATUS: opened
/var/log/trafficserver/diags.log
[May 20 18:31:00.613] {47816222021376} NOTE: updated diags config
[May 20 18:31:00.648] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:00.784] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:01.237] Server {47816222021376} DEBUG: (ssl)
[SSLNetProcessor::initSSLServerCTX] set the callback for external session
caching.
[May 20 18:31:01.412] Server {47816222021376} NOTE: logging initialized[7],
logging_mode = 3
[May 20 18:31:01.669] Server {47816222021376} NOTE: traffic server running
[May 20 18:31:01.793] Server {47816237516544} NOTE: cache enabled
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
[ssl_callback_NewSessionCacheEntry] store id
[D91C5F59EB43C5E8864303B449B9B1673D3218300EE03FDC4790125A7BCB521D]'s session
into cache.
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=82
SSL Read
GET https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg HTTP/1.0
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read=82
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4014
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[jira] [Assigned] (TS-964) No 64bit integer plugin APIs for HTTP headers
[ https://issues.apache.org/jira/browse/TS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-964: Assignee: Leif Hedstrom No 64bit integer plugin APIs for HTTP headers - Key: TS-964 URL: https://issues.apache.org/jira/browse/TS-964 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: William Bardwell Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.1 There are APIs for unsigned int, but stuff like content-length should be done as 64-bit values, so we should add TSMimeHdrFieldValueUint64Get(), TSMimeHdrFieldValueUint64Set(), TSMimeHdrFieldValueUint64Insert() or Int64 versions of those APIs (since the mime_* stuff seems to have unsigned int, int and int64, but no uint64). -- 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-964) No 64bit integer plugin APIs for HTTP headers
[ https://issues.apache.org/jira/browse/TS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-964. -- Resolution: Fixed No 64bit integer plugin APIs for HTTP headers - Key: TS-964 URL: https://issues.apache.org/jira/browse/TS-964 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: William Bardwell Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.1 There are APIs for unsigned int, but stuff like content-length should be done as 64-bit values, so we should add TSMimeHdrFieldValueUint64Get(), TSMimeHdrFieldValueUint64Set(), TSMimeHdrFieldValueUint64Insert() or Int64 versions of those APIs (since the mime_* stuff seems to have unsigned int, int and int64, but no uint64). -- 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-938) Our outgoing (request) Via: header seems to always default to 127.0.0.1 as the IP identifier
[ https://issues.apache.org/jira/browse/TS-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-938. Resolution: Fixed Our outgoing (request) Via: header seems to always default to 127.0.0.1 as the IP identifier Key: TS-938 URL: https://issues.apache.org/jira/browse/TS-938 Project: Traffic Server Issue Type: Bug Components: Network Affects Versions: 3.1.0 Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 3.1.1 This can cause serious problems, because if the other end is also an ATS server, also defaulting to thinking it's on 127.0.0.1, will treat this as a loop, and send a 400 response. We ought to try to send something more intelligent as the hex-IP in the request Via: header. This is particularly problematic when ATS is used as a forward (or intercepting) proxy, and have outgoing Via: headers enabled. -- 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-926) Enable IPv6 in HTTP handling.
[ https://issues.apache.org/jira/browse/TS-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-926. Resolution: Fixed Enable IPv6 in HTTP handling. - Key: TS-926 URL: https://issues.apache.org/jira/browse/TS-926 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.0.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: ipv6 Fix For: 3.1.1 Having put most of the infrastructure in place, the next step is to enable IPv6 for actually HTTP transactions. -- 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
