[jira] [Commented] (TS-1147) deprecate records.config SSL configuration
[
https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245296#comment-13245296
]
Igor Galić commented on TS-1147:
I suppose you'll only leave {{proxy.config.http.server_ports 443:ssl}} in
{{records.config}}
What about the default certificate that {{records.config}} still configures?
It needs to be configured if one *really* wants SSL enabled, even if all of the
real hosts are taken care of by {{ssl_multicert.config}}.
Now, in certain cases this might even make sense - someone accesses a proxy via
{{HTTPS}}, asking for a host this proxy does not serve. Do we terminate the TLS
session? Do we finish the TLS handshake offering a default certificate and
returning the RFC compliant 400 HTTP code?
Here's what we do now, which begs the question why, exactly, we need the
default certificate:
{noformat}
i.galic@pheme ~ % curl -vk -H'Host: this-is-a-bad-example.at'
https://176.9.55.235:443/
* About to connect() to 176.9.55.235 port 443 (#0)
* Trying 176.9.55.235... connected
* Connected to 176.9.55.235 (176.9.55.235) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to 176.9.55.235:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to 176.9.55.235:443
35 i.galic@pheme ~ %
{noformat}
deprecate records.config SSL configuration
--
Key: TS-1147
URL: https://issues.apache.org/jira/browse/TS-1147
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.1.5
Since ssl_multicert.config is a strict superset of the SSL certificate
configuration in records.config, we should deprecate configuring SSL
certificates in records.config and make ssl_multicert.config the One True Way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1147) deprecate records.config SSL configuration
[ https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245396#comment-13245396 ] James Peach commented on TS-1147: - Only the .filename options have been removed. I added explicit support for this in ssl_multicert: dest_ip=* ssl_cert_name=foo.crt No it doesn't. If we can't find a certificate we will just fail the connection. In my branch, the behaviour is to complete the SSL handshake using the default certificate. If the client accepts this, then there's no reason to return a 400. deprecate records.config SSL configuration -- Key: TS-1147 URL: https://issues.apache.org/jira/browse/TS-1147 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.5 Since ssl_multicert.config is a strict superset of the SSL certificate configuration in records.config, we should deprecate configuring SSL certificates in records.config and make ssl_multicert.config the One True Way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1147) deprecate records.config SSL configuration
[ https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245406#comment-13245406 ] James Peach commented on TS-1147: - Wow, trying to reply in line via email really doesn't work so well ... deprecate records.config SSL configuration -- Key: TS-1147 URL: https://issues.apache.org/jira/browse/TS-1147 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.5 Since ssl_multicert.config is a strict superset of the SSL certificate configuration in records.config, we should deprecate configuring SSL certificates in records.config and make ssl_multicert.config the One True Way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1185) fails to build from source with gcc 4.7
fails to build from source with gcc 4.7
---
Key: TS-1185
URL: https://issues.apache.org/jira/browse/TS-1185
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.4, 3.1.3
Environment: Debian Unstable with gcc 4.7
Reporter: Arno Toell
Using gcc 4.7, ATS fails to build from source. See Debian bug 667396
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further
information. gcc 4.7 fails with
{code}
g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
-I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt
-I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs
-I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF
.deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc
In file included from ../../lib/ts/libts.h:96:0,
from HttpClientSession.h:35,
from HttpClientSession.cc:35:
../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K =
unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:51:34: required from here
../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope, and
no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:240:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified
lookup
../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead
../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K, C)
[with K = unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:64:37: required from here
../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope, and
no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:258:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified
lookup
../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead
../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope, and
no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:263:21: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified
lookup
../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead
make[4]: *** [HttpClientSession.o] Error 1
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1185) fails to build from source with gcc 4.7
[
https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245907#comment-13245907
]
Arno Toell commented on TS-1185:
The full log is available at
http://people.debian.org/~lucas/logs/2012/03/29-clang-gcc47/unstable-gcc47/trafficserver_3.0.4-1_unstable-gcc47.log
Standard Debian build flags are:
{code}
CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -Werror=format-security
FFLAGS=-g -O2
LDFLAGS=-Wl,-z,relro %
{code}
fails to build from source with gcc 4.7
---
Key: TS-1185
URL: https://issues.apache.org/jira/browse/TS-1185
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.3, 3.0.4
Environment: Debian Unstable with gcc 4.7
Reporter: Arno Toell
Using gcc 4.7, ATS fails to build from source. See Debian bug 667396
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further
information. gcc 4.7 fails with
{code}
g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
-I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt
-I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs
-I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF
.deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc
In file included from ../../lib/ts/libts.h:96:0,
from HttpClientSession.h:35,
from HttpClientSession.cc:35:
../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K =
unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:51:34: required from here
../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:240:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead
../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K,
C) [with K = unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:64:37: required from here
../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:258:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead
../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:263:21: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead
make[4]: *** [HttpClientSession.o] Error 1
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1185) fails to build from source with gcc 4.7
[
https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245909#comment-13245909
]
Igor Galić commented on TS-1185:
{noformat}
CXXFLAGS=-D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 \
-D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.5 -g -O2
-fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-pipe \
-Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof
{noformat}
fails to build from source with gcc 4.7
---
Key: TS-1185
URL: https://issues.apache.org/jira/browse/TS-1185
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.3, 3.0.4
Environment: Debian Unstable with gcc 4.7
Reporter: Arno Toell
Using gcc 4.7, ATS fails to build from source. See Debian bug 667396
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further
information. gcc 4.7 fails with
{code}
g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
-I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt
-I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs
-I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF
.deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc
In file included from ../../lib/ts/libts.h:96:0,
from HttpClientSession.h:35,
from HttpClientSession.cc:35:
../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K =
unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:51:34: required from here
../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:240:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead
../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K,
C) [with K = unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:64:37: required from here
../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:258:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead
../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:263:21: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead
make[4]: *** [HttpClientSession.o] Error 1
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1119) fatal error when uploading gzip-transform plugin
[
https://issues.apache.org/jira/browse/TS-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1119:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
fatal error when uploading gzip-transform plugin
Key: TS-1119
URL: https://issues.apache.org/jira/browse/TS-1119
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.0.2
Reporter: angela asher
Priority: Blocker
Fix For: 3.3.0
Attachments: gzip-transform.diff
getting the following error on traffic.out when running the traffic server
with gzip-transform plugin:
[Feb 23 16:28:15.509] Server {47392853811680} DEBUG: (http) [13] calling
plugin on hook TS_HTTP_READ_RESPONSE_HDR_HOOK at hook 0x35BBEE0
FATAL: InkAPI.cc:3036: failed assert `sdk_sanity_check_null_ptr((void*)
value_len_ptr) == TS_SUCCESS`
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/lib/libtsutil.so.3(ink_fatal_va+0x9d)[0x2b1a7ecca37d]
/usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2b1a7ecca4d8]
/usr/local/lib/libtsutil.so.3(_ink_assert+0x85)[0x2b1a7ecc8af5]
/usr/local/bin/traffic_server(TSMimeHdrFieldValueStringGet+0x124)[0x4a9144]
/usr/local/libexec/trafficserver/gzip-transform.so(+0x1bde)[0x2b1a8b3c7bde]
/usr/local/libexec/trafficserver/gzip-transform.so(+0x27c4)[0x2b1a8b3c87c4]
/usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52cfa5]
/usr/local/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x420)[0x52f1c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x530568]
/usr/local/bin/traffic_server[0x681dcb]
/usr/local/bin/traffic_server[0x6848f1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67d402]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6a9ce4]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6aa673]
/usr/local/bin/traffic_server(main+0x1128)[0x4c07e8]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x2b1a81092c5d]
/usr/local/bin/traffic_server[0x47e0e9]
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
No such file or directory)
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
No such file or directory)
[Feb 23 16:28:16.522] Manager {140400187066336} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr/local'
[Feb 23 16:28:16.527] Manager {140400187066336} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '11'
[Feb 23 16:28:16.527] Manager {140400187066336} NOTE: [Alarms::signalAlarm]
Server Process born
[Feb 23 16:28:17.539] {47668265021920} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
[Feb 23 16:28:17.539] {47668265021920} NOTE: updated diags config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Config:
/usr/local/etc/trafficserver/ae_ua.config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Opening config
/usr/local/etc/trafficserver/ae_ua.config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[init_http_aeua_filter] - Total loaded 0 REGEXP for
Accept-Enconding/User-Agent filtering
[Feb 23 16:28:17.542] Server {47668265021920} NOTE: cache clustering disabled
[Feb 23 16:28:17.543] Server {47668265021920} DEBUG: (dns) ink_dns_init:
called with init_called = 0
[Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns)
localhost=isk-vsrv227
[Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns) Round-robin
nameservers = 0
[Feb 23 16:28:17.547] Server {47668265021920} NOTE: cache clustering disabled
[Feb 23 16:28:17.568] Server {47668265021920} NOTE: logging initialized[7],
logging_mode = 3
[Feb 23 16:28:17.569] Server {47668265021920} NOTE: loading plugin
'/usr/local/libexec/trafficserver/gzip-transform.so'
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.redirection_enabled = 0
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.number_of_redirections = 1
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.post_copy_size = 2048
[Feb 23 16:28:17.570] Server
[jira] [Updated] (TS-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1058:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Intercept an HTTP client's request
--
Key: TS-1058
URL: https://issues.apache.org/jira/browse/TS-1058
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Labels: patch
Fix For: 3.3.0
Attachments: patch.diff
Original Estimate: 24h
Remaining Estimate: 24h
I want that the trafficserver will give the client the response instead of
the server.
The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
so convenience to use it.
I want to use the regular flow of the trafficserver, and its regular parsing
commands.
The trafficserver's plugins examples also aren't using the
INKHttpTxnIntercept , but they rather using the rasing error method, and
then they response the request at the response hook.
So, this is whta i did.
On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
TS_EVENT_HTTP_ERROR.
I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
response with the KEEP-ALIVE header.
The problem is that the trafficserver is closing the connection although i
added to the response the KEEP-ALIVE header.
When the Trafficserver is trying to send response to the client, it terminate
the session after it.
Although I added the KEEP-ALIVE mime field - it didn't work.
The debug dump is looking like this:
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::state_api_callback, HTTP_API_CONTINUE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::state_api_callout, HTTP_API_CONTINUE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
adding producer 'internal msg'
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
adding consumer 'user agent'
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
tunnel_run started, p_arg is NULL
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
closed
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
destroy
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
The Solution:
I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
so the trafficserver will realy believe us that we want to keep this
connection alive :)
Example for the usage of the new function:
// Tell the trafficserver to not close this connection (keep-alive)
TSHttpTxnCloseAfterResponse(txnp, 0);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1069) better handle of the gzipped content
[ https://issues.apache.org/jira/browse/TS-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1069: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. better handle of the gzipped content Key: TS-1069 URL: https://issues.apache.org/jira/browse/TS-1069 Project: Traffic Server Issue Type: Sub-task Reporter: Zhao Yongming Fix For: 3.3.0 when the triggered URL is gzipped, prefetch engine will skip that request, while not put that URL in the prefetch url list, and start another request without accept gzip encodes? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1125: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.0 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-801) Crash Report: enable update will triger Segmentation fault
[
https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-801:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash Report: enable update will triger Segmentation fault
--
Key: TS-801
URL: https://issues.apache.org/jira/browse/TS-801
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 2.1.8
Environment: v2.1.8 and update function enabled.
Reporter: Zhao Yongming
Labels: update
Fix For: 3.3.0
{code}
b13621367...@hotmail.com: NOTE: Traffic Server received Sig 11: Segmentation
fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
b13621367...@hotmail.com:
/usr/local/ts/bin/traffic_server[0x5260c9]
/lib64/libpthread.so.0[0x3088e0f4c0]
[0x6e]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x6e)[0x57e0e2]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x18b)[0x57e369]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x13b13621367...@hotmail.com:
8)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x36)[0x5b5cb0]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::state_add_to_list(int,
void*)+0x2aa)[0x56a51c]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x2cb)[0x570c13]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
HTTPHdr*)+0x168)[0x5b5c1c]
/usr/local/ts/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x335)[0x53599f]
/usr/local/ts/bin/traffic_server(UpdateSM::HandleSMEvent(int,
Event*)+0x1ab)[0x535437]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x12c)[0x6fa9dc]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x9b)[0x6fabef]
/usr/local/ts/bin/traffic_server[0x6f9b4c]
/lib64/libpthread.so.0[0x3088e077e1]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[LocalManager::-PollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[Alarms::-SignalAlarm] Server Process was reset
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[May 26 16:25:15.577] Manager {140030245394400} NOTE:
[LocalManager::-StartProxy] Launching ts process
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-923) traffic_logstats: critical: cannot parse log files
[ https://issues.apache.org/jira/browse/TS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-923: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. traffic_logstats: critical: cannot parse log files -- Key: TS-923 URL: https://issues.apache.org/jira/browse/TS-923 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.0.1 Environment: Centos 5.6 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:12:36 EST 2009 x86_64 x86_64 x86_64 GNU/Linux Reporter: Hung Nguyen Fix For: 3.3.0 After running for about 3 days, traffic_logstats stop working with following error: traffic_logstats critical: can't parse log file I tried to set Logging to various parameter in record.config, but still cannot get traffic_logstats works. When this problem happens, TS uses less resource. In my setup, I use ram cache only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-891) Crash report: mime_hdr_sanity_check in mime_parser_parse during
[
https://issues.apache.org/jira/browse/TS-891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-891:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash report: mime_hdr_sanity_check in mime_parser_parse during
Key: TS-891
URL: https://issues.apache.org/jira/browse/TS-891
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.1
Environment: v3.0.1, submit from user
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.0
no other information, place holding first.
{code}
zym@zym6400 ~ $ c++filt /tmp/a
FATAL: MIME.cc:576: failed assert `strncasecmp(field-m_ptr_name, wks,
field-m_len_name) == 0`
/usr/local/ts/bin/traffic_server - STACK TRACE:
/usr/local/ts/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0x4003109b]
/usr/local/ts/lib/libtsutil.so.3(ink_fatal+0x2b)[0x400310ed]
/usr/local/ts/lib/libtsutil.so.3(_ink_assert+0xc4)[0x4002fd54]
/usr/local/ts/bin/traffic_server(mime_hdr_sanity_check(MIMEHdrImpl*)+0x323)[0x823f5c8]
/usr/local/ts/bin/traffic_server(mime_hdr_field_attach(MIMEHdrImpl*,
MIMEField*, int, MIMEField*)+0x36[0x8241e17]
/usr/local/ts/bin/traffic_server(mime_parser_parse(MIMEParser*, HdrHeap*,
MIMEHdrImpl*, char const**, char const*, bool, bool)+0x2b5)[0x82442b6]
/usr/local/ts/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x801)[0x823ae17]
/usr/local/ts/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x126)[0x82380f4]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x2f0)[0x819b87c]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1f[0x81a0cc0]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x47)[0x81154f9]
/usr/local/ts/bin/traffic_server[0x82f644c]
/usr/local/ts/bin/traffic_server[0x82f6e43]
/usr/local/ts/bin/traffic_server(UnixNetVConnection::net_read_io(NetHandler*,
EThread*)+0x17)[0x82f8c6d]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x62a)[0x82f2ea4]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x47)[0x81154f9]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x114)[0x831af5a]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x425)[0x831b529]
/usr/local/ts/bin/traffic_server(main+0x1245)[0x813f233]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x40476450]
/usr/local/ts/bin/traffic_server[0x80f60e1]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-921) TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the Transfer Encoding: chunked http header !
[
https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-921:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
TSIOBufferBlockReadStart() could'nt return the corresponding chunk data
length when original server using the Transfer Encoding: chunked http
header !
Key: TS-921
URL: https://issues.apache.org/jira/browse/TS-921
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.0.1
Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1,
Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G,
HardDisk: 500G
Reporter: taoyunxing
Labels: transfer_encoding_chunded
Fix For: 3.3.0
Original Estimate: 672h
Remaining Estimate: 672h
Recently I meet with a strange proble when I manage to get the server
response body in the Transfer Encoding: chunked mode:
I couldn't get the corresponding chunk length in hexdecimal ! The details as
follows:
I use the null-transform plugin modified to just output the server response
body, when the web server uses the Transfer Encoding: chunked header
to transfer chunked data to user agent, eg, I request the web page:
http://www.qq.com/;, I just get the chunk body data, but get no chunk length
in
the hexdecimal format 383cb\r\n before the chunk body data. the chunk body
data is uncompressed and like as !DOCTYPE html PUBLIC -//W3C//DTD XHTML
1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n...
In addition, I capture the data packet using the Wireshark software, I sure
that I see the chunk length 383cb\r\n before the chunk body data
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n..., it is
a complete chunk response !
I continue to check the code of null-transform.c, set a breakpoint at the
function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at
the breakpoint TSIOBufferBlockReadStart(), I print the return string of
TSIOBufferBlockReadStart(), there is no chunk data length at the head of
output string, which implies the api TSIOBufferBlockReadStart() has bug！
Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330,
avail=0xb6c8e288) at InkIOCoreAPI.cc:659
659 {
(gdb) s
660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
(gdb) n
667 p = blk-start();
(gdb)
668 if (avail)
(gdb) p p
$3 = 0xb1312000 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0
Transitional//EN\
\http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml
xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead\r\nmeta
http-equiv=\Conten...
(gdb)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-902) Crash report: invalid ip range in remap.config crash server
[
https://issues.apache.org/jira/browse/TS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-902:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash report: invalid ip range in remap.config crash server
---
Key: TS-902
URL: https://issues.apache.org/jira/browse/TS-902
Project: Traffic Server
Issue Type: Bug
Components: Configuration, HTTP
Affects Versions: 3.1.0, 3.0.1
Environment: TS 3.0.1
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.0
when I put a strage ip range, ie: src_ip=128.0.0.0-121.14.89.0 in remap ip
filtering, it will cause the server crash:
{code}
[TrafficServer] using root directory '/usr'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE: [Alarms::signalAlarm]
Server Process born
[Aug 4 11:04:54.222] {46990117603664} STATUS: opened
/var/log/trafficserver/diags.log
[Aug 4 11:04:54.224] {46990117603664} NOTE: updated diags config
[Aug 4 11:04:54.225] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.239] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.343] Server {46990117603664} NOTE: logging initialized[7],
logging_mode = 1
[Aug 4 11:04:54.345] Server {46990117603664} NOTE: PrefetchProcessor:
Started the prefetch processor
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: Could not add rule at
line #1; Aborting!
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: [ReverseProxy] Unable
to parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 1
FATAL: [ReverseProxy] Unable to parse IP value in
src_ip=128.0.0.0-121.14.89.0 at line 1
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x3ab46127dd]
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ab4612938]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x585)[0x580335]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x2fa)[0x58219a]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0xec)[0x4de75c]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x51ee7b]
/usr/bin/traffic_server(main+0xc07)[0x4bf177]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x389961d994]
/usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4793a9]
[Aug 4 11:04:54.506] Manager {140564987967264} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
{code}
and here is the rules defined in my remap.config:
{code}
.defflt tools @action=deny @src_ip=0.0.0.0-127.0.0.0
@src_ip=128.0.0.0-121.14.89.0 @src_ip=121.14.90.254-255.255.255.255
@method=PURGE
.useflt tools
{code}
well, it is invalid, but we should not crash, right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1146: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Fix For: 3.3.0 For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1128) gcc don't like break strict-aliasing in I_ProxyAllocator.h
[
https://issues.apache.org/jira/browse/TS-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1128:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
gcc don't like break strict-aliasing in I_ProxyAllocator.h
--
Key: TS-1128
URL: https://issues.apache.org/jira/browse/TS-1128
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Affects Versions: 3.1.4
Reporter: Zhao Yongming
Priority: Minor
Fix For: 3.3.0
{code}
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* UnixNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* NetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
make[2]: *** [SSLUnixNet.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [UnixNetProcessor.o] Error 1
mv -f .deps/NetVConnection.Tpo .deps/NetVConnection.Po
mv -f .deps/Net.Tpo .deps/Net.Po
mv -f .deps/UDPIOEvent.Tpo .deps/UDPIOEvent.Po
make[2]: *** [UnixNetAccept.o] Error 1
mv -f .deps/Connection.Tpo .deps/Connection.Po
mv -f .deps/SSLCertLookup.Tpo .deps/SSLCertLookup.Po
mv -f .deps/UnixConnection.Tpo .deps/UnixConnection.Po
mv -f .deps/SSLConfig.Tpo .deps/SSLConfig.Po
mv -f .deps/SSLNet.Tpo .deps/SSLNet.Po
mv -f .deps/UnixNet.Tpo .deps/UnixNet.Po
mv -f .deps/UnixNetPages.Tpo .deps/UnixNetPages.Po
mv -f .deps/Socks.Tpo .deps/Socks.Po
mv -f .deps/SSLNetVConnection.Tpo .deps/SSLNetVConnection.Po
mv -f .deps/UnixNetVConnection.Tpo .deps/UnixNetVConnection.Po
make[2]: Leaving directory
`/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.VFqSxi (%build)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1152) http_ui error,when i get http://localhost/cache/
[
https://issues.apache.org/jira/browse/TS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1152:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
http_ui error,when i get http://localhost/cache/
Key: TS-1152
URL: https://issues.apache.org/jira/browse/TS-1152
Project: Traffic Server
Issue Type: Bug
Components: Web UI
Affects Versions: 3.0.4
Environment: centos 6 x86_64
Reporter: bettydramit
Fix For: 3.3.0
When i enable http_ui ，I got follow error (get http://xxx.xxx.xxx.xxx/cache/)
[Mar 19 16:46:17.778] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:17.778] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:19.089] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:19.090] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:20.763] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:20.763] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:58:21.906] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /robots.txt not valid autoconf file
[Mar 19 16:58:21.906] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 17:01:43.703] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 17:01:43.703] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1106) redirect map generates multiple Via: header entries.
[
https://issues.apache.org/jira/browse/TS-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1106:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
redirect map generates multiple Via: header entries.
Key: TS-1106
URL: https://issues.apache.org/jira/browse/TS-1106
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.2
Reporter: Leif Hedstrom
Fix For: 3.3.0
It seems using the redirect rule in remap.config, ends up duplicating the
entry in the Via: header, e.g.
{code}
Via: http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p
eS:tNc i p s ]), http/1.1 kramer.ogre.com
(ApacheTrafficServer/3.1.3-unstable [u c s f p eS:tNc i p s ])
{code}
I'm not sure why this happens, if it's duplicating it, or if it's going
through the SM twice. I know i'm not proxying twice through the box.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1169) in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a cached object which is after TSCacheUrlSet
[
https://issues.apache.org/jira/browse/TS-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1169:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a
cached object which is after TSCacheUrlSet
---
Key: TS-1169
URL: https://issues.apache.org/jira/browse/TS-1169
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.3, 3.0.4
Environment: configure --enable-debug
Reporter: Conan Wang
Fix For: 3.3.0
{code}
#6 0x000100d269af in _ink_assert (a=0x1003c6be0 md5a == md5b ||
t_state.txn_conf-maintain_pristine_host_hdr, f=0x1003c514e HttpSM.cc,
l=3921) at ink_assert.cc:44
#7 0x000100123e59 in HttpSM::do_cache_delete_all_alts (this=0x109d41190,
cont=0x0) at HttpSM.cc:3921
{code}
in HttpSM::do_cache_delete_all_alts debug code, if a object key is rewritten
by TSCacheUrlSet, md5a will not equal md5b, and it will crash because
maintain_pristine_host_hdr = 0 ( when disable pristine_host_hdr ).
Anyway, the cached object is purged successfully. Maybe it's just a wrong
assert which didn't consider TSCacheUrlSet case.
{code}
#ifdef DEBUG
INK_MD5 md5a;
INK_MD5 md5b;
t_state.hdr_info.client_request.url_get()-MD5_get(md5a);
t_state.cache_info.lookup_url-MD5_get(md5b);
ink_assert(md5a == md5b || t_state.txn_conf-maintain_pristine_host_hdr);
#endif
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1155) POST requests that are chunked encoding hang when going forward to origin over SSL
[ https://issues.apache.org/jira/browse/TS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1155: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. POST requests that are chunked encoding hang when going forward to origin over SSL -- Key: TS-1155 URL: https://issues.apache.org/jira/browse/TS-1155 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Reporter: William Bardwell Fix For: 3.3.0 If you make a chunked encoded POST request, e.g.: curl -H Transfer-Encoding: chunked -d@/etc/ca-certificates.conf http://example.com/cgi-bin/cgi.pl Where ATS is going forward to the origin over SSL, it junk hangs for a little while and ends up returning a 502 response. The problem seems to be code at proxy/http/HttpTransact.cc:5273 which only checks for chunked encoding when the scheme is http. Just removing the extra scheme check makes it work for me. I don't know why it has that check, especially since it is checking for http or https right before that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1053) get combo_handler compiled
[
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1053:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
get combo_handler compiled
--
Key: TS-1053
URL: https://issues.apache.org/jira/browse/TS-1053
Project: Traffic Server
Issue Type: Task
Components: Plugins
Reporter: Conan Wang
Fix For: 3.3.0
Attachments: Makefile, combo_handler.diff, fetcher.diff
combo_handler require ESI's code. Before make ESI work as a lib, you can try
it this way:
make esi/lib and esi/fetcher the subdir of combo_handler and use the
makefile.
{noformat}
combo_handler
|combo_handler.cc
|fetcher
|lib
|LICENSE
|Makefile
|README
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-832) Crash Report: RecMessageMarshal_Realloc in cluster mode 2
[
https://issues.apache.org/jira/browse/TS-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-832:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash Report: RecMessageMarshal_Realloc in cluster mode 2
-
Key: TS-832
URL: https://issues.apache.org/jira/browse/TS-832
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Core
Affects Versions: 3.1.0
Environment: version trunk, aka v3.0 after, cluster mode set to 2(
management cluster ), --enable-debug
Reporter: Zhao Yongming
Labels: cluster, realloc
Fix For: 3.3.0
here is two core dumps:
{code}
#0 0x003c33030265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x003c33030265 in raise () from /lib64/libc.so.6
#1 0x003c33031d10 in abort () from /lib64/libc.so.6
#2 0x003c3306a84b in __libc_message () from /lib64/libc.so.6
#3 0x003c33075421 in realloc () from /lib64/libc.so.6
#4 0x2acf28ff4e01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2acf29248f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x20034150, event=1,
e=0x20033d30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x20034150,
event=1, data=0x20033d30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x200441b0) at
Thread.cc:88
#11 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x003c330d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x41f4c3e0:
rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
called by frame at 0x41f4c520
Arglist at 0x41f4c3d0, args:
Locals at 0x41f4c3d0, Previous frame's sp is 0x41f4c3e0
Saved registers:
rip at 0x41f4c3d8
{code}
{code}
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
#1 0x0038aa231d10 in abort () from /lib64/libc.so.6
#2 0x0038aa26a84b in __libc_message () from /lib64/libc.so.6
#3 0x0038aa275421 in realloc () from /lib64/libc.so.6
#4 0x2ab28042ce01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2ab280680f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x16a6f150, event=1,
e=0x16a6ed30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x16a6f150,
event=1, data=0x16a6ed30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x16a7f1b0) at
Thread.cc:88
#11 0x0038aae064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x0038aa2d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x406b03e0:
rip = 0x38aa230265 in raise; saved rip 0x38aa231d10
called by frame at 0x406b0520
Arglist at 0x406b03d0, args:
Locals at 0x406b03d0, Previous frame's sp is 0x406b03e0
Saved registers:
rip at 0x406b03d8
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1158) Race on mutex switching for NetVConnections in UnixNetVConnection::mainEvent
[ https://issues.apache.org/jira/browse/TS-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1158: -- Backport to Version: 3.0.5 (was: 3.0.4) Race on mutex switching for NetVConnections in UnixNetVConnection::mainEvent Key: TS-1158 URL: https://issues.apache.org/jira/browse/TS-1158 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.3 Environment: ALL Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.4 Attachments: ts-1158-jp1.patch Because of the way session management works, the vio.mutex must be re-verified to be identical to the one the lock was taken on after the lock is acquired. Otherwise there is a race when the mutex is switched allowing such that the old lock is held while the new lock is in not held. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
