[jira] [Resolved] (TS-1695) test_certlookup fails on FreeBSD 10
[
https://issues.apache.org/jira/browse/TS-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić resolved TS-1695.
Resolution: Fixed
\o/
test_certlookup fails on FreeBSD 10
---
Key: TS-1695
URL: https://issues.apache.org/jira/browse/TS-1695
Project: Traffic Server
Issue Type: Bug
Components: Portability
Environment: FreeBSD 10, amd64
Reporter: Igor Galić
Assignee: Susan Hinrichs
Labels: freebsd
Fix For: 5.3.0
{noformat}
Reading symbols from
/tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
[New process 100244]
[New Thread 803806400 (LWP 100244)]
Core was generated by `test_certlookup'.
Program terminated with signal 10, Bus error.
#0 0x000802cbc43b in ?? () from /lib/libc.so.7
(gdb) bt
#0 0x000802cbc43b in ?? () from /lib/libc.so.7
#1 0x000802cc8c74 in free () from /lib/libc.so.7
#2 0x00405ca6 in TrieSSLContextStorage::SSLEntry::Clear
(this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
#3 0x00405d21 in TrieSSLContextStorage::SSLEntry::~Trie
(this=0x80382c800, __in_chrg=optimized out) at
/home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
#4 0x00403c11 in SSLContextStorage::~SSLContextStorage
(this=0x80382c800, __in_chrg=optimized out) at
/home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
#5 0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0,
__in_chrg=optimized out) at
/home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
#6 0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0
regressionTest_SSLCertificateLookup, atype=0, pstatus=0x60dab8
regressionTest_SSLCertificateLookup+24)
at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
#7 0x00080085eff6 in start_test (t=0x60daa0
regressionTest_SSLCertificateLookup) at
/home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
#8 0x00080085f404 in RegressionTest::run (atest=0x0) at
/home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
#9 0x00402ce0 in main (argc=1, argv=0x7fffd470) at
/home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
(gdb)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1570) remap doesn't reject request whose Host has extra characters after port (like test.com:80xxx)
[
https://issues.apache.org/jira/browse/TS-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218007#comment-14218007
]
Alan M. Carroll commented on TS-1570:
-
Susan notes this line
{code}
std::string s(line_start);
{code}
is much worse than I thought because there is no guarantee {{line_start}} is
null terminated. This is a very important thing to keep in mind at all times
when working with the headers. She also noted that http_parser_parse_req is a
restartable parser and {{line_start}} is a local variable so its state is not
preserved across calls. If the header comes through in pieces and the {{HOST}}
field was in a previous chunk, this will incorrectly decide there was no
{{HOST}} field.
I will note that the original patch does bong 1.1 requests that are missing a
{{HOST}} field, I will leave that to Leif and Cynthia to hash out.
remap doesn't reject request whose Host has extra characters after port (like
test.com:80xxx)
---
Key: TS-1570
URL: https://issues.apache.org/jira/browse/TS-1570
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.0
Reporter: Conan Wang
Assignee: Cynthia Gu
Priority: Minor
Fix For: 5.3.0
Attachments: patch.diff, patch.diff1
remap.config:map http://test.com http://1.1.1.1
The request with Host: 'test.com:80xxx' or 'test.com:xxx' will get passed.
Such host is not filtered strictly.
Just report, didn't have big problem for me though.
curl http://127.0.0.1:8080/ -H Host: test.com:80xxx
or curl -x 127.0.0.1:8080 http://test.com:80xxx/ -v
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3153) Ability to disable/modify protocols based on SNI information
[ https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218009#comment-14218009 ] Alan M. Carroll commented on TS-3153: - The fundamental goal here is to be able to set the NPN set in an SSL NetVC before it does the NPN negotiation. For the particular use case that drove this bug it would be sufficient to filter the existing list, but I think we should aim for the more general mechanism. We already have the ssl_[un]register_protocol functions to manipulate the NPN list, the problem is that these are done globally. What would be necessary for this is to make an NPN set (internally SSLNextProtocolSet) a directly accessible object. This would require at least the following operations * Create NPN set. * Destroy NPN set. * Register and unregister protocol in NPN set. * Copy existing NPN set for a proxy port. * Set the NPN set for an SSL NetVC. Another hurdle I see is that proxy ports are also inaccessible. Even in the current use case it is important for the plugin to be able to manipulate the NPN set differently for different proxy ports. I'm a bit miffed because this was a central theme of my Early Intervention talk. I do think that if we're going to provide this kind of early intervention we need to do a robust, general API or we'll be piling hack upon hack to do all the things that will be desired. Ability to disable/modify protocols based on SNI information Key: TS-3153 URL: https://issues.apache.org/jira/browse/TS-3153 Project: Traffic Server Issue Type: Improvement Components: HTTP/2, SPDY Reporter: Bryan Call Fix For: 5.2.0 Attachments: TS-3153.diff We are running into problems where certain origin servers are having issues when SPDY is enabled. It would be great to have more control over when protocols are enabled. One way to do this would be to add a protocol options to the entry in the ssl_multicert config. We wound then add additional entries for domains that need to disable the protocols. All protocols should be enabled by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3153) Ability to disable/modify protocols based on SNI information
[ https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218081#comment-14218081 ] ASF subversion and git services commented on TS-3153: - Commit dafe0a3977a4f3eafae649c687474ac4bfc21110 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dafe0a3 ] Revert [TS-3153]: Add documentation for new API TSSslAdvertiseProtocolSet This reverts commit f19eba3ca70159af1ced63cc987b4a2508c570ba. Ability to disable/modify protocols based on SNI information Key: TS-3153 URL: https://issues.apache.org/jira/browse/TS-3153 Project: Traffic Server Issue Type: Improvement Components: HTTP/2, SPDY Reporter: Bryan Call Fix For: 5.2.0 Attachments: TS-3153.diff We are running into problems where certain origin servers are having issues when SPDY is enabled. It would be great to have more control over when protocols are enabled. One way to do this would be to add a protocol options to the entry in the ssl_multicert config. We wound then add additional entries for domains that need to disable the protocols. All protocols should be enabled by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3153) Ability to disable/modify protocols based on SNI information
[ https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218082#comment-14218082 ] ASF subversion and git services commented on TS-3153: - Commit a0bad98ec17c441ce8a44e181005df03630b469d in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a0bad98 ] Revert [TS-3153]: Ability to disable or modify npn advertisement based on SNI This reverts commit 24262d8f6a14b6bb7bf7288f6309a68f6dc8589b. Ability to disable/modify protocols based on SNI information Key: TS-3153 URL: https://issues.apache.org/jira/browse/TS-3153 Project: Traffic Server Issue Type: Improvement Components: HTTP/2, SPDY Reporter: Bryan Call Fix For: 5.2.0 Attachments: TS-3153.diff We are running into problems where certain origin servers are having issues when SPDY is enabled. It would be great to have more control over when protocols are enabled. One way to do this would be to add a protocol options to the entry in the ssl_multicert config. We wound then add additional entries for domains that need to disable the protocols. All protocols should be enabled by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3153) Ability to disable/modify protocols based on SNI information
[ https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218084#comment-14218084 ] ASF subversion and git services commented on TS-3153: - Commit 5f7f7cd2df02585ef9be3d0d5dd2e2475ccf7d2d in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5f7f7cd ] [TS-3153]: Reverting changes for TS-3153 as a better solution is being discussed Ability to disable/modify protocols based on SNI information Key: TS-3153 URL: https://issues.apache.org/jira/browse/TS-3153 Project: Traffic Server Issue Type: Improvement Components: HTTP/2, SPDY Reporter: Bryan Call Fix For: 5.2.0 Attachments: TS-3153.diff We are running into problems where certain origin servers are having issues when SPDY is enabled. It would be great to have more control over when protocols are enabled. One way to do this would be to add a protocol options to the entry in the ssl_multicert config. We wound then add additional entries for domains that need to disable the protocols. All protocols should be enabled by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3153) Ability to disable/modify protocols based on SNI information
[ https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218083#comment-14218083 ] ASF subversion and git services commented on TS-3153: - Commit 5f7f7cd2df02585ef9be3d0d5dd2e2475ccf7d2d in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5f7f7cd ] [TS-3153]: Reverting changes for TS-3153 as a better solution is being discussed Ability to disable/modify protocols based on SNI information Key: TS-3153 URL: https://issues.apache.org/jira/browse/TS-3153 Project: Traffic Server Issue Type: Improvement Components: HTTP/2, SPDY Reporter: Bryan Call Fix For: 5.2.0 Attachments: TS-3153.diff We are running into problems where certain origin servers are having issues when SPDY is enabled. It would be great to have more control over when protocols are enabled. One way to do this would be to add a protocol options to the entry in the ssl_multicert config. We wound then add additional entries for domains that need to disable the protocols. All protocols should be enabled by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3153) Ability to disable/modify protocols based on SNI information
[ https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218086#comment-14218086 ] Sudheer Vinukonda commented on TS-3153: --- [~amc]: Thanks, I agree that a generic API would perhaps be cleaner. I've reverted the changes until there's an agreement on the final solution. Ability to disable/modify protocols based on SNI information Key: TS-3153 URL: https://issues.apache.org/jira/browse/TS-3153 Project: Traffic Server Issue Type: Improvement Components: HTTP/2, SPDY Reporter: Bryan Call Fix For: 5.2.0 Attachments: TS-3153.diff We are running into problems where certain origin servers are having issues when SPDY is enabled. It would be great to have more control over when protocols are enabled. One way to do this would be to add a protocol options to the entry in the ssl_multicert config. We wound then add additional entries for domains that need to disable the protocols. All protocols should be enabled by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3130) Core dump in Logging
[
https://issues.apache.org/jira/browse/TS-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218131#comment-14218131
]
Alan M. Carroll commented on TS-3130:
-
I think we want to delay setting the buffer to NULL until the end of the
function. I think decrementing the buffer in the {{LB_BUFFER_TOO_SMALL}} case
is correct but we will need to return a fail to the caller. {{result_code}}
should be still valid just before the {{return}}.
Core dump in Logging
Key: TS-3130
URL: https://issues.apache.org/jira/browse/TS-3130
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 5.0.1
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.2.0
Seeing a core dump in logging when the configured log buffer is not
sufficient to print a log.
Here's the gdb back trace and some useful info:
{code}
(gdb) bt
#0 0x00665fed in ink_atomic_incrementint, int (mem=0x68, count=-1)
at ../../lib/ts/ink_atomic.h:89
#1 0x00662c8e in LogObject::_checkout_write (this=0x264b6f0,
write_offset=0x2ba25de4b508, bytes_needed=25376) at LogObject.cc:501
#2 0x006632aa in LogObject::log (this=0x264b6f0, lad=0x2ba25de4b650,
text_entry=0x0) at LogObject.cc:618
#3 0x006659f6 in LogObjectManager::log (this=0x263c0e8,
lad=0x2ba25de4b650) at LogObject.cc:1353
#4 0x00641a74 in Log::access (lad=0x2ba25de4b650) at Log.cc:1096
#5 0x005bab9b in HttpBodyTemplate::build_instantiated_buffer
(this=0x2a1ccc0, context=0x2ba4540c4a78, buflen_return=0x2ba25de4c1c8) at
HttpBodyFactory.cc:1011
#6 0x005b92a0 in HttpBodyFactory::fabricate (this=0x29f8820,
acpt_language_list=0x2ba25de4bd60, acpt_charset_list=0x2ba25de4bc00,
type=0x78c323 urlrouting#no_mapping, context=0x2ba4540c4a78,
buffer_length_return=0x2ba25de4c1c8,
content_language_return=0x2ba25de4bed8,
content_charset_return=0x2ba25de4bed0, set_return=0x2ba25de4bec8) at
HttpBodyFactory.cc:448
#7 0x005b8422 in HttpBodyFactory::fabricate_with_old_api(const char
*, HttpTransact::State *, int64_t, int64_t *, char *, size_t, char *, size_t,
const char *, typedef __va_list_tag __va_list_tag *) (
this=0x29f8820, type=0x78c323 urlrouting#no_mapping,
context=0x2ba4540c4a78, max_buffer_length=8192,
resulting_buffer_length=0x2ba25de4c1c8,
content_language_out_buf=0x2ba25de4c090 en,
content_language_buf_size=256, content_type_out_buf=0x2ba25de4bf90
text/html, content_type_buf_size=256, format=0x0, ap=0x2ba25de4c1d0) at
HttpBodyFactory.cc:138
#8 0x006091fe in HttpTransact::build_error_response
(s=0x2ba4540c4a78, status_code=HTTP_STATUS_NOT_FOUND,
reason_phrase_or_null=0x78c339 Not Found on Accelerator,
error_body_type=0x78c323 urlrouting#no_mapping, format=0x0) at
HttpTransact.cc:8071
#9 0x005eab76 in HttpTransact::EndRemapRequest (s=0x2ba4540c4a78) at
HttpTransact.cc:925
#10 0x005ddbfd in HttpSM::call_transact_and_set_next_state
(this=0x2ba4540c4a10, f=0) at HttpSM.cc:6834
#11 0x005ddee4 in HttpSM::set_next_state (this=0x2ba4540c4a10) at
HttpSM.cc:6892
#12 0x005ddd3a in HttpSM::call_transact_and_set_next_state
(this=0x2ba4540c4a10, f=0) at HttpSM.cc:6842
#13 0x005cc2b3 in HttpSM::handle_api_return (this=0x2ba4540c4a10) at
HttpSM.cc:1507
#14 0x005cc110 in HttpSM::state_api_callout (this=0x2ba4540c4a10,
event=0, data=0x0) at HttpSM.cc:1439
#15 0x005d7605 in HttpSM::do_api_callout_internal
(this=0x2ba4540c4a10) at HttpSM.cc:4800
#16 0x005e4010 in HttpSM::do_api_callout (this=0x2ba4540c4a10) at
HttpSM.cc:445
#17 0x005ddda0 in HttpSM::set_next_state (this=0x2ba4540c4a10) at
HttpSM.cc:6876
#18 0x005ddd3a in HttpSM::call_transact_and_set_next_state
(this=0x2ba4540c4a10, f=0) at HttpSM.cc:6842
#19 0x005cc2b3 in HttpSM::handle_api_return (this=0x2ba4540c4a10) at
HttpSM.cc:1507
#20 0x005cc110 in HttpSM::state_api_callout (this=0x2ba4540c4a10,
event=0, data=0x0) at HttpSM.cc:1439
#21 0x005d7605 in HttpSM::do_api_callout_internal
(this=0x2ba4540c4a10) at HttpSM.cc:4800
#22 0x005e4010 in HttpSM::do_api_callout (this=0x2ba4540c4a10) at
HttpSM.cc:445
#23 0x005ddda0 in HttpSM::set_next_state (this=0x2ba4540c4a10) at
HttpSM.cc:6876
#24 0x005ddd3a in HttpSM::call_transact_and_set_next_state
(this=0x2ba4540c4a10, f=0x5ec2ce
HttpTransact::ModifyRequest(HttpTransact::State*)) at HttpSM.cc:6842
#25 0x005ca241 in HttpSM::state_read_client_request_header
(this=0x2ba4540c4a10, event=100, data=0x2ba2e54a5e80) at HttpSM.cc:763
#26 0x005cf652 in HttpSM::main_handler (this=0x2ba4540c4a10,
event=100, data=0x2ba2e54a5e80) at HttpSM.cc:2500
#27
[jira] [Commented] (TS-3202) HTTP Parsing should not allow CTL characters in the method
[ https://issues.apache.org/jira/browse/TS-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218169#comment-14218169 ] ASF GitHub Bot commented on TS-3202: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/149 HTTP Parsing should not allow CTL characters in the method -- Key: TS-3202 URL: https://issues.apache.org/jira/browse/TS-3202 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 Attachments: TS-3202.diff http_parser_parse_req() will mark a series of bytes as a correctly parsed HTTP request if it meets the following constraints. bytes excluding white space+ white space+ bytes excluding white space+\n The first set of bytes is the method. The current code will match a bunch of control characters as a valid method (found via a case in production). Assuming the second set of bytes does not contain a valid domain name, the processing will eventually fail and return to the client a message about not being able to resolve the DNS address, which is confusing. Looking at the W3 specs, it looks like HTTP 1.1 has the most lax rules for what characters can form a method token. From my reading, a method can be any token (http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1), and any character but white space and control characters are allowed to be in a token (http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2). To improve the accuracy of our processing (and the accuracy of our error messages), I'd like to change the parsing of the method token in http_parser_parse_req() to restrict control characters from the method token as well as the white space characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2009) Disallow \0 in all headers
[ https://issues.apache.org/jira/browse/TS-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218170#comment-14218170 ] ASF GitHub Bot commented on TS-2009: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/148 Disallow \0 in all headers -- Key: TS-2009 URL: https://issues.apache.org/jira/browse/TS-2009 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Susan Hinrichs Fix For: 5.2.0 Attachments: ts-2009.diff Related to TS-1660, we should move the test for \0 in the Host: header to be generically applied when parsing all headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 resolved TS-898. -- Resolution: Fixed Closing this, we solved a bunch, and we should file new ones for what's remaining (instead of keeping one open indefinitely). fix potential problems from coverity scan - Key: TS-898 URL: https://issues.apache.org/jira/browse/TS-898 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.0.0 Environment: RHEL5 Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: 5.2.0 Ran Coverity over the code and it reported 856 potential problems with the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-2629) Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
[
https://issues.apache.org/jira/browse/TS-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2629.
---
Resolution: Won't Fix
Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
---
Key: TS-2629
URL: https://issues.apache.org/jira/browse/TS-2629
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: sometime
It seems even with the default configuration:
{code}
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
{code}
ATS can create much larger orphaned logs, e.g.
{code}
$ du -h log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
442M log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2724) purge waste memory
[
https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2724:
--
Assignee: (was: Leif Hedstrom)
purge waste memory
--
Key: TS-2724
URL: https://issues.apache.org/jira/browse/TS-2724
Project: Traffic Server
Issue Type: Bug
Affects Versions: 4.2.0
Reporter: bettydramit
Fix For: sometime
I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
records.config
{code}
proxy.config.cache.target_fragment_size INT 1048576
{code}
I use curl to get them :
{code}
for((i=0;i100;i++)); do curl -v -o /dev/null
http://www.test.com/testdir/$i.mp4; done
{code}
every file just get once, i can see ats memory usage is 138M
After use curl to purge them :
{code}
for((i=0;i100;i++)); do curl -v -o /dev/null -X purge
http://www.test.com/testdir/$i.mp4; done
{code}
I can see ats memory usage is 246M
every file removed from ats, why the memory usage enlarge about 100M
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2936) Comments and line continuations in remap.config is bad mojo
[
https://issues.apache.org/jira/browse/TS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2936:
--
Assignee: (was: Leif Hedstrom)
Comments and line continuations in remap.config is bad mojo
---
Key: TS-2936
URL: https://issues.apache.org/jira/browse/TS-2936
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Core
Reporter: Leif Hedstrom
Fix For: 5.3.0
If you do a line continuation on a commented out line in remap.config, it'll
still suck up the following line into the comment. This is less than ideal.
As an example, this does not work
{code}
map http://example.com http://real.example.com \
# @plugin=conf_remap.so @pparam= ... \
@plugin=header_rewrite.so @pparam= ...
{code}
The issue being that the second plugin line gets sucked into the comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2936) Comments and line continuations in remap.config is bad mojo
[
https://issues.apache.org/jira/browse/TS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2936:
--
Fix Version/s: (was: 5.2.0)
5.3.0
Comments and line continuations in remap.config is bad mojo
---
Key: TS-2936
URL: https://issues.apache.org/jira/browse/TS-2936
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.3.0
If you do a line continuation on a commented out line in remap.config, it'll
still suck up the following line into the comment. This is less than ideal.
As an example, this does not work
{code}
map http://example.com http://real.example.com \
# @plugin=conf_remap.so @pparam= ... \
@plugin=header_rewrite.so @pparam= ...
{code}
The issue being that the second plugin line gets sucked into the comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2936) Comments and line continuations in remap.config is bad mojo
[
https://issues.apache.org/jira/browse/TS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218197#comment-14218197
]
Leif Hedstrom commented on TS-2936:
---
Returning this to the pool, I think it'd be a good fix to not have it suck up
lines like that as part of the comments (but that's just my $0.01).
Also, I think the line continuations makes error reporting confusing; The line
number where the error occurs is no longer accurate (one continuated entry
counts as one line in the source file). I don't know if we have a separate bug
for that?
Comments and line continuations in remap.config is bad mojo
---
Key: TS-2936
URL: https://issues.apache.org/jira/browse/TS-2936
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Core
Reporter: Leif Hedstrom
Fix For: 5.3.0
If you do a line continuation on a commented out line in remap.config, it'll
still suck up the following line into the comment. This is less than ideal.
As an example, this does not work
{code}
map http://example.com http://real.example.com \
# @plugin=conf_remap.so @pparam= ... \
@plugin=header_rewrite.so @pparam= ...
{code}
The issue being that the second plugin line gets sucked into the comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2942) weird value on %fsiz field in log files
[
https://issues.apache.org/jira/browse/TS-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2942:
--
Fix Version/s: (was: 5.2.0)
5.3.0
weird value on %fsiz field in log files
-
Key: TS-2942
URL: https://issues.apache.org/jira/browse/TS-2942
Project: Traffic Server
Issue Type: Bug
Components: Logging, Metrics
Reporter: Daniel Picolli Biazus
Assignee: Leif Hedstrom
Fix For: 5.3.0
We've configured ATS as a reverse proxy, and We've been noticed a really
weird traffic value in our monitoring system. After spend some time digging
through log files, I could notice that, in some cases the field %fsiz
brings a huge value (20 characters) instead of the file size.
I found this closed issue regarding the fsiz implementation, and I think
there might be a issue when there is no Content-Length from the origin server.
https://issues.apache.org/jira/browse/TS-2212
Log format:
##
LogFormat
Name = myformat/
Format = %ttmsf%{Host}cqh%chi [%cqtn]
%cqhm %cquup %cqhv%pssc %cqhm %fsiz %cquup
%{User-Agent}cqh %{Referer}cqh %crc/
/LogFormat
##
Log result:
##
0.181 myhostname.com 123.123.123.123 [17/Jul/2014:15:50:33 -]GET
/foo/bar/file.jpg HTTP/1.1 200 GET 3904675161847313968
/foo/bar/file.jpg Mozilla/5.0 (Windows NT 6.2; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
http://myreferer.comTCP_MISS
###
In that case, the fsiz field has the value 3904675161847313968
instead the value of a few bytes.
I believe when there is no way to get the real content-length, we should
return 0 in order to avoid misinterpretation.
Thanks in advance,
Daniel
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218201#comment-14218201
]
Leif Hedstrom commented on TS-2955:
---
Is this done? If so, please close.
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Labels: review, yahoo
Fix For: 5.2.0
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2955:
--
Assignee: Sudheer Vinukonda (was: Leif Hedstrom)
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Labels: review, yahoo
Fix For: 5.2.0
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3013) lua doesn't build with ccache on darwin
[
https://issues.apache.org/jira/browse/TS-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3013:
--
Fix Version/s: (was: 5.2.0)
5.3.0
lua doesn't build with ccache on darwin
---
Key: TS-3013
URL: https://issues.apache.org/jira/browse/TS-3013
Project: Traffic Server
Issue Type: Bug
Components: Build, Lua
Reporter: James Peach
Assignee: Leif Hedstrom
Fix For: 5.3.0
{code}
Making all in luajit
test -d ../lib/luajit/src || (cd .. git submodule update --init)
test -d ../lib/luajit/src || cp -rf ./luajit ../lib/
cd luajit /Applications/Xcode6-Beta.app/Contents/Developer/usr/bin/make
BUILDMODE=static PREFIX=/opt/ats CC=ccache cc \
CFLAGS=-O0 -g -pipe -Wall
-Wno-deprecated-declarations -Qunused-arguments -Werror -mcx16
-DLUA_COMPAT_ALL -DLUA_USE_POSIX -DLUA_USE_DLOPEN LDFLAGS=
Building LuaJIT 2.0.3
/Applications/Xcode6-Beta.app/Contents/Developer/usr/bin/make -C src
HOSTCChost/minilua.o
host/minilua.c:1350:8: error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
if(((n)==(0)))
~~~^
{code}
I can't easily see what the problem is due to TS-2917.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3014) healthchecks.config not reloadable
[ https://issues.apache.org/jira/browse/TS-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3014: -- Fix Version/s: (was: 5.2.0) 5.3.0 healthchecks.config not reloadable -- Key: TS-3014 URL: https://issues.apache.org/jira/browse/TS-3014 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Ask Bjørn Hansen Assignee: Leif Hedstrom Priority: Minor Fix For: 5.3.0 Changing healthchecks.config appears to require a restart. That seems slightly unfortunate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3036) Add logging field to define the cache medium used to serve a HIT
[ https://issues.apache.org/jira/browse/TS-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3036: -- Fix Version/s: (was: sometime) 5.2.0 Add logging field to define the cache medium used to serve a HIT Key: TS-3036 URL: https://issues.apache.org/jira/browse/TS-3036 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Ryan Frantz Assignee: Leif Hedstrom Fix For: 5.2.0 I want to be able to differentiate between RAM cache HITs and disk cache HITs. Add a logging field to inform the administrator if the HIT came from RAM, at least. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3188) Do not set half_close flag for short post on keep_alive client connections
[ https://issues.apache.org/jira/browse/TS-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218205#comment-14218205 ] ASF subversion and git services commented on TS-3188: - Commit deb77cf15fa1bbab8232d9d907680451fb84545f in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=deb77cf ] TS-3188: Do not set half_close for keep alive POST. This closes #142. Do not set half_close flag for short post on keep_alive client connections -- Key: TS-3188 URL: https://issues.apache.org/jira/browse/TS-3188 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 The original logic would set the half_close flag on the client session if all the post information fit in the receive buffer before we started the post tunnel. However, if the client connection was to be used for multiple requests, this was incorrect. This flaw exhibited in my test safelyfiled site by doing a folder create (resulting in a short set of post arguments) followed by a file upload that tried to reuse the same connection. The file upload would fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3188) Do not set half_close flag for short post on keep_alive client connections
[ https://issues.apache.org/jira/browse/TS-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-3188. - Resolution: Fixed Fix Version/s: 5.2.0 Do not set half_close flag for short post on keep_alive client connections -- Key: TS-3188 URL: https://issues.apache.org/jira/browse/TS-3188 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 The original logic would set the half_close flag on the client session if all the post information fit in the receive buffer before we started the post tunnel. However, if the client connection was to be used for multiple requests, this was incorrect. This flaw exhibited in my test safelyfiled site by doing a folder create (resulting in a short set of post arguments) followed by a file upload that tried to reuse the same connection. The file upload would fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3189) Do not start reading data on server to user agent tunnel too soon
[ https://issues.apache.org/jira/browse/TS-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218216#comment-14218216 ] ASF subversion and git services commented on TS-3189: - Commit a34bebbe5bf432c9d27052a31c68dadef46e32c7 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a34bebb ] TS-3189: Delay the do_io_read on the server to user agent tunnel to avoid cases of the incorrect tunnel handling EOS in the post case. This closes #143. Do not start reading data on server to user agent tunnel too soon - Key: TS-3189 URL: https://issues.apache.org/jira/browse/TS-3189 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs The original logic would set up a do_io_read for max_int in HttpSM::attach_server_session. However, at this point there still may be things finishing up in the user_agent to server tunnel (for posts). We were seeing occasional cases of the EOS for the tunnel to user_agent communication being incorrectly delivered to the consumer of the user_agent to server tunnel. It is sufficient to set up a 0 length read in HttpSM::attach_server_session. This will enable the correct handlers to deal with inactivity timeouts. Then we can setup the real read in HttpSM::setup_server_read_response_header() after we know that the user_agent to origin server tunnel has been taken down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3188) Do not set half_close flag for short post on keep_alive client connections
[ https://issues.apache.org/jira/browse/TS-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218222#comment-14218222 ] ASF GitHub Bot commented on TS-3188: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/142 Do not set half_close flag for short post on keep_alive client connections -- Key: TS-3188 URL: https://issues.apache.org/jira/browse/TS-3188 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 The original logic would set the half_close flag on the client session if all the post information fit in the receive buffer before we started the post tunnel. However, if the client connection was to be used for multiple requests, this was incorrect. This flaw exhibited in my test safelyfiled site by doing a folder create (resulting in a short set of post arguments) followed by a file upload that tried to reuse the same connection. The file upload would fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3189) Do not start reading data on server to user agent tunnel too soon
[ https://issues.apache.org/jira/browse/TS-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218223#comment-14218223 ] ASF GitHub Bot commented on TS-3189: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/143 Do not start reading data on server to user agent tunnel too soon - Key: TS-3189 URL: https://issues.apache.org/jira/browse/TS-3189 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs The original logic would set up a do_io_read for max_int in HttpSM::attach_server_session. However, at this point there still may be things finishing up in the user_agent to server tunnel (for posts). We were seeing occasional cases of the EOS for the tunnel to user_agent communication being incorrectly delivered to the consumer of the user_agent to server tunnel. It is sufficient to set up a 0 length read in HttpSM::attach_server_session. This will enable the correct handlers to deal with inactivity timeouts. Then we can setup the real read in HttpSM::setup_server_read_response_header() after we know that the user_agent to origin server tunnel has been taken down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3190) Change producer_run() to run a specific producer in more cases
[ https://issues.apache.org/jira/browse/TS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs resolved TS-3190. Resolution: Fixed Fix Version/s: 5.2.0 Change producer_run() to run a specific producer in more cases -- Key: TS-3190 URL: https://issues.apache.org/jira/browse/TS-3190 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 Found while tracking down TS-3105. It seemed like sometimes producers were having producer_run called on them multiple times. producer_run can be run on a particular producers or on all producers added at that point in time. There are a couple places where multiple producers are set up and so producer_run(NULL) makes sense. But in many cases a producer is carefully added and then producer_run(NULL) is called on all producers that are around that that point in time. It seems safer to call producer_run() on the newly added producer in those cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3190) Change producer_run() to run a specific producer in more cases
[ https://issues.apache.org/jira/browse/TS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218263#comment-14218263 ] ASF subversion and git services commented on TS-3190: - Commit 9e2fce4d2568ff3f0b5f2db333c7e502bdd0cdd9 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9e2fce4 ] TS-3190: Use the version of producer_run that runs a specific producer instead of all producers. This closes #144. Change producer_run() to run a specific producer in more cases -- Key: TS-3190 URL: https://issues.apache.org/jira/browse/TS-3190 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Found while tracking down TS-3105. It seemed like sometimes producers were having producer_run called on them multiple times. producer_run can be run on a particular producers or on all producers added at that point in time. There are a couple places where multiple producers are set up and so producer_run(NULL) makes sense. But in many cases a producer is carefully added and then producer_run(NULL) is called on all producers that are around that that point in time. It seems safer to call producer_run() on the newly added producer in those cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3189) Do not start reading data on server to user agent tunnel too soon
[ https://issues.apache.org/jira/browse/TS-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs resolved TS-3189. Resolution: Fixed Fix Version/s: 5.2.0 Do not start reading data on server to user agent tunnel too soon - Key: TS-3189 URL: https://issues.apache.org/jira/browse/TS-3189 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 The original logic would set up a do_io_read for max_int in HttpSM::attach_server_session. However, at this point there still may be things finishing up in the user_agent to server tunnel (for posts). We were seeing occasional cases of the EOS for the tunnel to user_agent communication being incorrectly delivered to the consumer of the user_agent to server tunnel. It is sufficient to set up a 0 length read in HttpSM::attach_server_session. This will enable the correct handlers to deal with inactivity timeouts. Then we can setup the real read in HttpSM::setup_server_read_response_header() after we know that the user_agent to origin server tunnel has been taken down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3190) Change producer_run() to run a specific producer in more cases
[ https://issues.apache.org/jira/browse/TS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218272#comment-14218272 ] ASF GitHub Bot commented on TS-3190: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/144 Change producer_run() to run a specific producer in more cases -- Key: TS-3190 URL: https://issues.apache.org/jira/browse/TS-3190 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 Found while tracking down TS-3105. It seemed like sometimes producers were having producer_run called on them multiple times. producer_run can be run on a particular producers or on all producers added at that point in time. There are a couple places where multiple producers are set up and so producer_run(NULL) makes sense. But in many cases a producer is carefully added and then producer_run(NULL) is called on all producers that are around that that point in time. It seems safer to call producer_run() on the newly added producer in those cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2962) header_rewrite default exists matcher not working
[
https://issues.apache.org/jira/browse/TS-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2962:
--
Fix Version/s: (was: 5.2.0)
5.3.0
header_rewrite default exists matcher not working
---
Key: TS-2962
URL: https://issues.apache.org/jira/browse/TS-2962
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 5.0.1
Reporter: Nick Muerdter
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.3.0
The
[documentation|https://docs.trafficserver.apache.org/en/latest/reference/plugins/header_rewrite.en.html#operands-to-conditions]
for the header_rewrite plugin indicates that if you don't specify a matcher
on a condition, then the matcher checks if a value exists. However, if I'm
understanding the intended behavior correctly, this is not the behavior I'm
seeing. If I don't specify an explicit matcher on the condition, then the
condition never seems to match (at least for http headers).
Here's a simplified example in a stock 5.0.1 installation that should add a
{{X-Testing}} header to the response if the {{Surrogate-Control}} header
exists on the response:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control}
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:43 GMT
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
But as you can see from this response, no such header is added.
If I change the condition to a regex match for one or more characters, then
the header gets added as I expect:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control} /.+/
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:12 GMT
X-Testing: Hello
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
The regex based approach works fine, but it took me a while to realize what
was going on and figure this out (the primary example in the documentation
also seems to be utilizing this exists logic so that also doesn't work for
me).
So if the condition without an explicit matcher should check for a variable's
existence, that doesn't seem to be working. Alternatively, if the current
behavior is working as intended, then I think the documentation and examples
might need to be updated (and if that's the case, I'd be happy to take a stab
at that).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3064) expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers
[ https://issues.apache.org/jira/browse/TS-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218509#comment-14218509 ] ASF subversion and git services commented on TS-3064: - Commit e580f0d6df9ebd9311f0428d64dba381511e890f in trafficserver's branch refs/heads/master from [~dmorilha] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e580f0d ] TS-3064 Expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers. expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers --- Key: TS-3064 URL: https://issues.apache.org/jira/browse/TS-3064 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Daniel Vitor Morilha Assignee: Leif Hedstrom Labels: review Fix For: 5.2.0 Attachments: ts3064.diff TS_EVENT_VCONN_ACTIVE_TIMEOUT = 106 is missing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3064) expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers
[ https://issues.apache.org/jira/browse/TS-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3064. --- Resolution: Fixed expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers --- Key: TS-3064 URL: https://issues.apache.org/jira/browse/TS-3064 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Daniel Vitor Morilha Assignee: Leif Hedstrom Labels: review Fix For: 5.2.0 Attachments: ts3064.diff TS_EVENT_VCONN_ACTIVE_TIMEOUT = 106 is missing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3064) expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers
[ https://issues.apache.org/jira/browse/TS-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218511#comment-14218511 ] ASF subversion and git services commented on TS-3064: - Commit 84a8c842459b9f7fb0ba80418b4f1c4dc576f0b3 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=84a8c84 ] Add TS-3064 to CHANGES. expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers --- Key: TS-3064 URL: https://issues.apache.org/jira/browse/TS-3064 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Daniel Vitor Morilha Assignee: Leif Hedstrom Labels: review Fix For: 5.2.0 Attachments: ts3064.diff TS_EVENT_VCONN_ACTIVE_TIMEOUT = 106 is missing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2959) Compiler warnings from gcc 4.9.1
[
https://issues.apache.org/jira/browse/TS-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber reassigned TS-2959:
---
Assignee: Phil Sorber (was: Susan Hinrichs)
Compiler warnings from gcc 4.9.1
Key: TS-2959
URL: https://issues.apache.org/jira/browse/TS-2959
Project: Traffic Server
Issue Type: Bug
Components: Core, DNS
Reporter: Leif Hedstrom
Assignee: Phil Sorber
Fix For: 5.2.0
Attachments: ts-2959.diff
We get:
{code}
In file included from ../../iocore/hostdb/P_HostDB.h:47:0,
from ../../proxy/Main.cc:63:
../../iocore/hostdb/P_MultiCache.h: In member function ‘void
MultiCacheC::rebuild_element(int, char*, RebuildMC) [with C = HostDBInfo]’:
../../iocore/hostdb/P_MultiCache.h:468:23: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:468:65: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:487:29: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:509:39: error: array subscript is above
array bounds [-Werror=array-bounds]
if (hits ((max_hits / 2) + 1) * elements[level])
^
../../iocore/hostdb/P_MultiCache.h:511:33: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:468:23: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:468:65: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:487:29: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:509:39: error: array subscript is above
array bounds [-Werror=array-bounds]
if (hits ((max_hits / 2) + 1) * elements[level])
^
../../iocore/hostdb/P_MultiCache.h:511:33: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:552:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:558:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++)
^
../../iocore/hostdb/P_MultiCache.h:552:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:558:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++)
^
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TS-2959) Compiler warnings from gcc 4.9.1
[
https://issues.apache.org/jira/browse/TS-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber reopened TS-2959:
-
Backport to Version: 4.2.3
Compiler warnings from gcc 4.9.1
Key: TS-2959
URL: https://issues.apache.org/jira/browse/TS-2959
Project: Traffic Server
Issue Type: Bug
Components: Core, DNS
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Fix For: 5.2.0
Attachments: ts-2959.diff
We get:
{code}
In file included from ../../iocore/hostdb/P_HostDB.h:47:0,
from ../../proxy/Main.cc:63:
../../iocore/hostdb/P_MultiCache.h: In member function ‘void
MultiCacheC::rebuild_element(int, char*, RebuildMC) [with C = HostDBInfo]’:
../../iocore/hostdb/P_MultiCache.h:468:23: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:468:65: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:487:29: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:509:39: error: array subscript is above
array bounds [-Werror=array-bounds]
if (hits ((max_hits / 2) + 1) * elements[level])
^
../../iocore/hostdb/P_MultiCache.h:511:33: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:468:23: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:468:65: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:487:29: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:509:39: error: array subscript is above
array bounds [-Werror=array-bounds]
if (hits ((max_hits / 2) + 1) * elements[level])
^
../../iocore/hostdb/P_MultiCache.h:511:33: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:552:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:558:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++)
^
../../iocore/hostdb/P_MultiCache.h:552:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:558:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++)
^
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3065) Delete the header Transfer-Encoding when the error body was set
[ https://issues.apache.org/jira/browse/TS-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218599#comment-14218599 ] ASF subversion and git services commented on TS-3065: - Commit 7b6857a27dac87bc68870bc6f53925e77c6a60de in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7b6857a ] Add TS-3065 to CHANGES Delete the header Transfer-Encoding when the error body was set - Key: TS-3065 URL: https://issues.apache.org/jira/browse/TS-3065 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: portl4t Assignee: Leif Hedstrom Labels: review Fix For: 5.2.0 Attachments: 0001-TS-3065-Delete-the-header-Transfer-Encoding-when-the.patch TSHttpTxnErrorBodySet(...) will usually be called in the plugin to set the body of the client response when error exists, but sometimes the header Transfer-Encoding will be inserted into the client response(from handle_response_keep_alive_headers(...)), and we should delete this header to indicate that the body was not chunked. = HTTP/1.1 500 INKApi Error Date: Sun, 07 Sep 2014 10:03:31 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 0 ^C HTTP/1.1 404 Not Found Date: Sun, 07 Sep 2014 10:01:35 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 12 Content-Type: text/html ^C -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3065) Delete the header Transfer-Encoding when the error body was set
[ https://issues.apache.org/jira/browse/TS-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218597#comment-14218597 ] ASF subversion and git services commented on TS-3065: - Commit 79f88d5f9d868a46b382ec5f62895b515a143936 in trafficserver's branch refs/heads/master from [~portl4t] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=79f88d5 ] TS-3065 RemoveTransfer-Encoding header when the error body was set by ATS (e.g. plugin). Delete the header Transfer-Encoding when the error body was set - Key: TS-3065 URL: https://issues.apache.org/jira/browse/TS-3065 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: portl4t Assignee: Leif Hedstrom Labels: review Fix For: 5.2.0 Attachments: 0001-TS-3065-Delete-the-header-Transfer-Encoding-when-the.patch TSHttpTxnErrorBodySet(...) will usually be called in the plugin to set the body of the client response when error exists, but sometimes the header Transfer-Encoding will be inserted into the client response(from handle_response_keep_alive_headers(...)), and we should delete this header to indicate that the body was not chunked. = HTTP/1.1 500 INKApi Error Date: Sun, 07 Sep 2014 10:03:31 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 0 ^C HTTP/1.1 404 Not Found Date: Sun, 07 Sep 2014 10:01:35 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 12 Content-Type: text/html ^C -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3065) Delete the header Transfer-Encoding when the error body was set
[ https://issues.apache.org/jira/browse/TS-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3065. --- Resolution: Fixed Delete the header Transfer-Encoding when the error body was set - Key: TS-3065 URL: https://issues.apache.org/jira/browse/TS-3065 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: portl4t Assignee: Leif Hedstrom Labels: review Fix For: 5.2.0 Attachments: 0001-TS-3065-Delete-the-header-Transfer-Encoding-when-the.patch TSHttpTxnErrorBodySet(...) will usually be called in the plugin to set the body of the client response when error exists, but sometimes the header Transfer-Encoding will be inserted into the client response(from handle_response_keep_alive_headers(...)), and we should delete this header to indicate that the body was not chunked. = HTTP/1.1 500 INKApi Error Date: Sun, 07 Sep 2014 10:03:31 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 0 ^C HTTP/1.1 404 Not Found Date: Sun, 07 Sep 2014 10:01:35 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 12 Content-Type: text/html ^C -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-2835) Remove some dead code in ParseRules
[
https://issues.apache.org/jira/browse/TS-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2835.
---
Resolution: Invalid
Fix Version/s: (was: 5.2.0)
Invalid.
Remove some dead code in ParseRules
---
Key: TS-2835
URL: https://issues.apache.org/jira/browse/TS-2835
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
I'd like to remove the #iffdef's around
{code}
COMPILE_PARSE_RULES
{code}
and
{code}
THIS_IS_THE_ORIGINAL_CODE
{code}
In the ParseRules.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3140) Traffic server crashes when there is a redirect response in cache
[ https://issues.apache.org/jira/browse/TS-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218673#comment-14218673 ] Alan M. Carroll commented on TS-3140: - What's the expected behavior here? I think that if redirect following is enabled, ATS shouldn't cache a redirect, it should follow it. Is the cache happening because the # of redirects has been exceeded? Traffic server crashes when there is a redirect response in cache - Key: TS-3140 URL: https://issues.apache.org/jira/browse/TS-3140 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 5.0.1 Reporter: zouyu Assignee: Leif Hedstrom Labels: crash, review Fix For: 5.2.0 Attachments: TS-3140.diff Traffic server will crash in below steps: 1. Enable redirect and http cache, make sure that traffic server can cache redirect request redirect response such as 302/307 response. 2. make a remap url in traffic server which will remap to a redirect url 'redirect_url_1' which points to 'www.google.com' ( note that 'www.google.com' is also a redirect url which may point to 'www.google.com.sg') 3. make number_of_redirections=1 in records.config. 4. access the 'redirect_url_1'. At first time, after access it, traffic server will cache the redirect response such as 307. 5. try to access the 'redirect_url_1' again, this time traffic server will crash. The root cause is that in above case, traffic sever will check the cache in a loop definitely which will exhausted the stack space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3140) Traffic server crashes when there is a redirect response in cache
[ https://issues.apache.org/jira/browse/TS-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3140: -- Assignee: Alan M. Carroll (was: Leif Hedstrom) Traffic server crashes when there is a redirect response in cache - Key: TS-3140 URL: https://issues.apache.org/jira/browse/TS-3140 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 5.0.1 Reporter: zouyu Assignee: Alan M. Carroll Labels: crash, review Fix For: 5.2.0 Attachments: TS-3140.diff Traffic server will crash in below steps: 1. Enable redirect and http cache, make sure that traffic server can cache redirect request redirect response such as 302/307 response. 2. make a remap url in traffic server which will remap to a redirect url 'redirect_url_1' which points to 'www.google.com' ( note that 'www.google.com' is also a redirect url which may point to 'www.google.com.sg') 3. make number_of_redirections=1 in records.config. 4. access the 'redirect_url_1'. At first time, after access it, traffic server will cache the redirect response such as 307. 5. try to access the 'redirect_url_1' again, this time traffic server will crash. The root cause is that in above case, traffic sever will check the cache in a loop definitely which will exhausted the stack space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
