[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660666#comment-14660666 ] ASF GitHub Bot commented on TS-3828: Github user jpeach commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128482080 Other HTTP servers do send the Content-Length on HEAD requests; I think that we should do the same. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660886#comment-14660886 ] ASF GitHub Bot commented on TS-3828: Github user zizhong commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128524834 great points. Actually this patch will send the content length. The content length modified is only in the Http State structure but not in the real HDRs. The field TransferEncoding is deleted in the current implementation which will stay deleted in this patch. On Friday, August 7, 2015, James Peach notificati...@github.com wrote: Other HTTP servers do send the Content-Length on HEAD requests; I think that we should do the same. — Reply to this email directly or view it on GitHub https://github.com/apache/trafficserver/pull/271#issuecomment-128482080. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2536) Performance improvements to VariableExpander in header_rewrite
[ https://issues.apache.org/jira/browse/TS-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660874#comment-14660874 ] Leif Hedstrom commented on TS-2536: --- What we need here is an API that allows body factory style expansions via a plugin API. Give it a string (MIObuffer), with the log tags, and have it return a string (MIOBuffer) that is expanded. Performance improvements to VariableExpander in header_rewrite -- Key: TS-2536 URL: https://issues.apache.org/jira/browse/TS-2536 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Fix For: sometime It seems that VariableExpander gets instantiated and executed on every add-header operator. However, this seems rather suboptimal for a number of reasons: 1. It might not even be necessary (i.e. there might not be any % strings in the static string. 2. Perhaps even more important, we look for these strings on every request, even though if they are there, they would always be in the same position on every request. One suggestion would be to incorporate the VariableExpander state as part of parsing the configuration on startup / reload. Maybe it gets complicated when there are other expansions, but it still feels we can pre-parse these strings and get some ideas of what needs to be expanded once, and not on every request. This is similar to how e.g. the regex_remap plugin works, it recalculates the positions and expansion once only. Thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660900#comment-14660900 ] ASF GitHub Bot commented on TS-3828: Github user sudheerv commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128529543 Thanks @zizhong - that's nice to hear. Needless to say, I'm :+1: on the patch :) HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-3828: Assignee: Brian Geffon HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659710#comment-14659710 ] ASF GitHub Bot commented on TS-3828: GitHub user zizhong opened a pull request: https://github.com/apache/trafficserver/pull/271 TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked or Content-Length, ATS now waits for the http body which will never come. Then the ATS goes though several timeouts whose length is configured by the record called proxy.config.http.transaction_no_activity_timeout_out. You can merge this pull request into a Git repository by running: $ git pull https://github.com/zizhong/trafficserver TS-3828 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/271.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #271 commit aa9b94fab4020798b81a749f6e5994387f7a09c9 Author: Zizhong Zhang zizh...@linkedin.com Date: 2015-08-06T08:49:50Z TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked commit d7fa8ccdde14b205ebb6ce423df7313e69574794 Author: Zizhong Zhang zizh...@linkedin.com Date: 2015-08-06T08:51:54Z TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661238#comment-14661238 ] ASF subversion and git services commented on TS-3828: - Commit 84cfe45c4891df5ea1f5b06547727afe7c0beed9 in trafficserver's branch refs/heads/6.0.x from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=84cfe45 ] Merge branch 'master' into 6.0.x * master: TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS. ensure the Content-Length is passed over. TS-3829 Remove remnants of proxy.pac TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661236#comment-14661236
]
ASF subversion and git services commented on TS-3829:
-
Commit 84cfe45c4891df5ea1f5b06547727afe7c0beed9 in trafficserver's branch
refs/heads/6.0.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=84cfe45 ]
Merge branch 'master' into 6.0.x
* master:
TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked.
ADD TESTS. ensure the Content-Length is passed over.
TS-3829 Remove remnants of proxy.pac
TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked.
ADD TESTS
TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661232#comment-14661232
]
ASF subversion and git services commented on TS-3829:
-
Commit 1bf8746e0c60899a1f87fc6a47af2cceb55dd45a in trafficserver's branch
refs/heads/6.0.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1bf8746 ]
TS-3829 Remove remnants of proxy.pac
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661231#comment-14661231 ] ASF subversion and git services commented on TS-3828: - Commit d7fa8ccdde14b205ebb6ce423df7313e69574794 in trafficserver's branch refs/heads/6.0.x from [~zhangzizhong] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d7fa8cc ] TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661235#comment-14661235 ] ASF subversion and git services commented on TS-3828: - Commit 84cfe45c4891df5ea1f5b06547727afe7c0beed9 in trafficserver's branch refs/heads/6.0.x from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=84cfe45 ] Merge branch 'master' into 6.0.x * master: TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS. ensure the Content-Length is passed over. TS-3829 Remove remnants of proxy.pac TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661233#comment-14661233 ] ASF subversion and git services commented on TS-3828: - Commit a0f8567a2ad75b8c25781e9e20cdcfb208b1fe6b in trafficserver's branch refs/heads/6.0.x from [~zhangzizhong] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a0f8567 ] TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS. ensure the Content-Length is passed over. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661234#comment-14661234 ] ASF subversion and git services commented on TS-3828: - Commit 2f154297a749bc9da54ce4373ef7198dcd75fb02 in trafficserver's branch refs/heads/6.0.x from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2f15429 ] Merge branch 'TS-3828' of https://github.com/zizhong/trafficserver HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: tsqa-lint #419
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660976#comment-14660976 ] Brian Geffon commented on TS-3828: -- [~zwoop], I'll get this landed today. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660936#comment-14660936 ] Leif Hedstrom commented on TS-3828: --- [~briang] Go ahead and commit this on master, and they cherry-pick it to 6.0.x branch. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661172#comment-14661172 ] ASF subversion and git services commented on TS-3828: - Commit d7fa8ccdde14b205ebb6ce423df7313e69574794 in trafficserver's branch refs/heads/master from [~zhangzizhong] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d7fa8cc ] TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661175#comment-14661175 ] ASF GitHub Bot commented on TS-3828: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/271 HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661171#comment-14661171 ] ASF subversion and git services commented on TS-3828: - Commit aa9b94fab4020798b81a749f6e5994387f7a09c9 in trafficserver's branch refs/heads/master from [~zhangzizhong] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=aa9b94f ] TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- 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=14660922#comment-14660922
]
Leif Hedstrom commented on TS-3740:
---
[~gancho] Is this at all related to TS-3137 ?
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: centos_7-master » gcc,centos_7,debug #1064
See https://ci.trafficserver.apache.org/job/centos_7-master/compiler=gcc,label=centos_7,type=debug/1064/ -- [...truncated 17767 lines...] *** TEST 51 *** STARTING *** *** TEST 51 *** PASSED *** *** TEST 52 *** STARTING *** *** TEST 52 *** PASSED *** *** TEST 53 *** STARTING *** *** TEST 53 *** PASSED *** *** TEST 54 *** STARTING *** *** TEST 54 *** PASSED *** *** TEST 55 *** STARTING *** *** TEST 55 *** PASSED *** *** TEST 56 *** STARTING *** *** TEST 56 *** PASSED *** *** TEST 57 *** STARTING *** *** TEST 57 *** PASSED *** *** TEST 58 *** STARTING *** *** TEST 58 *** PASSED *** *** TEST 59 *** STARTING *** *** TEST 59 *** PASSED *** *** TEST 60 *** STARTING *** *** TEST 60 *** PASSED *** *** TEST 61 *** STARTING *** *** TEST 61 *** PASSED *** *** TEST 62 *** STARTING *** *** TEST 62 *** PASSED *** *** TEST 63 *** STARTING *** *** TEST 63 *** PASSED *** *** TEST 64 *** STARTING *** *** TEST 64 *** PASSED *** *** TEST 65 *** STARTING *** *** TEST 65 *** PASSED *** *** TEST 66 *** STARTING *** *** TEST 66 *** PASSED *** *** TEST 67 *** STARTING *** *** TEST 67 *** PASSED *** *** TEST 68 *** STARTING *** *** TEST 68 *** PASSED *** *** TEST 69 *** STARTING *** *** TEST 69 *** PASSED *** *** TEST 70 *** STARTING *** *** TEST 70 *** PASSED *** *** TEST 71 *** STARTING *** *** TEST 71 *** PASSED *** *** TEST 72 *** STARTING *** *** TEST 72 *** PASSED *** *** TEST 73 *** STARTING *** *** TEST 73 *** PASSED *** *** TEST 74 *** STARTING *** *** TEST 74 *** PASSED *** *** TEST 75 *** STARTING *** *** TEST 75 *** PASSED *** *** TEST 76 *** STARTING *** *** TEST 76 *** PASSED *** *** TEST 77 *** STARTING *** *** TEST 77 *** PASSED *** *** TEST 78 *** STARTING *** *** TEST 78 *** PASSED *** *** TEST 79 *** STARTING *** *** TEST 79 *** PASSED *** *** TEST 80 *** STARTING *** *** TEST 80 *** PASSED *** *** TEST 81 *** STARTING *** *** TEST 81 *** PASSED *** *** TEST 82 *** STARTING *** *** TEST 82 *** PASSED *** *** TEST 83 *** STARTING *** *** TEST 83 *** PASSED *** *** TEST 84 *** STARTING *** *** TEST 84 *** PASSED *** *** TEST 85 *** STARTING *** *** TEST 85 *** PASSED *** *** TEST 86 *** STARTING *** *** TEST 86 *** PASSED *** *** TEST 87 *** STARTING *** *** TEST 87 *** PASSED *** *** TEST 88 *** STARTING *** *** TEST 88 *** PASSED *** *** TEST 89 *** STARTING *** *** TEST 89 *** PASSED *** *** TEST 90 *** STARTING *** *** TEST 90 *** PASSED *** *** TEST 91 *** STARTING *** *** TEST 91 *** PASSED *** *** TEST 92 *** STARTING *** *** TEST 92 *** PASSED *** *** TEST 93 *** STARTING *** *** TEST 93 *** PASSED *** *** TEST 94 *** STARTING *** *** TEST 94 *** PASSED *** *** TEST 95 *** STARTING *** *** TEST 95 *** PASSED *** *** TEST 96 *** STARTING *** *** TEST 96 *** PASSED *** *** TEST 97 *** STARTING *** *** TEST 97 *** PASSED *** *** TEST 98 *** STARTING *** *** TEST 98 *** PASSED *** *** TEST 99 *** STARTING *** *** TEST 99 *** PASSED *** *** TEST 100 *** STARTING *** *** TEST 100 *** PASSED *** *** TEST 101 *** STARTING *** *** TEST 101 *** PASSED *** *** TEST 102 *** STARTING *** *** TEST 102 *** PASSED *** *** TEST 103 *** STARTING *** *** TEST 103 *** PASSED *** *** TEST 104 *** STARTING *** *** TEST 104 *** PASSED *** *** TEST 105 *** STARTING *** *** TEST 105 *** PASSED *** *** TEST 106 *** STARTING *** *** TEST 106 *** PASSED *** *** TEST 107 *** STARTING *** *** TEST 107 *** PASSED *** *** TEST 108 *** STARTING *** *** TEST 108 *** PASSED *** *** TEST 109 *** STARTING *** *** TEST 109 *** PASSED *** *** TEST 110 *** STARTING *** *** TEST 110 *** PASSED *** *** TEST 111 *** STARTING *** *** TEST 111 *** PASSED *** *** TEST 112 *** STARTING *** *** TEST 112 *** PASSED *** *** TEST 113 *** STARTING *** *** TEST 113 *** PASSED *** *** TEST 114 *** STARTING *** *** TEST 114 *** PASSED *** *** TEST 115 *** STARTING *** *** TEST 115 *** PASSED *** *** TEST 116 *** STARTING *** *** TEST 116 *** PASSED *** *** TEST 117 *** STARTING *** *** TEST 117 *** PASSED *** *** TEST 118 *** STARTING *** *** TEST 118 *** PASSED *** *** TEST 119 *** STARTING *** *** TEST 119 *** PASSED *** *** TEST 120 *** STARTING *** *** TEST 120 *** PASSED *** *** TEST 121 *** STARTING *** *** TEST 121 *** PASSED *** *** TEST 122 *** STARTING *** *** TEST 122 *** PASSED *** *** TEST 123 *** STARTING *** *** TEST 123 *** PASSED *** *** TEST 124 *** STARTING *** *** TEST 124 *** PASSED *** *** TEST 125 *** STARTING *** *** TEST 125 *** PASSED *** *** TEST 126 *** STARTING *** *** TEST 126 *** PASSED *** *** TEST 127 *** STARTING *** *** TEST 127 *** PASSED *** *** TEST 128 *** STARTING *** *** TEST 128 *** PASSED *** *** TEST 129 *** STARTING *** *** TEST 129 *** PASSED *** *** TEST 130 *** STARTING *** *** TEST 130 *** PASSED *** *** TEST 131 *** STARTING *** *** TEST 131 *** PASSED *** *** TEST 132 *** STARTING *** *** TEST 132 *** PASSED *** *** TEST 133 *** STARTING *** *** TEST 133 *** PASSED *** *** TEST 134 *** STARTING *** *** TEST 134 *** PASSED *** *** TEST 135 *** STARTING *** *** TEST 135
[jira] [Updated] (TS-3819) H2 error logging
[ https://issues.apache.org/jira/browse/TS-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryo Okubo updated TS-3819: -- Attachment: h2_errorlog_0003.patch Regenerated my patch. [~zwoop] pelase look h2_errorlog_0003.patch H2 error logging Key: TS-3819 URL: https://issues.apache.org/jira/browse/TS-3819 Project: Traffic Server Issue Type: New Feature Components: HTTP/2 Reporter: Ryo Okubo Fix For: 6.0.0 Attachments: h2_errorlog_0001.patch, h2_errorlog_0002.patch, h2_errorlog_0003.patch RST_STREAM and GOAWAY may deliver [various errors|https://tools.ietf.org/html/rfc7540#section-7]. I want to record them to error.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3819) H2 error logging
[ https://issues.apache.org/jira/browse/TS-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661147#comment-14661147 ] Ryo Okubo edited comment on TS-3819 at 8/7/15 1:00 AM: --- Regenerated my patch. [~zwoop] please look h2_errorlog_0003.patch was (Author: rokubo): Regenerated my patch. [~zwoop] pelase look h2_errorlog_0003.patch H2 error logging Key: TS-3819 URL: https://issues.apache.org/jira/browse/TS-3819 Project: Traffic Server Issue Type: New Feature Components: HTTP/2 Reporter: Ryo Okubo Fix For: 6.0.0 Attachments: h2_errorlog_0001.patch, h2_errorlog_0002.patch, h2_errorlog_0003.patch RST_STREAM and GOAWAY may deliver [various errors|https://tools.ietf.org/html/rfc7540#section-7]. I want to record them to error.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3826) Traffic Server add message No Content to response when is 204 code.
[ https://issues.apache.org/jira/browse/TS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661159#comment-14661159 ] fengidri commented on TS-3826: -- Thanks, I found this code. So I thinks this is a bug. Will should fix this. Traffic Server add message No Content to response when is 204 code. - Key: TS-3826 URL: https://issues.apache.org/jira/browse/TS-3826 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 4.2.0 Reporter: fengidri Labels: newbie Fix For: 6.0.0 I found that When the 204 response is cached, the response from the cache will be added No Content message. Why? Anybody know this? Thanks!! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661174#comment-14661174 ] ASF subversion and git services commented on TS-3828: - Commit 2f154297a749bc9da54ce4373ef7198dcd75fb02 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2f15429 ] Merge branch 'TS-3828' of https://github.com/zizhong/trafficserver HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661176#comment-14661176 ] ASF GitHub Bot commented on TS-3828: Github user bgaff commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128559255 I've merged this into master, I'll now backport it to 6.0.x HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661173#comment-14661173 ] ASF subversion and git services commented on TS-3828: - Commit a0f8567a2ad75b8c25781e9e20cdcfb208b1fe6b in trafficserver's branch refs/heads/master from [~zhangzizhong] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a0f8567 ] TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked. ADD TESTS. ensure the Content-Length is passed over. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3829:
--
Fix Version/s: (was: 6.1.0)
6.0.0
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660933#comment-14660933 ] ASF GitHub Bot commented on TS-3828: Github user bgaff commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128533986 Great, I'm glad everyone is on board. Zizhong actually made sure to add a test to validate the case where the server sends a content-length. But I do see now that it's missing an assert on validating the content length is received by the client too, so @zizhong let's get that added to the tests and then I'll get this merged. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-3829.
---
Resolution: Fixed
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660932#comment-14660932
]
ASF subversion and git services commented on TS-3829:
-
Commit fdceeb5f6cee93dad7579fb56e37ee952fa0ad23 in trafficserver's branch
refs/heads/6.0.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fdceeb5 ]
TS-3829 Remove remnants of proxy.pac
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3829:
--
Backport to Version: (was: 6.0.0)
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3826) Traffic Server add message No Content to response when is 204 code.
[ https://issues.apache.org/jira/browse/TS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661159#comment-14661159 ] fengidri edited comment on TS-3826 at 8/7/15 1:18 AM: -- Thanks, I found this code. So I thinks this is a bug. We should fix this. was (Author: fengidri): Thanks, I found this code. So I thinks this is a bug. Will should fix this. Traffic Server add message No Content to response when is 204 code. - Key: TS-3826 URL: https://issues.apache.org/jira/browse/TS-3826 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 4.2.0 Reporter: fengidri Labels: newbie Fix For: 6.0.0 I found that When the 204 response is cached, the response from the cache will be added No Content message. Why? Anybody know this? Thanks!! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Build failed in Jenkins: tsqa-master #771
See https://ci.trafficserver.apache.org/job/tsqa-master/771/changes
Changes:
[Leif Hedstrom] TS-3829 Remove remnants of proxy.pac
--
Started by upstream project out_of_tree-master build number 1073
originally caused by:
Started by an SCM change
Started by upstream project in_tree-master build number 1292
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 1bf8746e0c60899a1f87fc6a47af2cceb55dd45a
(refs/remotes/origin/master)
/usr/bin/git config core.sparsecheckout # timeout=10
/usr/bin/git checkout -f 1bf8746e0c60899a1f87fc6a47af2cceb55dd45a
/usr/bin/git rev-list 559766411410f36a82f28632f8308cc2d20e74b0 # timeout=10
[tsqa-master] $ /bin/bash -xe /tmp/hudson7158432192605746490.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=08062015
++ TODAY=08062015
++ 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/771
++ 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] [Commented] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660971#comment-14660971
]
Brian Geffon commented on TS-3821:
--
I'm not sure this is related to atscppapi. It does sound more like TS-2645,
[~ksj] can you reproduce this issue consistently? If you can reproduce is
consistently can you please share how you're doing it? Also if if possible can
you share plugin source code?
Segmentation fault possibly due leaks in atscppapi
--
Key: TS-3821
URL: https://issues.apache.org/jira/browse/TS-3821
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Jiri Podhorsky
Assignee: Brian Geffon
Fix For: 6.1.0
Hello,
I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled
plugins in atscppapi, in which are used other Plugins than GlobalPlugin
(TransformationPlugin, InterceptionPlugin,...)
i'm building traffic server only with parameters:
./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver
--enable-cppapi
I'm getting segfault:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
{noformat}
I tried to find an Issue and found possible leak in dectructor ~Transaction()
of Transaction.cc file.
The leak is, there is added plugin by addPlugin(TransactionPlugin *);
and according to documentation
[https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
Transaction should be responsible for cleaning.
But nothing removes items of list state_.plugins_, where should be pointers
to memory allocated with new, which won't be deleted by delete state_;
I tried to correct it with
{noformat}
for (TransactionPlugin* tmp : state_-plugins_) {
delete tmp;
}
{noformat}
But it didn't work. I'm getting similar segfault with another
{noformat}
traffic_server: Segmentation fault (Invalid permissions for mapped object
[0x2b86141ea898])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
[0x2b86141ea898]
{noformat}
I tried to find more deep and find the plugins should be freed by delete in
another class in file utils_internal.cc.
But if this is true, I should see in debug mode message, which is printed
before delete:
{noformat}
LOG_DEBUG(Locked Mutex...Deleting transaction plugin at %p, *iter);
{noformat}
But I don't see such messages in log.
I can see in error.log lot of these messages. I'm getting them at least every
second.
{noformat}
20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server
request already initialized
{noformat}
Can you help me find the issue? Thanks for help in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is back to normal : centos_7-master » gcc,centos_7,debug #1065
See https://ci.trafficserver.apache.org/job/centos_7-master/compiler=gcc,label=centos_7,type=debug/1065/
Jenkins build is still unstable: tsqa-lint #421
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
Jenkins build is still unstable: tsqa-lint #420
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
[jira] [Commented] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660931#comment-14660931
]
ASF subversion and git services commented on TS-3829:
-
Commit 1bf8746e0c60899a1f87fc6a47af2cceb55dd45a in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1bf8746 ]
TS-3829 Remove remnants of proxy.pac
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.1.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: tsqa-lint #418
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661179#comment-14661179 ] ASF subversion and git services commented on TS-3828: - Commit 8f89e542cd7e3927153b01b792d5e56e2b282029 in trafficserver's branch refs/heads/6.0.x from [~zhangzizhong] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8f89e54 ] TS-3828: HEAD requests hang when origin returns Transfer-Encoding: Chunked HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661180#comment-14661180 ] Brian Geffon commented on TS-3828: -- Landed in master and back ported to 6.0.x, closing... HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon closed TS-3828. Resolution: Fixed HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1232) Support unknown methods in HTTP requests
[ https://issues.apache.org/jira/browse/TS-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659547#comment-14659547 ] ASF GitHub Bot commented on TS-1232: Github user ushachar commented on the pull request: https://github.com/apache/trafficserver/pull/270#issuecomment-128261744 I'm not too sure about this -- It's one thing to allow/block unknown methods that parse properly (TS-1232/TS-1407), but adding non-HTTP methods to the HTTP method list just for the ip-allow functionlity seems like another thing that can be best accomplished in plugin space Some technical comments: 1) Maybe rename HTTP_WKSIDX_... - WEBDAV_WKSIDX_... 2) Some WebDAV methods should be treated like POST in that they are required to have payload (I don't think there's any method that's explicitly forbidden from having payload). 3) Should we support the If header? (http://www.webdav.org/specs/rfc4918.html#rfc.section.10.4.5) Support unknown methods in HTTP requests Key: TS-1232 URL: https://issues.apache.org/jira/browse/TS-1232 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.3 Reporter: Uri Shachar Labels: http Fix For: 3.2.4 Original Estimate: 72h Remaining Estimate: 72h When acting as a transparent proxy, we may intercept WebDAV and other HTTP based protocols. Currently, the response will be 405 Method Not Allowed even though ATS can deal with the request as long as the rest of it is well-formed. Adding this functionality requires only minor changes and it could be configured on/off (proxy.config.http.accept_unknown_methods) Interested? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659844#comment-14659844
]
Jiri Podhorsky edited comment on TS-3821 at 8/6/15 11:20 AM:
-
Ok, I build trafficserver with --enable-debug and run gdb just like in here
[https://cwiki.apache.org/confluence/display/TS/Filing+useful+bug+reports].
Here is backtrace of gdb:
{noformat}
#0 0x007c7906 in ?? ()
#1 0x007c7900 in ?? ()
#2 0x0064cd0c in HttpTunnel::producer_run (this=0x7fffb9e49838,
p=0x7fffb9e49a38) at HttpTunnel.cc:915
#3 0x0064c567 in HttpTunnel::tunnel_run (this=0x7fffb9e49838,
p_arg=0x7fffb9e49a38) at HttpTunnel.cc:733
#4 0x0060d269 in HttpSM::setup_internal_transfer (this=0x7fffb9e483e0,
handler_arg=(int (HttpSM::*)(HttpSM * const, int, void *)) 0x600c4e
HttpSM::tunnel_handler(int, void*)) at HttpSM.cc:5992
#5 0x005fc21e in HttpSM::handle_api_return (this=0x7fffb9e483e0) at
HttpSM.cc:1580
#6 0x00611811 in HttpSM::set_next_state (this=0x7fffb9e483e0) at
HttpSM.cc:7125
#7 0x006103aa in HttpSM::call_transact_and_set_next_state
(this=0x7fffb9e483e0, f=0x6234a6
HttpTransact::HandleApiErrorJump(HttpTransact::State*)) at HttpSM.cc:6852
#8 0x005fbe8d in HttpSM::state_api_callout (this=0x7fffb9e483e0,
event=60001, data=0x0) at HttpSM.cc:1467
#9 0x005fb4b0 in HttpSM::state_api_callback (this=0x7fffb9e483e0,
event=60001, data=0x0) at HttpSM.cc:1275
#10 0x00540e51 in TSHttpTxnReenable (txnp=0x7fffb9e483e0,
event=TS_EVENT_HTTP_ERROR) at InkAPI.cc:5614
#11 0x7fffd96570b7 in atscppapi::Transaction::error (this=0x7fffb0081430)
at Transaction.cc:111
#12 0x7fffd9a86af1 in BlockIP::handleSendRequestHeaders (this=0x2cbd580,
transaction=...) at BlockIP.cc:52
#13 0x7fffd96561ef in (anonymous namespace)::invokePluginForEvent
(plugin=0x2cbd580, ats_txn_handle=0x7fffb9e483e0,
event=TS_EVENT_HTTP_SEND_REQUEST_HDR) at utils_internal.cc:116
#14 0x7fffd9656579 in atscppapi::utils::internal::invokePluginForEvent
(plugin=0x2cbd580, ats_txn_handle=0x7fffb9e483e0,
event=TS_EVENT_HTTP_SEND_REQUEST_HDR) at utils_internal.cc:222
#15 0x7fffd96550a1 in (anonymous namespace)::handleGlobalPluginEvents
(cont=0x2cc20b0, event=TS_EVENT_HTTP_SEND_REQUEST_HDR, edata=0x7fffb9e483e0) at
GlobalPlugin.cc:58
#16 0x0053519d in INKContInternal::handle_event (this=0x2cc20b0,
event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1003
#17 0x00520494 in Continuation::handleEvent (this=0x2cc20b0,
event=60004, data=0x7fffb9e483e0) at ../iocore/eventsystem/I_Continuation.h:145
#18 0x00535abc in APIHook::invoke (this=0x2cc30e0, event=60004,
edata=0x7fffb9e483e0) at InkAPI.cc:1221
#19 0x005fbb5b in HttpSM::state_api_callout (this=0x7fffb9e483e0,
event=6, data=0x0) at HttpSM.cc:1381
#20 0x005fb4b0 in HttpSM::state_api_callback (this=0x7fffb9e483e0,
event=6, data=0x0) at HttpSM.cc:1275
#21 0x00540e51 in TSHttpTxnReenable (txnp=0x7fffb9e483e0,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
#22 0x7fffd9656089 in (anonymous namespace)::handleTransactionEvents
(cont=0x2cc2120, event=TS_EVENT_HTTP_SEND_REQUEST_HDR, edata=0x7fffb9e483e0) at
utils_internal.cc:88
#23 0x0053519d in INKContInternal::handle_event (this=0x2cc2120,
event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1003
#24 0x00520494 in Continuation::handleEvent (this=0x2cc2120,
event=60004, data=0x7fffb9e483e0) at ../iocore/eventsystem/I_Continuation.h:145
#25 0x00535abc in APIHook::invoke (this=0x2cc3160, event=60004,
edata=0x7fffb9e483e0) at InkAPI.cc:1221
#26 0x005fbb5b in HttpSM::state_api_callout (this=0x7fffb9e483e0,
event=0, data=0x0) at HttpSM.cc:1381
#27 0x006092ad in HttpSM::do_api_callout_internal (this=0x7fffb9e483e0)
at HttpSM.cc:4886
#28 0x0061716f in HttpSM::do_api_callout (this=0x7fffb9e483e0) at
HttpSM.cc:442
#29 0x0060bb8a in HttpSM::setup_server_send_request_api
(this=0x7fffb9e483e0) at HttpSM.cc:5660
#30 0x00609fbc in HttpSM::handle_http_server_open (this=0x7fffb9e483e0)
at HttpSM.cc:5154
#31 0x005fc7a3 in HttpSM::state_http_server_open (this=0x7fffb9e483e0,
event=200, data=0x4c89100) at HttpSM.cc:1650
#32 0x005ffdfc in HttpSM::main_handler (this=0x7fffb9e483e0, event=200,
data=0x4c89100) at HttpSM.cc:2552
#33 0x00520494 in Continuation::handleEvent (this=0x7fffb9e483e0,
event=200, data=0x4c89100) at ../iocore/eventsystem/I_Continuation.h:145
#34 0x00793757 in UnixNetVConnection::connectUp (this=0x4c89100,
t=0x7fffeb47e010, fd=-1) at UnixNetVConnection.cc:1197
#35 0x0078e11b in UnixNetProcessor::connect_re_internal
(this=0x108cb40, cont=0x7fffb9e483e0, target=0x7fffb9e48a90,
opt=0x7fffe25edb10) at UnixNetProcessor.cc:248
#36 0x0054a1ca in
[jira] [Commented] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[ https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659844#comment-14659844 ] Jiri Podhorsky commented on TS-3821: Ok, I build trafficserver with --enable-debug and run gdb just like in here [https://cwiki.apache.org/confluence/display/TS/Filing+useful+bug+reports]. Here is backtrace from gdb: #0 0x007c7906 in ?? () #1 0x007c7900 in ?? () #2 0x0064cd0c in HttpTunnel::producer_run (this=0x7fffb9e49838, p=0x7fffb9e49a38) at HttpTunnel.cc:915 #3 0x0064c567 in HttpTunnel::tunnel_run (this=0x7fffb9e49838, p_arg=0x7fffb9e49a38) at HttpTunnel.cc:733 #4 0x0060d269 in HttpSM::setup_internal_transfer (this=0x7fffb9e483e0, handler_arg=(int (HttpSM::*)(HttpSM * const, int, void *)) 0x600c4e HttpSM::tunnel_handler(int, void*)) at HttpSM.cc:5992 #5 0x005fc21e in HttpSM::handle_api_return (this=0x7fffb9e483e0) at HttpSM.cc:1580 #6 0x00611811 in HttpSM::set_next_state (this=0x7fffb9e483e0) at HttpSM.cc:7125 #7 0x006103aa in HttpSM::call_transact_and_set_next_state (this=0x7fffb9e483e0, f=0x6234a6 HttpTransact::HandleApiErrorJump(HttpTransact::State*)) at HttpSM.cc:6852 #8 0x005fbe8d in HttpSM::state_api_callout (this=0x7fffb9e483e0, event=60001, data=0x0) at HttpSM.cc:1467 #9 0x005fb4b0 in HttpSM::state_api_callback (this=0x7fffb9e483e0, event=60001, data=0x0) at HttpSM.cc:1275 #10 0x00540e51 in TSHttpTxnReenable (txnp=0x7fffb9e483e0, event=TS_EVENT_HTTP_ERROR) at InkAPI.cc:5614 #11 0x7fffd96570b7 in atscppapi::Transaction::error (this=0x7fffb0081430) at Transaction.cc:111 #12 0x7fffd9a86af1 in BlockIP::handleSendRequestHeaders (this=0x2cbd580, transaction=...) at BlockIP.cc:52 #13 0x7fffd96561ef in (anonymous namespace)::invokePluginForEvent (plugin=0x2cbd580, ats_txn_handle=0x7fffb9e483e0, event=TS_EVENT_HTTP_SEND_REQUEST_HDR) at utils_internal.cc:116 #14 0x7fffd9656579 in atscppapi::utils::internal::invokePluginForEvent (plugin=0x2cbd580, ats_txn_handle=0x7fffb9e483e0, event=TS_EVENT_HTTP_SEND_REQUEST_HDR) at utils_internal.cc:222 #15 0x7fffd96550a1 in (anonymous namespace)::handleGlobalPluginEvents (cont=0x2cc20b0, event=TS_EVENT_HTTP_SEND_REQUEST_HDR, edata=0x7fffb9e483e0) at GlobalPlugin.cc:58 #16 0x0053519d in INKContInternal::handle_event (this=0x2cc20b0, event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1003 #17 0x00520494 in Continuation::handleEvent (this=0x2cc20b0, event=60004, data=0x7fffb9e483e0) at ../iocore/eventsystem/I_Continuation.h:145 #18 0x00535abc in APIHook::invoke (this=0x2cc30e0, event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1221 #19 0x005fbb5b in HttpSM::state_api_callout (this=0x7fffb9e483e0, event=6, data=0x0) at HttpSM.cc:1381 #20 0x005fb4b0 in HttpSM::state_api_callback (this=0x7fffb9e483e0, event=6, data=0x0) at HttpSM.cc:1275 #21 0x00540e51 in TSHttpTxnReenable (txnp=0x7fffb9e483e0, event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614 #22 0x7fffd9656089 in (anonymous namespace)::handleTransactionEvents (cont=0x2cc2120, event=TS_EVENT_HTTP_SEND_REQUEST_HDR, edata=0x7fffb9e483e0) at utils_internal.cc:88 #23 0x0053519d in INKContInternal::handle_event (this=0x2cc2120, event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1003 #24 0x00520494 in Continuation::handleEvent (this=0x2cc2120, event=60004, data=0x7fffb9e483e0) at ../iocore/eventsystem/I_Continuation.h:145 #25 0x00535abc in APIHook::invoke (this=0x2cc3160, event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1221 #26 0x005fbb5b in HttpSM::state_api_callout (this=0x7fffb9e483e0, event=0, data=0x0) at HttpSM.cc:1381 #27 0x006092ad in HttpSM::do_api_callout_internal (this=0x7fffb9e483e0) at HttpSM.cc:4886 #28 0x0061716f in HttpSM::do_api_callout (this=0x7fffb9e483e0) at HttpSM.cc:442 #29 0x0060bb8a in HttpSM::setup_server_send_request_api (this=0x7fffb9e483e0) at HttpSM.cc:5660 #30 0x00609fbc in HttpSM::handle_http_server_open (this=0x7fffb9e483e0) at HttpSM.cc:5154 #31 0x005fc7a3 in HttpSM::state_http_server_open (this=0x7fffb9e483e0, event=200, data=0x4c89100) at HttpSM.cc:1650 #32 0x005ffdfc in HttpSM::main_handler (this=0x7fffb9e483e0, event=200, data=0x4c89100) at HttpSM.cc:2552 #33 0x00520494 in Continuation::handleEvent (this=0x7fffb9e483e0, event=200, data=0x4c89100) at ../iocore/eventsystem/I_Continuation.h:145 #34 0x00793757 in UnixNetVConnection::connectUp (this=0x4c89100, t=0x7fffeb47e010, fd=-1) at UnixNetVConnection.cc:1197 #35 0x0078e11b in UnixNetProcessor::connect_re_internal (this=0x108cb40, cont=0x7fffb9e483e0, target=0x7fffb9e48a90, opt=0x7fffe25edb10) at UnixNetProcessor.cc:248 #36 0x0054a1ca in NetProcessor::connect_re (this=0x108cb40, cont=0x7fffb9e483e0,
[jira] [Comment Edited] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659844#comment-14659844
]
Jiri Podhorsky edited comment on TS-3821 at 8/6/15 11:19 AM:
-
Ok, I build trafficserver with --enable-debug and run gdb just like in here
[https://cwiki.apache.org/confluence/display/TS/Filing+useful+bug+reports].
Here is backtrace from gdb:
{noformat}
#0 0x007c7906 in ?? ()
#1 0x007c7900 in ?? ()
#2 0x0064cd0c in HttpTunnel::producer_run (this=0x7fffb9e49838,
p=0x7fffb9e49a38) at HttpTunnel.cc:915
#3 0x0064c567 in HttpTunnel::tunnel_run (this=0x7fffb9e49838,
p_arg=0x7fffb9e49a38) at HttpTunnel.cc:733
#4 0x0060d269 in HttpSM::setup_internal_transfer (this=0x7fffb9e483e0,
handler_arg=(int (HttpSM::*)(HttpSM * const, int, void *)) 0x600c4e
HttpSM::tunnel_handler(int, void*)) at HttpSM.cc:5992
#5 0x005fc21e in HttpSM::handle_api_return (this=0x7fffb9e483e0) at
HttpSM.cc:1580
#6 0x00611811 in HttpSM::set_next_state (this=0x7fffb9e483e0) at
HttpSM.cc:7125
#7 0x006103aa in HttpSM::call_transact_and_set_next_state
(this=0x7fffb9e483e0, f=0x6234a6
HttpTransact::HandleApiErrorJump(HttpTransact::State*)) at HttpSM.cc:6852
#8 0x005fbe8d in HttpSM::state_api_callout (this=0x7fffb9e483e0,
event=60001, data=0x0) at HttpSM.cc:1467
#9 0x005fb4b0 in HttpSM::state_api_callback (this=0x7fffb9e483e0,
event=60001, data=0x0) at HttpSM.cc:1275
#10 0x00540e51 in TSHttpTxnReenable (txnp=0x7fffb9e483e0,
event=TS_EVENT_HTTP_ERROR) at InkAPI.cc:5614
#11 0x7fffd96570b7 in atscppapi::Transaction::error (this=0x7fffb0081430)
at Transaction.cc:111
#12 0x7fffd9a86af1 in BlockIP::handleSendRequestHeaders (this=0x2cbd580,
transaction=...) at BlockIP.cc:52
#13 0x7fffd96561ef in (anonymous namespace)::invokePluginForEvent
(plugin=0x2cbd580, ats_txn_handle=0x7fffb9e483e0,
event=TS_EVENT_HTTP_SEND_REQUEST_HDR) at utils_internal.cc:116
#14 0x7fffd9656579 in atscppapi::utils::internal::invokePluginForEvent
(plugin=0x2cbd580, ats_txn_handle=0x7fffb9e483e0,
event=TS_EVENT_HTTP_SEND_REQUEST_HDR) at utils_internal.cc:222
#15 0x7fffd96550a1 in (anonymous namespace)::handleGlobalPluginEvents
(cont=0x2cc20b0, event=TS_EVENT_HTTP_SEND_REQUEST_HDR, edata=0x7fffb9e483e0) at
GlobalPlugin.cc:58
#16 0x0053519d in INKContInternal::handle_event (this=0x2cc20b0,
event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1003
#17 0x00520494 in Continuation::handleEvent (this=0x2cc20b0,
event=60004, data=0x7fffb9e483e0) at ../iocore/eventsystem/I_Continuation.h:145
#18 0x00535abc in APIHook::invoke (this=0x2cc30e0, event=60004,
edata=0x7fffb9e483e0) at InkAPI.cc:1221
#19 0x005fbb5b in HttpSM::state_api_callout (this=0x7fffb9e483e0,
event=6, data=0x0) at HttpSM.cc:1381
#20 0x005fb4b0 in HttpSM::state_api_callback (this=0x7fffb9e483e0,
event=6, data=0x0) at HttpSM.cc:1275
#21 0x00540e51 in TSHttpTxnReenable (txnp=0x7fffb9e483e0,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5614
#22 0x7fffd9656089 in (anonymous namespace)::handleTransactionEvents
(cont=0x2cc2120, event=TS_EVENT_HTTP_SEND_REQUEST_HDR, edata=0x7fffb9e483e0) at
utils_internal.cc:88
#23 0x0053519d in INKContInternal::handle_event (this=0x2cc2120,
event=60004, edata=0x7fffb9e483e0) at InkAPI.cc:1003
#24 0x00520494 in Continuation::handleEvent (this=0x2cc2120,
event=60004, data=0x7fffb9e483e0) at ../iocore/eventsystem/I_Continuation.h:145
#25 0x00535abc in APIHook::invoke (this=0x2cc3160, event=60004,
edata=0x7fffb9e483e0) at InkAPI.cc:1221
#26 0x005fbb5b in HttpSM::state_api_callout (this=0x7fffb9e483e0,
event=0, data=0x0) at HttpSM.cc:1381
#27 0x006092ad in HttpSM::do_api_callout_internal (this=0x7fffb9e483e0)
at HttpSM.cc:4886
#28 0x0061716f in HttpSM::do_api_callout (this=0x7fffb9e483e0) at
HttpSM.cc:442
#29 0x0060bb8a in HttpSM::setup_server_send_request_api
(this=0x7fffb9e483e0) at HttpSM.cc:5660
#30 0x00609fbc in HttpSM::handle_http_server_open (this=0x7fffb9e483e0)
at HttpSM.cc:5154
#31 0x005fc7a3 in HttpSM::state_http_server_open (this=0x7fffb9e483e0,
event=200, data=0x4c89100) at HttpSM.cc:1650
#32 0x005ffdfc in HttpSM::main_handler (this=0x7fffb9e483e0, event=200,
data=0x4c89100) at HttpSM.cc:2552
#33 0x00520494 in Continuation::handleEvent (this=0x7fffb9e483e0,
event=200, data=0x4c89100) at ../iocore/eventsystem/I_Continuation.h:145
#34 0x00793757 in UnixNetVConnection::connectUp (this=0x4c89100,
t=0x7fffeb47e010, fd=-1) at UnixNetVConnection.cc:1197
#35 0x0078e11b in UnixNetProcessor::connect_re_internal
(this=0x108cb40, cont=0x7fffb9e483e0, target=0x7fffb9e48a90,
opt=0x7fffe25edb10) at UnixNetProcessor.cc:248
#36 0x0054a1ca in
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659955#comment-14659955 ] ASF GitHub Bot commented on TS-3828: Github user bgaff commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128352032 I worked with @zizhong on this patch and so obviously I give it a +1. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660352#comment-14660352
]
Leif Hedstrom commented on TS-3821:
---
This looks similar to TS-2645 as well, doesn't it ? [~ksj] can you take a look,
and see if they are the same?
Segmentation fault possibly due leaks in atscppapi
--
Key: TS-3821
URL: https://issues.apache.org/jira/browse/TS-3821
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Jiri Podhorsky
Assignee: Brian Geffon
Fix For: 6.1.0
Hello,
I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled
plugins in atscppapi, in which are used other Plugins than GlobalPlugin
(TransformationPlugin, InterceptionPlugin,...)
i'm building traffic server only with parameters:
./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver
--enable-cppapi
I'm getting segfault:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
{noformat}
I tried to find an Issue and found possible leak in dectructor ~Transaction()
of Transaction.cc file.
The leak is, there is added plugin by addPlugin(TransactionPlugin *);
and according to documentation
[https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
Transaction should be responsible for cleaning.
But nothing removes items of list state_.plugins_, where should be pointers
to memory allocated with new, which won't be deleted by delete state_;
I tried to correct it with
{noformat}
for (TransactionPlugin* tmp : state_-plugins_) {
delete tmp;
}
{noformat}
But it didn't work. I'm getting similar segfault with another
{noformat}
traffic_server: Segmentation fault (Invalid permissions for mapped object
[0x2b86141ea898])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
[0x2b86141ea898]
{noformat}
I tried to find more deep and find the plugins should be freed by delete in
another class in file utils_internal.cc.
But if this is true, I should see in debug mode message, which is printed
before delete:
{noformat}
LOG_DEBUG(Locked Mutex...Deleting transaction plugin at %p, *iter);
{noformat}
But I don't see such messages in log.
I can see in error.log lot of these messages. I'm getting them at least every
second.
{noformat}
20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server
request already initialized
{noformat}
Can you help me find the issue? Thanks for help in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660432#comment-14660432 ] ASF GitHub Bot commented on TS-3828: Github user sudheerv commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128454326 I've a small concern/question on the patch. the RFC for HEAD method says: The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted. https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-4.3.2 So, it does seem like we are not necessarily breaking the spec if we are omitting the Content-Length or Transfer-Encoding headers (part of the payload headers in https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-3.3). Ideally, the Origin server should not have sent the chunked-encoding for a HEAD method, but, since the rfc indicates it's optional, unfortunately, we have no choice but to handle both the presence and absence of those headers in the server response. Looking at the patch, I'm not sure to understand whether the headers are actually being dropped in the client response - Is it possible to validate the behavior (i.e whether we are dropping the headers or not) after the patch? At the very least, this helps us to understand/agree on (and perhaps even document) our behavior. I also wonder if this may also be a slight compatibility issue, if some clients have been relying on receiving payload headers (especially, Content-Length) from ATS, so, would have to be done in 6.0. The best case scenario would be if we are not actually dropping the headers in the response and just correctly terminating the transaction. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660580#comment-14660580 ] William Bardwell commented on TS-3828: -- Just to be clear, be careful that you do not delete/zero out the Content-Length header in the client response to a HEAD request. That would break lots of things. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3829:
--
Backport to Version: 6.0.0
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.1.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (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 reassigned TS-3777:
--
Assignee: Susan Hinrichs
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
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-3618) Crashes in traffic_cop on shutdown / restart
[
https://issues.apache.org/jira/browse/TS-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660614#comment-14660614
]
Leif Hedstrom commented on TS-3618:
---
yes :) I marked it for v5.3.2, we have seen this in our prod too.
Crashes in traffic_cop on shutdown / restart
Key: TS-3618
URL: https://issues.apache.org/jira/browse/TS-3618
Project: Traffic Server
Issue Type: Bug
Components: Cop
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 6.0.0
We're seeing crashes coming from traffic_cop on shutdown or restart, I was
able to get the following backtrace: Which seems to indicate that the call to
exit() is causing a std::map to call malloc which is obviously not allowed in
a signal handler. My proposed fix will be to defer the call to exit() until
after the signal handler as returned.
{code}
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/traffic_cop...Reading symbols from
/usr/lib/debug/usr/bin/traffic_cop.debug...done.
done.
[New Thread 1536]
[New Thread 1011]
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debug*' install
/usr/lib/debug/.build-id/4e/31c47b2868d02adbbefc6f53fd6d9881e9c4b4
Reading symbols from /usr/lib64/libtsmgmt.so.5.2.0...Reading symbols from
/usr/lib/debug/usr/lib64/libtsmgmt.so.5.2.0.debug...done.
done.
Loaded symbols for /usr/lib64/libtsmgmt.so.5.2.0
Reading symbols from /usr/lib64/libtsutil.so.5.2.0...Reading symbols from
/usr/lib/debug/usr/lib64/libtsutil.so.5.2.0.debug...done.
done.
Loaded symbols for /usr/lib64/libtsutil.so.5.2.0
Reading symbols from /usr/lib64/libtcl8.5.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libtcl8.5.so
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /export/apps/openssl/lib/libssl.so.1.0.0...Reading
symbols from /usr/lib/debug/export/apps/openssl/lib/libssl.so.1.0.0.debug...
warning: /usr/lib/debug/export/apps/openssl/lib/libssl.so.1.0.0.debug:
separate debug info file has no debug info
(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /export/apps/openssl/lib/libssl.so.1.0.0
Reading symbols from /export/apps/openssl/lib/libcrypto.so.1.0.0...Reading
symbols from
/usr/lib/debug/export/apps/openssl/lib/libcrypto.so.1.0.0.debug...
warning: /usr/lib/debug/export/apps/openssl/lib/libcrypto.so.1.0.0.debug:
separate debug info file has no debug info
(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /export/apps/openssl/lib/libcrypto.so.1.0.0
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpcre.so.0
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/lib64/libxml2.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libxml2.so.2
Reading symbols from /usr/lib64/libstdc++.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libkrb5.so.3
[jira] [Updated] (TS-3618) Crashes in traffic_cop on shutdown / restart
[
https://issues.apache.org/jira/browse/TS-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3618:
--
Backport to Version: 5.3.2
Crashes in traffic_cop on shutdown / restart
Key: TS-3618
URL: https://issues.apache.org/jira/browse/TS-3618
Project: Traffic Server
Issue Type: Bug
Components: Cop
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 6.0.0
We're seeing crashes coming from traffic_cop on shutdown or restart, I was
able to get the following backtrace: Which seems to indicate that the call to
exit() is causing a std::map to call malloc which is obviously not allowed in
a signal handler. My proposed fix will be to defer the call to exit() until
after the signal handler as returned.
{code}
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/traffic_cop...Reading symbols from
/usr/lib/debug/usr/bin/traffic_cop.debug...done.
done.
[New Thread 1536]
[New Thread 1011]
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debug*' install
/usr/lib/debug/.build-id/4e/31c47b2868d02adbbefc6f53fd6d9881e9c4b4
Reading symbols from /usr/lib64/libtsmgmt.so.5.2.0...Reading symbols from
/usr/lib/debug/usr/lib64/libtsmgmt.so.5.2.0.debug...done.
done.
Loaded symbols for /usr/lib64/libtsmgmt.so.5.2.0
Reading symbols from /usr/lib64/libtsutil.so.5.2.0...Reading symbols from
/usr/lib/debug/usr/lib64/libtsutil.so.5.2.0.debug...done.
done.
Loaded symbols for /usr/lib64/libtsutil.so.5.2.0
Reading symbols from /usr/lib64/libtcl8.5.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libtcl8.5.so
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /export/apps/openssl/lib/libssl.so.1.0.0...Reading
symbols from /usr/lib/debug/export/apps/openssl/lib/libssl.so.1.0.0.debug...
warning: /usr/lib/debug/export/apps/openssl/lib/libssl.so.1.0.0.debug:
separate debug info file has no debug info
(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /export/apps/openssl/lib/libssl.so.1.0.0
Reading symbols from /export/apps/openssl/lib/libcrypto.so.1.0.0...Reading
symbols from
/usr/lib/debug/export/apps/openssl/lib/libcrypto.so.1.0.0.debug...
warning: /usr/lib/debug/export/apps/openssl/lib/libcrypto.so.1.0.0.debug:
separate debug info file has no debug info
(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /export/apps/openssl/lib/libcrypto.so.1.0.0
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpcre.so.0
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/lib64/libxml2.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libxml2.so.2
Reading symbols from /usr/lib64/libstdc++.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols
found)...done.
Loaded
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660349#comment-14660349 ] ASF GitHub Bot commented on TS-3828: Github user zwoop commented on the pull request: https://github.com/apache/trafficserver/pull/271#issuecomment-128445110 This seems reasonable to me as well. If I understand this, basically you are saying, if we expect no body, also explicitly ignore any transfer encoding? HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-3829:
-
Assignee: Leif Hedstrom
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.1.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3829:
--
Fix Version/s: 6.0.0
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Fix For: 6.1.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3829:
--
Fix Version/s: (was: 6.0.0)
6.1.0
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.1.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
[
https://issues.apache.org/jira/browse/TS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3829:
--
Issue Type: Improvement (was: Bug)
Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Fix For: 6.1.0
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname,
proxy.pac) == 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3829) Remnants of proxy.pac that needs to be removed for 6.0.0
Leif Hedstrom created TS-3829:
-
Summary: Remnants of proxy.pac that needs to be removed for 6.0.0
Key: TS-3829
URL: https://issues.apache.org/jira/browse/TS-3829
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
[~jpe...@apache.org] found a few more places to cleanup:
{code}
cmd/traffic_manager/AddConfigFilesHere.cc: configFiles-addFile(proxy.pac,
false);
cmd/traffic_manager/traffic_manager.cc: } else if (strcmp(fname, proxy.pac)
== 0) {
cmd/traffic_manager/traffic_manager.cc:mgmt_log(stderr, [fileUpdated]
proxy.pac file has been modified\n);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3827) Cleanup code only depends on drafts of HTTP/2
Masaori Koshiba created TS-3827:
---
Summary: Cleanup code only depends on drafts of HTTP/2
Key: TS-3827
URL: https://issues.apache.org/jira/browse/TS-3827
Project: Traffic Server
Issue Type: Improvement
Components: HTTP/2
Reporter: Masaori Koshiba
HTTP/2 implementation is developed with drafts of RFC 7540 originally.
Thus some fields like {{HTTP2_FLAGS_CONTINUATION_PAD_LOW}} are exists, although
padding is removed from CONTINUATION frame in RFC 7540.
And many comments are copied from old drafts too.
We should investigate and cleanup those code and comments.
See Also: [Appendix B. Change Log of
draft-ietf-httpbis-http2-17|https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#appendix-B]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3792) Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file causes segmentation faults on first DNS query
[
https://issues.apache.org/jira/browse/TS-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659616#comment-14659616
]
ASF GitHub Bot commented on TS-3792:
Github user bgaff commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-128275994
@SolidWallOfCode @jpeach are you guys okay with this current iteration? If
we don't have any objections I'll get this merged.
Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file
causes segmentation faults on first DNS query
-
Key: TS-3792
URL: https://issues.apache.org/jira/browse/TS-3792
Project: Traffic Server
Issue Type: Bug
Reporter: Thomas Jackson
Assignee: Brian Geffon
Fix For: 6.1.0
{code}
[connect] ERROR (main_socket_fd 9): Connection refused
[Jul 22 17:04:34.553] {0x2b293f16b960} ERROR: wrote crash log to
/var/log/trafficserver/crash-2015-07-22-170434.log
traffic_server: Floating point exception (Integer divide by zero
[0x6d8e5a])traffic_server - STACK TRACE:
traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50994e]
/lib64/libpthread.so.0[0x340d40f710]
traffic_server[0x6d8e5a]
traffic_server(_ZN8DNSEntry9mainEventEiP5Event+0x3d3)[0x6d9a95]
traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
traffic_server(_ZN12DNSProcessor5getbyEPKciiP12ContinuationRKNS_7OptionsE+0x1c1)[0x6d9e45]
traffic_server(_ZN12DNSProcessor13gethostbynameEP12ContinuationPKcRKNS_7OptionsE+0x44)[0x6ccb30]
traffic_server(_ZN18HostDBContinuation6do_dnsEv+0x290)[0x6cadbc]
traffic_server(_ZN18HostDBContinuation10probeEventEiP5Event+0x2bc)[0x6ca8a6]
traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x786d56]
traffic_server(_ZN7EThread7executeEv+0xa0)[0x786f24]
traffic_server(main+0x1246)[0x53da75]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x340cc1ed5d]
traffic_server[0x4f47a9]
Floating point exception (core dumped)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3819) H2 error logging
[ https://issues.apache.org/jira/browse/TS-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryo Okubo updated TS-3819: -- Attachment: h2_errorlog_0002.patch Additinal patch replaces Log::error() with Error() and clang-format's H2 error logging Key: TS-3819 URL: https://issues.apache.org/jira/browse/TS-3819 Project: Traffic Server Issue Type: New Feature Components: HTTP/2 Reporter: Ryo Okubo Fix For: 6.0.0 Attachments: h2_errorlog_0001.patch, h2_errorlog_0002.patch RST_STREAM and GOAWAY may deliver [various errors|https://tools.ietf.org/html/rfc7540#section-7]. I want to record them to error.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3818) traffic_ctl subcommand to show default configuration values
[
https://issues.apache.org/jira/browse/TS-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3818:
--
Fix Version/s: 6.1.0
traffic_ctl subcommand to show default configuration values
---
Key: TS-3818
URL: https://issues.apache.org/jira/browse/TS-3818
Project: Traffic Server
Issue Type: New Feature
Components: Console, Management API, Utilities
Reporter: James Peach
Assignee: James Peach
Fix For: 6.1.0
Add a {{traffic_ctl}} subcommand to just dump the defaults. It's easy to do
and occasionally useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3827) Cleanup code only depends on drafts of HTTP/2
[
https://issues.apache.org/jira/browse/TS-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3827:
--
Fix Version/s: 6.1.0
Cleanup code only depends on drafts of HTTP/2
--
Key: TS-3827
URL: https://issues.apache.org/jira/browse/TS-3827
Project: Traffic Server
Issue Type: Improvement
Components: HTTP/2
Reporter: Masaori Koshiba
Fix For: 6.1.0
HTTP/2 implementation is developed with drafts of RFC 7540 originally.
Thus some fields like {{HTTP2_FLAGS_CONTINUATION_PAD_LOW}} are exists,
although padding is removed from CONTINUATION frame in RFC 7540.
And many comments are copied from old drafts too.
We should investigate and cleanup those code and comments.
See Also: [Appendix B. Change Log of
draft-ietf-httpbis-http2-17|https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#appendix-B]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3828: -- Fix Version/s: 6.0.0 HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3818) traffic_ctl subcommand to show default configuration values
[
https://issues.apache.org/jira/browse/TS-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660237#comment-14660237
]
Leif Hedstrom commented on TS-3818:
---
Putting this for 6.1.0 for now, but this would be useful for 6.0.0 if we can
get it landed soon. If so, please update the Fix Version accordingly.
traffic_ctl subcommand to show default configuration values
---
Key: TS-3818
URL: https://issues.apache.org/jira/browse/TS-3818
Project: Traffic Server
Issue Type: New Feature
Components: Console, Management API, Utilities
Reporter: James Peach
Assignee: James Peach
Fix For: 6.1.0
Add a {{traffic_ctl}} subcommand to just dump the defaults. It's easy to do
and occasionally useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660240#comment-14660240 ] Leif Hedstrom commented on TS-3828: --- Marking for 6.0.0, please review and commit. I'm curious too, is this a regression on an old time bug? If it's old time, maybe it should be a back port to 5.3.2. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3826) Traffic Server add message No Content to response when is 204 code.
[ https://issues.apache.org/jira/browse/TS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3826: -- Fix Version/s: 6.0.0 Traffic Server add message No Content to response when is 204 code. - Key: TS-3826 URL: https://issues.apache.org/jira/browse/TS-3826 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 4.2.0 Reporter: fengidri Labels: newbie Fix For: 6.0.0 I found that When the 204 response is cached, the response from the cache will be added No Content message. Why? Anybody know this? Thanks!! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3826) Traffic Server add message No Content to response when is 204 code.
[ https://issues.apache.org/jira/browse/TS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3826: -- Labels: newbie (was: ) Traffic Server add message No Content to response when is 204 code. - Key: TS-3826 URL: https://issues.apache.org/jira/browse/TS-3826 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 4.2.0 Reporter: fengidri Labels: newbie Fix For: 6.0.0 I found that When the 204 response is cached, the response from the cache will be added No Content message. Why? Anybody know this? Thanks!! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3826) Traffic Server add message No Content to response when is 204 code.
[ https://issues.apache.org/jira/browse/TS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3826: -- Component/s: HTTP Traffic Server add message No Content to response when is 204 code. - Key: TS-3826 URL: https://issues.apache.org/jira/browse/TS-3826 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 4.2.0 Reporter: fengidri Labels: newbie Fix For: 6.0.0 I found that When the 204 response is cached, the response from the cache will be added No Content message. Why? Anybody know this? Thanks!! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3826) Traffic Server add message No Content to response when is 204 code.
[
https://issues.apache.org/jira/browse/TS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660244#comment-14660244
]
Leif Hedstrom commented on TS-3826:
---
Do you have negative caching enabled in records.config? From what it looks
like, you hit upon this code:
{code}
if (t_state.negative_caching t_state.hdr_info.server_response.status_get()
== HTTP_STATUS_NO_CONTENT) {
int s = sizeof(No Content) - 1;
buf-write(No Content, s);
nbytes += s;
}
{code}
There are two places where we do this (different paths). If you can, just try
to remove this, and see what happens?
I bet, but not 100% sure, that this is an artifact that ATS did not allow
caching empty documents in the past. There's now a setting for this:
{code}
CONFIG proxy.config.http.cache.allow_empty_doc INT 1
{code}
So, maybe, just maybe, we should eliminate this dummy body ? If to, that
might be a 6.0.0 fix that we should consider right now, since this would be the
time to break compatibility.
Traffic Server add message No Content to response when is 204 code.
-
Key: TS-3826
URL: https://issues.apache.org/jira/browse/TS-3826
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 4.2.0
Reporter: fengidri
Labels: newbie
Fix For: 6.0.0
I found that When the 204 response is cached, the response from the
cache will be added No Content message.
Why? Anybody know this?
Thanks!!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
Brian Geffon created TS-3828: Summary: HEAD requests hang when origin returns Transfer-Encoding: Chunked Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3819) H2 error logging
[ https://issues.apache.org/jira/browse/TS-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660219#comment-14660219 ] Leif Hedstrom commented on TS-3819: --- [~rokubo] This last patch did not apply cleanly on current master. H2 error logging Key: TS-3819 URL: https://issues.apache.org/jira/browse/TS-3819 Project: Traffic Server Issue Type: New Feature Components: HTTP/2 Reporter: Ryo Okubo Fix For: 6.0.0 Attachments: h2_errorlog_0001.patch, h2_errorlog_0002.patch RST_STREAM and GOAWAY may deliver [various errors|https://tools.ietf.org/html/rfc7540#section-7]. I want to record them to error.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
