[jira] [Created] (TS-3450) rename header_rewrite condition INTERNAL-TRANSACTION as INTERNAL-TXN
Sudheer Vinukonda created TS-3450:
-
Summary: rename header_rewrite condition INTERNAL-TRANSACTION as
INTERNAL-TXN
Key: TS-3450
URL: https://issues.apache.org/jira/browse/TS-3450
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
TS-2834 adds a condition {{INTERNAL-TRANSACTION}}. To make it consistent with
the general {{txn}} usage in the ATS source and make the condition shorter to
type :), [~zwoop] suggested to duplicate the condition with {{INTERNAL-TXN}}
and eventually retire the longer form condition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3449) Create a dup TS API of TSHttpIsInternalRequest with name TSHttpIsInternalTransaction
[ https://issues.apache.org/jira/browse/TS-3449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3449: -- Affects Version/s: 5.3.0 Fix Version/s: 5.3.0 Create a dup TS API of TSHttpIsInternalRequest with name TSHttpIsInternalTransaction Key: TS-3449 URL: https://issues.apache.org/jira/browse/TS-3449 Project: Traffic Server Issue Type: Improvement Components: TS API Affects Versions: 5.3.0 Reporter: Sudheer Vinukonda Fix For: 5.3.0 [~zwoop] noticed that the naming of the API TSHttpIsInternalRequest() is a little bit confusing, since it takes in a txnp parameter. It would perhaps be clearer if the API were called TSHttpIsInternalTransaction. (incidentally, there's a condition in header_rewrite plugin that is also named INTERNAL-TRANSACTION - TS-2834). To remove the confusion, Leif suggested to duplicate the existing TS API TSHttpIsInternalRequest() as TSHttpIsInternalTransaction() and eventually retire the TSHttpIsInternalRequest() API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3449) Create a dup TS API of TSHttpIsInternalRequest with name TSHttpIsInternalTransaction
Sudheer Vinukonda created TS-3449: - Summary: Create a dup TS API of TSHttpIsInternalRequest with name TSHttpIsInternalTransaction Key: TS-3449 URL: https://issues.apache.org/jira/browse/TS-3449 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Sudheer Vinukonda [~zwoop] noticed that the naming of the API TSHttpIsInternalRequest() is a little bit confusing, since it takes in a txnp parameter. It would perhaps be clearer if the API were called TSHttpIsInternalTransaction. (incidentally, there's a condition in header_rewrite plugin that is also named INTERNAL-TRANSACTION - TS-2834). To remove the confusion, Leif suggested to duplicate the existing TS API TSHttpIsInternalRequest() as TSHttpIsInternalTransaction() and eventually retire the TSHttpIsInternalRequest() API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3450) rename header_rewrite condition INTERNAL-TRANSACTION as INTERNAL-TXN
[
https://issues.apache.org/jira/browse/TS-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3450:
--
Affects Version/s: 5.3.0
Fix Version/s: 5.3.0
rename header_rewrite condition INTERNAL-TRANSACTION as INTERNAL-TXN
-
Key: TS-3450
URL: https://issues.apache.org/jira/browse/TS-3450
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Affects Versions: 5.3.0
Reporter: Sudheer Vinukonda
Fix For: 5.3.0
TS-2834 adds a condition {{INTERNAL-TRANSACTION}}. To make it consistent with
the general {{txn}} usage in the ATS source and make the condition shorter to
type :), [~zwoop] suggested to duplicate the condition with {{INTERNAL-TXN}}
and eventually retire the longer form condition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3443) Configure openssl 1.0.2 tls1.h detection faulty
[ https://issues.apache.org/jira/browse/TS-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365314#comment-14365314 ] Susan Hinrichs commented on TS-3443: The fix looks fine to me as well. It is odd that we don't see this issue with custom built openssl 1.0.2. Configure openssl 1.0.2 tls1.h detection faulty --- Key: TS-3443 URL: https://issues.apache.org/jira/browse/TS-3443 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Felix Buenemann Fix For: 6.0.0 The configure check for tls1.h fails, because at least on openssl 1.0.2 tls1.h depends on a macro from openssl/safestack.h. I've created [pull request #180 on github|https://github.com/apache/trafficserver/pull/180] to fix the detection by including openssl/ssl.h in the configure check, which in turn includes safestack.h. Given that ssl.h is already required that solution should be fully backwards compatible to older versions that might not require safestack.h. This problem affects at least master and 5.2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366620#comment-14366620 ] Bin commented on TS-3427: - It's been pretty crazy lately. atscppapi_out_of_tree_2.diff finally arrived. compilation error of atscppapi when configured for a out-of-tree build -- Key: TS-3427 URL: https://issues.apache.org/jira/browse/TS-3427 Project: Traffic Server Issue Type: Bug Components: Build, CPP API Reporter: Bin Assignee: Brian Geffon Fix For: 6.0.0 Attachments: atscppapi_3.diff, atscppapi_out_of_tree_2.diff, unused_variables.diff Header file not found error when --enable-cppapi is enabled for an out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin updated TS-3427: Attachment: atscppapi_out_of_tree_2.diff compilation error of atscppapi when configured for a out-of-tree build -- Key: TS-3427 URL: https://issues.apache.org/jira/browse/TS-3427 Project: Traffic Server Issue Type: Bug Components: Build, CPP API Reporter: Bin Assignee: Brian Geffon Fix For: 6.0.0 Attachments: atscppapi_3.diff, atscppapi_out_of_tree_2.diff, unused_variables.diff Header file not found error when --enable-cppapi is enabled for an out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support
[
https://issues.apache.org/jira/browse/TS-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364576#comment-14364576
]
Masaori Koshiba edited comment on TS-3216 at 3/17/15 6:08 AM:
--
[~jpe...@apache.org], thanks for rewiew.
I agree with that I should avoid making {{ssl_multicert.config}} more complex.
{quote}
It assumes that there is only 1 backup pin, the backup pin is contained in a
CSR, and that the CSR is available to ATS. All of these assumptions seem shaky
to me.
{quote}
Do you mean even if there are 2 cert settings in {{ssl_multicert.config}}, only
one backup pin is enough?
I thought adding HPKP setting in {{records.config}} like HSTS at first.
But, AFAIU, when we have 2 certs, each certs needs different CSRs to generate
backup pins.
Because when current cert is expired, current pin and backup pin is cached in
browser,
so we have to generate new cert from CSR which used to generate backup pin.
This is why I add HPKP settings in {{ssl_multicert.config}}.
was (Author: masaori):
[~jpe...@apache.org], thanks for rewiew.
I agree with that I should avoid making {{ssl_multicert.config}} more complex.
It assumes that there is only 1 backup pin, the backup pin is contained in a
CSR,
and that the CSR is available to ATS. All of these assumptions seem shaky to
me.
Do you mean even if there are 2 cert settings in {{ssl_multicert.config}}, only
one backup pin is enough?
I thought adding HPKP setting in {{records.config}} like HSTS at first.
But, AFAIU, when we have 2 certs, each certs needs different CSRs to generate
backup pins.
Because when current cert is expired, current pin and backup pin is cached in
browser,
so we have to generate new cert from CSR which used to generate backup pin.
This is why I add HPKP settings in {{ssl_multicert.config}}.
Add HPKP (Public Key Pinning Extension for HTTP) support
Key: TS-3216
URL: https://issues.apache.org/jira/browse/TS-3216
Project: Traffic Server
Issue Type: New Feature
Components: SSL
Reporter: Masaori Koshiba
Assignee: James Peach
Labels: review
Fix For: 6.0.0
Attachments: hpkp-001.patch, hpkp-002.patch
Add Public Key Pinning Extension for HTTP Support in Traffic Server.
Public Key Pinning Extension for HTTP (draft-ietf-websec-key-pinning-21)
- https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
[
https://issues.apache.org/jira/browse/TS-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365956#comment-14365956
]
Brian Geffon commented on TS-3424:
--
Ok since [~shinrich] created TS-3451, let's close this guy out with the
intention of backporting to 5.2.x, sound good?
SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
--
Key: TS-3424
URL: https://issues.apache.org/jira/browse/TS-3424
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff,
ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff,
undo-handshake-buffer.diff
Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in
{{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see
the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
record mac}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
[
https://issues.apache.org/jira/browse/TS-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365958#comment-14365958
]
Leif Hedstrom commented on TS-3424:
---
[~briang] Sounds good. Since there's a long thread here, can you summarize what
git commits (just the UUID) should be back ported to 5.2.1 please?
SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
--
Key: TS-3424
URL: https://issues.apache.org/jira/browse/TS-3424
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff,
ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff,
undo-handshake-buffer.diff
Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in
{{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see
the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
record mac}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366071#comment-14366071
]
Dzmitry Markovich commented on TS-3312:
---
[~zwoop], [~briang] - i fixed the naming and attached a patch.
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive3.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3452) Better debug messages for SSL_ERROR_SSL errors
[ https://issues.apache.org/jira/browse/TS-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366157#comment-14366157 ] ASF subversion and git services commented on TS-3452: - Commit 49d0ef822c097c83b9714dfc7ef7c7932c1ed935 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=49d0ef8 ] TS-3452: Better debug messages for SSL_ERROR_SSL: update changes Better debug messages for SSL_ERROR_SSL errors -- Key: TS-3452 URL: https://issues.apache.org/jira/browse/TS-3452 Project: Traffic Server Issue Type: Bug Components: Core, SSL Reporter: Brian Geffon Fix For: 5.3.0 In the case of SSL_ERROR_SSL we can log better information, I'll drop in a patch to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3452) Better debug messages for SSL_ERROR_SSL errors
[ https://issues.apache.org/jira/browse/TS-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-3452: Assignee: Brian Geffon Better debug messages for SSL_ERROR_SSL errors -- Key: TS-3452 URL: https://issues.apache.org/jira/browse/TS-3452 Project: Traffic Server Issue Type: Bug Components: Core, SSL Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.3.0 In the case of SSL_ERROR_SSL we can log better information, I'll drop in a patch to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3452) Better debug messages for SSL_ERROR_SSL errors
[ https://issues.apache.org/jira/browse/TS-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366156#comment-14366156 ] ASF subversion and git services commented on TS-3452: - Commit 6cd3e45c9d8cc579f0bdc4dbd99b10aeb6438e1a in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6cd3e45 ] TS-3452: Better debug messages for SSL_ERROR_SSL Better debug messages for SSL_ERROR_SSL errors -- Key: TS-3452 URL: https://issues.apache.org/jira/browse/TS-3452 Project: Traffic Server Issue Type: Bug Components: Core, SSL Reporter: Brian Geffon Fix For: 5.3.0 In the case of SSL_ERROR_SSL we can log better information, I'll drop in a patch to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Build failed in Jenkins: out_of_tree-master #646
See https://ci.trafficserver.apache.org/job/out_of_tree-master/646/changes Changes: [Leif Hedstrom] Fix indentation. [Leif Hedstrom] Fix indentation. [Thomas Jackson] Add tests for connect_attempts within (retries for connection to origin) [Thomas Jackson] Add initial chunked encoding tests [James Peach] tsqa: add basic regression tests wrapper [James Peach] tsqa: add build tests for uncommon configuration options [briang] TS-3452: Better debug messages for SSL_ERROR_SSL [briang] TS-3452: Better debug messages for SSL_ERROR_SSL: update changes -- [...truncated 631 lines...] Detecting operating system...success [linux] Detecting machine architecture...success [x86_64] Finding dirname command..success [/bin/dirname] Determining build directory..success [https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/lib/ck] Finding gzip toolsuccess [/bin/gzip] Finding suitable compilersuccess [/bin/cc] Detecting VMA bits...success [48] Checking header file usability...success [stdbool.h] Checking header file usability...success [stddef.h] Checking header file usability...success [stdint.h] Checking header file usability...success [string.h] Generating header files..success Generating build files...success VERSION = 0.4.5 BUILD_DIR = https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/BUILDS/lib/ck SRC_DIR = https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/lib/ck SYSTEM = linux PROFILE = x86_64 CC = /bin/cc COMPILER = gcc CFLAGS = -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -std=gnu99 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -fstrict-aliasing -O2 -pipe -Wno-parentheses -fPIC PTHREAD_CFLAGS = -pthread LD = /bin/cc LDNAME = libck.so LDNAME_VERSION = libck.so.0.4.5 LDNAME_MAJOR = libck.so.0 LDFLAGS = -Wl,-soname,libck.so.0 -m64 -shared -fPIC GZIP = /bin/gzip -c CORES = 2 POINTER_PACK = CK_MD_POINTER_PACK_DISABLE VMA_BITS = 48 MEMORY_MODEL = CK_MD_TSO RTM = CK_MD_RTM_DISABLE Headers will be installed in /usr/local/include Libraries will be installed in /usr/local/lib Documentation will be installed in /usr/local/share/man configure: Build option summary: CC: ccache cc CXX:ccache c++ CPP:cc -E CFLAGS: -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -mcx16 CXXFLAGS:-std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 CPPFLAGS: -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 LDFLAGS: SHARED_CFLAGS: -fPIC SHARED_CXXFLAGS:-fPIC SHARED_CXXLINKFLAGS: SHARED_LDFLAGS: -shared OPENSSL_LDFLAGS: OPENSSL_INCLUDES: EXTRA_CC_LDFLAGS: EXTRA_CXX_LDFLAGS: -rdynamic LIBTOOL_LINK_FLAGS: ++ make -j5 V=1 Making all in lib/ck make[1]: Entering directory `https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/BUILDS/lib/ck' make -C doc all || exit make[2]: Entering directory `https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/BUILDS/lib/ck/doc' for target in CK_ARRAY_FOREACH ck_array_buffer ck_array_commit ck_array_deinit ck_array_init ck_array_initialized ck_array_length ck_array_put ck_array_put_unique ck_array_remove ck_array_deinit ck_brlock ck_ht_count ck_ht_destroy ck_ht_gc ck_ht_get_spmc ck_ht_grow_spmc ck_ht_hash ck_ht_hash_direct ck_ht_init ck_ht_put_spmc ck_ht_remove_spmc ck_ht_reset_spmc ck_ht_reset_size_spmc ck_ht_set_spmc ck_ht_entry_empty ck_ht_entry_key ck_ht_entry_key_direct ck_ht_entry_key_length ck_ht_entry_key_set ck_ht_entry_key_set_direct ck_ht_entry_set ck_ht_entry_set_direct ck_ht_entry_value_direct ck_ht_entry_value ck_ht_iterator_init ck_ht_next ck_ht_stat ck_bitmap_init ck_bitmap_reset ck_bitmap_set ck_bitmap_bts ck_bitmap_test ck_bitmap_base ck_bitmap_union ck_bitmap_size ck_bitmap_clear ck_bitmap_bits ck_bitmap_buffer ck_bitmap_next ck_bitmap_iterator_init ck_elide ck_epoch_barrier ck_epoch_begin ck_epoch_call ck_epoch_end ck_epoch_init ck_epoch_poll ck_epoch_recycle ck_epoch_register ck_epoch_reclaim ck_epoch_synchronize ck_epoch_unregister ck_hs_gc ck_hs_init ck_hs_destroy CK_HS_HASH ck_hs_apply ck_hs_iterator_init ck_hs_next ck_hs_get ck_hs_put ck_hs_set ck_hs_fas ck_hs_remove ck_hs_move ck_hs_grow ck_hs_rebuild ck_hs_count
[jira] [Commented] (TS-3452) Better debug messages for SSL_ERROR_SSL errors
[ https://issues.apache.org/jira/browse/TS-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366167#comment-14366167 ] ASF subversion and git services commented on TS-3452: - Commit a008a0a80cd9e32e6f45a404ffeb1619eb477fc7 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a008a0a ] TS-3452: Better debug messages for SSL_ERROR_SSL: fixing format string warning Better debug messages for SSL_ERROR_SSL errors -- Key: TS-3452 URL: https://issues.apache.org/jira/browse/TS-3452 Project: Traffic Server Issue Type: Bug Components: Core, SSL Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.3.0 In the case of SSL_ERROR_SSL we can log better information, I'll drop in a patch to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Build failed in Jenkins: out_of_tree-master #647
See https://ci.trafficserver.apache.org/job/out_of_tree-master/647/changes Changes: [briang] TS-3452: Better debug messages for SSL_ERROR_SSL: fixing format string warning -- [...truncated 627 lines...] config.status: executing depfiles commands config.status: executing libtool commands === configuring in lib/ck (https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/BUILDS/lib/ck) configure: running /bin/sh ../../../lib/ck/configure --disable-option-checking '--prefix=/usr/local' '--enable-ccache' '--enable-werror' '--enable-experimental-plugins' '--enable-example-plugins' '--enable-test-tools' '--enable-reclaimable-freelist' '--enable-wccp' 'CORES=2' --cache-file=/dev/null --srcdir=../../../lib/ck Detecting operating system...success [linux] Detecting machine architecture...success [x86_64] Finding dirname command..success [/bin/dirname] Determining build directory..success [https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/lib/ck] Finding gzip toolsuccess [/bin/gzip] Finding suitable compilersuccess [/bin/cc] Detecting VMA bits...success [48] Checking header file usability...success [stdbool.h] Checking header file usability...success [stddef.h] Checking header file usability...success [stdint.h] Checking header file usability...success [string.h] Generating header files..success Generating build files...success VERSION = 0.4.5 BUILD_DIR = https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/BUILDS/lib/ck SRC_DIR = https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/lib/ck SYSTEM = linux PROFILE = x86_64 CC = /bin/cc COMPILER = gcc CFLAGS = -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -std=gnu99 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -fstrict-aliasing -O2 -pipe -Wno-parentheses -fPIC PTHREAD_CFLAGS = -pthread LD = /bin/cc LDNAME = libck.so LDNAME_VERSION = libck.so.0.4.5 LDNAME_MAJOR = libck.so.0 LDFLAGS = -Wl,-soname,libck.so.0 -m64 -shared -fPIC GZIP = /bin/gzip -c CORES = 2 POINTER_PACK = CK_MD_POINTER_PACK_DISABLE VMA_BITS = 48 MEMORY_MODEL = CK_MD_TSO RTM = CK_MD_RTM_DISABLE Headers will be installed in /usr/local/include Libraries will be installed in /usr/local/lib Documentation will be installed in /usr/local/share/man configure: Build option summary: CC: ccache cc CXX:ccache c++ CPP:cc -E CFLAGS: -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -mcx16 CXXFLAGS:-std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 CPPFLAGS: -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 LDFLAGS: SHARED_CFLAGS: -fPIC SHARED_CXXFLAGS:-fPIC SHARED_CXXLINKFLAGS: SHARED_LDFLAGS: -shared OPENSSL_LDFLAGS: OPENSSL_INCLUDES: EXTRA_CC_LDFLAGS: EXTRA_CXX_LDFLAGS: -rdynamic LIBTOOL_LINK_FLAGS: ++ make -j5 V=1 Making all in lib/ck make[1]: Entering directory `https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/BUILDS/lib/ck' make -C doc all || exit make[2]: Entering directory `https://ci.trafficserver.apache.org/job/out_of_tree-master/ws/src/BUILDS/lib/ck/doc' for target in CK_ARRAY_FOREACH ck_array_buffer ck_array_commit ck_array_deinit ck_array_init ck_array_initialized ck_array_length ck_array_put ck_array_put_unique ck_array_remove ck_array_deinit ck_brlock ck_ht_count ck_ht_destroy ck_ht_gc ck_ht_get_spmc ck_ht_grow_spmc ck_ht_hash ck_ht_hash_direct ck_ht_init ck_ht_put_spmc ck_ht_remove_spmc ck_ht_reset_spmc ck_ht_reset_size_spmc ck_ht_set_spmc ck_ht_entry_empty ck_ht_entry_key ck_ht_entry_key_direct ck_ht_entry_key_length ck_ht_entry_key_set ck_ht_entry_key_set_direct ck_ht_entry_set ck_ht_entry_set_direct ck_ht_entry_value_direct ck_ht_entry_value ck_ht_iterator_init ck_ht_next ck_ht_stat ck_bitmap_init ck_bitmap_reset ck_bitmap_set ck_bitmap_bts ck_bitmap_test ck_bitmap_base ck_bitmap_union ck_bitmap_size ck_bitmap_clear ck_bitmap_bits ck_bitmap_buffer ck_bitmap_next ck_bitmap_iterator_init ck_elide ck_epoch_barrier ck_epoch_begin ck_epoch_call ck_epoch_end ck_epoch_init ck_epoch_poll ck_epoch_recycle ck_epoch_register ck_epoch_reclaim ck_epoch_synchronize ck_epoch_unregister ck_hs_gc ck_hs_init ck_hs_destroy CK_HS_HASH ck_hs_apply
[jira] [Commented] (TS-3452) Better debug messages for SSL_ERROR_SSL errors
[ https://issues.apache.org/jira/browse/TS-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366178#comment-14366178 ] ASF subversion and git services commented on TS-3452: - Commit 5fcd9d74f20f8b9b3aa8dd361fa4d037676b00ef in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5fcd9d7 ] TS-3452: Better debug messages for SSL_ERROR_SSL: incorporate changes suggested by sudheer to peek. Better debug messages for SSL_ERROR_SSL errors -- Key: TS-3452 URL: https://issues.apache.org/jira/browse/TS-3452 Project: Traffic Server Issue Type: Bug Components: Core, SSL Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.3.0 In the case of SSL_ERROR_SSL we can log better information, I'll drop in a patch to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to normal : in_tree-master #804
See https://ci.trafficserver.apache.org/job/in_tree-master/804/changes
[jira] [Commented] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2
[
https://issues.apache.org/jira/browse/TS-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366143#comment-14366143
]
Brian Geffon commented on TS-3451:
--
On 5.0 we're seeing an error rate of about *0.015%*
{code}
Tue Mar 17 21:36:47 UTC 2015
proxy.process.ssl.ssl_error_ssl=5903229
proxy.process.ssl.total_success_handshake_count=1723736605
Tue Mar 17 21:37:47 UTC 2015
proxy.process.ssl.ssl_error_ssl=5903229
proxy.process.ssl.total_success_handshake_count=1723762651
Tue Mar 17 21:38:47 UTC 2015
proxy.process.ssl.ssl_error_ssl=5903231
proxy.process.ssl.total_success_handshake_count=1723788457
Tue Mar 17 21:39:47 UTC 2015
proxy.process.ssl.ssl_error_ssl=5903231
proxy.process.ssl.total_success_handshake_count=1723813778
Tue Mar 17 21:40:47 UTC 2015
proxy.process.ssl.ssl_error_ssl=5903235
proxy.process.ssl.total_success_handshake_count=1723839761
{code}
On 5.2 we're consistently seeing an error rate of about *0.25%*
{code}
Tue Mar 17 21:29:53 UTC 2015
proxy.process.ssl.ssl_error_ssl=1504
proxy.process.ssl.total_success_handshake_count=355370
Tue Mar 17 21:30:53 UTC 2015
proxy.process.ssl.ssl_error_ssl=1541
proxy.process.ssl.total_success_handshake_count=370410
Tue Mar 17 21:31:53 UTC 2015
proxy.process.ssl.ssl_error_ssl=1580
proxy.process.ssl.total_success_handshake_count=385499
Tue Mar 17 21:32:53 UTC 2015
proxy.process.ssl.ssl_error_ssl=1624
proxy.process.ssl.total_success_handshake_count=400661
Tue Mar 17 21:33:53 UTC 2015
proxy.process.ssl.ssl_error_ssl=1647
proxy.process.ssl.total_success_handshake_count=415756
{code}
SSL_ERROR_SSL increases moving from 5.0 to 5.2
--
Key: TS-3451
URL: https://issues.apache.org/jira/browse/TS-3451
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Susan Hinrichs
Assignee: Brian Geffon
I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is
seeing beyond the handshake buffer errors causing the decryption failed or
bad record mac messages described in TS-3424.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dzmitry Markovich updated TS-3312:
--
Attachment: keep_alive3.diff
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive3.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366124#comment-14366124
]
Brian Geffon commented on TS-3312:
--
[~dmich] Thanks! I'll wait for [~amc] to throw out any last feedback and commit
it very soon.
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive3.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Build failed in Jenkins: in_tree-master #802
See https://ci.trafficserver.apache.org/job/in_tree-master/802/changes Changes: [Leif Hedstrom] Fix indentation. [Leif Hedstrom] Fix indentation. [Thomas Jackson] Add tests for connect_attempts within (retries for connection to origin) [Thomas Jackson] Add initial chunked encoding tests [James Peach] tsqa: add basic regression tests wrapper [James Peach] tsqa: add build tests for uncommon configuration options [briang] TS-3452: Better debug messages for SSL_ERROR_SSL [briang] TS-3452: Better debug messages for SSL_ERROR_SSL: update changes -- [...truncated 655 lines...] Detecting operating system...success [linux] Detecting machine architecture...success [x86_64] Finding dirname command..success [/bin/dirname] Determining build directory..success [https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck] Finding gzip toolsuccess [/bin/gzip] Finding suitable compilersuccess [/bin/cc] Detecting VMA bits...success [48] Checking header file usability...success [stdbool.h] Checking header file usability...success [stddef.h] Checking header file usability...success [stdint.h] Checking header file usability...success [string.h] Generating header files..success Generating build files...success VERSION = 0.4.5 BUILD_DIR = https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck SRC_DIR = https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck SYSTEM = linux PROFILE = x86_64 CC = /bin/cc COMPILER = gcc CFLAGS = -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -std=gnu99 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -fstrict-aliasing -O2 -pipe -Wno-parentheses -fPIC PTHREAD_CFLAGS = -pthread LD = /bin/cc LDNAME = libck.so LDNAME_VERSION = libck.so.0.4.5 LDNAME_MAJOR = libck.so.0 LDFLAGS = -Wl,-soname,libck.so.0 -m64 -shared -fPIC GZIP = /bin/gzip -c CORES = 2 POINTER_PACK = CK_MD_POINTER_PACK_DISABLE VMA_BITS = 48 MEMORY_MODEL = CK_MD_TSO RTM = CK_MD_RTM_DISABLE Headers will be installed in /usr/local/include Libraries will be installed in /usr/local/lib Documentation will be installed in /usr/local/share/man configure: Build option summary: CC: ccache cc CXX:ccache c++ CPP:cc -E CFLAGS: -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -mcx16 CXXFLAGS:-std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 CPPFLAGS: -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 LDFLAGS: SHARED_CFLAGS: -fPIC SHARED_CXXFLAGS:-fPIC SHARED_CXXLINKFLAGS: SHARED_LDFLAGS: -shared OPENSSL_LDFLAGS: OPENSSL_INCLUDES: EXTRA_CC_LDFLAGS: EXTRA_CXX_LDFLAGS: -rdynamic LIBTOOL_LINK_FLAGS: ++ make -j5 V=1 Making all in lib/ck make[1]: Entering directory `https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck' make -C doc all || exit make[2]: Entering directory `https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck/doc' for target in CK_ARRAY_FOREACH ck_array_buffer ck_array_commit ck_array_deinit ck_array_init ck_array_initialized ck_array_length ck_array_put ck_array_put_unique ck_array_remove ck_array_deinit ck_brlock ck_ht_count ck_ht_destroy ck_ht_gc ck_ht_get_spmc ck_ht_grow_spmc ck_ht_hash ck_ht_hash_direct ck_ht_init ck_ht_put_spmc ck_ht_remove_spmc ck_ht_reset_spmc ck_ht_reset_size_spmc ck_ht_set_spmc ck_ht_entry_empty ck_ht_entry_key ck_ht_entry_key_direct ck_ht_entry_key_length ck_ht_entry_key_set ck_ht_entry_key_set_direct ck_ht_entry_set ck_ht_entry_set_direct ck_ht_entry_value_direct ck_ht_entry_value ck_ht_iterator_init ck_ht_next ck_ht_stat ck_bitmap_init ck_bitmap_reset ck_bitmap_set ck_bitmap_bts ck_bitmap_test ck_bitmap_base ck_bitmap_union ck_bitmap_size ck_bitmap_clear ck_bitmap_bits ck_bitmap_buffer ck_bitmap_next ck_bitmap_iterator_init ck_elide ck_epoch_barrier ck_epoch_begin ck_epoch_call ck_epoch_end ck_epoch_init ck_epoch_poll ck_epoch_recycle ck_epoch_register ck_epoch_reclaim ck_epoch_synchronize ck_epoch_unregister ck_hs_gc ck_hs_init ck_hs_destroy CK_HS_HASH ck_hs_apply ck_hs_iterator_init ck_hs_next ck_hs_get ck_hs_put ck_hs_set ck_hs_fas ck_hs_remove ck_hs_move ck_hs_grow ck_hs_rebuild ck_hs_count ck_hs_reset ck_hs_reset_size ck_hs_stat ck_rhs_gc
[jira] [Updated] (TS-3448) Add an internal Mod to ControlMatcher (a boolean value)
[
https://issues.apache.org/jira/browse/TS-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3448:
--
Description:
This allows, as an example, exclusion of parent.config for requests that are
internal. Or, different cache.config rules for internal requests. Example usage
could be
{code}
dest_domain=. parent=proxy1.example.com:8080; proxy2.example.com:8080
internal=false
{code}
This would allow this rule to only trigger if the request is not an internal
(plugin) request.
was:
This allows, as an example, exclusion of parent.config for requests that are
internal. Or, different cache.config rules for internal requests. Example usage
could be
{code}
dest_domain=. parent=proxy1.example.com:8080; proxy2.example.com:8080
internal_request=false
{code}
This would allow this rule to only trigger if the request is not an internal
(plugin) request.
Add an internal Mod to ControlMatcher (a boolean value)
-
Key: TS-3448
URL: https://issues.apache.org/jira/browse/TS-3448
Project: Traffic Server
Issue Type: New Feature
Components: Configuration, Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.3.0
This allows, as an example, exclusion of parent.config for requests that are
internal. Or, different cache.config rules for internal requests. Example
usage could be
{code}
dest_domain=. parent=proxy1.example.com:8080; proxy2.example.com:8080
internal=false
{code}
This would allow this rule to only trigger if the request is not an internal
(plugin) request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3448) Add an internal Mod to ControlMatcher (a boolean value)
[
https://issues.apache.org/jira/browse/TS-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3448:
--
Summary: Add an internal Mod to ControlMatcher (a boolean value) (was:
Add an internal_request Mod to ControlMatcher (a boolean value))
Add an internal Mod to ControlMatcher (a boolean value)
-
Key: TS-3448
URL: https://issues.apache.org/jira/browse/TS-3448
Project: Traffic Server
Issue Type: New Feature
Components: Configuration, Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.3.0
This allows, as an example, exclusion of parent.config for requests that are
internal. Or, different cache.config rules for internal requests. Example
usage could be
{code}
dest_domain=. parent=proxy1.example.com:8080; proxy2.example.com:8080
internal_request=false
{code}
This would allow this rule to only trigger if the request is not an internal
(plugin) request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3452) Better debug messages for SSL_ERROR_SSL errors
[ https://issues.apache.org/jira/browse/TS-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-3452. -- Resolution: Fixed Better debug messages for SSL_ERROR_SSL errors -- Key: TS-3452 URL: https://issues.apache.org/jira/browse/TS-3452 Project: Traffic Server Issue Type: Bug Components: Core, SSL Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.3.0 In the case of SSL_ERROR_SSL we can log better information, I'll drop in a patch to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Build failed in Jenkins: in_tree-master #803
See https://ci.trafficserver.apache.org/job/in_tree-master/803/changes Changes: [briang] TS-3452: Better debug messages for SSL_ERROR_SSL: fixing format string warning -- [...truncated 651 lines...] config.status: executing depfiles commands config.status: executing libtool commands === configuring in lib/ck (https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck) configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr/local' '--enable-ccache' '--enable-werror' '--enable-experimental-plugins' '--enable-example-plugins' '--enable-test-tools' '--enable-reclaimable-freelist' '--enable-wccp' '--enable-cppapi' 'CORES=2' --cache-file=/dev/null --srcdir=. Detecting operating system...success [linux] Detecting machine architecture...success [x86_64] Finding dirname command..success [/bin/dirname] Determining build directory..success [https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck] Finding gzip toolsuccess [/bin/gzip] Finding suitable compilersuccess [/bin/cc] Detecting VMA bits...success [48] Checking header file usability...success [stdbool.h] Checking header file usability...success [stddef.h] Checking header file usability...success [stdint.h] Checking header file usability...success [string.h] Generating header files..success Generating build files...success VERSION = 0.4.5 BUILD_DIR = https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck SRC_DIR = https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck SYSTEM = linux PROFILE = x86_64 CC = /bin/cc COMPILER = gcc CFLAGS = -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -std=gnu99 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -fstrict-aliasing -O2 -pipe -Wno-parentheses -fPIC PTHREAD_CFLAGS = -pthread LD = /bin/cc LDNAME = libck.so LDNAME_VERSION = libck.so.0.4.5 LDNAME_MAJOR = libck.so.0 LDFLAGS = -Wl,-soname,libck.so.0 -m64 -shared -fPIC GZIP = /bin/gzip -c CORES = 2 POINTER_PACK = CK_MD_POINTER_PACK_DISABLE VMA_BITS = 48 MEMORY_MODEL = CK_MD_TSO RTM = CK_MD_RTM_DISABLE Headers will be installed in /usr/local/include Libraries will be installed in /usr/local/lib Documentation will be installed in /usr/local/share/man configure: Build option summary: CC: ccache cc CXX:ccache c++ CPP:cc -E CFLAGS: -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -mcx16 CXXFLAGS:-std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 CPPFLAGS: -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 LDFLAGS: SHARED_CFLAGS: -fPIC SHARED_CXXFLAGS:-fPIC SHARED_CXXLINKFLAGS: SHARED_LDFLAGS: -shared OPENSSL_LDFLAGS: OPENSSL_INCLUDES: EXTRA_CC_LDFLAGS: EXTRA_CXX_LDFLAGS: -rdynamic LIBTOOL_LINK_FLAGS: ++ make -j5 V=1 Making all in lib/ck make[1]: Entering directory `https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck' make -C doc all || exit make[2]: Entering directory `https://ci.trafficserver.apache.org/job/in_tree-master/ws/src/lib/ck/doc' for target in CK_ARRAY_FOREACH ck_array_buffer ck_array_commit ck_array_deinit ck_array_init ck_array_initialized ck_array_length ck_array_put ck_array_put_unique ck_array_remove ck_array_deinit ck_brlock ck_ht_count ck_ht_destroy ck_ht_gc ck_ht_get_spmc ck_ht_grow_spmc ck_ht_hash ck_ht_hash_direct ck_ht_init ck_ht_put_spmc ck_ht_remove_spmc ck_ht_reset_spmc ck_ht_reset_size_spmc ck_ht_set_spmc ck_ht_entry_empty ck_ht_entry_key ck_ht_entry_key_direct ck_ht_entry_key_length ck_ht_entry_key_set ck_ht_entry_key_set_direct ck_ht_entry_set ck_ht_entry_set_direct ck_ht_entry_value_direct ck_ht_entry_value ck_ht_iterator_init ck_ht_next ck_ht_stat ck_bitmap_init ck_bitmap_reset ck_bitmap_set ck_bitmap_bts ck_bitmap_test ck_bitmap_base ck_bitmap_union ck_bitmap_size ck_bitmap_clear ck_bitmap_bits ck_bitmap_buffer ck_bitmap_next ck_bitmap_iterator_init ck_elide ck_epoch_barrier ck_epoch_begin ck_epoch_call ck_epoch_end ck_epoch_init ck_epoch_poll ck_epoch_recycle ck_epoch_register ck_epoch_reclaim ck_epoch_synchronize ck_epoch_unregister ck_hs_gc ck_hs_init ck_hs_destroy CK_HS_HASH ck_hs_apply ck_hs_iterator_init ck_hs_next ck_hs_get ck_hs_put ck_hs_set
[jira] [Commented] (TS-3446) custom logging for Cookie header
[ https://issues.apache.org/jira/browse/TS-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364855#comment-14364855 ] Scott Beardsley commented on TS-3446: - I don't see docs for trim here can you elaborate what trim does?: https://docs.trafficserver.apache.org/en/latest/admin/event-logging-formats.en.html Do you mean splice? I don't think splice would work since there is no way of knowing where the cookie falls in the string. This feature would require essentially a split on the semi-colon (and space?) dividing the cookie name/value pairs. Here is a good primer on the format: http://curl.haxx.se/rfc/cookie_spec.html BTW bonus points if the feature deals with set-cookie response headers too (this is more complex though since you need to deal with scope and expires). custom logging for Cookie header Key: TS-3446 URL: https://issues.apache.org/jira/browse/TS-3446 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Scott Beardsley Priority: Minor I have a use case that requires logging a specific cookie in the UA request. The only way to do this today is to log the entire Cookie request header then parse out the cookie name/value pair that I am interested in after the fact. The problem with that approach is that some cookie data is sensitive and must not exist in logs. Plus logging the entire cookie header is just wasteful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3448) Add an internal_request Mod to ControlMatcher (a boolean value)
[
https://issues.apache.org/jira/browse/TS-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365691#comment-14365691
]
Leif Hedstrom commented on TS-3448:
---
Hmm, ok. We have a mess here already, in header-rewrite, it's called
INTERNAL-TRANSACTION :/
Add an internal_request Mod to ControlMatcher (a boolean value)
-
Key: TS-3448
URL: https://issues.apache.org/jira/browse/TS-3448
Project: Traffic Server
Issue Type: New Feature
Components: Configuration, Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.3.0
This allows, as an example, exclusion of parent.config for requests that are
internal. Or, different cache.config rules for internal requests. Example
usage could be
{code}
dest_domain=. parent=proxy1.example.com:8080; proxy2.example.com:8080
internal_request=false
{code}
This would allow this rule to only trigger if the request is not an internal
(plugin) request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3448) Add an internal_request Mod to ControlMatcher (a boolean value)
[
https://issues.apache.org/jira/browse/TS-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365597#comment-14365597
]
James Peach commented on TS-3448:
-
Consider naming this {{internal}} to match the {{@internal}} ACL filter for
{{remap.config}}.
Add an internal_request Mod to ControlMatcher (a boolean value)
-
Key: TS-3448
URL: https://issues.apache.org/jira/browse/TS-3448
Project: Traffic Server
Issue Type: New Feature
Components: Configuration, Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.3.0
This allows, as an example, exclusion of parent.config for requests that are
internal. Or, different cache.config rules for internal requests. Example
usage could be
{code}
dest_domain=. parent=proxy1.example.com:8080; proxy2.example.com:8080
internal_request=false
{code}
This would allow this rule to only trigger if the request is not an internal
(plugin) request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366291#comment-14366291
]
Alan M. Carroll commented on TS-3312:
-
I'm going to rain on this parade because that's just how I roll.
It's unclear to me this bug even exists. What, exactly, is the problem? One is
resetting the timeout. But that's not a bug, it's a feature, as described in
the message itself - reseting timeout to maintain minimum number of
connections, exactly as required by setting the configuration option
{{origin_min_keep_alive_connections}} to 10. It's done twice because the
inactivity timeout is set to 30s and we see the resets occuring at 30 and 60
seconds after being put in the pool. The connection then gets an EOS which
indicates the origin server shut it down. This occurs 60 seconds after the
session is put in the pool, again exactly as expected if the origin server has
a 60 second timeout.
On to poor Dzmitry. The primary issue I see is tieing the inactivity setting to
releasing the session. This is not the same as ending the transaction. In
particular the changes around line 4735 are going to happen after the
transaction has been destroyed and a new one created so any changes made in the
current transaction should *not* apply to that server session, as it is
associated almost certainly with a different origin (if not, it would have been
re-used instead of put in to the pool). So this is simply wrong.
To make any more criticism requires asking what exactly are we trying to do
here? If it's to propagate settings from a particular HttpSM into the server
session used by the HttpSM (because those settings may have been changed during
the HttpSM run based on transaction specific data) then we should do that at
the end of the HttpSM and not necessarily when it is put in to the pool. After
all, may we not want that to apply even for the sticky session case noted
above? So that if no new transaction does show up on the client session, the
server session times out as indicated by the default or the API supplied value?
What might be simpler and more accurately implement the desired behavior
(presuming we can even agree on that) is to have a seperate method on
HttpServerSession that sets the time out and have the HttpSM call that just
before the place where the server session can be released.
This leads to a related question. If the API is used to change the inactivity
timeout, when does that take effect? Is the timeout for the server session
immediately updated? If so then perhaps the HttpSM clean should just call that.
Otherwise would that be a bug with regard to what is expected to happen?
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive3.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Build failed in Jenkins: tsqa-master #240
See https://ci.trafficserver.apache.org/job/tsqa-master/240/changes Changes: [Leif Hedstrom] Fix indentation. [Leif Hedstrom] Fix indentation. [Thomas Jackson] Add tests for connect_attempts within (retries for connection to origin) [Thomas Jackson] Add initial chunked encoding tests [James Peach] tsqa: add basic regression tests wrapper [James Peach] tsqa: add build tests for uncommon configuration options [briang] TS-3452: Better debug messages for SSL_ERROR_SSL [briang] TS-3452: Better debug messages for SSL_ERROR_SSL: update changes [briang] TS-3452: Better debug messages for SSL_ERROR_SSL: fixing format string warning [briang] TS-3452: Better debug messages for SSL_ERROR_SSL: incorporate changes suggested by sudheer to peek. -- [...truncated 13205 lines...] 10 687 3437.300 51847342/5184734 2211 2211 2211 85458691 12.90 10 699 3497.600 51450346/5145034 2254 2254 2254 85242617 13.90 10 710 3551.100 50898767/5089876 2285 2285 2285 84195527 14.90 10 714 3574.300 51357407/5135740 2292 2292 2292 84902617 15.90 10 712 3561.600 51601617/5160161 2274 2274 2273 85056110 16.90 10 716 3581.900 50526075/5052607 2287 2287 2287 83110796 17.90 10 721 3606.700 50573912/5057391 2307 2307 2307 83476684 18.90 10 713 3568.200 50952400/5095240 2292 2292 2292 84172932 19.90 con new ops 1B lat bytes/per svrs new ops total time err 10 717 3591.300 50668650/5066865 2305 2305 2305 83740316 20.90 10 718 3593.500 51665972/5166597 2298 2298 2298 85811687 21.90 10 716 3583.400 52792141/5279214 2287 2287 2288 87380246 22.90 10 718 3592.700 53794353/5379435 2288 2288 2287 88580979 23.90 10 715 3578.800 54077547/5407754 2283 2283 2283 89371928 24.90 10 718 3593.600 53629963/5362996 2302 2302 2303 88449400 25.90 10 718 3595.500 53641793/5364179 2306 2306 2306 87719395 26.90 10 719 3599.000 52740011/5274001 2294 2294 2294 86058604 27.90 MSG: reloading logging configuration 10 715 3576.000 52764832/5276483 2280 2280 2279 86082677 28.90 10 715 3579.000 54253900/5425390 2296 2296 2297 89013562 29.90 10 718 3595.400 54126816/5412681 2307 2307 2307 88905670 30.90 10 716 3582.300 54208446/5420844 2289 2289 2289 88919658 31.90 10 716 3586.500 53210465/5321046 2296 2296 2296 87544292 32.90 10 715 3581.200 53854514/5385451 2293 2293 2293 88474295 33.90 10 712 3567.100 54227945/5422794 2289 2289 2288 89268981 34.90 10 712 3566.100 53974597/5397459 2293 2293 2293 89265605 35.90 10 714 3572.500 53752112/5375211 2304 2304 2303 89185850 36.90 10 714 3575.600 52890567/5289056 2306 2306 2306 87658662 37.90 10 712 3562.500 53092191/5309219 2294 2294 2294 87684286 38.90 10 714 3573.800 53997935/5399793 2297 2297 2297 88552526 39.90 con new ops 1B lat bytes/per svrs new ops total time err 10 710 3552.800 54327495/5432749 2283 2283 2283 89545373 40.90 10 703 3516.500 54297007/5429700 2254 2254 2254 89257816 41.90 10 702 3514.600 53820264/5382026 2248 2248 2248 88521005 42.90 10 704 3523.300 53726094/5372609 2263 2263 2263 7442 43.90 10 707 3536.400 52901774/5290177 2265 2265 2265 88159671 44.90 10 707 3537.300 53574871/5357487 2272 2272 2273 89605980 45.90 10 710 3555.300 53705594/5370559 2288 2288 2287 89906655 46.90 10 714 3577.000 53627035/5362703 2308 2308 2308 89907153 47.90 10 711 3558.400 53640576/5364057 2289 2289 2289 89736514 48.90 10 714 3574.900 52976810/5297681 2295 2295 2295 88381271 49.90 10 714 3574.700 52603167/5260316 2291 2291 2291 87372299 50.90 10 716 3585.200 53105360/5310536 2298 2298 2298 87803401 51.90 10 717 3587.600 53037589/5303758 2297 2297 2297 87248330 52.90 10 720 3606.600 52964924/5296492 2310 2310 2310 87272625 53.90 10 717 3590.300 53285833/5328583 2294 2294 2294 87613508 54.90 10 714 3573.500 52690281/5269028 2288 2288 2288 86636191 55.90 10 713 3568.600 52260624/5226062 2289 2289 2290 85750035 56.90 10 713 3570.200 52245520/5224552
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365913#comment-14365913
]
Dzmitry Markovich commented on TS-3312:
---
[~briang], could you please take a look? I addressed feedback with previous
patch.
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive2.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
[
https://issues.apache.org/jira/browse/TS-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365956#comment-14365956
]
Brian Geffon edited comment on TS-3424 at 3/17/15 8:10 PM:
---
Ok since [~shinrich] created TS-3451, let's close this guy out with the
intention of backporting to 5.2.x, sound good? I just don't see the commit in
the comment history for some reason.
was (Author: briang):
Ok since [~shinrich] created TS-3451, let's close this guy out with the
intention of backporting to 5.2.x, sound good?
SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
--
Key: TS-3424
URL: https://issues.apache.org/jira/browse/TS-3424
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff,
ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff,
undo-handshake-buffer.diff
Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in
{{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see
the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
record mac}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365977#comment-14365977
]
Leif Hedstrom commented on TS-3312:
---
I wasn't thrilled about the release either, but I'll manage. However, I feel
strongly that we should use better names in these signatures. For example:
{code}
void releaseSession(HttpServerSession* ss, ink_hrtime inactivity_timeout_in =
0);
void HttpServerSession::release(ink_hrtime timeout_in);
{code}
If I understand correctly, these are the KA timeouts for the origin
connections, no? Then the names of these parameters should reflect that, at a
minimum they should be named _out, but even so, inactivity_timeout_out is very
confusing since we have another timeout for exactly that (which is *not* the KA
timeout). I think the prototypes should be something like
{code}
void releaseSession(HttpServerSession* ss, ink_hrtime ka_timeout_out = 0);
void HttpServerSession::release(ink_hrtime ka_timeout_out);
{code}
Maybe it's our naming convention that's confusing, but _in and _out here refers
to incoming connection vs outgoing connection, not if it's an in or out
variable.
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive2.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365935#comment-14365935
]
Brian Geffon commented on TS-3312:
--
I'm not thrilled that we have to modify the {{release()}} signature, but I see
why it's necessary. This looks good to me, if there are no other
objections/comments/suggestions I'll commit this latest version in the next few
days.
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive2.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2
Susan Hinrichs created TS-3451: -- Summary: SSL_ERROR_SSL increases moving from 5.0 to 5.2 Key: TS-3451 URL: https://issues.apache.org/jira/browse/TS-3451 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Susan Hinrichs I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is seeing beyond the handshake buffer errors causing the decryption failed or bad record mac messages described in TS-3424. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2
[ https://issues.apache.org/jira/browse/TS-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-3451: Assignee: Brian Geffon SSL_ERROR_SSL increases moving from 5.0 to 5.2 -- Key: TS-3451 URL: https://issues.apache.org/jira/browse/TS-3451 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Susan Hinrichs Assignee: Brian Geffon I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is seeing beyond the handshake buffer errors causing the decryption failed or bad record mac messages described in TS-3424. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dzmitry Markovich updated TS-3312:
--
Attachment: (was: keep_alive3.diff)
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dzmitry Markovich updated TS-3312:
--
Attachment: keep_alive3.diff
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive3.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2
[ https://issues.apache.org/jira/browse/TS-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366006#comment-14366006 ] Susan Hinrichs commented on TS-3451: Running 5.2 plus the fix from TS-3424 in production with additional debug prints to get details of SSL_ERROR_SSL from SSLAccept, I'm seeing a burst of 1-5 errors about once a minute. I see mostly the following * SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback - This is the most frequent message by far in the log. This seems like a legitimate error. The server is preventing clients from negotiating protocol A and falling back to lower protocol B. https://dwradcliffe.com/2014/10/16/testing-tls-fallback.html * SSL3_GET_CLIENT_HELLO:no shared cipher - The client and server have no ciphers in common. This is quite a believable error. * SSL3_GET_CLIENT_HELLO:required cipher missing - This means that on a session resume, the client is offering different ciphers than was used when the cipher was originally negotiated. Seems odd. See a discussion here about having android having issues here. https://code.google.com/p/android/issues/detail?id=97132 * SSL3_GET_MESSAGE:unexpected message * SSL3_READ_BYTES:sslv3 alert unexpected message * SSL3_READ_BYTES:sslv3 alert bad certificate * SSL3_READ_BYTES:sslv3 alert bad record mac - Perhaps we still have some corruption from the handshake? * SSL3_READ_BYTES:sslv3 alert illegal parameter * SSL3_READ_BYTES:tlsv1 alert unknown ca SSL_ERROR_SSL increases moving from 5.0 to 5.2 -- Key: TS-3451 URL: https://issues.apache.org/jira/browse/TS-3451 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Susan Hinrichs Assignee: Brian Geffon I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is seeing beyond the handshake buffer errors causing the decryption failed or bad record mac messages described in TS-3424. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dzmitry Markovich updated TS-3312:
--
Attachment: (was: keep_alive2.diff)
KA timeout to origin does not seem to honor configurations
--
Key: TS-3312
URL: https://issues.apache.org/jira/browse/TS-3312
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: Leif Hedstrom
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: keep_alive3.diff
Doing some basic testing, with the following settings:
{code}
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
I see ATS timing out the origin sessions after 30sec, with a
{code}
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
{code}
What's also interesting, after I made a config change per Geffon's suggestion:
{code}
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
{code}
I see the following in the diagnostic trace:
{code}
[Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release
session] session placed into shared pool
[Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT],
reseting timeout to maintain minimum number of connections
[Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0]
[session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
{code}
So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS.
I first though it was the origin that closed the connection, but from what I
could tell, the timeout on the origin was set to 60s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2
[
https://issues.apache.org/jira/browse/TS-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366025#comment-14366025
]
Brian Geffon commented on TS-3451:
--
I see mostly the following:
{code}
ERR_get_error=336109835 (error:1408A10B:SSL
routines:SSL3_GET_CLIENT_HELLO:wrong version number)
ERR_get_error=336109761 (error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no
shared cipher)
ERR_get_error=336204149 (error:140A1175:SSL
routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback)
ERR_get_error=336027900 (error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol)
{code}
With wrong version number and inappropriate fallback as the majority of them
SSL_ERROR_SSL increases moving from 5.0 to 5.2
--
Key: TS-3451
URL: https://issues.apache.org/jira/browse/TS-3451
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Susan Hinrichs
Assignee: Brian Geffon
I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is
seeing beyond the handshake buffer errors causing the decryption failed or
bad record mac messages described in TS-3424.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365053#comment-14365053
]
Zhaonanli commented on TS-2205:
---
hi , arise again, version 4.2.2
AIO caused system hang
--
Key: TS-2205
URL: https://issues.apache.org/jira/browse/TS-2205
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.1
Reporter: Zhao Yongming
Assignee: weijin
Priority: Critical
the system may hang with AIO thread CPU usage rising:
{code}
top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3447) Failing to remap POST requests if buffer_upload plugin is enabled and Host header contains port number
[
https://issues.apache.org/jira/browse/TS-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365130#comment-14365130
]
ASF GitHub Bot commented on TS-3447:
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/181#discussion_r26573216
--- Diff: plugins/experimental/buffer_upload/buffer_upload.cc ---
@@ -753,6 +753,15 @@ attach_pvc_plugin(TSCont /* contp ATS_UNUSED */,
TSEvent event, void *edata)
memcpy(replacement_host_str, host_hdr_str_val,
host_hdr_str_val_len);
TSDebug(DEBUG_TAG, Adding host to request url: %s,
replacement_host_str);
+const char *colon = strstr(replacement_host_str, :);
--- End diff --
Why {{strstr}} instead of {{strchr}}?
Failing to remap POST requests if buffer_upload plugin is enabled and Host
header contains port number
--
Key: TS-3447
URL: https://issues.apache.org/jira/browse/TS-3447
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Ethan Lai
Fix For: 6.0.0
We've experienced POST request mapping issues in some situation while
buffer_upload plugin is enabled.
After cross reference, we found that Host header with port value cannot be
mapped correctly.
Sample remap.config:
{quote}
map http://www.example.com/ http://127.0.0.1:8001/
map http://www.example.com:8080/ http://127.0.0.1:8001/
{quote}
Sample plugin.config
{quote}
buffer_upload.so conf/trafficserver/buffer_upload/buffer_upload.config
{quote}
Sample buffer_upload.config
{quote}
use_disk_buffer 1
convert_url 0
chunk_size 1024
url_list_file conf/trafficserver/buffer_upload/url_list.config
base_dirvar/buffer_upload_tmp
subdir_num 100
thread_num 10
mem_buffer_size 51000
{quote}
Sample buffer upload url_list.config
{quote}
http://www.example.com/upload/upload.php
{quote}
Sample cmds responses
{quote}
curl http://www.example.com/test.php -X POST -d 'blah'
map ok
curl http://www.example.com:8080/test.php
map ok
curl http://www.example.com:8080/test.php -X POST -d 'blah'
404 Not Found! (Not Found on Accelerator)
{quote}
I've tried to correct this and will update with pull request shortly, thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3447) Failing to remap POST requests if buffer_upload plugin is enabled and Host header contains port number
[
https://issues.apache.org/jira/browse/TS-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365122#comment-14365122
]
ASF GitHub Bot commented on TS-3447:
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/181#discussion_r26573116
--- Diff: plugins/experimental/buffer_upload/buffer_upload.cc ---
@@ -753,6 +753,15 @@ attach_pvc_plugin(TSCont /* contp ATS_UNUSED */,
TSEvent event, void *edata)
memcpy(replacement_host_str, host_hdr_str_val,
host_hdr_str_val_len);
TSDebug(DEBUG_TAG, Adding host to request url: %s,
replacement_host_str);
+const char *colon = strstr(replacement_host_str, :);
+if (colon != NULL colon + 1 != NULL) {
+ int port_str_val = atoi(colon + 1);
+
+ if (port_str_val != 80) {
+TSUrlPortSet(req_bufp, url_loc, port_str_val);
+ }
+ host_hdr_str_val_len -= strlen(colon);
--- End diff --
Why not {{host_hdr_str_val_len = colon - host_hdr_str_val_len;}} if you
want to clip at the colon?
Failing to remap POST requests if buffer_upload plugin is enabled and Host
header contains port number
--
Key: TS-3447
URL: https://issues.apache.org/jira/browse/TS-3447
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Ethan Lai
Fix For: 6.0.0
We've experienced POST request mapping issues in some situation while
buffer_upload plugin is enabled.
After cross reference, we found that Host header with port value cannot be
mapped correctly.
Sample remap.config:
{quote}
map http://www.example.com/ http://127.0.0.1:8001/
map http://www.example.com:8080/ http://127.0.0.1:8001/
{quote}
Sample plugin.config
{quote}
buffer_upload.so conf/trafficserver/buffer_upload/buffer_upload.config
{quote}
Sample buffer_upload.config
{quote}
use_disk_buffer 1
convert_url 0
chunk_size 1024
url_list_file conf/trafficserver/buffer_upload/url_list.config
base_dirvar/buffer_upload_tmp
subdir_num 100
thread_num 10
mem_buffer_size 51000
{quote}
Sample buffer upload url_list.config
{quote}
http://www.example.com/upload/upload.php
{quote}
Sample cmds responses
{quote}
curl http://www.example.com/test.php -X POST -d 'blah'
map ok
curl http://www.example.com:8080/test.php
map ok
curl http://www.example.com:8080/test.php -X POST -d 'blah'
404 Not Found! (Not Found on Accelerator)
{quote}
I've tried to correct this and will update with pull request shortly, thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3447) Failing to remap POST requests if buffer_upload plugin is enabled and Host header contains port number
[
https://issues.apache.org/jira/browse/TS-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365166#comment-14365166
]
ASF GitHub Bot commented on TS-3447:
Github user yzlai commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/181#discussion_r26576225
--- Diff: plugins/experimental/buffer_upload/buffer_upload.cc ---
@@ -753,6 +753,15 @@ attach_pvc_plugin(TSCont /* contp ATS_UNUSED */,
TSEvent event, void *edata)
memcpy(replacement_host_str, host_hdr_str_val,
host_hdr_str_val_len);
TSDebug(DEBUG_TAG, Adding host to request url: %s,
replacement_host_str);
+const char *colon = strstr(replacement_host_str, :);
--- End diff --
This is copied from
https://github.com/apache/trafficserver/blob/master/plugins/experimental/buffer_upload/buffer_upload.cc#L633
However, I can use strchr instead ^^a
Failing to remap POST requests if buffer_upload plugin is enabled and Host
header contains port number
--
Key: TS-3447
URL: https://issues.apache.org/jira/browse/TS-3447
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Ethan Lai
Fix For: 6.0.0
We've experienced POST request mapping issues in some situation while
buffer_upload plugin is enabled.
After cross reference, we found that Host header with port value cannot be
mapped correctly.
Sample remap.config:
{quote}
map http://www.example.com/ http://127.0.0.1:8001/
map http://www.example.com:8080/ http://127.0.0.1:8001/
{quote}
Sample plugin.config
{quote}
buffer_upload.so conf/trafficserver/buffer_upload/buffer_upload.config
{quote}
Sample buffer_upload.config
{quote}
use_disk_buffer 1
convert_url 0
chunk_size 1024
url_list_file conf/trafficserver/buffer_upload/url_list.config
base_dirvar/buffer_upload_tmp
subdir_num 100
thread_num 10
mem_buffer_size 51000
{quote}
Sample buffer upload url_list.config
{quote}
http://www.example.com/upload/upload.php
{quote}
Sample cmds responses
{quote}
curl http://www.example.com/test.php -X POST -d 'blah'
map ok
curl http://www.example.com:8080/test.php
map ok
curl http://www.example.com:8080/test.php -X POST -d 'blah'
404 Not Found! (Not Found on Accelerator)
{quote}
I've tried to correct this and will update with pull request shortly, thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1807: - Fix Version/s: (was: 5.3.0) 6.0.0 shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Labels: review Fix For: 6.0.0 Attachments: TS-1807.diff In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365213#comment-14365213 ] William Bardwell commented on TS-1807: -- Yeah until I can button-hole someone to look at that change and see if it is reasonable or an early sign of madness I don't want to check it in. shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Labels: review Fix For: 6.0.0 Attachments: TS-1807.diff In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3447) Failing to remap POST requests if buffer_upload plugin is enabled and Host header contains port number
[
https://issues.apache.org/jira/browse/TS-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365485#comment-14365485
]
ASF GitHub Bot commented on TS-3447:
Github user bryancall commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/181#discussion_r26590946
--- Diff: plugins/experimental/buffer_upload/buffer_upload.cc ---
@@ -753,6 +753,15 @@ attach_pvc_plugin(TSCont /* contp ATS_UNUSED */,
TSEvent event, void *edata)
memcpy(replacement_host_str, host_hdr_str_val,
host_hdr_str_val_len);
TSDebug(DEBUG_TAG, Adding host to request url: %s,
replacement_host_str);
+const char *colon = strchr(replacement_host_str, ':');
+if (colon != NULL colon + 1 != NULL) {
+ int port_str_val = atoi(colon + 1);
+
+ if (port_str_val != 80) {
--- End diff --
Why only check for port 80 and not 443? Also, you should consider checking
the scheme.
Failing to remap POST requests if buffer_upload plugin is enabled and Host
header contains port number
--
Key: TS-3447
URL: https://issues.apache.org/jira/browse/TS-3447
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Ethan Lai
Fix For: 6.0.0
We've experienced POST request mapping issues in some situation while
buffer_upload plugin is enabled.
After cross reference, we found that Host header with port value cannot be
mapped correctly.
Sample remap.config:
{quote}
map http://www.example.com/ http://127.0.0.1:8001/
map http://www.example.com:8080/ http://127.0.0.1:8001/
{quote}
Sample plugin.config
{quote}
buffer_upload.so conf/trafficserver/buffer_upload/buffer_upload.config
{quote}
Sample buffer_upload.config
{quote}
use_disk_buffer 1
convert_url 0
chunk_size 1024
url_list_file conf/trafficserver/buffer_upload/url_list.config
base_dirvar/buffer_upload_tmp
subdir_num 100
thread_num 10
mem_buffer_size 51000
{quote}
Sample buffer upload url_list.config
{quote}
http://www.example.com/upload/upload.php
{quote}
Sample cmds responses
{quote}
curl http://www.example.com/test.php -X POST -d 'blah'
map ok
curl http://www.example.com:8080/test.php
map ok
curl http://www.example.com:8080/test.php -X POST -d 'blah'
404 Not Found! (Not Found on Accelerator)
{quote}
I've tried to correct this and will update with pull request shortly, thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3447) Failing to remap POST requests if buffer_upload plugin is enabled and Host header contains port number
[
https://issues.apache.org/jira/browse/TS-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365491#comment-14365491
]
ASF GitHub Bot commented on TS-3447:
Github user bryancall commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/181#discussion_r26591169
--- Diff: plugins/experimental/buffer_upload/buffer_upload.cc ---
@@ -753,6 +753,15 @@ attach_pvc_plugin(TSCont /* contp ATS_UNUSED */,
TSEvent event, void *edata)
memcpy(replacement_host_str, host_hdr_str_val,
host_hdr_str_val_len);
--- End diff --
Might as well clean up the memset. You can set
replacement_host_str[host_hdr_str_val_len + 1] = '\0' after the memcpy instead
of doing a memset.
Failing to remap POST requests if buffer_upload plugin is enabled and Host
header contains port number
--
Key: TS-3447
URL: https://issues.apache.org/jira/browse/TS-3447
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Ethan Lai
Fix For: 6.0.0
We've experienced POST request mapping issues in some situation while
buffer_upload plugin is enabled.
After cross reference, we found that Host header with port value cannot be
mapped correctly.
Sample remap.config:
{quote}
map http://www.example.com/ http://127.0.0.1:8001/
map http://www.example.com:8080/ http://127.0.0.1:8001/
{quote}
Sample plugin.config
{quote}
buffer_upload.so conf/trafficserver/buffer_upload/buffer_upload.config
{quote}
Sample buffer_upload.config
{quote}
use_disk_buffer 1
convert_url 0
chunk_size 1024
url_list_file conf/trafficserver/buffer_upload/url_list.config
base_dirvar/buffer_upload_tmp
subdir_num 100
thread_num 10
mem_buffer_size 51000
{quote}
Sample buffer upload url_list.config
{quote}
http://www.example.com/upload/upload.php
{quote}
Sample cmds responses
{quote}
curl http://www.example.com/test.php -X POST -d 'blah'
map ok
curl http://www.example.com:8080/test.php
map ok
curl http://www.example.com:8080/test.php -X POST -d 'blah'
404 Not Found! (Not Found on Accelerator)
{quote}
I've tried to correct this and will update with pull request shortly, thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
