Jenkins build is still unstable: tsqa-lint #436
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
[jira] [Updated] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.
[ https://issues.apache.org/jira/browse/TS-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3837: -- Affects Version/s: 6.1.0 The setting wait_for_cache waits indefinitely even when there are no cache disks configured. Key: TS-3837 URL: https://issues.apache.org/jira/browse/TS-3837 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Affects Versions: 6.1.0 Reporter: Sudheer Vinukonda The setting *proxy.config.http.wait_for_cache* allows to let traffic_server wait for the cache to initialize before processing requests (it basically blocks accepts). This is fine when cache is configured, but, if there are no disks configured in *storage.config*, this setting makes requests wait indefinitely. Ideally, the setting should consider cache initialized (disabled) when no disks are configured and just proxy the requests rather than block them forever. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.
Sudheer Vinukonda created TS-3837: - Summary: The setting wait_for_cache waits indefinitely even when there are no cache disks configured. Key: TS-3837 URL: https://issues.apache.org/jira/browse/TS-3837 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Sudheer Vinukonda The setting *proxy.config.http.wait_for_cache* allows to let traffic_server wait for the cache to initialize before processing requests (it basically blocks accepts). This is fine when cache is configured, but, if there are no disks configured in *storage.config*, this setting makes requests wait indefinitely. Ideally, the setting should consider cache initialized (disabled) when no disks are configured and just proxy the requests rather than block them forever. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3838) Alphabetize switches for help flag
Daniel Xu created TS-3838: - Summary: Alphabetize switches for help flag Key: TS-3838 URL: https://issues.apache.org/jira/browse/TS-3838 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Daniel Xu Eg. `./traffic_server -h` would print all the flags in alphabetized order. It would make it easier for the user to quickly find the flag they're looking for. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3777) TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS
[
https://issues.apache.org/jira/browse/TS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696094#comment-14696094
]
Sudheer Vinukonda edited comment on TS-3777 at 8/13/15 10:52 PM:
-
Does it make sense to always do the below for any requests marked internal
(independent of EOS)? We don't even allow/support plugins to reuse a pluginVC
connection for more than one request anyway?
{code}
t_state.client_info.keep_alive = HTTP_NO_KEEPALIVE;
t_state.client_info.pipeline_possible = false;
{code}
was (Author: sudheerv):
Does it make sense to always do the below for any requests marked internal
(independent of EOS)? We don't even allow/support plugins trying to reuse a
pluginVC connection for more than one request anyway?
{code}
t_state.client_info.keep_alive = HTTP_NO_KEEPALIVE;
t_state.client_info.pipeline_possible = false;
{code}
TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor
TS_VCONN_EOS
Key: TS-3777
URL: https://issues.apache.org/jira/browse/TS-3777
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Daniel Vitor Morilha
Assignee: Susan Hinrichs
Labels: yahoo
Fix For: 6.1.0
Attachments: ts-3777-2.diff, ts-3777.diff
When using TSHttpConnect to connect to ATS itself (internal vconnection),
sending a POST request and receiving a CHUNKED response. ATS does not fire
neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
Trying to close the vconnection from the plug-in after receiving the last
chunk (\r\n0\r\n) results into the PluginVC repeating the following message:
{noformat}
[Jul 14 21:24:06.094] Server {0x77fbe800} DEBUG: (pvc_event) [0] Passive:
Received event 1
{noformat}
I am glad to provide an example if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3777) TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS
[
https://issues.apache.org/jira/browse/TS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696094#comment-14696094
]
Sudheer Vinukonda commented on TS-3777:
---
Does it make sense to always do the below for any requests marked internal
(independent of EOS)? We don't even allow/support plugins trying to reuse a
pluginVC connection for more than one request anyway?
{code}
t_state.client_info.keep_alive = HTTP_NO_KEEPALIVE;
t_state.client_info.pipeline_possible = false;
{code}
TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor
TS_VCONN_EOS
Key: TS-3777
URL: https://issues.apache.org/jira/browse/TS-3777
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Daniel Vitor Morilha
Assignee: Susan Hinrichs
Labels: yahoo
Fix For: 6.1.0
Attachments: ts-3777-2.diff, ts-3777.diff
When using TSHttpConnect to connect to ATS itself (internal vconnection),
sending a POST request and receiving a CHUNKED response. ATS does not fire
neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
Trying to close the vconnection from the plug-in after receiving the last
chunk (\r\n0\r\n) results into the PluginVC repeating the following message:
{noformat}
[Jul 14 21:24:06.094] Server {0x77fbe800} DEBUG: (pvc_event) [0] Passive:
Received event 1
{noformat}
I am glad to provide an example if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3838) Alphabetize switches for help flag
[ https://issues.apache.org/jira/browse/TS-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-3838: -- Labels: newbie (was: ) Priority: Minor (was: Major) Alphabetize switches for help flag -- Key: TS-3838 URL: https://issues.apache.org/jira/browse/TS-3838 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Daniel Xu Priority: Minor Labels: newbie Eg. `./traffic_server -h` would print all the flags in alphabetized order. It would make it easier for the user to quickly find the flag they're looking for. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3777) TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS
[
https://issues.apache.org/jira/browse/TS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-3777:
---
Attachment: ts-3777-2.diff
[~sudheerv], you are right. The internal flag is set. It was the
pipeline_possible flag that was triggering the half close flag.
It turns out that my original patch was missing setting some extra flags on EOS
in client_watch_for_abort. I had been testing on a branch with additional
fixes that I thought were independent. I was able to clear the
pipeline_possible flag there and remove the additional HttpClientSession
read_state state to fix the issue that Daniel was seeing.
The shorter patch is in ts-3777-2.diff. Actually running on this patch
directly. Will go ahead and run in production to verify no memory leak.
TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor
TS_VCONN_EOS
Key: TS-3777
URL: https://issues.apache.org/jira/browse/TS-3777
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Daniel Vitor Morilha
Assignee: Susan Hinrichs
Labels: yahoo
Fix For: 6.1.0
Attachments: ts-3777-2.diff, ts-3777.diff
When using TSHttpConnect to connect to ATS itself (internal vconnection),
sending a POST request and receiving a CHUNKED response. ATS does not fire
neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
Trying to close the vconnection from the plug-in after receiving the last
chunk (\r\n0\r\n) results into the PluginVC repeating the following message:
{noformat}
[Jul 14 21:24:06.094] Server {0x77fbe800} DEBUG: (pvc_event) [0] Passive:
Received event 1
{noformat}
I am glad to provide an example if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3740) header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
[
https://issues.apache.org/jira/browse/TS-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695916#comment-14695916
]
Gancho Tenev edited comment on TS-3740 at 8/13/15 8:50 PM:
---
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of PATH and in QSA mode
(appending query parameters to) when forming the Location header. TS-3740
patch always uses client request URI when replacing those variables to form the
Location header regardless of which hook condition matches while TS-3137
patch uses the corresponding URI at each particular hook (which is consistent
with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI to form Location header (it is always available regardless of which hook
condition matches, it fitted the above origin time-out use-case well and seemed
a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
was (Author: gancho):
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of %{PATH} and in QSA
mode (appending query parameters to) when forming the Location header.
TS-3740 patch always uses client request URI when replacing those variables to
form the Location header regardless of which hook condition matches while
TS-3137 patch uses the corresponding URI at each particular hook (which is
consistent with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI to form Location header (it is always available regardless of which hook
condition matches, it fitted the above origin time-out use-case well and seemed
a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
Key: TS-3740
URL: https://issues.apache.org/jira/browse/TS-3740
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Gancho Tenev
Assignee: Gancho Tenev
Fix For: 6.1.0
DESCRIPTION:
ATS header_rewrite plugin set-redirect operation doesn't work with
SEND_RESPONSE_HDR_HOOK. Please see the debugging notes below for more info.
HOW TO REPRODUCE:
Here is a sample plugin configuration files that reproduce the problem
$ cat /opt/ats/etc/trafficserver/remap.config
map http://p1 http://h1:8001 \
@plugin=header_rewrite.so
@pparam=/opt/ats/etc/trafficserver/header_rewrite.config
$ cat /opt/ats/etc/trafficserver/header_rewrite.config
cond %{SEND_RESPONSE_HDR_HOOK}
cond %{STATUS} =502
set-redirect 302 http://p0/%{PATH} [QSA]
DEBUGGING NOTES:
Both conditions in the header_rewrite.config are evaluated correctly but
set-redirect has no effect and the response to the UA is not modified as
expected. After some debugging it turned out that if the set-redirect
(OperatorSetDestination::exec) is not called from the remap plugin it has no
effect. The header_rewrite plugin creates a continuation to be called from
SEND_RESPONSE_HDR_HOOK (TSHttpHookAdd()). OperatorSetDestination::exec
doesn't have code to handle the case when the set-redirect operation is _not_
called directly from the remap plugin (TSRemapDoRemap()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3740) header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
[
https://issues.apache.org/jira/browse/TS-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695916#comment-14695916
]
Gancho Tenev commented on TS-3740:
--
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of %{PATH} and in QSA
mode (appending query parameters to) when forming the Location header.
TS-3740 patch always uses client request URI when replacing those variables to
form the Location header regardless of which hook condition matches while
TS-3137 patch uses the corresponding URI at each particular hook (which is
consistent with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI to form Location header (it is always available regardless of which hook
condition matches, it fitted the above origin time-out use-case well and seemed
a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
Key: TS-3740
URL: https://issues.apache.org/jira/browse/TS-3740
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Gancho Tenev
Assignee: Gancho Tenev
Fix For: 6.1.0
DESCRIPTION:
ATS header_rewrite plugin set-redirect operation doesn't work with
SEND_RESPONSE_HDR_HOOK. Please see the debugging notes below for more info.
HOW TO REPRODUCE:
Here is a sample plugin configuration files that reproduce the problem
$ cat /opt/ats/etc/trafficserver/remap.config
map http://p1 http://h1:8001 \
@plugin=header_rewrite.so
@pparam=/opt/ats/etc/trafficserver/header_rewrite.config
$ cat /opt/ats/etc/trafficserver/header_rewrite.config
cond %{SEND_RESPONSE_HDR_HOOK}
cond %{STATUS} =502
set-redirect 302 http://p0/%{PATH} [QSA]
DEBUGGING NOTES:
Both conditions in the header_rewrite.config are evaluated correctly but
set-redirect has no effect and the response to the UA is not modified as
expected. After some debugging it turned out that if the set-redirect
(OperatorSetDestination::exec) is not called from the remap plugin it has no
effect. The header_rewrite plugin creates a continuation to be called from
SEND_RESPONSE_HDR_HOOK (TSHttpHookAdd()). OperatorSetDestination::exec
doesn't have code to handle the case when the set-redirect operation is _not_
called directly from the remap plugin (TSRemapDoRemap()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3740) header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
[
https://issues.apache.org/jira/browse/TS-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695916#comment-14695916
]
Gancho Tenev edited comment on TS-3740 at 8/13/15 8:55 PM:
---
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of PATH and in QSA mode
(appending query parameters) when forming the Location header. TS-3740 patch
always uses client request URI when replacing those variables to form the
Location header regardless of which hook condition matches while TS-3137
patch uses the corresponding URI at each particular hook (which is consistent
with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI when forming Location header (it is always available regardless of which
hook condition matches, it fitted the above origin time-out use-case well and
seemed a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
was (Author: gancho):
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of PATH and in QSA mode
(appending query parameters) when forming the Location header. TS-3740 patch
always uses client request URI when replacing those variables to form the
Location header regardless of which hook condition matches while TS-3137
patch uses the corresponding URI at each particular hook (which is consistent
with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI to form Location header (it is always available regardless of which hook
condition matches, it fitted the above origin time-out use-case well and seemed
a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
Key: TS-3740
URL: https://issues.apache.org/jira/browse/TS-3740
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Gancho Tenev
Assignee: Gancho Tenev
Fix For: 6.1.0
DESCRIPTION:
ATS header_rewrite plugin set-redirect operation doesn't work with
SEND_RESPONSE_HDR_HOOK. Please see the debugging notes below for more info.
HOW TO REPRODUCE:
Here is a sample plugin configuration files that reproduce the problem
$ cat /opt/ats/etc/trafficserver/remap.config
map http://p1 http://h1:8001 \
@plugin=header_rewrite.so
@pparam=/opt/ats/etc/trafficserver/header_rewrite.config
$ cat /opt/ats/etc/trafficserver/header_rewrite.config
cond %{SEND_RESPONSE_HDR_HOOK}
cond %{STATUS} =502
set-redirect 302 http://p0/%{PATH} [QSA]
DEBUGGING NOTES:
Both conditions in the header_rewrite.config are evaluated correctly but
set-redirect has no effect and the response to the UA is not modified as
expected. After some debugging it turned out that if the set-redirect
(OperatorSetDestination::exec) is not called from the remap plugin it has no
effect. The header_rewrite plugin creates a continuation to be called from
SEND_RESPONSE_HDR_HOOK (TSHttpHookAdd()). OperatorSetDestination::exec
doesn't have code to handle the case when the set-redirect operation is _not_
called directly from the remap plugin (TSRemapDoRemap()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Build failed in Jenkins: tsqa-master #781
See https://ci.trafficserver.apache.org/job/tsqa-master/781/changes
Changes:
[Bryan Call] TS-3752: Problem with larger headers and HTTP/2
--
Started by upstream project out_of_tree-master build number 1084
originally caused by:
Started by an SCM change
Started by upstream project in_tree-master build number 1303
originally caused by:
Started by an SCM change
Building remotely on QA3 (qa) in workspace
https://ci.trafficserver.apache.org/job/tsqa-master/ws/
/usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
/usr/bin/git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/trafficserver.git # timeout=10
Cleaning workspace
/usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
/usr/bin/git reset --hard # timeout=10
/usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/trafficserver.git
/usr/bin/git --version # timeout=10
/usr/bin/git -c core.askpass=true fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/trafficserver.git
+refs/heads/*:refs/remotes/origin/*
/usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
/usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} #
timeout=10
Checking out Revision a5818b350d48ea14598d1c876124b393a936f3c9
(refs/remotes/origin/master)
/usr/bin/git config core.sparsecheckout # timeout=10
/usr/bin/git checkout -f a5818b350d48ea14598d1c876124b393a936f3c9
/usr/bin/git rev-list b7f4314069318c6f3b6ab9fd504e7f5525cbb96c # timeout=10
[tsqa-master] $ /bin/bash -xe /tmp/hudson6524351973017427172.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test tsqa-master '!=' tsqa-master
++ ATS_MAKE=make
++ test tsqa-master '!=' tsqa-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=08132015
++ TODAY=08132015
++ ATS_BRANCH=master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ export ATS_BRANCH
++ test tsqa-master '!=' tsqa-master
+ source /home/jenkins/bin/tsqa.sh
++ TSQA_LAYOUT_DIR=https://ci.trafficserver.apache.org/job/tsqa-master/ws/781
++ cd https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa
++ make test
New python executable in virtualenv/bin/python
Installing
Setuptools..done.
Installing
Pip.done.
make update
make[1]: Entering directory
`https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa'
Exception:
Traceback (most recent call last):
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/basecommand.py;,
line 134, in main
status = self.run(options, args)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/commands/install.py;,
line 220, in run
for req in parse_requirements(filename, finder=finder, options=options):
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 1477, in parse_requirements
req = InstallRequirement.from_line(line, comes_from,
prereleases=getattr(options, pre, None))
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 129, in from_line
return cls(req, comes_from, url=url, prereleases=prereleases)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 44, in __init__
req = pkg_resources.Requirement.parse(req)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pkg_resources.py;,
line 2914, in parse
reqs = list(parse_requirements(s))
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pkg_resources.py;,
line 2839, in
[jira] [Comment Edited] (TS-3740) header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
[
https://issues.apache.org/jira/browse/TS-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695916#comment-14695916
]
Gancho Tenev edited comment on TS-3740 at 8/13/15 8:56 PM:
---
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of PATH and in QSA mode
(appending query parameters) when forming the Location header. TS-3740 patch
always uses client request URI when replacing those variables to form the
Location header regardless of which hook condition matches while TS-3137
patch uses the corresponding URI at each particular hook (which is consistent
with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI when forming Location header (it is always available regardless of which
hook condition matches, it fitted the above origin time-out use-case well and
seemed a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
was (Author: gancho):
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of PATH and in QSA mode
(appending query parameters) when forming the Location header. TS-3740 patch
always uses client request URI when replacing those variables to form the
Location header regardless of which hook condition matches while TS-3137
patch uses the corresponding URI at each particular hook (which is consistent
with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI when forming Location header (it is always available regardless of which
hook condition matches, it fitted the above origin time-out use-case well and
seemed a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
Key: TS-3740
URL: https://issues.apache.org/jira/browse/TS-3740
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Gancho Tenev
Assignee: Gancho Tenev
Fix For: 6.1.0
DESCRIPTION:
ATS header_rewrite plugin set-redirect operation doesn't work with
SEND_RESPONSE_HDR_HOOK. Please see the debugging notes below for more info.
HOW TO REPRODUCE:
Here is a sample plugin configuration files that reproduce the problem
$ cat /opt/ats/etc/trafficserver/remap.config
map http://p1 http://h1:8001 \
@plugin=header_rewrite.so
@pparam=/opt/ats/etc/trafficserver/header_rewrite.config
$ cat /opt/ats/etc/trafficserver/header_rewrite.config
cond %{SEND_RESPONSE_HDR_HOOK}
cond %{STATUS} =502
set-redirect 302 http://p0/%{PATH} [QSA]
DEBUGGING NOTES:
Both conditions in the header_rewrite.config are evaluated correctly but
set-redirect has no effect and the response to the UA is not modified as
expected. After some debugging it turned out that if the set-redirect
(OperatorSetDestination::exec) is not called from the remap plugin it has no
effect. The header_rewrite plugin creates a continuation to be called from
SEND_RESPONSE_HDR_HOOK (TSHttpHookAdd()). OperatorSetDestination::exec
doesn't have code to handle the case when the set-redirect operation is _not_
called directly from the remap plugin (TSRemapDoRemap()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: tsqa-lint #439
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
[jira] [Commented] (TS-3752) Problem with larger headers and HTTP/2
[ https://issues.apache.org/jira/browse/TS-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695921#comment-14695921 ] ASF GitHub Bot commented on TS-3752: Github user bryancall commented on the pull request: https://github.com/apache/trafficserver/pull/276#issuecomment-130838839 Looks good so far, I am going to test it. Problem with larger headers and HTTP/2 -- Key: TS-3752 URL: https://issues.apache.org/jira/browse/TS-3752 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Assignee: Masaori Koshiba Labels: yahoo Fix For: 6.0.0 There is a problem when ATS receives a HEADERS or CONTINUATION frame on the HEADERS frame and there is no end of header to be decoded. If there is 1 small header at the beginning of the frame it will work, but if a large header either starts at the beginning of the frame or started on the previous frame and don't end until the next frame then the decoded_bytes will be 0. This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3740) header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
[
https://issues.apache.org/jira/browse/TS-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695916#comment-14695916
]
Gancho Tenev edited comment on TS-3740 at 8/13/15 8:52 PM:
---
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of PATH and in QSA mode
(appending query parameters) when forming the Location header. TS-3740 patch
always uses client request URI when replacing those variables to form the
Location header regardless of which hook condition matches while TS-3137
patch uses the corresponding URI at each particular hook (which is consistent
with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI to form Location header (it is always available regardless of which hook
condition matches, it fitted the above origin time-out use-case well and seemed
a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
was (Author: gancho):
Yes, just by reading around the 2 patches (didn't have a chance to experiment
with TS-3137 patch) it seems that they are meant to accomplish the same thing -
enable set-redirect operation when not called from the remap plugin.
There is an important difference in the replacing of PATH and in QSA mode
(appending query parameters to) when forming the Location header. TS-3740
patch always uses client request URI when replacing those variables to form the
Location header regardless of which hook condition matches while TS-3137
patch uses the corresponding URI at each particular hook (which is consistent
with the way set-destination is implemented).
I don't have visibility of all header-rewrite use-cases but it seems that
although at the time it looked more reasonable to always use the client request
URI to form Location header (it is always available regardless of which hook
condition matches, it fitted the above origin time-out use-case well and seemed
a more straightforward way to configure the redirects), it may be more
reasonable to do it in TS-3137 way (which looks also more consistent with
set-destination operation implementation as well).
Any ideas and opinions are appreciated!
header_rewrite plugin: set-redirect doesn't work with SEND_RESPONSE_HDR_HOOK
Key: TS-3740
URL: https://issues.apache.org/jira/browse/TS-3740
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Gancho Tenev
Assignee: Gancho Tenev
Fix For: 6.1.0
DESCRIPTION:
ATS header_rewrite plugin set-redirect operation doesn't work with
SEND_RESPONSE_HDR_HOOK. Please see the debugging notes below for more info.
HOW TO REPRODUCE:
Here is a sample plugin configuration files that reproduce the problem
$ cat /opt/ats/etc/trafficserver/remap.config
map http://p1 http://h1:8001 \
@plugin=header_rewrite.so
@pparam=/opt/ats/etc/trafficserver/header_rewrite.config
$ cat /opt/ats/etc/trafficserver/header_rewrite.config
cond %{SEND_RESPONSE_HDR_HOOK}
cond %{STATUS} =502
set-redirect 302 http://p0/%{PATH} [QSA]
DEBUGGING NOTES:
Both conditions in the header_rewrite.config are evaluated correctly but
set-redirect has no effect and the response to the UA is not modified as
expected. After some debugging it turned out that if the set-redirect
(OperatorSetDestination::exec) is not called from the remap plugin it has no
effect. The header_rewrite plugin creates a continuation to be called from
SEND_RESPONSE_HDR_HOOK (TSHttpHookAdd()). OperatorSetDestination::exec
doesn't have code to handle the case when the set-redirect operation is _not_
called directly from the remap plugin (TSRemapDoRemap()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3839) Regression test fails by new overridable setting
Gota Adachi created TS-3839:
---
Summary: Regression test fails by new overridable setting
Key: TS-3839
URL: https://issues.apache.org/jira/browse/TS-3839
Project: Traffic Server
Issue Type: Bug
Reporter: Gota Adachi
Regression test fails by modifications related to TS-3835 .
{code}
$ sudo /usr/local/bin/traffic_server -R 3
traffic_server: using root directory '/usr/local'
REGRESSION_TEST initialization begun
REGRESSION TEST Hdrs started
...
[SDK_API_ENCODING] TSBase64Decode : [TestCase1] PASS { ok }
REGRESSION_RESULT SDK_API_ENCODING: PASSED
REGRESSION TEST SDK_API_OVERRIDABLE_CONFIGS started
FATAL: InkAPI.cc:8118: failed assert `sdk_sanity_check_null_ptr((void *)name)
== TS_SUCCESS`
traffic_server: Aborted (Signal sent by tkill() 13831 99)traffic_server - STACK
TRACE:
/usr/local/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4a53a9]
/lib64/libc.so.6(+0x326a0)[0x7f92848cb6a0]
/lib64/libc.so.6(gsignal+0x35)[0x7f92848cb625]
/lib64/libc.so.6(abort+0x175)[0x7f92848cce05]
/usr/local/lib/libtsutil.so.6(+0x28c03)[0x7f9286d60c03]
/usr/local/lib/libtsutil.so.6(+0x28c9d)[0x7f9286d60c9d]
/usr/local/lib/libtsutil.so.6(+0x266a5)[0x7f9286d5e6a5]
/usr/local/bin/traffic_server(TSHttpTxnConfigFind+0xa4)[0x4ba824]
/usr/local/bin/traffic_server(_Z42RegressionTest_SDK_API_OVERRIDABLE_CONFIGSP14RegressionTestiPi+0x122)[0x4f2342]
/usr/local/lib/libtsutil.so.6(_ZN14RegressionTest3runEPc+0xb3)[0x7f9286d5a2d3]
/usr/local/bin/traffic_server(_ZN14RegressionCont9mainEventEiP5Event+0x75)[0x4d7fd5]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x7417a5]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6a3)[0x7422c3]
/usr/local/bin/traffic_server[0x740c1a]
/lib64/libpthread.so.0(+0x79d1)[0x7f92846839d1]
/lib64/libc.so.6(clone+0x6d)[0x7f92849818fd]
{code}
It seems to lack added config name in SDK_Overridable_Configs[].
{noformat}
diff --git a/proxy/InkAPITest.cc b/proxy/InkAPITest.cc
index 704a759..5fefdb3 100644
--- a/proxy/InkAPITest.cc
+++ b/proxy/InkAPITest.cc
@@ -7207,7 +7207,7 @@ const char *SDK_Overridable_Configs[TS_CONFIG_LAST_ENTRY]
= {
proxy.config.http.cache.max_open_read_retries,
proxy.config.http.cache.range.write,
proxy.config.http.post.check.content_length.enabled,
proxy.config.http.global_user_agent_header,
proxy.config.http.auth_server_session_private,
proxy.config.http.slow.log.threshold, proxy.config.http.cache.generation,
- proxy.config.body_factory.template_base};
+ proxy.config.body_factory.template_base,
proxy.config.http.cache.open_write_fail_action};
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS)(RegressionTest *test, int /*
atype ATS_UNUSED */, int *pstatus)
{
{noformat}
this patch fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3840) net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
[
https://issues.apache.org/jira/browse/TS-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit updated TS-3840:
Description:
when some https sites with ats 5.2.0
sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome
It disappear when refresh the page(ctrl+f5)
{code}
#CONFIG proxy.config.http.server_ports STRING 80 81 8085 443:proto=spdy;http:ssl
{code}
was:
when some https sites with ats 5.2.0
sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome
It disappear when refresh the page(ctrl+f5)
net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
---
Key: TS-3840
URL: https://issues.apache.org/jira/browse/TS-3840
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 5.2.0
Reporter: bettydramit
Labels: https
when some https sites with ats 5.2.0
sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome
It disappear when refresh the page(ctrl+f5)
{code}
#CONFIG proxy.config.http.server_ports STRING 80 81 8085
443:proto=spdy;http:ssl
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3839) Regression test fails by new overridable setting
[
https://issues.apache.org/jira/browse/TS-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gota Adachi updated TS-3839:
Component/s: Core
Regression test fails by new overridable setting
Key: TS-3839
URL: https://issues.apache.org/jira/browse/TS-3839
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Gota Adachi
Regression test fails by modifications related to TS-3835 .
{code}
$ sudo /usr/local/bin/traffic_server -R 3
traffic_server: using root directory '/usr/local'
REGRESSION_TEST initialization begun
REGRESSION TEST Hdrs started
...
[SDK_API_ENCODING] TSBase64Decode : [TestCase1] PASS { ok }
REGRESSION_RESULT SDK_API_ENCODING: PASSED
REGRESSION TEST SDK_API_OVERRIDABLE_CONFIGS started
FATAL: InkAPI.cc:8118: failed assert `sdk_sanity_check_null_ptr((void *)name)
== TS_SUCCESS`
traffic_server: Aborted (Signal sent by tkill() 13831 99)traffic_server -
STACK TRACE:
/usr/local/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4a53a9]
/lib64/libc.so.6(+0x326a0)[0x7f92848cb6a0]
/lib64/libc.so.6(gsignal+0x35)[0x7f92848cb625]
/lib64/libc.so.6(abort+0x175)[0x7f92848cce05]
/usr/local/lib/libtsutil.so.6(+0x28c03)[0x7f9286d60c03]
/usr/local/lib/libtsutil.so.6(+0x28c9d)[0x7f9286d60c9d]
/usr/local/lib/libtsutil.so.6(+0x266a5)[0x7f9286d5e6a5]
/usr/local/bin/traffic_server(TSHttpTxnConfigFind+0xa4)[0x4ba824]
/usr/local/bin/traffic_server(_Z42RegressionTest_SDK_API_OVERRIDABLE_CONFIGSP14RegressionTestiPi+0x122)[0x4f2342]
/usr/local/lib/libtsutil.so.6(_ZN14RegressionTest3runEPc+0xb3)[0x7f9286d5a2d3]
/usr/local/bin/traffic_server(_ZN14RegressionCont9mainEventEiP5Event+0x75)[0x4d7fd5]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x7417a5]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6a3)[0x7422c3]
/usr/local/bin/traffic_server[0x740c1a]
/lib64/libpthread.so.0(+0x79d1)[0x7f92846839d1]
/lib64/libc.so.6(clone+0x6d)[0x7f92849818fd]
{code}
It seems to lack added config name in SDK_Overridable_Configs[].
{noformat}
diff --git a/proxy/InkAPITest.cc b/proxy/InkAPITest.cc
index 704a759..5fefdb3 100644
--- a/proxy/InkAPITest.cc
+++ b/proxy/InkAPITest.cc
@@ -7207,7 +7207,7 @@ const char
*SDK_Overridable_Configs[TS_CONFIG_LAST_ENTRY] = {
proxy.config.http.cache.max_open_read_retries,
proxy.config.http.cache.range.write,
proxy.config.http.post.check.content_length.enabled,
proxy.config.http.global_user_agent_header,
proxy.config.http.auth_server_session_private,
proxy.config.http.slow.log.threshold, proxy.config.http.cache.generation,
- proxy.config.body_factory.template_base};
+ proxy.config.body_factory.template_base,
proxy.config.http.cache.open_write_fail_action};
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS)(RegressionTest *test, int /*
atype ATS_UNUSED */, int *pstatus)
{
{noformat}
this patch fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Build failed in Jenkins: tsqa-master #782
See https://ci.trafficserver.apache.org/job/tsqa-master/782/changes
Changes:
[James Peach] TS-3839: Fix overrideable config regression tests
--
Started by upstream project out_of_tree-master build number 1085
originally caused by:
Started by an SCM change
Started by upstream project in_tree-master build number 1304
originally caused by:
Started by an SCM change
Building remotely on QA3 (qa) in workspace
https://ci.trafficserver.apache.org/job/tsqa-master/ws/
/usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
/usr/bin/git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/trafficserver.git # timeout=10
Cleaning workspace
/usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
/usr/bin/git reset --hard # timeout=10
/usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/trafficserver.git
/usr/bin/git --version # timeout=10
/usr/bin/git -c core.askpass=true fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/trafficserver.git
+refs/heads/*:refs/remotes/origin/*
/usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
/usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} #
timeout=10
Checking out Revision 6fcff147bc8de214b0f511cb9fcaa32fd5c6187e
(refs/remotes/origin/master)
/usr/bin/git config core.sparsecheckout # timeout=10
/usr/bin/git checkout -f 6fcff147bc8de214b0f511cb9fcaa32fd5c6187e
/usr/bin/git rev-list a5818b350d48ea14598d1c876124b393a936f3c9 # timeout=10
[tsqa-master] $ /bin/bash -xe /tmp/hudson2712543035977830990.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test tsqa-master '!=' tsqa-master
++ ATS_MAKE=make
++ test tsqa-master '!=' tsqa-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=08142015
++ TODAY=08142015
++ ATS_BRANCH=master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ export ATS_BRANCH
++ test tsqa-master '!=' tsqa-master
+ source /home/jenkins/bin/tsqa.sh
++ TSQA_LAYOUT_DIR=https://ci.trafficserver.apache.org/job/tsqa-master/ws/782
++ cd https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa
++ make test
New python executable in virtualenv/bin/python
Installing
Setuptools..done.
Installing
Pip.done.
make update
make[1]: Entering directory
`https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa'
Exception:
Traceback (most recent call last):
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/basecommand.py;,
line 134, in main
status = self.run(options, args)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/commands/install.py;,
line 220, in run
for req in parse_requirements(filename, finder=finder, options=options):
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 1477, in parse_requirements
req = InstallRequirement.from_line(line, comes_from,
prereleases=getattr(options, pre, None))
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 129, in from_line
return cls(req, comes_from, url=url, prereleases=prereleases)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 44, in __init__
req = pkg_resources.Requirement.parse(req)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pkg_resources.py;,
line 2914, in parse
reqs = list(parse_requirements(s))
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pkg_resources.py;,
line 2839, in
Jenkins build is still unstable: tsqa-lint #440
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
Jenkins build is still unstable: tsqa-lint #441
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
[jira] [Updated] (TS-3840) net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
[ https://issues.apache.org/jira/browse/TS-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-3840: Affects Version/s: 5.2.0 net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes --- Key: TS-3840 URL: https://issues.apache.org/jira/browse/TS-3840 Project: Traffic Server Issue Type: Bug Affects Versions: 5.2.0 Reporter: bettydramit Labels: https when some https sites with ats 5.2.0 sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome It disappear when refresh the page(ctrl+f5) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3840) net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
[ https://issues.apache.org/jira/browse/TS-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-3840: Labels: https (was: ) net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes --- Key: TS-3840 URL: https://issues.apache.org/jira/browse/TS-3840 Project: Traffic Server Issue Type: Bug Affects Versions: 5.2.0 Reporter: bettydramit Labels: https when some https sites with ats 5.2.0 sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome It disappear when refresh the page(ctrl+f5) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3840) net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
bettydramit created TS-3840: --- Summary: net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes Key: TS-3840 URL: https://issues.apache.org/jira/browse/TS-3840 Project: Traffic Server Issue Type: Bug Reporter: bettydramit when some https sites with ats 5.2.0 sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome It disappear when refresh the page(ctrl+f5) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3752) Problem with larger headers and HTTP/2
[ https://issues.apache.org/jira/browse/TS-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696275#comment-14696275 ] ASF GitHub Bot commented on TS-3752: Github user masaori335 commented on the pull request: https://github.com/apache/trafficserver/pull/276#issuecomment-130907474 Rebased a5818b350d48ea14598d1c876124b393a936f3c9 Problem with larger headers and HTTP/2 -- Key: TS-3752 URL: https://issues.apache.org/jira/browse/TS-3752 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Assignee: Masaori Koshiba Labels: yahoo Fix For: 6.0.0 There is a problem when ATS receives a HEADERS or CONTINUATION frame on the HEADERS frame and there is no end of header to be decoded. If there is 1 small header at the beginning of the frame it will work, but if a large header either starts at the beginning of the frame or started on the previous frame and don't end until the next frame then the decoded_bytes will be 0. This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3839) Regression test fails by new overridable setting
[
https://issues.apache.org/jira/browse/TS-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696420#comment-14696420
]
ASF subversion and git services commented on TS-3839:
-
Commit 6fcff147bc8de214b0f511cb9fcaa32fd5c6187e in trafficserver's branch
refs/heads/master from [~g-adachi]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6fcff14 ]
TS-3839: Fix overrideable config regression tests
Regression test fails by new overridable setting
Key: TS-3839
URL: https://issues.apache.org/jira/browse/TS-3839
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Gota Adachi
Fix For: 6.0.0
Regression test fails by modifications related to TS-3835 .
{code}
$ sudo /usr/local/bin/traffic_server -R 3
traffic_server: using root directory '/usr/local'
REGRESSION_TEST initialization begun
REGRESSION TEST Hdrs started
...
[SDK_API_ENCODING] TSBase64Decode : [TestCase1] PASS { ok }
REGRESSION_RESULT SDK_API_ENCODING: PASSED
REGRESSION TEST SDK_API_OVERRIDABLE_CONFIGS started
FATAL: InkAPI.cc:8118: failed assert `sdk_sanity_check_null_ptr((void *)name)
== TS_SUCCESS`
traffic_server: Aborted (Signal sent by tkill() 13831 99)traffic_server -
STACK TRACE:
/usr/local/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4a53a9]
/lib64/libc.so.6(+0x326a0)[0x7f92848cb6a0]
/lib64/libc.so.6(gsignal+0x35)[0x7f92848cb625]
/lib64/libc.so.6(abort+0x175)[0x7f92848cce05]
/usr/local/lib/libtsutil.so.6(+0x28c03)[0x7f9286d60c03]
/usr/local/lib/libtsutil.so.6(+0x28c9d)[0x7f9286d60c9d]
/usr/local/lib/libtsutil.so.6(+0x266a5)[0x7f9286d5e6a5]
/usr/local/bin/traffic_server(TSHttpTxnConfigFind+0xa4)[0x4ba824]
/usr/local/bin/traffic_server(_Z42RegressionTest_SDK_API_OVERRIDABLE_CONFIGSP14RegressionTestiPi+0x122)[0x4f2342]
/usr/local/lib/libtsutil.so.6(_ZN14RegressionTest3runEPc+0xb3)[0x7f9286d5a2d3]
/usr/local/bin/traffic_server(_ZN14RegressionCont9mainEventEiP5Event+0x75)[0x4d7fd5]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x7417a5]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6a3)[0x7422c3]
/usr/local/bin/traffic_server[0x740c1a]
/lib64/libpthread.so.0(+0x79d1)[0x7f92846839d1]
/lib64/libc.so.6(clone+0x6d)[0x7f92849818fd]
{code}
It seems to lack added config name in SDK_Overridable_Configs[].
{noformat}
diff --git a/proxy/InkAPITest.cc b/proxy/InkAPITest.cc
index 704a759..5fefdb3 100644
--- a/proxy/InkAPITest.cc
+++ b/proxy/InkAPITest.cc
@@ -7207,7 +7207,7 @@ const char
*SDK_Overridable_Configs[TS_CONFIG_LAST_ENTRY] = {
proxy.config.http.cache.max_open_read_retries,
proxy.config.http.cache.range.write,
proxy.config.http.post.check.content_length.enabled,
proxy.config.http.global_user_agent_header,
proxy.config.http.auth_server_session_private,
proxy.config.http.slow.log.threshold, proxy.config.http.cache.generation,
- proxy.config.body_factory.template_base};
+ proxy.config.body_factory.template_base,
proxy.config.http.cache.open_write_fail_action};
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS)(RegressionTest *test, int /*
atype ATS_UNUSED */, int *pstatus)
{
{noformat}
this patch fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3839) Regression test fails by new overridable setting
[
https://issues.apache.org/jira/browse/TS-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-3839.
-
Resolution: Fixed
Assignee: James Peach
Fix Version/s: 6.0.0
Thanks!
Regression test fails by new overridable setting
Key: TS-3839
URL: https://issues.apache.org/jira/browse/TS-3839
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Gota Adachi
Assignee: James Peach
Fix For: 6.0.0
Regression test fails by modifications related to TS-3835 .
{code}
$ sudo /usr/local/bin/traffic_server -R 3
traffic_server: using root directory '/usr/local'
REGRESSION_TEST initialization begun
REGRESSION TEST Hdrs started
...
[SDK_API_ENCODING] TSBase64Decode : [TestCase1] PASS { ok }
REGRESSION_RESULT SDK_API_ENCODING: PASSED
REGRESSION TEST SDK_API_OVERRIDABLE_CONFIGS started
FATAL: InkAPI.cc:8118: failed assert `sdk_sanity_check_null_ptr((void *)name)
== TS_SUCCESS`
traffic_server: Aborted (Signal sent by tkill() 13831 99)traffic_server -
STACK TRACE:
/usr/local/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4a53a9]
/lib64/libc.so.6(+0x326a0)[0x7f92848cb6a0]
/lib64/libc.so.6(gsignal+0x35)[0x7f92848cb625]
/lib64/libc.so.6(abort+0x175)[0x7f92848cce05]
/usr/local/lib/libtsutil.so.6(+0x28c03)[0x7f9286d60c03]
/usr/local/lib/libtsutil.so.6(+0x28c9d)[0x7f9286d60c9d]
/usr/local/lib/libtsutil.so.6(+0x266a5)[0x7f9286d5e6a5]
/usr/local/bin/traffic_server(TSHttpTxnConfigFind+0xa4)[0x4ba824]
/usr/local/bin/traffic_server(_Z42RegressionTest_SDK_API_OVERRIDABLE_CONFIGSP14RegressionTestiPi+0x122)[0x4f2342]
/usr/local/lib/libtsutil.so.6(_ZN14RegressionTest3runEPc+0xb3)[0x7f9286d5a2d3]
/usr/local/bin/traffic_server(_ZN14RegressionCont9mainEventEiP5Event+0x75)[0x4d7fd5]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x7417a5]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6a3)[0x7422c3]
/usr/local/bin/traffic_server[0x740c1a]
/lib64/libpthread.so.0(+0x79d1)[0x7f92846839d1]
/lib64/libc.so.6(clone+0x6d)[0x7f92849818fd]
{code}
It seems to lack added config name in SDK_Overridable_Configs[].
{noformat}
diff --git a/proxy/InkAPITest.cc b/proxy/InkAPITest.cc
index 704a759..5fefdb3 100644
--- a/proxy/InkAPITest.cc
+++ b/proxy/InkAPITest.cc
@@ -7207,7 +7207,7 @@ const char
*SDK_Overridable_Configs[TS_CONFIG_LAST_ENTRY] = {
proxy.config.http.cache.max_open_read_retries,
proxy.config.http.cache.range.write,
proxy.config.http.post.check.content_length.enabled,
proxy.config.http.global_user_agent_header,
proxy.config.http.auth_server_session_private,
proxy.config.http.slow.log.threshold, proxy.config.http.cache.generation,
- proxy.config.body_factory.template_base};
+ proxy.config.body_factory.template_base,
proxy.config.http.cache.open_write_fail_action};
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS)(RegressionTest *test, int /*
atype ATS_UNUSED */, int *pstatus)
{
{noformat}
this patch fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3840) net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
[ https://issues.apache.org/jira/browse/TS-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-3840: Component/s: Cache net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes --- Key: TS-3840 URL: https://issues.apache.org/jira/browse/TS-3840 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.0 Reporter: bettydramit Labels: https when some https sites with ats 5.2.0 sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome It disappear when refresh the page(ctrl+f5) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3777) TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS
[
https://issues.apache.org/jira/browse/TS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695472#comment-14695472
]
Sudheer Vinukonda commented on TS-3777:
---
AFAIK, TSHttpConnect should already mark the request as internal by default,
unless specified otherwise using fetch flags. SPDY/H2 explicitly mark the
request as non-internal, despite using PluginVC/FetchSM.
Also, FWICT based on the references to the internal request status, it seems to
be explicitly added for this exact problem you are trying to solve with TS-3640
(the half_close flag is skipped for internal requests). So, I'm curious to know
why/how the plugin's request is not marked internal.
TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor
TS_VCONN_EOS
Key: TS-3777
URL: https://issues.apache.org/jira/browse/TS-3777
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Daniel Vitor Morilha
Assignee: Susan Hinrichs
Labels: yahoo
Fix For: 6.1.0
Attachments: ts-3777.diff
When using TSHttpConnect to connect to ATS itself (internal vconnection),
sending a POST request and receiving a CHUNKED response. ATS does not fire
neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
Trying to close the vconnection from the plug-in after receiving the last
chunk (\r\n0\r\n) results into the PluginVC repeating the following message:
{noformat}
[Jul 14 21:24:06.094] Server {0x77fbe800} DEBUG: (pvc_event) [0] Passive:
Received event 1
{noformat}
I am glad to provide an example if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3840) net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
[
https://issues.apache.org/jira/browse/TS-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit updated TS-3840:
Description:
when some https sites with ats 5.2.0
sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome
It disappear when refresh the page(ctrl+f5)
{code}
CONFIG proxy.config.http.server_ports STRING 80 443:ssl
{code}
was:
when some https sites with ats 5.2.0
sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome
It disappear when refresh the page(ctrl+f5)
{code}
#CONFIG proxy.config.http.server_ports STRING 80 81 8085 443:proto=spdy;http:ssl
{code}
net::ERR_SSL_BAD_RECORD_MAC_ALERT sometimes
---
Key: TS-3840
URL: https://issues.apache.org/jira/browse/TS-3840
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 5.2.0
Reporter: bettydramit
Labels: https
when some https sites with ats 5.2.0
sometimes will be get net::ERR_SSL_BAD_RECORD_MAC_ALERT with chrome
It disappear when refresh the page(ctrl+f5)
{code}
CONFIG proxy.config.http.server_ports STRING 80 443:ssl
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3752) Problem with larger headers and HTTP/2
[ https://issues.apache.org/jira/browse/TS-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695953#comment-14695953 ] ASF subversion and git services commented on TS-3752: - Commit a5818b350d48ea14598d1c876124b393a936f3c9 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a5818b3 ] TS-3752: Problem with larger headers and HTTP/2 Added back in the debug messages Problem with larger headers and HTTP/2 -- Key: TS-3752 URL: https://issues.apache.org/jira/browse/TS-3752 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Assignee: Masaori Koshiba Labels: yahoo Fix For: 6.0.0 There is a problem when ATS receives a HEADERS or CONTINUATION frame on the HEADERS frame and there is no end of header to be decoded. If there is 1 small header at the beginning of the frame it will work, but if a large header either starts at the beginning of the frame or started on the previous frame and don't end until the next frame then the decoded_bytes will be 0. This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
