[jira] [Commented] (TS-2796) Leaking CacheVConnections
[ https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997180#comment-13997180 ] Zhao Yongming commented on TS-2796: --- hmm, from what I know, many people have the memory issue, and it is a malloc and gc issue, but they just don't realized it. that is why I am pushing the reclaim freelist enabled by default. why not test it if you can vevify the result in hours. and please take a look at the 'allocated' - 'in-use' where memory/ioBufAllocator size 32K, if you sum up them, that is the memory you leak. the same as TS-1006 Leaking CacheVConnections - Key: TS-2796 URL: https://issues.apache.org/jira/browse/TS-2796 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2, 4.2.1, 5.0.0 Reporter: Brian Geffon Labels: yahoo Fix For: 5.0.0 It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. The code path in CacheVC that is allocating the IoBuffers is memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom the real issue here is the leaking CacheVC. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2803) Use documentation strings extracted from source files in project documentation
[ https://issues.apache.org/jira/browse/TS-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13996623#comment-13996623 ] ASF GitHub Bot commented on TS-2803: GitHub user jablko opened a pull request: https://github.com/apache/trafficserver/pull/84 TS-2803: Use documentation strings extracted from source files in projec... ...t documentation You can merge this pull request into a Git repository by running: $ git pull https://github.com/jablko/trafficserver TS-2803 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/84.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #84 commit 27d758224cdea1f7cb0b64fac3b313a387ccfd42 Author: Jack Bates j...@nottheoilrig.com Date: 2014-05-13T16:51:53Z TS-2803: Use documentation strings extracted from source files in project documentation Use documentation strings extracted from source files in project documentation -- Key: TS-2803 URL: https://issues.apache.org/jira/browse/TS-2803 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructuredText, and then use them inside Sphinx documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997108#comment-13997108 ] Ethan Lai edited comment on TS-2344 at 5/14/14 12:36 AM: - [~zwoop] I've close previous pull request and create a new one with this patch, which remove handleIfRedirect() in done section. I'm done with this ticket, please kindly review it. was (Author: yzlai): [~zwoop] I've close previous pull request and create a new one with this patch, which remove handleIfRedirect() in done section. Please kindly review it. 404 error was logged while url redirect request was processed corrctly -- Key: TS-2344 URL: https://issues.apache.org/jira/browse/TS-2344 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Eddie Assignee: Leif Hedstrom Labels: Review Fix For: 5.0.0 Attachments: no_redirect_after_map.patch I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly and I could see the expected response in log as below: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed in the error log too, which generates a lot of error logs (log rotation configured) and filling up disk space pretty fast. 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly I could see the expected response in log as well: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed too: 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG proxy.config.log.extended2_log_enabled INT 0 CONFIG proxy.config.log.extended2_log_is_ascii INT 1 CONFIG proxy.config.log.extended2_log_name STRING extended2 CONFIG proxy.config.log.extended2_log_header STRING NULL CONFIG proxy.config.log.separate_icp_logs INT 0 CONFIG proxy.config.log.separate_host_logs INT 0 Is this a bug or is this a misconfiguration? Does anyone have any idea?) and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common
[jira] [Created] (TS-2794) Build failure related to header requirements of atscppapi
Ryo OKUBO created TS-2794:
-
Summary: Build failure related to header requirements of atscppapi
Key: TS-2794
URL: https://issues.apache.org/jira/browse/TS-2794
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Ryo OKUBO
Assignee: Brian Geffon
When I built my plugin outside of trafficserver source tree, I found build
failure related to header requirements of atscppapi as below logs.
{noformat}
# I set /usr/local/trafficserver/ as prefix.
In file included from
/usr/local/trafficserver/include/atscppapi/Transaction.h:30:
/usr/local/trafficserver/include/atscppapi/shared_ptr.h:28:10: fatal error:
'ink_autoconf.h' file not found
#include ink_autoconf.h
^
1 error generated.
{noformat}
The shared_ptr.h requires a variable defined on ink_autoconf.h but it doesn't
exist in destination directory. so I've already posted Pull-Request on GitHub
to fix it. please review, and show me better solution if you have.
https://github.com/apache/trafficserver/pull/80
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2810) add TSVConnFdCreate API
James Peach created TS-2810:
---
Summary: add TSVConnFdCreate API
Key: TS-2810
URL: https://issues.apache.org/jira/browse/TS-2810
Project: Traffic Server
Issue Type: Bug
Components: Core, TS API
Reporter: James Peach
Add a new API {{TSVConnFdCreate}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-2792: Summary: Large request header causes unexpected remap (was: Large request header occurs unexpected remap) Large request header causes unexpected remap Key: TS-2792 URL: https://issues.apache.org/jira/browse/TS-2792 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Attachments: quickfix.diff I get unexpected remap result when I request with likely 4KB of header. It seems to be caused by coalescing of heaps. In url_rewrite_remap_request, requestPath points to the path string of the URL. However, the address of the string may be changed in remap process in this function (e.g. request_url-host_set()). Because large header uses lots of space so reallocation of heap may be caused when we modify the header values. So the memcpy in this function may use the old invalid address as a source, and it results unexpected remap and also results broken log outputs. It may not cause crashes, but works incorrectly. How to reproduce: It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2807) SPDY + TLS matches http remap rules
[ https://issues.apache.org/jira/browse/TS-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998155#comment-13998155 ] Brian Geffon commented on TS-2807: -- I validated that this works as expected. This issue can be closed. SPDY + TLS matches http remap rules --- Key: TS-2807 URL: https://issues.apache.org/jira/browse/TS-2807 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Bryan Call Assignee: Brian Geffon Labels: spdy, yahoo Fix For: 5.0.0 When a client connects with SPDY + TLS it shouldn't match the http:// from remap rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[ https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994130#comment-13994130 ] Sudheer Vinukonda commented on TS-2791: --- So, the above fix seem to help - POST requests are now successful with this fix. I am yet to verify that the fix will still work if I check for the method to PURGE alone. But, in the mean time, can Yunkai Zhang comment on whether this fix might cause any other side affects? SPDY POST transactions failing with ERR_CLIENT_ABORT Key: TS-2791 URL: https://issues.apache.org/jira/browse/TS-2791 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo During our production testing of SPDY, we noticed that when trying to compose mails (POST transactions) on Firefox, we are seeing Network Error from the browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue appears to be likely specific to SPDY transactions and seem to be triggered by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer. After some investigation, it looks like this may be caused by a timing issue related to streaming of the POST data to the origin.. If the POST body (data) is available by the time client session and origin connection is ready, the POST is successful, but, if the data is large enough that it is not all read yet by the time origin connection is established, the streaming does not get triggered. Debugging further to identify the root cause. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2810) add TSVConnFdCreate API
[
https://issues.apache.org/jira/browse/TS-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2810:
Fix Version/s: 5.0.0
Assignee: James Peach
add TSVConnFdCreate API
---
Key: TS-2810
URL: https://issues.apache.org/jira/browse/TS-2810
Project: Traffic Server
Issue Type: Bug
Components: Core, TS API
Reporter: James Peach
Assignee: James Peach
Fix For: 5.0.0
Add a new API {{TSVConnFdCreate}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2619) TSRecordDump has a bad declaration
[
https://issues.apache.org/jira/browse/TS-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber resolved TS-2619.
-
Resolution: Fixed
TSRecordDump has a bad declaration
--
Key: TS-2619
URL: https://issues.apache.org/jira/browse/TS-2619
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: James Peach
Assignee: Phil Sorber
Priority: Blocker
Fix For: 5.0.0
{{TSRecordDump}} is declared as taking a {{TSRecordType}} constant. However,
this API also is defined to be able to operate on a {{TSRecordType}} bit
mask. When you do this, you get the following compiler error:
{code}
/opt/ats/include/ts/ts.h|3083 col 14| note: candidate function not viable: no
known conversion from 'int' to 'TSRecordType' for 1st argument
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998340#comment-13998340 ] Leif Hedstrom commented on TS-2801: --- It seems turning off the HTTP cache in ATS fixes the problem. I.e. it's only when serving content out of cache that it gets it wrong. This would also explain why it happens with both HTTPS and SPDY. If the SPDY request caches a corrupt page, presumably both HTTPS and SPDY would serve that broken page equally broken. Enabling SPDY can cause page corruptions Key: TS-2801 URL: https://issues.apache.org/jira/browse/TS-2801 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Fix For: sometime Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png When I build ATS with SPDY support, I see (sometimes) severe page corruptions on my site. What's even odd, these corruptions happens even more frequently from browsers which do not support SPDY. Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is no long corrupted. See the attached screenschot from a corruption from https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2342) problem with cache.cache_responses_to_cookies value 0
[
https://issues.apache.org/jira/browse/TS-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997990#comment-13997990
]
Leif Hedstrom commented on TS-2342:
---
Paul, I totally dropped the ball on this... Sorry about that. Can you maybe
attach a proposed patch for these fixes? Against current master branch :).
Thanks!
problem with cache.cache_responses_to_cookies value 0
-
Key: TS-2342
URL: https://issues.apache.org/jira/browse/TS-2342
Project: Traffic Server
Issue Type: Bug
Components: Cache, Configuration
Reporter: Paul Marquess
Assignee: Leif Hedstrom
Fix For: 5.0.0
I’m attempting to configure TS (3.2.0 but the issue seems to be present in
4.0.2 as well) to disable caching for all content where a cookie is present.
Setting cache.cache_responses_to_cookies to 0 looks like it should do that
according to the comment in records.config
# cache responses to cookies has 5 options:
# 0 - do not cache any responses to cookies
# 1 - cache for any content-type
# 2 - cache only for image types
# 3 - cache for all but text content-types
# 4 - cache for all but text content-types except OS response
# without Set-Cookie or with Cache-Control: public
# See also cache-responses-to-cookies in cache.config.
CONFIG proxy.config.http.cache.cache_responses_to_cookies INT 1
Unfortunately when I set cache.cache_responses_to_cookies to 0 in
records.config I don’t see anything written to the cache at all.
Am I correct in assuming that cache.cache_responses_to_cookies is intended to
influence the caching of content only when a cookie is in play? So the
behaviour I’m seeing is wrong?
Looking in do_cookiesprevent_caching in HttpTransact.cc it looks like the
test for the 0 use case (COOKIES_CACHE_NONE) is done too early. Below is the
code
// Can cache all regardless of cookie header - just ignore all cookie
headers
if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
return false;
}
// Do not cache if cookies option is COOKIES_CACHE_NONE
if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
return true;
}
...
if (!response-presence(MIME_PRESENCE_SET_COOKIE)
!request-presence(MIME_PRESENCE_COOKIE) (cached_request == NULL
||
!cached_request-presence(MIME_PRESENCE_COOKIE))) {
return false;
}
I don’t see any other tests in the code that check for cookies that would be
triggered before do_cookiesprevent_caching is invoked, so surely the
COOKIES_CACHE_NONE test needs to be done after the presence of cookies
headers has been determined?
So the code would become
// Can cache all regardless of cookie header - just ignore all cookie
headers
if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
return false;
}
...
if (!response-presence(MIME_PRESENCE_SET_COOKIE)
!request-presence(MIME_PRESENCE_COOKIE) (cached_request == NULL
||
!cached_request-presence(MIME_PRESENCE_COOKIE))) {
return false;
}
// Know we have a cookie present at this point
// Do not cache if cookies option is COOKIES_CACHE_NONE
// and cookie detected
if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
return true;
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2803) Use documentation strings extracted from source files in project documentation
[ https://issues.apache.org/jira/browse/TS-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2803: Component/s: Documentation Fix Version/s: 5.0.0 Assignee: James Peach This looks great. Will merge by the end of the week. Use documentation strings extracted from source files in project documentation -- Key: TS-2803 URL: https://issues.apache.org/jira/browse/TS-2803 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Jack Bates Assignee: James Peach Fix For: 5.0.0 Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructuredText, and then use them inside Sphinx documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998303#comment-13998303 ] Ethan Lai commented on TS-2344: --- Sorry, do not notice that constant changed in 5.x. I've committed the new change, please take a look again. 404 error was logged while url redirect request was processed corrctly -- Key: TS-2344 URL: https://issues.apache.org/jira/browse/TS-2344 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Eddie Assignee: Leif Hedstrom Labels: Review Fix For: 5.0.0 Attachments: no_redirect_after_map.patch I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly and I could see the expected response in log as below: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed in the error log too, which generates a lot of error logs (log rotation configured) and filling up disk space pretty fast. 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly I could see the expected response in log as well: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed too: 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG proxy.config.log.extended2_log_enabled INT 0 CONFIG proxy.config.log.extended2_log_is_ascii INT 1 CONFIG proxy.config.log.extended2_log_name STRING extended2 CONFIG proxy.config.log.extended2_log_header STRING NULL CONFIG proxy.config.log.separate_icp_logs INT 0 CONFIG proxy.config.log.separate_host_logs INT 0 Is this a bug or is this a misconfiguration? Does anyone have any idea?) and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG
[jira] [Commented] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998342#comment-13998342 ] Leif Hedstrom commented on TS-2801: --- Update: Even with the http.cache turned off, I once in a while get what looks like an empty page. This happens with both HTTPS and SPDY requests (but only when SPDY is built). Enabling SPDY can cause page corruptions Key: TS-2801 URL: https://issues.apache.org/jira/browse/TS-2801 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Fix For: sometime Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png When I build ATS with SPDY support, I see (sometimes) severe page corruptions on my site. What's even odd, these corruptions happens even more frequently from browsers which do not support SPDY. Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is no long corrupted. See the attached screenschot from a corruption from https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2789) Typo in HttpSessionManger would cause ATS reuse wrong session to origin server.
[
https://issues.apache.org/jira/browse/TS-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kang li updated TS-2789:
Description:
There is a typo in HttpSessionManger
(ats_ip_addr_eq(s-server_ip.sa, addr) ats_ip_port_cast(addr) ==
ats_ip_port_cast(addr)))
The fix would be
{code}
- (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
+ (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(s-server_ip.sa) == ats_ip_port_cast(addr)))
{code}
This typo skip the port check, so if requests to same origin server would use
one same session even though different port.
Which would cause ATS-5.0 reuse wrong session to origin.
was:
There is a typo in HttpSessionManger
(ats_ip_addr_eq(s-server_ip.sa, addr) ats_ip_port_cast(addr) ==
ats_ip_port_cast(addr)))
The fix would be
- (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
+ (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(s-server_ip.sa) == ats_ip_port_cast(addr)))
This typo skip the port check, so if requests to same origin server would use
one same session even though different port.
Which would cause ATS-5.0 reuse wrong session to origin.
Typo in HttpSessionManger would cause ATS reuse wrong session to origin
server.
---
Key: TS-2789
URL: https://issues.apache.org/jira/browse/TS-2789
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: kang li
There is a typo in HttpSessionManger
(ats_ip_addr_eq(s-server_ip.sa, addr) ats_ip_port_cast(addr) ==
ats_ip_port_cast(addr)))
The fix would be
{code}
- (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
+ (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(s-server_ip.sa) == ats_ip_port_cast(addr)))
{code}
This typo skip the port check, so if requests to same origin server would use
one same session even though different port.
Which would cause ATS-5.0 reuse wrong session to origin.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2805) Client connections are connecting with SPDY 3 instead of 3.1
[ https://issues.apache.org/jira/browse/TS-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997001#comment-13997001 ] Bryan Call commented on TS-2805: The order looks like it needs to be changed: Protocol selection It's expected that a client will have a list of protocols that it supports, in preference order, and will only select a protocol if the server supports it. In that case, the client SHOULD select the first protocol advertised by the server that it also supports. In the event that the client doesn't support any of server's protocols, or the server doesn't advertise any, it SHOULD select the first protocol that it supports. There may be cases where the client knows, via other means, that a server supports an unadvertised protocol. In these cases the client can simply select that protocol. https://tools.ietf.org/id/draft-agl-tls-nextprotoneg-03.html#rfc.section.4 Client connections are connecting with SPDY 3 instead of 3.1 Key: TS-2805 URL: https://issues.apache.org/jira/browse/TS-2805 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Bryan Call Assignee: Brian Geffon Labels: spdy, yahoo Fix For: 5.0.0 When testing with Chrome spdycat it is preferring to connect with SPDY 3: [bcall@cat ~]$ spdycat -v https://l10.ycs.sjb.yahoo.com [ 0.025] NPN select next protocol: the remote server offers: * spdy/3 * spdy/3.1 * http/1.0 * http/1.1 NPN selected the protocol: spdy/3 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2807) SPDY + TLS matches http remap rules
[ https://issues.apache.org/jira/browse/TS-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-2807. -- Resolution: Implemented SPDY + TLS matches http remap rules --- Key: TS-2807 URL: https://issues.apache.org/jira/browse/TS-2807 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Bryan Call Assignee: Brian Geffon Labels: spdy, yahoo Fix For: 5.0.0 When a client connects with SPDY + TLS it shouldn't match the http:// from remap rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2789) Typo in HttpSessionManger would cause ATS reuse wrong session to origin server.
[
https://issues.apache.org/jira/browse/TS-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2789:
--
Assignee: Bryan Call
Typo in HttpSessionManger would cause ATS reuse wrong session to origin
server.
---
Key: TS-2789
URL: https://issues.apache.org/jira/browse/TS-2789
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: kang li
Assignee: Bryan Call
Labels: yahoo
Fix For: 5.0.0
There is a typo in HttpSessionManger
(ats_ip_addr_eq(s-server_ip.sa, addr) ats_ip_port_cast(addr) ==
ats_ip_port_cast(addr)))
The fix would be
{code}
- (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
+ (ats_ip_addr_eq(s-server_ip.sa, addr)
ats_ip_port_cast(s-server_ip.sa) == ats_ip_port_cast(addr)))
{code}
This typo skip the port check, so if requests to same origin server would use
one same session even though different port.
Which would cause ATS-5.0 reuse wrong session to origin.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2809) Make various header sizes configurable (instead of fixed)
Leif Hedstrom created TS-2809:
-
Summary: Make various header sizes configurable (instead of fixed)
Key: TS-2809
URL: https://issues.apache.org/jira/browse/TS-2809
Project: Traffic Server
Issue Type: New Feature
Components: Core, HTTP
Reporter: Leif Hedstrom
It'd be swell if [~amc] could make some of the currently static buffer sizes
runtime configurable. Ideally even overridable. For example
{code}
proxy/hdrs/HdrHeap.h:#define HDR_HEAP_DEFAULT_SIZE 2048
proxy/hdrs/HdrHeap.h:#define HDR_STR_HEAP_DEFAULT_SIZE 2048
proxy/http/HttpSM.h:#define HTTP_HEADER_BUFFER_SIZE 2048
{code}
There might be several others :). I imagine a site using ATS could have some
reasonable knowledge of their typical header sizes, and size these accordingly
for optimal performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2782) ats crash in master in HdrHeap::inherit_string_heaps
[
https://issues.apache.org/jira/browse/TS-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993422#comment-13993422
]
Feifei Cai commented on TS-2782:
Hi [~briang],
Thank you for your commit, and it works!
I build a package using the latest master, and test upgrading from some earlier
version (before your first TS-2766's commit) to this new package, and there's
no crash issues now.
ats crash in master in HdrHeap::inherit_string_heaps
Key: TS-2782
URL: https://issues.apache.org/jira/browse/TS-2782
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Labels: spdy, yahoo
When testing master on production hosts, noticed the below crash occuring
repeatedly every time ats version is changed. This crash stops happening
after clearing the cache. This needs further investigation, but, I remember a
discussion between briang and zwoop about duplicate string fields in HdrHeap.
Not sure if this core is related to that. Would appreciate if briang or zwoop
can comment. Thank you.
{code}
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x30d3c0f500)[0x2aae27e2d500]
/home/y/bin/traffic_server(_ZN7HdrHeap20inherit_string_heapsEPKS_+0x271)[0x61caa1]
/home/y/bin/traffic_server(_Z14http_hdr_cloneP11HTTPHdrImplP7HdrHeapS2_+0x93)[0x619f83]
/home/y/bin/traffic_server(_ZN19HttpTransactHeaders18copy_header_fieldsEP7HTTPHdrS1_bl+0x1be)[0x5c201e]
/home/y/bin/traffic_server(_ZN12HttpTransact14build_responseEPNS_5StateEP7HTTPHdrS3_11HTTPVersion10HTTPStatusPKc+0x3ed)[0x5a287d]
/home/y/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0x354)[0x5b67f4]
/home/y/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x448)[0x5b84c8]
/home/y/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x66)[0x573816]
/home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x58ba72]
/home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x583070]
/home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x58d06a]
/home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x58ba72]
/home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x583070]
/home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x58d06a]
/home/y/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0xfe)[0x58533e]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x587de8]
/home/y/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1b2)[0x566e12]
/home/y/bin/traffic_server(_ZN7CacheVC8callcontEi+0x53)[0x653453]
/home/y/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x7cf)[0x6be9af]
/home/y/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x1ed)[0x69d40d]
/home/y/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x6539c5]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aef]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x71561b]
/home/y/bin/traffic_server[0x713e9a]
/lib64/libpthread.so.0(+0x30d3c07851)[0x2aae27e25851]
/lib64/libc.so.6(clone+0x6d)[0x30d38e890d]
{code}
gdb output below:
{code}
(gdb) bt
#0 ink_atomic_incrementint, int (this=0x2afb60113010,
inherit_from=0x2afaa824e688) at ../../lib/ts/ink_atomic.h:162
#1 refcount_inc (this=0x2afb60113010, inherit_from=0x2afaa824e688) at
../../lib/ts/Ptr.h:279
#2 operator= (this=0x2afb60113010, inherit_from=0x2afaa824e688) at
../../lib/ts/Ptr.h:408
#3 attach_str_heap (this=0x2afb60113010, inherit_from=0x2afaa824e688) at
HdrHeap.cc:1000
#4 HdrHeap::inherit_string_heaps (this=0x2afb60113010,
inherit_from=0x2afaa824e688) at HdrHeap.cc:1081
#5 0x00619f83 in http_hdr_clone (s_hh=0x2afaa824e710,
s_heap=0x2afaa824e688, d_heap=0x2afb60113010) at HTTP.cc:375
#6 0x005c201e in copy (src_hdr=0x2afaa824e0b8,
new_hdr=0x2afac4058c50, retain_proxy_auth_hdrs=false, date=0) at
../../proxy/hdrs/HTTP.h:867
#7 HttpTransactHeaders::copy_header_fields (src_hdr=0x2afaa824e0b8,
new_hdr=0x2afac4058c50, retain_proxy_auth_hdrs=false, date=0) at
HttpTransactHeaders.cc:201
#8 0x005a287d in HttpTransact::build_response (s=0x2afac4058570,
base_response=0x2afaa824e0b8, outgoing_response=0x2afac4058c50,
outgoing_version=value optimized out,
status_code=HTTP_STATUS_NONE, reason_phrase=0x7323ac None) at
HttpTransact.cc:7926
#9 0x005b67f4 in HttpTransact::build_response_from_cache
(s=0x2afac4058570, warning_code=HTTP_WARNING_CODE_NONE) at
[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997683#comment-13997683 ] Leif Hedstrom commented on TS-2344: --- That branch does not build for me, PROXY_INTERNAL_CACHE_NOOP is not defined. 404 error was logged while url redirect request was processed corrctly -- Key: TS-2344 URL: https://issues.apache.org/jira/browse/TS-2344 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Eddie Assignee: Leif Hedstrom Labels: Review Fix For: 5.0.0 Attachments: no_redirect_after_map.patch I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly and I could see the expected response in log as below: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed in the error log too, which generates a lot of error logs (log rotation configured) and filling up disk space pretty fast. 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly I could see the expected response in log as well: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed too: 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG proxy.config.log.extended2_log_enabled INT 0 CONFIG proxy.config.log.extended2_log_is_ascii INT 1 CONFIG proxy.config.log.extended2_log_name STRING extended2 CONFIG proxy.config.log.extended2_log_header STRING NULL CONFIG proxy.config.log.separate_icp_logs INT 0 CONFIG proxy.config.log.separate_host_logs INT 0 Is this a bug or is this a misconfiguration? Does anyone have any idea?) and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG proxy.config.log.extended2_log_enabled INT 0
[jira] [Commented] (TS-2237) URL encoding wrong in squid.blog
[ https://issues.apache.org/jira/browse/TS-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998290#comment-13998290 ] James Peach commented on TS-2237: - Bleccch ... it double-encodes :( URL encoding wrong in squid.blog Key: TS-2237 URL: https://issues.apache.org/jira/browse/TS-2237 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: David Carlin Priority: Minor Fix For: 5.0.0 I was replaying URLs captured from squid.blog and I noticed I was getting 404's for some of them when squid.blog showed a 200 for that request. Turns out there is an issue with URL encoding. For example: Requesting file 'duck%20sports%20authority.gif' via curl will put this in the logs: duck%2520sports%2520authority.gif The % from %20 (space) in the request is being converted to %25 resulting in %2520 I tested both the %cquc and %cquuc log fields - same thing happens. I tested on ATS 3.2.0 and 3.3.5 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2797) Not all manpages getting built
[ https://issues.apache.org/jira/browse/TS-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2797. - Resolution: Fixed Not all manpages getting built -- Key: TS-2797 URL: https://issues.apache.org/jira/browse/TS-2797 Project: Traffic Server Issue Type: Bug Components: Documentation Affects Versions: 5.0.0 Reporter: Jack Bates Assignee: James Peach Fix For: 5.0.0 Not all of the manpages are getting built because they are not part of the man_pages list in doc/conf.py This patch adds all of the files in the doc/reference/api directory to the list of manual pages. It also adds the manual page descriptions to the HTML output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2793) remove UnixNetVConnection::selected_next_protocol
James Peach created TS-2793:
---
Summary: remove UnixNetVConnection::selected_next_protocol
Key: TS-2793
URL: https://issues.apache.org/jira/browse/TS-2793
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: James Peach
SPDY uses {{UnixNetVConnection::selected_next_protocol}} to track the SPDY
version requested in the NPN handshake. This is unnecessary, since SPDY can
easily provide a different acceptor on every different NPN string. We should
remove this and simplify the remains.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
