[jira] [Assigned] (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 clent is broken

2012-07-24 Thread Zhao Yongming (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhao Yongming reassigned TS-464:


Assignee: weijin

I think this is the samve issue we are tracking in taobao, where it will case 
many http SM hangup in system, it never time out and close, it is very 
dangerous in heavy system like us, Wei jin and Koutai working on this and have 
a patch for testing currently, will submit it later.

> Chunked response with bad Content-Length header to HTTP/1.0 clent is broken
> ---
>
> Key: TS-464
> URL: https://issues.apache.org/jira/browse/TS-464
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: weijin
> Fix For: 3.3.1
>
>
> A client sends an HTTP/1.0 request through ATS, which gets proxied with 
> HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) 
> returns with both
> Content-Length: 10
> Transfer-Encoding: chunked
> and a chunked body which is > 10 bytes long. In this case, ATS should still 
> respond with an HTTP/1.0 response, undoing the chunking, and return with an 
> appropriate CL: header. We do everything, except set the correct 
> Content-Length header, we simply return the erroneous CL header that the 
> Origin provided. This is not allowed in the RFC.
> (Originally discovered using Coadvisor).

--
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-1375) too many connections, throttling

2012-07-24 Thread bettydramit (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422006#comment-13422006
 ] 

bettydramit commented on TS-1375:
-

[Jul 25 10:05:06.376] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 10:05:06.376] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 10:06:06.372] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 10:06:06.372] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 10:07:06.374] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 10:07:06.374] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0xf4a0)[0x2afd75dd84a0]
/lib64/libc.so.6(fclose+0x4)[0x2afd783db704]
/usr/lib64/trafficserver/plugins/config.so(_Z15logs_xml_changeSt6vectorI8Object_tSaIS0_EE+0x86e)[0x2afd982bc6fe]
/usr/lib64/trafficserver/plugins/config.so(_Z9do_configSsPi+0x243)[0x2afd982bde23]
/usr/lib64/trafficserver/plugins/config.so(+0xdef6)[0x2afd982b9ef6]
/usr/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x365)[0x4cc655]
/usr/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x55a)[0x4ccf5a]
/usr/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x2c9)[0x4cda19]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x693024]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5ab)[0x693a9b]
/usr/bin/traffic_server[0x691ff2]
/lib64/libpthread.so.0(+0x77f1)[0x2afd75dd07f1]
/lib64/libc.so.6(clone+0x6d)[0x2afd7845b92d]
[Jul 25 10:07:38.214] Manager {0x7f4649cfc7e0} FATAL: 
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Jul 25 10:07:38.214] Manager {0x7f4649cfc7e0} FATAL:  (last system error 104: 
Connection reset by peer)
[Jul 25 10:07:38.214] Manager {0x7f4649cfc7e0} NOTE: 
[LocalManager::mgmtShutdown] Executing shutdown request.
[Jul 25 10:07:38.214] Manager {0x7f4649cfc7e0} NOTE: 
[LocalManager::processShutdown] Executing process shutdown request.
[Jul 25 10:07:38.215] Manager {0x7f4649cfc7e0} ERROR: 
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Jul 25 10:07:38.215] Manager {0x7f4649cfc7e0} ERROR:  (last system error 32: 
Broken pipe)
[E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
[Jul 25 10:07:38.272] {0x7ff37a45e7e0} STATUS: opened 
/var/log/trafficserver/manager.log
[Jul 25 10:07:38.273] {0x7ff37a45e7e0} NOTE: updated diags config
[Jul 25 10:07:38.273] Manager {0x7ff37a45e7e0} NOTE: [appendDefaultDomain] 
Unable to determine default domain name. Nodes will be know by their unqualifie

> too many connections, throttling
> 
>
> Key: TS-1375
> URL: https://issues.apache.org/jira/browse/TS-1375
> Project: Traffic Server
>  Issue Type: Bug
> Environment: centos 6.2 x86_64  ats from git(3.3.0)
>Reporter: bettydramit
>Assignee: kuotai
>
> [Jul 20 09:09:19.787] Server {0x2ad5ddd00060} WARNING: too many open file 
> descriptors, emergency throttling
> [Jul 20 09:09:19.788] Server {0x2ad5ded28700} WARNING: too many connections, 
> throttling
> [Jul 20 09:19:19.823] Server {0x2ad5eb6d2700} WARNING: too many connections, 
> throttling
> [Jul 20 09:19:22.634] Manager {0x7f10bc4327e0} NOTE: [Alarms::signalAlarm] 
> Skipping Alarm: 'too many connections, throttling'
> [TrafficManager] ==> Cleaning up and reissuing signal #15
> [Jul 20 09:21:50.819] Manager {0x7f10bc4327e0} ERROR: [TrafficManager] ==> 
> Cleaning up and reissuing signal #15
> [Jul 20 09:21:50.819] Manager {0x7f10bc4327e0} ERROR:  (last system error 2: 
> No such file or directory)
> NOTE: Traffic Server received Sig 15: Terminated
> [TrafficManager] ==> signal #15

--
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-1375) too many connections, throttling

2012-07-24 Thread bettydramit (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422004#comment-13422004
 ] 

bettydramit commented on TS-1375:
-


[Jul 25 06:16:06.327] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:16:06.327] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:17:06.325] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:17:06.325] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:18:06.327] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:18:06.327] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:19:06.325] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:19:06.325] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:20:06.327] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:20:06.327] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:21:06.327] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:21:06.327] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:22:06.325] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:22:06.325] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:23:06.321] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:23:06.321] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:24:06.320] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:24:06.320] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:25:06.315] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:25:06.315] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:26:06.320] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:26:06.320] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:27:06.318] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:27:06.318] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:28:06.316] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:28:06.316] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:29:06.313] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:29:06.313] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:30:06.309] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:30:06.309] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:31:06.304] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:31:06.304] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:32:06.303] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:32:06.303] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:33:06.305] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:33:06.305] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:34:06.309] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:34:06.309] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:35:06.309] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:35:06.309] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:36:06.305] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:36:06.305] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:37:06.305] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:37:06.305] Server {0x2afd7a6c1700} WARNING: unable to snap statistics
[Jul 25 06:38:06.304] Server {0x2afd7a6c1700} WARNING: unable to open 
/var/run/trafficserver/stats.snap: Too many open files
[Jul 25 06:38:06.304] Server {0x2afd7a6c1700} WARNING: unable to snap statist

[jira] [Comment Edited] (TS-1378) IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind

2012-07-24 Thread Alan M. Carroll (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421127#comment-13421127
 ] 

Alan M. Carroll edited comment on TS-1378 at 7/25/12 12:56 AM:
---

Can you compile this, run it, and let me know the output?

{code:title=getaddrinfo.c}
# include 
# include 
# include 
# include 
# include 

int main() {
  char const* v6 = "::1";
  struct addrinfo ai_hints;
  struct addrinfo* ai_result;
  struct addrinfo* spot;
  int zret;
  memset(&ai_hints, 0, sizeof(ai_hints));
  ai_hints.ai_family = AF_UNSPEC;
  ai_hints.ai_flags = AI_ADDRCONFIG;
  zret = getaddrinfo(v6, 0, &ai_hints, &ai_result);
  printf("zret=%d\n", zret);
  if (0 == zret) {
for (spot = ai_result ; spot ; spot = spot->ai_next ) {
  struct sockaddr const* ip = spot->ai_addr;
  if (ip->sa_family == AF_INET6) {
printf("IPv6 valid\n");
break;
  }
}
  }
  return 0;
}
{code}

  was (Author: amc):
Can you compile this, run it, and let me know the output?

{code:title=getaddrinfo.c}
# include 
# include 
# include 
# include 
# include 

int main() {
  char const* v6 = "::1";
  struct addrinfo ai_hints;
  struct addrinfo* ai_result;
  struct addrinfo* spot;
  int zret;
  memset(&ai_hints, 0, sizeof(ai_hints));
  ai_hints.ai_family = AF_UNSPEC;
  ai_hints.ai_flags = AI_ADDRCONFIG;
  zret = getaddrinfo(v6, 0, &ai_hints, &ai_result);
  printf("zret=%d\n", zret);
  for (spot = ai_result ; spot ; spot = spot->ai_next ) {
struct sockaddr const* ip = spot->ai_addr;
if (ip->sa_family == AF_INET6) {
  printf("IPv6 valid\n");
  break;
}
  }
  return 0;
}
{code}
  
> IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind
> 
>
> Key: TS-1378
> URL: https://issues.apache.org/jira/browse/TS-1378
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Affects Versions: 3.2.0
> Environment: ubuntu 10.04
>Reporter: Kingsley Foreman
>Assignee: Alan M. Carroll
>
> IPv6 addresses always report as an error on proxy.local.incoming_ip_to_bind
> an example
> LOCAL proxy.local.incoming_ip_to_bind STRING 127.0.0.1 ::1
> WARNING: 'proxy.local.incoming_ip_to_bind' has an value '::1' that is not 
> recognized as an IP address, ignored.

--
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-1355) Drop support for Unices which don't support 64bit time_t

2012-07-24 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421888#comment-13421888
 ] 

Leif Hedstrom commented on TS-1355:
---

I obviously understand the meaning of "dropping support", I'm wondering why 
this was necessary, and what it fixes.

> Drop support for Unices which don't support 64bit time_t
> 
>
> Key: TS-1355
> URL: https://issues.apache.org/jira/browse/TS-1355
> Project: Traffic Server
>  Issue Type: Task
> Environment: Unix
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.3.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] [Commented] (TS-1355) Drop support for Unices which don't support 64bit time_t

2012-07-24 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421866#comment-13421866
 ] 

Leif Hedstrom commented on TS-1355:
---

Fwiw, doing
{code}
git revert ede9cd51b3a9b840df6e03775e76bf9bb3149339
{code}

with the rest of current "trunk" compiles and runs fine on my 32-bit system. I 
still don't understand why this fix/commit was necessary, it seems identical to 
the old code on a system with 64-bit time_t, and completely broken for systems 
with 32-bit time_t.

> Drop support for Unices which don't support 64bit time_t
> 
>
> Key: TS-1355
> URL: https://issues.apache.org/jira/browse/TS-1355
> Project: Traffic Server
>  Issue Type: Task
> Environment: Unix
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.3.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] [Commented] (TS-1378) IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind

2012-07-24 Thread Alan M. Carroll (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421733#comment-13421733
 ] 

Alan M. Carroll commented on TS-1378:
-

I loaded up Ubuntu 10.04 on a VM and tried this. It turns out the test program 
does *not* work, unless you omit the AI_ADDRCONFIG line, returning a zret of 
-9. It seems on Ubuntu the default configured IPv6 addresses do not count as 
far as the system having any IPv6 addresses. On my test VM if I explicitly 
added an IPv6 address then both the test program and ATS worked. Trying adding 
the equivalent of your IPv4 address, such as

{code}
sudo ip addr add fc01:192:168:1::17/64 dev eth0
{code}

See if that fixes the parse problem with ATS.

> IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind
> 
>
> Key: TS-1378
> URL: https://issues.apache.org/jira/browse/TS-1378
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Affects Versions: 3.2.0
> Environment: ubuntu 10.04
>Reporter: Kingsley Foreman
>Assignee: Alan M. Carroll
>
> IPv6 addresses always report as an error on proxy.local.incoming_ip_to_bind
> an example
> LOCAL proxy.local.incoming_ip_to_bind STRING 127.0.0.1 ::1
> WARNING: 'proxy.local.incoming_ip_to_bind' has an value '::1' that is not 
> recognized as an IP address, ignored.

--
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-1380) SSL wildcard lookup doesn't find the longest match

2012-07-24 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421619#comment-13421619
 ] 

Leif Hedstrom commented on TS-1380:
---

Looks good, except passing in the strlen(reverse) + 1. From the IRC discussion, 
it seems this was not intended?

> SSL wildcard lookup doesn't find the longest match
> --
>
> Key: TS-1380
> URL: https://issues.apache.org/jira/browse/TS-1380
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 3.2.0
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 3.3.0
>
>
> Bug report from Todd Harpersberger: 
> 
> Note that Todd states the *.mycompany.com certificate is always served. This 
> should not happen because we always search for the *longest* wildcard match. 

--
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-1355) Drop support for Unices which don't support 64bit time_t

2012-07-24 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421550#comment-13421550
 ] 

Leif Hedstrom commented on TS-1355:
---

Hmmm, this kinda sucks, because the patch 
(ede9cd51b3a9b840df6e03775e76bf9bb3149339) completely disables ATS from 
functioning on my 32-bit Fedora Core 7 system (this is a system similar to 
RHEL4).

I'm probably one of only a few users of such an ancient system, but if we keep 
this, I will not be able to test ATS 3.3.x or later. I'm hoping we will not 
backport this to v3.2.x though (I'd probably -1 that :).

> Drop support for Unices which don't support 64bit time_t
> 
>
> Key: TS-1355
> URL: https://issues.apache.org/jira/browse/TS-1355
> Project: Traffic Server
>  Issue Type: Task
> Environment: Unix
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.3.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] [Commented] (TS-1378) IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind

2012-07-24 Thread Alan M. Carroll (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421459#comment-13421459
 ] 

Alan M. Carroll commented on TS-1378:
-

I am absolutely stumped on this. I can't see anything in the code that would 
lead to this kind of result. I will have to get an Ubuntu VM up and run the 
debugger there.

> IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind
> 
>
> Key: TS-1378
> URL: https://issues.apache.org/jira/browse/TS-1378
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Affects Versions: 3.2.0
> Environment: ubuntu 10.04
>Reporter: Kingsley Foreman
>Assignee: Alan M. Carroll
>
> IPv6 addresses always report as an error on proxy.local.incoming_ip_to_bind
> an example
> LOCAL proxy.local.incoming_ip_to_bind STRING 127.0.0.1 ::1
> WARNING: 'proxy.local.incoming_ip_to_bind' has an value '::1' that is not 
> recognized as an IP address, ignored.

--
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-998) Broken ClientReq in TSAPI

2012-07-24 Thread Nick Kew (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421263#comment-13421263
 ] 

Nick Kew commented on TS-998:
-

Yes, we have a workaround, and that's even been simplified recently.  I gave up 
on it when it became clear that this bug is considered a Feature by some 
established users, so a simple/clean fix wouldn't be accepted.

I do recollect this going through a couple of iterations to try and coexist 
with the 'Feature'.  From your last comment it's evident it got left in an 
Abandon state.  So I guess it's time to abandon the fix and mark the bug 
WONTFIX?

> Broken ClientReq in TSAPI
> -
>
> Key: TS-998
> URL: https://issues.apache.org/jira/browse/TS-998
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: any
>Reporter: Nick Kew
>Assignee: Nick Kew
> Fix For: 3.3.1
>
>
> Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request 
> line.
> Expected behaviour: In a PRE_REMAP hook it should return the client request 
> line and headers, ideally verbatim.
> Observed behaviour: "http://"; is prepended to the request URL:
>   GET /path/ HTTP/1.1
> becomes
>   GET http:///path/ HTTP/1.1
> (yes, that's three slashes)
> Pseudo-code to reproduce from a PRE_REMAP hook:
>   TSHttpTxnClientReqGet(txnp, &buf, &hdr);
>   TSHttpHdrPrint(buf, hdr, iobuf);
>   reader = TSIOBufferReaderAlloc(iobuf);
>   block = TSIOBufferReaderStart(reader);
>   len = TSIOBufferBlockReadAvail(block, reader);
>   data = TSIOBufferBlockReadStart(block, reader, &len);
> Now examine the contents of data.
> Assigned to AMC as suggested yesterday on-list.

--
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-1291) ignore query string in url

2012-07-24 Thread Conan Wang (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421249#comment-13421249
 ] 

Conan Wang commented on TS-1291:


It's easy to normalize the URL in TS plugin (about 10 lines core code for this 
requirement).
Actually I have a simple remap plugin inspired by cacheurl above. Can configure 
like: 
{code}
map  http://example.com  http://real.example.com  
@plugin=cache_ignore_querystring.so
{code}
Contact me if you would like to try(or I can open source it somewhere). It's 
stable in my common reverse-proxy environment.

> ignore query string in url
> --
>
> Key: TS-1291
> URL: https://issues.apache.org/jira/browse/TS-1291
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Affects Versions: 3.0.4
> Environment: Ubuntu 11.04 / ATS 3.0.4
>Reporter: JH Kim
>Assignee: Leif Hedstrom
>
> I use ATS 3.0.4 in reverse proxy cache. Is there any method to cache with 
> ignore query string?
> For example request urls are not same, but contents are same. like below;
> request 1 : 
> http://mysite.test.com/static/cs4.swf?clickthru=http://yoursite.test.com/main.asp?bcode=N0400&mseq=177
> request 2 : 
> http://mysite.test.com/static/cs4.swf?clickthru=http://yoursite.test.com/main.asp?bcode=N0400&mseq=178
> request 3 : 
> http://mysite.test.com/static/cs4.swf?clickthru=http://yoursite.test.com/main.asp?bcode=N0400&mseq=179
> Actually, http://mysite.test.com/static/cs4.swf is same object.
> How to ignore query string like 
> "?clickthru=http://yoursite.test.com/main.asp?bcode=N0400&mseq=179";
> thanks.

--
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