[jira] Assigned: (TS-500) Less draconian checks on Content-Length: + Connection: close from origin
[
https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-500:
Assignee: Leif Hedstrom
> Less draconian checks on Content-Length: + Connection: close from origin
>
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length
> header from Origin. We have a particularly troublesome case, which breaks
> youtube and possibly other streaming media sites:
>
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is//
> // not keep-alive, we set to read until the server//
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
>
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a
> records.config option). This would obviously require extensive testing, and
> probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
>If the actual number of
>octets sent in the message is more than the indicated Content-
>Length, the recipient MUST only process the message-body up to
>the field value's number of octets; the remainder of the message
>MUST either be discarded or treated as the next message in a
>pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-494) SSL over ATS sending partial certificate chain
[
https://issues.apache.org/jira/browse/TS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-494.
--
Resolution: Fixed
> SSL over ATS sending partial certificate chain
> ---
>
> Key: TS-494
> URL: https://issues.apache.org/jira/browse/TS-494
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 2.1.3
>Reporter: vijaya bhaskar mamidi
> Fix For: 2.1.4
>
>
> ATS is sending only the first certificate block from the file configured
> under the "proxy.config.ssl.server.cert_chain.filename" setting in
> records.config.
> Code in SSLNet.cc
> int
> SSL_CTX_add_extra_chain_cert_file(SSL_CTX * ctx, const char *file)
> {
> BIO *in;
> int j;
> int ret = 0;
> X509 *x = NULL;
> in = BIO_new(BIO_s_file_internal());
> if (in == NULL) {
> SSLerr(SSL_F_SSL_USE_CERTIFICATE_FILE, ERR_R_BUF_LIB);
> goto end;
> }
> if (BIO_read_filename(in, file) <= 0) {
> SSLerr(SSL_F_SSL_USE_CERTIFICATE_FILE, ERR_R_SYS_LIB);
> goto end;
> }
> j = ERR_R_PEM_LIB;
> x = PEM_read_bio_X509(in, NULL, ctx->default_passwd_callback,
> ctx->default_passwd_callback_userdata);
> if (x == NULL) {
> SSLerr(SSL_F_SSL_USE_CERTIFICATE_FILE, j);
> goto end;
> }
> ret = SSL_CTX_add_extra_chain_cert(ctx, x);
> end:
> // if (x != NULL) X509_free(x);
> if (in != NULL)
> BIO_free(in);
> return (ret);
> }
> should loop across all the cert and the code should be:
> while ((x = PEM_read_bio_X509(in, NULL, ctx->default_passwd_callback,
> ctx->default_passwd_callback_userdata)) != NULL) {
> ret = SSL_CTX_add_extra_chain_cert(ctx, x);
> if (!ret) {
> X509_free(x);
> BIO_free(in);
>return -1;
> }
>}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-506) Poor performance on proxied requests which are not cacheable.
[
https://issues.apache.org/jira/browse/TS-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-506:
-
Fix Version/s: (was: 2.1.4)
2.1.5
> Poor performance on proxied requests which are not cacheable.
> -
>
> Key: TS-506
> URL: https://issues.apache.org/jira/browse/TS-506
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Leif Hedstrom
> Fix For: 2.1.5
>
>
> This is a problem similar in behavior and how to reproduce as TS-505.
> I have a test setup using lighttpd (stock config, but with the port changed
> to port 82, and logging disabled). I've also disabled Keep-Alive on lighttpd,
> with a line like this in /etc/lighttpd/lighttpd.conf
> server.max-keep-alive-requests = 0
> I've created a small file (42 bytes) in /var/www/lighttpd/cl-test.html.
> I'm running Apache TS with a stock config ("gmake install") with the
> following configuration changes:
> records.config:
> ---
> CONFIG proxy.config.http.server_port INT 80
> CONFIG proxy.config.http.cache.required_headers INT 2
> CONFIG proxy.config.log2.logging_enabled INT 0
> remap.config:
> -
> map http://loki.ogre.com/lighttpd/ http://localhost:82/
> I'm "benchmarking" this using "ab" from a second host, running a command like
> ab -c 20 -n 1 http://loki.ogre.com/lighttpd/cl-test.html
> Test 1: http caching is disabled with a records.config setting
> CONFIG proxy.config.http.cache.http INT 0
> Results:
> Requests per second:9319.75 [#/sec] (mean)
> Time per request: 2.146 [ms] (mean)
> Time per request: 0.107 [ms] (mean, across all concurrent requests)
> Test 2: http caching enabled, records.config is
> CONFIG proxy.config.http.cache.http INT 0
> Results:
> Requests per second:2967.59 [#/sec] (mean)
> Time per request: 6.739 [ms] (mean)
> Time per request: 0.337 [ms] (mean, across all concurrent requests)
> So, simply enabling the cache makes it process 3x less QPS and at 3x the
> latency. There is again no disk I/O on either of these tests.
> If I "combine" the worst case scenario, from TS-505 and this bug, and run the
> test with http.cache=1 (cache enabled) and have the lighttpd server send
> Connection: keep-alive responses, the performance plunges:
> Requests per second:173.09 [#/sec] (mean)
> Time per request: 115.548 [ms] (mean)
> Time per request: 5.777 [ms] (mean, across all concurrent requests)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-402) Add WCCP support
[ https://issues.apache.org/jira/browse/TS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-402: - Fix Version/s: (was: 2.1.4) 2.1.5 > Add WCCP support > > > Key: TS-402 > URL: https://issues.apache.org/jira/browse/TS-402 > Project: Traffic Server > Issue Type: New Feature > Components: Network >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 2.1.5 > > > Allow ATS to communicate via WCCP as an optional feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-500) Less draconian checks on Content-Length: + Connection: close from origin
[
https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927498#action_12927498
]
Leif Hedstrom commented on TS-500:
--
I'm still examining this "issue" and have found a number of interesting
"problems" (separate bugs filed). I hope to have my analysis done today or
tomorrow, and come up with a recommendation.
> Less draconian checks on Content-Length: + Connection: close from origin
>
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length
> header from Origin. We have a particularly troublesome case, which breaks
> youtube and possibly other streaming media sites:
>
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is//
> // not keep-alive, we set to read until the server//
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
>
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a
> records.config option). This would obviously require extensive testing, and
> probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
>If the actual number of
>octets sent in the message is more than the indicated Content-
>Length, the recipient MUST only process the message-body up to
>the field value's number of octets; the remainder of the message
>MUST either be discarded or treated as the next message in a
>pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-228) Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use "long" anywhere in TS
[ https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-228: - Fix Version/s: (was: 2.1.4) 2.1.5 > Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we > shoud not use "long" anywhere in TS > > > Key: TS-228 > URL: https://issues.apache.org/jira/browse/TS-228 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: John Plevyak >Assignee: John Plevyak >Priority: Critical > Fix For: 2.1.5 > > > Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit. > This is a potential can of worms which at the least is making records.snap > incompatible but at worse could be the cause of other bugs. > In any case we should not be using "long" in the TS code, but instead use > either "int" which is always 32-bits or "inkXXX" of a particular size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-505) Worse performance when Origin server sends Connection: keep-alive
[
https://issues.apache.org/jira/browse/TS-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-505:
-
Fix Version/s: (was: 2.1.4)
2.1.5
> Worse performance when Origin server sends Connection: keep-alive
> -
>
> Key: TS-505
> URL: https://issues.apache.org/jira/browse/TS-505
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Leif Hedstrom
> Fix For: 2.1.5
>
>
> I have a test setup using lighttpd (stock config, but with the port changed
> to port 82, and logging disabled). I've created a small file (42 bytes) in
> /var/www/lighttpd/cl-test.html.
> I'm running Apache TS with a stock config ("gmake install") with the
> following configuration changes:
> records.config:
> ---
> CONFIG proxy.config.http.server_port INT 80
> CONFIG proxy.config.http.cache.required_headers INT 2
> CONFIG proxy.config.log2.logging_enabled INT 0
> remap.config:
> -
> map http://loki.ogre.com/lighttpd/ http://localhost:82/
> I'm "benchmarking" this using "ab" from a second host, running a command like
> ab -c 20 -n 1 http://loki.ogre.com/lighttpd/cl-test.html
> Test 1: I disable Keep-Alive in lighttpd, adding a configuration like this to
> /etc/lighttpd/lighttpd.conf:
> server.max-keep-alive-requests = 0
> Test results are
> Requests per second:9056.01 [#/sec] (mean)
> Time per request: 2.208 [ms] (mean)
> Time per request: 0.110 [ms] (mean, across all concurrent requests)
> Test 2: I enable Keep-Alive in lighttpd, with
> server.max-keep-alive-requests = 100
> Test results are:
> Requests per second:4456.33 [#/sec] (mean)
> Time per request: 4.488 [ms] (mean)
> Time per request: 0.224 [ms] (mean, across all concurrent requests)
> This might not seem like a huge difference, but why would it be serving 2x
> fewer QPS and 2x the latency with keep-alive to the origin server? If
> anything, I'd expect it to be faster with keep-alive, right ? Shouldn't that
> be noticeably less work?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-492) Allow use of client supplied IP address for origin server.
[ https://issues.apache.org/jira/browse/TS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-492: - Fix Version/s: (was: 2.1.4) 2.1.5 > Allow use of client supplied IP address for origin server. > -- > > Key: TS-492 > URL: https://issues.apache.org/jira/browse/TS-492 > Project: Traffic Server > Issue Type: New Feature > Components: DNS >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Fix For: 2.1.5 > > > When operating in transparent mode, the IP address of the origin server is > available from the client socket connection. This enhancement would add a > switch (default to false) that would use that IP address rather than doing a > host DB or DNS lookup *if* the URL had not been modified. If the URL is > modified (remapped) then the lookup would proceed, ignoring this > configuration flag. > This not only enhances performance but also is required for certain websites > that embed the IP address of the origin server in the exchange and use DNS > switching for performance. In that case ATS can connect to a different origin > server than the client intended, leading to a protocol failure. One prominent > example is Microsoft Windows update. > For now, this switch can be turned on globally and disabled locally by > creating identity mappings for the exceptions. It may be desirable at some > point to be able to specifically disable it rather then depend on the > serendipitous effects of remapping. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-435) SplitDNS doesn't work
[
https://issues.apache.org/jira/browse/TS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-435:
-
Fix Version/s: (was: 2.1.4)
2.1.5
> SplitDNS doesn't work
> -
>
> Key: TS-435
> URL: https://issues.apache.org/jira/browse/TS-435
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Affects Versions: 2.0.1
> Environment: Debian 5.0.5 kernel 2.6.26-1-686 #1 SMP
>Reporter: Martin Leventan
>Assignee: Leif Hedstrom
>Priority: Trivial
> Fix For: 2.1.5
>
>
> Server configured as forward proxy with SplitDNS enable. At start get system
> DNS server but at client request fail to resolve URL.
> record.config (DNS section)
> CONFIG proxy.config.dns.search_default_domains INT 1
> CONFIG proxy.config.dns.splitDNS.enabled INT 1
> CONFIG proxy.config.dns.splitdns.def_domain STRING lapampa.gov.ar
> CONFIG proxy.config.dns.url_expansions STRING NULL
> CONFIG proxy.config.dns.round_robin_nameservers INT 0
> CONFIG proxy.config.dns.nameservers STRING NULL
> CONFIG proxy.config.dns.validate_query_name INT 0
> splitdns.config
> dest_domain=lapampa.gov.ar named=10.2.1.72 serach_list=lapampa.gov.ar
> Debug:
> [TrafficServer] using root directory '/opt/trafficserver-2'
> [Sep 8 11:55:57.512] {3079767744} STATUS: opened
> var/log/trafficserver/diags.log
> [Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Config: "etc/trafficserver/ae_ua.config"
> [Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Opening config
> "etc/trafficserver/ae_ua.config"
> [Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
> [Sep 8 11:55:57.514] Server {3079767744} DEBUG: (http_aeua)
> [init_http_aeua_filter] - Total loaded 0 REGEXP for
> Accept-Enconding/User-Agent filtering
> [Sep 8 11:55:57.548] Server {3079767744} DEBUG: (dns) ink_dns_init: called
> with init_called = 0
> [Sep 8 11:55:57.587] Server {3079767744} DEBUG: (dns)
> localhost=h6514asi106.glp.gov.ar
> [Sep 8 11:55:57.587] Server {3079767744} DEBUG: (dns) Round-robin
> nameservers = 0
> [Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns)
> DNSHandler::startEvent_sdns: on thread2
> [Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) open_con: opening
> connection 10.2.1.73:53
> [Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) random port = 17507
> [Sep 8 11:55:57.616] Server {3062635408} DEBUG: (dns) opening connection
> 10.2.1.73:53 SUCCEEDED for 0
> [Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns)
> DNSHandler::startEvent_sdns: on thread1
> [Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) open_con: opening
> connection 10.2.1.73:53
> [Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) random port = 42681
> [Sep 8 11:55:57.616] Server {3063688080} DEBUG: (dns) opening connection
> 10.2.1.73:53 SUCCEEDED for 0
> [Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
> proxy.config.connection_collapsing.hashtable_enabled = 0
> [Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
> proxy.config.connection_collapsing.rww_wait_time = 0
> [Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
> proxy.config.connection_collapsing.revalidate_window_period = 0
> [Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
> proxy.config.http.redirection_enabled = 0
> [Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
> proxy.config.http.number_of_redirections = 1
> [Sep 8 11:55:57.690] Server {3079767744} DEBUG: (http_init)
> proxy.config.http.post_copy_size = 2048
> [Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns)
> DNSHandler::startEvent: on thread0
> [Sep 8 11:55:57.713] Server {3079767744} DEBUG: (dns) open_con: opening
> connection 10.2.1.73:53
> [Sep 8 11:55:57.715] Server {3079767744} DEBUG: (dns) random port = 40576
> [Sep 8 11:55:57.715] Server {3079767744} DEBUG: (dns) opening connection
> 10.2.1.73:53 SUCCEEDED for 0
> .
> + Incoming Request +
> -- State Machine Id: 0
> GET http://www.lapampa.gov.ar/ HTTP/1.1^M
> Host: www.lapampa.gov.ar^M
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19)
> Gecko/2010072023 Iceweasel/3.0.6 (Debian-3.0.6-3)^M
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
> Accept-Language: en-us,en;q=0.5^M
> Accept-Encoding: gzip,deflate^M
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7^M
> Keep-Alive: 300^M
> Proxy-Connection: keep-alive^M
> Cookie: LaPampa2_tpl=LaPampa2^M
> Cache-Control: max-age=0^M
> ^M
> [Sep 8 11:56:01.134] Server {3079767744} DEBUG: (http_trans)
> [DecideCacheLookup] Will do cache lookup.
> [Sep 8 11:56:01.134] Server {3079767744} DEBUG: (http_seq)
> [DecideCacheLook
[jira] Resolved: (TS-14) InkAPI is not 64-bit clean
[ https://issues.apache.org/jira/browse/TS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-14. - Resolution: Fixed > InkAPI is not 64-bit clean > -- > > Key: TS-14 > URL: https://issues.apache.org/jira/browse/TS-14 > Project: Traffic Server > Issue Type: Bug > Components: InkAPI >Affects Versions: 2.0.0a > Environment: x86_64 linux >Reporter: John Plevyak >Assignee: Leif Hedstrom > Fix For: 2.1.4 > > Attachments: TS-14.diff > > > This is different than the 64-bit port in that it effects the public API. In > particular there are functions which use 'int' where they should be using > other types for things like sizes which could exceed 2^32, the 'int' size > even on 64-bit linux. Specifically: > api/include/InkAPI.h: inkapi int INKfread(INKFile filep, void *buf, int > length); > But a full review of the API should be conducted and the types updated. In > this case inku64, ink_off_t or most likely size_t would > be more appropriate. All of these are 64-bit on 64-bit linux. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-357) Compiling with -Wconversion generates a lot of errors
[ https://issues.apache.org/jira/browse/TS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-357: - Fix Version/s: (was: 2.2.0) 2.3.0 > Compiling with -Wconversion generates a lot of errors > - > > Key: TS-357 > URL: https://issues.apache.org/jira/browse/TS-357 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: Bryan Call > Fix For: 2.3.0 > > > After adding -Wconversion to CFLAGS and CXXFLAGS I got 11k errors: > [bc...@snowball traffic.git]$ gmake -k 2> /dev/stdout | grep -c ' error: ' > 11432 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-172) REGRESSION_RESULT SDK_API_HttpTxnTransform: FAILED
[
https://issues.apache.org/jira/browse/TS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-172:
-
Fix Version/s: (was: 2.2.0)
2.3.0
> REGRESSION_RESULT SDK_API_HttpTxnTransform: FAILED
> --
>
> Key: TS-172
> URL: https://issues.apache.org/jira/browse/TS-172
> Project: Traffic Server
> Issue Type: Bug
> Components: InkAPI
>Affects Versions: 2.0.0a
> Environment: All
>Reporter: George Paul
>Priority: Minor
> Fix For: 2.3.0
>
>
> The following SDK API regression tests fails.
> env
> TS_ROOT=/home/georgep/projects/apache/trafficserver/git_trunk_TS74/trafficserver/ubuntu904/test_dir/usr/local
> ./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpTxnTransform
> REGRESSION_TEST initialization begun
> REGRESSION TEST SDK_API_HttpTxnTransform started
> [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { ok }
> [SDK_API_HttpTxnTransform] INKHttpTxnTransformRespGet : [TestCase] <> {
> ok }
> [SDK_API_HttpTxnTransform] INKHttpTxnTransformRespGet : [TestCase] <> {
> ok }
> [SDK_API_HttpTxnTransform] INKHttpTxnUntransformedResponseCache : [TestCase1]
> <> { ok }
> [SDK_API_HttpTxnTransform] INKHttpTxnTransformedResponseCache : [TestCase1]
> <> { Value's Mismatch }
> [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did
> not pass transformed_resp_cache }
> REGRESSION_RESULT SDK_API_HttpTxnTransform:FAILED
> REGRESSION_TEST DONE: FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-340) EC2 Updates/Testing/Building
[ https://issues.apache.org/jira/browse/TS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-340: - Fix Version/s: (was: 2.2.0) 2.3.0 > EC2 Updates/Testing/Building > > > Key: TS-340 > URL: https://issues.apache.org/jira/browse/TS-340 > Project: Traffic Server > Issue Type: Bug > Components: Build, Portability >Affects Versions: 2.0.0a > Environment: EC2 >Reporter: Jason Giedymin >Assignee: Jason Giedymin >Priority: Minor > Fix For: 2.3.0 > > > 1.) More Lucid Testing > 2.) Rebuild with latest ATS Release > 3.) Seed to West, EU, Asia datacenters (20 Images in total, > Fedora/Ubuntu9/Ubuntu10/32/64) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-362) Create packaging scripts for TrafficServer
[ https://issues.apache.org/jira/browse/TS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-362: - Fix Version/s: (was: 2.2.0) 2.3.0 > Create packaging scripts for TrafficServer > -- > > Key: TS-362 > URL: https://issues.apache.org/jira/browse/TS-362 > Project: Traffic Server > Issue Type: New Feature > Components: Packaging > Environment: Linux, Solaris >Reporter: Mladen Turk >Assignee: Mladen Turk >Priority: Minor > Fix For: 2.3.0 > > Original Estimate: 504h > Remaining Estimate: 504h > > Create pkg directory build/pkg with sub-directories for rpm and pkg > This will allow to create .rpm and Solaris .package.gz platform native > installation packages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-192) REGRESSION_RESULT SDK_API_HttpSsn: FAILED
[ https://issues.apache.org/jira/browse/TS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-192: - Fix Version/s: (was: 2.2.0) 2.3.0 > REGRESSION_RESULT SDK_API_HttpSsn: FAILED > - > > Key: TS-192 > URL: https://issues.apache.org/jira/browse/TS-192 > Project: Traffic Server > Issue Type: Bug > Components: InkAPI >Affects Versions: 2.0.0a > Environment: All >Reporter: George Paul >Priority: Minor > Fix For: 2.3.0 > > > The following SDK API regression tests fails. This did not happen before, but > testing on older SVN revision (r909505) has shown it existed when working on > TS-74. Possibly a timing issue in the test. > env > TS_ROOT=/home/georgep/projects/apache/trafficserver/svn_trunk_r909505/traffic/ubuntu904/test_dir/usr/local > ./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpSsn > REGRESSION_TEST initialization begun > REGRESSION TEST SDK_API_HttpSsn started > REGRESSION_RESULT SDK_API_HttpSsn: FAILED > REGRESSION_TEST DONE: FAILED -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-53) remove old management code
[ https://issues.apache.org/jira/browse/TS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-53: Fix Version/s: (was: 2.2.0) 2.3.0 > remove old management code > -- > > Key: TS-53 > URL: https://issues.apache.org/jira/browse/TS-53 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Bryan Call >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 2.3.0 > > > Remove old management code that we won't use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-173) REGRESSION_RESULT SDK_API_HttpTxnCache: FAILED
[
https://issues.apache.org/jira/browse/TS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-173:
-
Fix Version/s: (was: 2.2.0)
2.3.0
> REGRESSION_RESULT SDK_API_HttpTxnCache: FAILED
> --
>
> Key: TS-173
> URL: https://issues.apache.org/jira/browse/TS-173
> Project: Traffic Server
> Issue Type: Bug
> Components: InkAPI
>Affects Versions: 2.0.0a
> Environment: All
>Reporter: George Paul
>Priority: Minor
> Fix For: 2.3.0
>
>
> The following SDK API regression tests fails.
> env
> TS_ROOT=/home/georgep/projects/apache/trafficserver/git_trunk_TS74/trafficserver/ubuntu904/test_dir/usr/local
> ./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpTxnCache
> REGRESSION_TEST initialization begun
> REGRESSION TEST SDK_API_HttpTxnCache started
> [SDK_API_HttpTxnCache] INKHttpTxnCacheLookupStatusGet : [TestCase1] <>
> { ok }
> [SDK_API_HttpTxnCache] INKHttpTxnCacheLookupStatusGet : [TestCase2] <>
> { Incorrect Value returned by INKHttpTxnCacheLookupStatusGet }
> REGRESSION_RESULT SDK_API_HttpTxnCache:FAILED
> REGRESSION_TEST DONE: FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-378) FIx the strict-aliasing rules warnings
[
https://issues.apache.org/jira/browse/TS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-378:
-
Fix Version/s: (was: 2.2.0)
2.3.0
> FIx the strict-aliasing rules warnings
> --
>
> Key: TS-378
> URL: https://issues.apache.org/jira/browse/TS-378
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Affects Versions: 2.2.0
>Reporter: Mladen Turk
>Assignee: Mladen Turk
>Priority: Minor
> Fix For: 2.3.0
>
>
> Currently the compile fails with -fstrict-aliasing.
> The reason is mostly using int pointers to read or write 64 bit numbers
> Eg. INK_MD5.cc has
> struct INK_MD5
> {
> uint64 b[2];
> uint32 word(int i)
> {
> uint32 *p = (uint32 *) & b[0];
> return p[i];
> }
> ...
> };
> Such things can be easily fixed and properly handled using unions
> (they are invented for that)
> struct INK_MD5
> {
> union {
> uint64 q[2];
> uint32 u[4];
> unsigned char b[16];
> } s;
> uint32 word(int i)
> {
> return s.w[i];
> }
> ...
> };
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-341) Update Contrib Scripts
[ https://issues.apache.org/jira/browse/TS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-341: - Fix Version/s: (was: 2.2.0) 2.3.0 > Update Contrib Scripts > -- > > Key: TS-341 > URL: https://issues.apache.org/jira/browse/TS-341 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 2.0.0 > Environment: EC2 >Reporter: Jason Giedymin >Assignee: Jason Giedymin >Priority: Minor > Fix For: 2.3.0 > > > - The EC2 images i created last month had updates to the contrib scripts > which need to be synced with the source repo. > - Need to udpate the scripts to point to the source repo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-171) REGRESSION_RESULT SDK_API_HttpAltInfo: FAILED
[
https://issues.apache.org/jira/browse/TS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-171:
-
Fix Version/s: (was: 2.2.0)
2.3.0
> REGRESSION_RESULT SDK_API_HttpAltInfo: FAILED
> -
>
> Key: TS-171
> URL: https://issues.apache.org/jira/browse/TS-171
> Project: Traffic Server
> Issue Type: Bug
> Components: InkAPI
>Affects Versions: 2.0.0a
> Environment: All
>Reporter: George Paul
>Priority: Minor
> Fix For: 2.3.0
>
>
> The following SDK API regression tests fails.
> env
> TS_ROOT=/home/georgep/projects/apache/trafficserver/git_trunk_TS74/trafficserver/ubuntu904/test_dir/usr/local
> ./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpAltInfo
> REGRESSION_TEST initialization begun
> REGRESSION TEST SDK_API_HttpAltInfo started
> [SDK_API_HttpAltInfo] INKHttpAltInfo : [All] <> { Test not executed
> even once }
> REGRESSION_RESULT SDK_API_HttpAltInfo: FAILED
> REGRESSION_TEST DONE: FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-174) REGRESSION_RESULT SDK_API_HttpHookAdd: FAILED
[
https://issues.apache.org/jira/browse/TS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-174:
-
Fix Version/s: (was: 2.2.0)
2.3.0
> REGRESSION_RESULT SDK_API_HttpHookAdd: FAILED
> -
>
> Key: TS-174
> URL: https://issues.apache.org/jira/browse/TS-174
> Project: Traffic Server
> Issue Type: Bug
> Components: InkAPI
>Affects Versions: 2.0.0a
> Environment: All
>Reporter: George Paul
>Priority: Minor
> Fix For: 2.3.0
>
>
> The following SDK API regression tests fails.
> env
> TS_ROOT=/home/georgep/projects/apache/trafficserver/git_trunk_TS74/trafficserver/ubuntu904/test_dir/usr/local
> ./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpHookAdd
> REGRESSION_TEST initialization begun
> REGRESSION TEST SDK_API_HttpHookAdd started
> [SDK_API_HttpHookAdd] INKHttpTxnClientReqGet : [TestCase1] <> { ok }
> [SDK_API_HttpHookAdd] INKHttpTxnClientIncomingPortGet : [TestCase1] <>
> { ok }
> [SDK_API_HttpHookAdd] INKHttpTxnClientRemotePortGet : [TestCase1] <> {
> ok }
> [SDK_API_HttpHookAdd] INKHttpTxnClientIPGet : [TestCase1] <> { ok }
> [SDK_API_HttpHookAdd] INKHttpTxnServerIPGet : [TestCase1] <> { ok }
> [SDK_API_HttpHookAdd] INKHttpTxnServerReqGet : [TestCase1] <> { ok }
> [SDK_API_HttpHookAdd] INKHttpTxnNextHopIPGet : [TestCase1] <> { ok }
> [SDK_API_HttpHookAdd] INKHttpTxnServerRespGet : [TestCase1] <> { ok }
> [SDK_API_HttpHookAdd] INKHttpTxnClientRespGet : [TestCase1] <> { ok }
> [SDK_API_HttpHookAdd] INKHttpHookAdd : [TestCase1] <> { Hooks not
> called or request failure. Hook mask = 7 }
> [SDK_API_HttpHookAdd] INKHttpTxnReenable : [TestCase1] <> { ok }
> REGRESSION_RESULT SDK_API_HttpHookAdd: FAILED
> REGRESSION_TEST DONE: FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-501) http.current_server_connections can get way too large
[ https://issues.apache.org/jira/browse/TS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-501. -- Resolution: Fixed > http.current_server_connections can get way too large > - > > Key: TS-501 > URL: https://issues.apache.org/jira/browse/TS-501 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.0.0 >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Blocker > Fix For: 2.1.4 > > Attachments: TS-501.diff > > > We're not doing the correct increment on a few counters, using a different > API compared to how we decement those counters. This has the effect that the > counter can get out of whack, causing all sorts of interesting behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
