[jira] [Commented] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886218#comment-13886218 ] Brian Geffon commented on TS-2541: -- You're right, I shouldn't be using presence bits for those headers. I'll get that removed before committing. > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > Attachments: ws.patch > > > Add WebSocket Support in TrafficServer. > websocket is enabled on a remap basis, you will setup a websocket mapping by > specifying the ws:// or wss:// schemes, for example add the following to > remap.config: > map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ > Next, the current number of websocket connections can be monitored via the > stats variable proxy.process.http.websocket.current_active_client_connections > Community feedback would be appreciated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886197#comment-13886197 ] Leif Hedstrom commented on TS-2541: --- Sweet! One small comment / question: Do we need the PRESENCE bit's for these two strings? I don't see you actually using them anywhere, so are they actually worth spending two out of 64 precious bits on 'em ? What I'd like us to do for v5.0.0, is to go through both header token and the MIME_PRESENCE bits, and make sure that we both have all header tokens (WKS) that the modern web uses, as well as making sure we use the MIME_PRESENCE bits / presence() API optimal in the code (we might be able to free up more bits for future use for example). > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > Attachments: ws.patch > > > Add WebSocket Support in TrafficServer. > websocket is enabled on a remap basis, you will setup a websocket mapping by > specifying the ws:// or wss:// schemes, for example add the following to > remap.config: > map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ > Next, the current number of websocket connections can be monitored via the > stats variable proxy.process.http.websocket.current_active_client_connections > Community feedback would be appreciated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2541: - Description: Add WebSocket Support in TrafficServer. websocket is enabled on a remap basis, you will setup a websocket mapping by specifying the ws:// or wss:// schemes, for example add the following to remap.config: map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ Next, the current number of websocket connections can be monitored via the stats variable proxy.process.http.websocket.current_active_client_connections Community feedback would be appreciated. was: Add WebSocket Support in TrafficServer. websocket is enabled on a remap basis, you will setup a websocket mapping by specifying the ws:// or wss:// schemes, for example add the following to remap.config: map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ Next, the current number of websocket connections can be monitored via the stats variable > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > Attachments: ws.patch > > > Add WebSocket Support in TrafficServer. > websocket is enabled on a remap basis, you will setup a websocket mapping by > specifying the ws:// or wss:// schemes, for example add the following to > remap.config: > map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ > Next, the current number of websocket connections can be monitored via the > stats variable proxy.process.http.websocket.current_active_client_connections > Community feedback would be appreciated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2541: - Description: Add WebSocket Support in TrafficServer. WebSocket is enabled on a remap basis, you will setup a WebSocket mapping by specifying the ws:// or wss:// schemes. was:Add WebSocket Support in TrafficServer. > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > Attachments: ws.patch > > > Add WebSocket Support in TrafficServer. > WebSocket is enabled on a remap basis, you will setup a WebSocket mapping by > specifying the ws:// or wss:// schemes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2541: - Attachment: ws.patch > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > Attachments: ws.patch > > > Add WebSocket Support in TrafficServer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2541: - Description: Add WebSocket Support in TrafficServer. websocket is enabled on a remap basis, you will setup a websocket mapping by specifying the ws:// or wss:// schemes, for example add the following to remap.config: map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ Next, the current number of websocket connections can be monitored via the stats variable was: Add WebSocket Support in TrafficServer. WebSocket is enabled on a remap basis, you will setup a WebSocket mapping by specifying the ws:// or wss:// schemes. > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > Attachments: ws.patch > > > Add WebSocket Support in TrafficServer. > websocket is enabled on a remap basis, you will setup a websocket mapping by > specifying the ws:// or wss:// schemes, for example add the following to > remap.config: > map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ > Next, the current number of websocket connections can be monitored via the > stats variable -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2210) add API to get access to the client cert in the SSL Net VC
[
https://issues.apache.org/jira/browse/TS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886094#comment-13886094
]
James Peach commented on TS-2210:
-
[~bcall] and I chatted about this on IRC. The fundamental problem with exposing
SSL abstractions is that there's a huge amount of API that is needed for
plugins do be able to do the sorts of things they can do directly with the
OpenSSL API. The number of plugins that actually need this is very small and
the likelihood of Traffic Server using a TLS layer other than OpenSSL is slim.
So I propose the following API:
{code}
void * TSHttpSsnSSLContextGet(TSHttpSsn); // Returns SSL_CTX *
{code}
I don't much like the name of this API, but I think that this addresses the
needs of this ticket and also TS-1584.
> add API to get access to the client cert in the SSL Net VC
> --
>
> Key: TS-2210
> URL: https://issues.apache.org/jira/browse/TS-2210
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL, TS API
>Reporter: Bryan Call
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: 2210.diff
>
>
> In SSLNetVConnection SSL_get_peer_certificate(ssl) is called and client_cert
> is set. There is a request from Brian France to get access to the client
> cert.
> He wants to be able to call X509_NAME_oneline(), X509_get_subject_name(), and
> X509_get_issuer_name() on the cert.
> Where the cert is set in the code:
> iocore/net/SSLNetVConnection.cc:499:client_cert =
> SSL_get_peer_certificate(ssl);
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2542) Turn on caching zero length responses by default
[ https://issues.apache.org/jira/browse/TS-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2542: --- Fix Version/s: 5.0.0 > Turn on caching zero length responses by default > > > Key: TS-2542 > URL: https://issues.apache.org/jira/browse/TS-2542 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bryan Call > Fix For: 5.0.0 > > > 301 response is not being cached in forward proxy mode if content length is > zero bytes. > Test with a zero byte content length - doing multiple requests: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:44:03 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 0 > Content-Type: text/html; charset=UTF-8 > Age: 0 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t > cCMi p sS]) > Is cached if the content length is non-zero: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:48:11 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 4 > Content-Type: text/html; charset=UTF-8 > Age: 7 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t > cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2542) Turn on
[ https://issues.apache.org/jira/browse/TS-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2542: --- Summary: Turn on (was: ATS doesn't cache 301 response if the content length is 0) > Turn on > > > Key: TS-2542 > URL: https://issues.apache.org/jira/browse/TS-2542 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bryan Call > Fix For: 5.0.0 > > > 301 response is not being cached in forward proxy mode if content length is > zero bytes. > Test with a zero byte content length - doing multiple requests: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:44:03 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 0 > Content-Type: text/html; charset=UTF-8 > Age: 0 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t > cCMi p sS]) > Is cached if the content length is non-zero: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:48:11 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 4 > Content-Type: text/html; charset=UTF-8 > Age: 7 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t > cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2542) Turn on caching zero length responses by default
[ https://issues.apache.org/jira/browse/TS-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2542: --- Summary: Turn on caching zero length responses by default (was: Turn on ) > Turn on caching zero length responses by default > > > Key: TS-2542 > URL: https://issues.apache.org/jira/browse/TS-2542 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bryan Call > Fix For: 5.0.0 > > > 301 response is not being cached in forward proxy mode if content length is > zero bytes. > Test with a zero byte content length - doing multiple requests: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:44:03 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 0 > Content-Type: text/html; charset=UTF-8 > Age: 0 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t > cCMi p sS]) > Is cached if the content length is non-zero: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:48:11 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 4 > Content-Type: text/html; charset=UTF-8 > Age: 7 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t > cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2542) ATS doesn't cache 301 response if the content length is 0
[ https://issues.apache.org/jira/browse/TS-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886075#comment-13886075 ] Bryan Call commented on TS-2542: Configuring the server to cache empty doc fixed the problem: CONFIG proxy.config.http.cache.allow_empty_doc INT 1 Thanks [~zwoop] > ATS doesn't cache 301 response if the content length is 0 > - > > Key: TS-2542 > URL: https://issues.apache.org/jira/browse/TS-2542 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bryan Call > > 301 response is not being cached in forward proxy mode if content length is > zero bytes. > Test with a zero byte content length - doing multiple requests: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:44:03 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 0 > Content-Type: text/html; charset=UTF-8 > Age: 0 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t > cCMi p sS]) > Is cached if the content length is non-zero: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:48:11 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 4 > Content-Type: text/html; charset=UTF-8 > Age: 7 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t > cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [jira] [Created] (TS-2542) ATS doesn't cache 301 response if the content length is 0
Bryan, this is known and fixed alteady, there's a new configuration to allow caching of zero length documents. -- Leif > On Jan 29, 2014, at 4:50 PM, "Bryan Call (JIRA)" wrote: > > Bryan Call created TS-2542: > -- > > Summary: ATS doesn't cache 301 response if the content length is 0 > Key: TS-2542 > URL: https://issues.apache.org/jira/browse/TS-2542 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bryan Call > > > 301 response is not being cached in forward proxy mode if content length is > zero bytes. > > Test with a zero byte content length - doing multiple requests: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:44:03 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 0 > Content-Type: text/html; charset=UTF-8 > Age: 0 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t > cCMi p sS]) > > Is cached if the content length is non-zero: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:48:11 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 4 > Content-Type: text/html; charset=UTF-8 > Age: 7 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t > cCHi p s ]) > > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160)
[jira] [Created] (TS-2542) ATS doesn't cache 301 response if the content length is 0
Bryan Call created TS-2542: -- Summary: ATS doesn't cache 301 response if the content length is 0 Key: TS-2542 URL: https://issues.apache.org/jira/browse/TS-2542 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Bryan Call 301 response is not being cached in forward proxy mode if content length is zero bytes. Test with a zero byte content length - doing multiple requests: [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s http://homer.bryancall.com/301.php HTTP/1.1 301 Moved Permanently Date: Wed, 29 Jan 2014 23:44:03 GMT Server: ATS X-Powered-By: PHP/5.5.7 Location: http://www.yahoo.com/ Content-Length: 0 Content-Type: text/html; charset=UTF-8 Age: 0 Proxy-Connection: keep-alive Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t cCMi p sS]) Is cached if the content length is non-zero: [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s http://homer.bryancall.com/301.php HTTP/1.1 301 Moved Permanently Date: Wed, 29 Jan 2014 23:48:11 GMT Server: ATS X-Powered-By: PHP/5.5.7 Location: http://www.yahoo.com/ Content-Length: 4 Content-Type: text/html; charset=UTF-8 Age: 7 Proxy-Connection: keep-alive Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2541: - Fix Version/s: 4.2.0 > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > > Add WebSocket Support in TrafficServer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885929#comment-13885929
]
Leif Hedstrom commented on TS-612:
--
I changed fix version of this to v5.0.0, if you think this will land this week,
move it to v4.2.0.
> ATS does not allow password protected certificates
> --
>
> Key: TS-612
> URL: https://issues.apache.org/jira/browse/TS-612
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Igor Galić
>Assignee: Ron Barber
> Fix For: 5.0.0
>
>
> Create a (self-signed) certificate with a password that is non-empty. {cat
> server.key server.crt > server.pem} and configure it as
> {CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
> The result will be:
> {noformat}
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
> ---
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
> Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
> 2010 at 12:58:34)
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
> var/log/trafficserver/diags.log
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
> diags config
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
> cache disks specified in etc/trafficserver/storage.config: cache disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
> unable to open cache disk(s): Cache Disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Cannot use server private key file.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting
> password:pem_lib.c:105:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password
> read:pem_lib.c:406:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM
> lib:ssl_rsa.c:669:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Can't initialize the SSL library, disabling SSL termination!.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging
> initialized[7], logging_mode = 3
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic
> server running
> {noformat}
> A first -- ugly -- shot would be to at least have a password field in the
> configuration.
> In the end something taking the input of an external program or from a file
> would be more desirable.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-612:
-
Fix Version/s: (was: 6.0.0)
5.0.0
> ATS does not allow password protected certificates
> --
>
> Key: TS-612
> URL: https://issues.apache.org/jira/browse/TS-612
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Igor Galić
>Assignee: Ron Barber
> Fix For: 5.0.0
>
>
> Create a (self-signed) certificate with a password that is non-empty. {cat
> server.key server.crt > server.pem} and configure it as
> {CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
> The result will be:
> {noformat}
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
> ---
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
> Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
> 2010 at 12:58:34)
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
> var/log/trafficserver/diags.log
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
> diags config
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
> cache disks specified in etc/trafficserver/storage.config: cache disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
> unable to open cache disk(s): Cache Disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Cannot use server private key file.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting
> password:pem_lib.c:105:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password
> read:pem_lib.c:406:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM
> lib:ssl_rsa.c:669:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Can't initialize the SSL library, disabling SSL termination!.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging
> initialized[7], logging_mode = 3
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic
> server running
> {noformat}
> A first -- ugly -- shot would be to at least have a password field in the
> configuration.
> In the end something taking the input of an external program or from a file
> would be more desirable.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-2541: Assignee: Brian Geffon > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > > Add WebSocket Support in TrafficServer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2541: - Fix Version/s: (was: 4.1.3) > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > > Add WebSocket Support in TrafficServer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2541: - Fix Version/s: 4.1.3 > Add WebSocket support > - > > Key: TS-2541 > URL: https://issues.apache.org/jira/browse/TS-2541 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Brian Geffon > > Add WebSocket Support in TrafficServer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885900#comment-13885900
]
Scott Harris commented on TS-2138:
--
have tested again with patch from weijin and issue is fixed.
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.2.0
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2541) Add WebSocket support
Brian Geffon created TS-2541: Summary: Add WebSocket support Key: TS-2541 URL: https://issues.apache.org/jira/browse/TS-2541 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Brian Geffon Add WebSocket Support in TrafficServer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885882#comment-13885882
]
James Peach edited comment on TS-612 at 1/29/14 10:06 PM:
--
You don't need the {{passwd_cb}} typedef since OpenSSL provides a
{{pem_password_cb}} typedef. From looking at {{crypto/pem/pem.h}} you should
probably puke if OpenSSL is < 0.9.4, though.
{{SSL_CLEAR_PW_REFERENCES}} should be written in functional style, like
{{SSL_CLEAR_PW_REFERENCES(ud, ctx)}}.
Need to remove {{ink_process.h}} remnants.
I think the code that selects the dialog callback could be simpler. Here's what
I suggest:
{code}
passphrase_cb_userdata ud(params, serverDialog, serverCertPtr, serverKeyPtr);
if (serverDialog) {
int (*passwd_cb)(char *buf, int size, int rwflag, void *userdata);
if (strncmp(serverDialog,"exec:", 5) == 0) {
ud._serverDialog = &serverDialog[5];
// validate the exec program
if (!ssl_private_key_validate_exec(ud._serverDialog)) {
SSLError("failed to access '%s' pass phrase program: %s", (const char
*)ud._serverDialog,strerror(errno));
goto fail;
}
passwd_cb = ssl_private_key_passphrase_callback_exec;
} else if (strcmp(serverDialog, "builtin") == 0) {
passwd_cb = ssl_private_key_passphrase_callback_builtin;
} else {
// XXX Puke ...
}
SSL_CTX_set_default_passwd_cb(ctx, passwd_cb);
SSL_CTX_set_default_passwd_cb_userdata(ctx, &ud);
}
{code}
Why do the dialog functions allocate temporary buffer? It looks like they could
put the passphrase right into the buffer that OpenSSL gives us.
Nice documentation updates!
was (Author: jamespeach):
You don't need the {{passwd_cb}} typedef since OpenSSL provides a
{{pem_password_cb}} typedef. From looking at {{crypto/pem/pem.h}} you should
probably puke if OpenSSL is < 0.9.4, though.
{{SSL_CLEAR_PW_REFERENCES}} should be written in functional style, like
{{SSL_CLEAR_PW_REFERENCES(ud, ctx)}}.
Need to remove {{ink_process.h}} remnants.
I think the code that selects the dialog callback could be simpler. Here's what
I suggest:
{code}
passphrase_cb_userdata ud(params, serverDialog, serverCertPtr, serverKeyPtr);
if (serverDialog) {
int (*passwd_cb)(char *buf, int size, int rwflag, void *userdata);
if (strncmp(serverDialog,"exec:", 5) == 0) {
ud._serverDialog = &serverDialog[5];
// validate the exec program
if (!ssl_private_key_validate_exec(ud._serverDialog)) {
SSLError("failed to access '%s' pass phrase program: %s", (const char
*)ud._serverDialog,strerror(errno));
goto fail;
}
} else if (strcmp(serverDialog, "builtin") == 0) {
passwd_cb = ssl_private_key_passphrase_callback_exec;
} else {
// XXX Puke ...
passwd_cb = ssl_private_key_passphrase_callback_builtin;
}
SSL_CTX_set_default_passwd_cb(ctx, passwd_cb);
SSL_CTX_set_default_passwd_cb_userdata(ctx, &ud);
}
{code}
Why do the dialog functions allocate temporary buffer? It looks like they could
put the passphrase right into the buffer that OpenSSL gives us.
Nice documentation updates!
> ATS does not allow password protected certificates
> --
>
> Key: TS-612
> URL: https://issues.apache.org/jira/browse/TS-612
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Igor Galić
>Assignee: Ron Barber
> Fix For: 6.0.0
>
>
> Create a (self-signed) certificate with a password that is non-empty. {cat
> server.key server.crt > server.pem} and configure it as
> {CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
> The result will be:
> {noformat}
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
> ---
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
> Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
> 2010 at 12:58:34)
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
> var/log/trafficserver/diags.log
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
> diags config
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
> cache disks specified in etc/trafficserver/storage.config: cache disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
> unable to open cache disk(s): Cache Disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Cannot use server p
[jira] [Commented] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885882#comment-13885882
]
James Peach commented on TS-612:
You don't need the {{passwd_cb}} typedef since OpenSSL provides a
{{pem_password_cb}} typedef. From looking at {{crypto/pem/pem.h}} you should
probably puke if OpenSSL is < 0.9.4, though.
{{SSL_CLEAR_PW_REFERENCES}} should be written in functional style, like
{{SSL_CLEAR_PW_REFERENCES(ud, ctx)}}.
Need to remove {{ink_process.h}} remnants.
I think the code that selects the dialog callback could be simpler. Here's what
I suggest:
{code}
passphrase_cb_userdata ud(params, serverDialog, serverCertPtr, serverKeyPtr);
if (serverDialog) {
int (*passwd_cb)(char *buf, int size, int rwflag, void *userdata);
if (strncmp(serverDialog,"exec:", 5) == 0) {
ud._serverDialog = &serverDialog[5];
// validate the exec program
if (!ssl_private_key_validate_exec(ud._serverDialog)) {
SSLError("failed to access '%s' pass phrase program: %s", (const char
*)ud._serverDialog,strerror(errno));
goto fail;
}
} else if (strcmp(serverDialog, "builtin") == 0) {
passwd_cb = ssl_private_key_passphrase_callback_exec;
} else {
// XXX Puke ...
passwd_cb = ssl_private_key_passphrase_callback_builtin;
}
SSL_CTX_set_default_passwd_cb(ctx, passwd_cb);
SSL_CTX_set_default_passwd_cb_userdata(ctx, &ud);
}
{code}
Why do the dialog functions allocate temporary buffer? It looks like they could
put the passphrase right into the buffer that OpenSSL gives us.
Nice documentation updates!
> ATS does not allow password protected certificates
> --
>
> Key: TS-612
> URL: https://issues.apache.org/jira/browse/TS-612
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Igor Galić
>Assignee: Ron Barber
> Fix For: 6.0.0
>
>
> Create a (self-signed) certificate with a password that is non-empty. {cat
> server.key server.crt > server.pem} and configure it as
> {CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
> The result will be:
> {noformat}
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
> ---
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
> Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
> 2010 at 12:58:34)
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
> var/log/trafficserver/diags.log
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
> diags config
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
> cache disks specified in etc/trafficserver/storage.config: cache disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
> unable to open cache disk(s): Cache Disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Cannot use server private key file.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting
> password:pem_lib.c:105:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password
> read:pem_lib.c:406:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM
> lib:ssl_rsa.c:669:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Can't initialize the SSL library, disabling SSL termination!.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging
> initialized[7], logging_mode = 3
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic
> server running
> {noformat}
> A first -- ugly -- shot would be to at least have a password field in the
> configuration.
> In the end something taking the input of an external program or from a file
> would be more desirable.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2540) header_rewrite: Does not detect a Statement without a predicated as an error
Leif Hedstrom created TS-2540:
-
Summary: header_rewrite: Does not detect a Statement without a
predicated as an error
Key: TS-2540
URL: https://issues.apache.org/jira/browse/TS-2540
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Leif Hedstrom
For example, this config silently fails with no errors, and worse, leaves the
parser in a potentially erroneous state (causing subsequent rules to be wrong):
{code}
cond %{READ_REQUEST_HDR_HOOK}
X-Some-Header "zwoop"
{code}
Yes, it's obviously a config error (it should have a "set-config" predicate),
but we should detect this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2540) header_rewrite: Does not detect a Statement without a predicated as an error
[
https://issues.apache.org/jira/browse/TS-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2540:
--
Fix Version/s: 5.0.0
> header_rewrite: Does not detect a Statement without a predicated as an error
>
>
> Key: TS-2540
> URL: https://issues.apache.org/jira/browse/TS-2540
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 5.0.0
>
>
> For example, this config silently fails with no errors, and worse, leaves the
> parser in a potentially erroneous state (causing subsequent rules to be
> wrong):
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> X-Some-Header "zwoop"
> {code}
> Yes, it's obviously a config error (it should have a "set-config" predicate),
> but we should detect this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2353) add ability to load ssl certs that are owned by root and only read only by the user
[
https://issues.apache.org/jira/browse/TS-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2353:
Attachment: TS-2353-mutex.patch
> add ability to load ssl certs that are owned by root and only read only by
> the user
> ---
>
> Key: TS-2353
> URL: https://issues.apache.org/jira/browse/TS-2353
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP, SSL
>Reporter: Bryan Call
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS-2353-mutex.patch, TS-2353_3.patch,
> ssl-start-as-root.patch
>
>
> [Nov 15 01:11:23.748] Server {0x2aaff3cb33a0} ERROR:
> SSL::0:error:0200100D:system library:fopen:Permission
> denied:bss_file.c:355:fopen('//search.crt','r')
> [Nov 15 01:11:23.748] Server {0x2aaff3cb33a0} ERROR:
> SSL::0:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:357:
> [Nov 15 01:11:23.748] Server {0x2aaff3cb33a0} ERROR:
> SSL::0:error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system
> lib:ssl_rsa.c:470:
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2353) add ability to load ssl certs that are owned by root and only read only by the user
[
https://issues.apache.org/jira/browse/TS-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885654#comment-13885654
]
James Peach commented on TS-2353:
-
Mutex handling in ElevateAccess is not gonna work. See new patch for how this
ought to be.
Please add a new SSL option to {{records.config}}enable root privileges for
reading the SSL certs. This should be disabled by default and the documentation
should discourage people from turning it on :)
> add ability to load ssl certs that are owned by root and only read only by
> the user
> ---
>
> Key: TS-2353
> URL: https://issues.apache.org/jira/browse/TS-2353
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP, SSL
>Reporter: Bryan Call
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS-2353_3.patch, ssl-start-as-root.patch
>
>
> [Nov 15 01:11:23.748] Server {0x2aaff3cb33a0} ERROR:
> SSL::0:error:0200100D:system library:fopen:Permission
> denied:bss_file.c:355:fopen('//search.crt','r')
> [Nov 15 01:11:23.748] Server {0x2aaff3cb33a0} ERROR:
> SSL::0:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:357:
> [Nov 15 01:11:23.748] Server {0x2aaff3cb33a0} ERROR:
> SSL::0:error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system
> lib:ssl_rsa.c:470:
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2138.
---
Resolution: Fixed
I think I moved this to the wrong state, sorry.
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.2.0
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Reopened] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reopened TS-2138:
---
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.2.0
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1767) Cache Lookup Regex using incorrect urls
[
https://issues.apache.org/jira/browse/TS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885514#comment-13885514
]
Thomas Berger commented on TS-1767:
---
Is i found this problem very annoying, i had a look.
What i found so far:
The helper class UrlPrintHack should prepare the URL Object for the printing
process.
It should set the Host in the Url string from the Host header. For some reasons
{code}hdr->m_target_in_url{code} seems to be true, so that the host is not set
from the header.
I will investigate this issue, unless someone is already working on this and
want to finish it.
> Cache Lookup Regex using incorrect urls
> ---
>
> Key: TS-1767
> URL: https://issues.apache.org/jira/browse/TS-1767
> Project: Traffic Server
> Issue Type: Bug
> Components: Web UI
>Reporter: Scott Harris
> Fix For: sometime
>
>
> When using the cache regex lookup returned urls contain origin server not of
> incoming mapping to ats.
> Ie using map http://incoming http://10.1.1.1:8080
> returned regex urls are : http://10.1.1.1:8080/ instead of
> http://incoming/
> Selecting any of these results in "Cache Lookup Failed, or missing in cluster"
> Doing url lookup with incoming url returns valid result.
> Using version 3.2.4 running as a reverse proxy
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom closed TS-2138.
-
Resolution: Fixed
Sounds like this is fixed? Reopen if not.
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.2.0
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2537) Segmentation Fault with cache files and linux native AIO
[
https://issues.apache.org/jira/browse/TS-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2537:
--
Summary: Segmentation Fault with cache files and linux native AIO (was:
Segmentation Fault with cache files and aio)
> Segmentation Fault with cache files and linux native AIO
>
>
> Key: TS-2537
> URL: https://issues.apache.org/jira/browse/TS-2537
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.1.2
>Reporter: Thomas Berger
> Labels: crash
> Fix For: sometime
>
>
> We have multiple crashes with trafficserver if we use AIO.
> {code}
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x2ba879a1e030]
> /usr/bin/traffic_server(ink_aio_read(AIOCallback*, int)+0x26)[0x605796]
> /usr/bin/traffic_server(CacheVC::handleRead(int, Event*)+0x5c1)[0x5db1c1]
> /usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x55e)[0x5f23ae]
> /usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x86)[0x5dd176]
> /usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x8e)[0x4f6f1e]
> /usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0x102)[0x513812]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1a1)[0x5162f1]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x174a)[0x51789a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/gzip.so(+0x4c9e)[0x2ba884004c9e]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/header_filter.so(+0x2acf)[0x2ba87fc03acf]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x524)[0x503df4]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x95)[0x5028c5]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_add_to_list(int, void*)+0x14f)[0x50302f]
> /usr/bin/traffic_server(HttpSM::attach_client_session(HttpClientSession*,
> IOBufferReader*)+0x434)[0x503894]
> /usr/bin/traffic_server(HttpClientSession::state_keep_alive(int, void*)+0x8b)
> [0x4f873b]
> /usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x2e)
> [0x6157de]
> /usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
> EThread*)+0x807)[0x6078f7]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x4e7)[0x60f6e7]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x15a)[0x62c10a]
> /usr/bin/traffic_server(EThread::execute()+0x954)[0x62ccb4]
> /usr/bin/traffic_server[0x62b174]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x2ba879a15b50]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ba87a426a7d]
> {code}
> If we deactivate the cache files, we have no cache, but also no crashes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2537) Segmentation Fault with cache files and linux native AIO
[
https://issues.apache.org/jira/browse/TS-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2537:
--
Fix Version/s: (was: 4.2.0)
sometime
> Segmentation Fault with cache files and linux native AIO
>
>
> Key: TS-2537
> URL: https://issues.apache.org/jira/browse/TS-2537
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.1.2
>Reporter: Thomas Berger
> Labels: crash
> Fix For: sometime
>
>
> We have multiple crashes with trafficserver if we use AIO.
> {code}
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x2ba879a1e030]
> /usr/bin/traffic_server(ink_aio_read(AIOCallback*, int)+0x26)[0x605796]
> /usr/bin/traffic_server(CacheVC::handleRead(int, Event*)+0x5c1)[0x5db1c1]
> /usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x55e)[0x5f23ae]
> /usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x86)[0x5dd176]
> /usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x8e)[0x4f6f1e]
> /usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0x102)[0x513812]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1a1)[0x5162f1]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x174a)[0x51789a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/gzip.so(+0x4c9e)[0x2ba884004c9e]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/header_filter.so(+0x2acf)[0x2ba87fc03acf]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x524)[0x503df4]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x95)[0x5028c5]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_add_to_list(int, void*)+0x14f)[0x50302f]
> /usr/bin/traffic_server(HttpSM::attach_client_session(HttpClientSession*,
> IOBufferReader*)+0x434)[0x503894]
> /usr/bin/traffic_server(HttpClientSession::state_keep_alive(int, void*)+0x8b)
> [0x4f873b]
> /usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x2e)
> [0x6157de]
> /usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
> EThread*)+0x807)[0x6078f7]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x4e7)[0x60f6e7]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x15a)[0x62c10a]
> /usr/bin/traffic_server(EThread::execute()+0x954)[0x62ccb4]
> /usr/bin/traffic_server[0x62b174]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x2ba879a15b50]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ba87a426a7d]
> {code}
> If we deactivate the cache files, we have no cache, but also no crashes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2530) False positive detected for Multi-Hop cycle when using private IP
[ https://issues.apache.org/jira/browse/TS-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885484#comment-13885484 ] ASF subversion and git services commented on TS-2530: - Commit 666bb424786c4dc7f8816fb5568abb3d124b96f1 in branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=666bb42 ] TS-2530 - CHANGES not correct, fixed. > False positive detected for Multi-Hop cycle when using private IP > - > > Key: TS-2530 > URL: https://issues.apache.org/jira/browse/TS-2530 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Ron Barber >Assignee: Alan M. Carroll > Fix For: 4.2.0 > > Attachments: TS-2530.patch > > > With hosts A and B running ATS where both hosts have private IPs (10.0.0.1 & > 10.0.0.2) AND have a local loopback which have a public IP 27.1.1.1 we are > getting HTTP/1.1 400 Multi-Hop Cycle Detected when host A forwards a request > to host B. > ATS searches the incoming Via header for its own ip address > (Machine::instance()->ip_hex_string) to determine if the request has been > forwarded back to itself. > Cause: ATS is selecting the public IP address of the server to insert in the > Via header (even if it's not on a routable interface). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2530) False positive detected for Multi-Hop cycle when using private IP
[ https://issues.apache.org/jira/browse/TS-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885466#comment-13885466 ] ASF subversion and git services commented on TS-2530: - Commit 61dbe66ece9dff3ab98abfc3d2463ca65bd75d3e in branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=61dbe66 ] TS-2530 - Check for loopback interfaces to avoid false multi-cycle hop detection > False positive detected for Multi-Hop cycle when using private IP > - > > Key: TS-2530 > URL: https://issues.apache.org/jira/browse/TS-2530 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Ron Barber >Assignee: Alan M. Carroll > Fix For: 4.2.0 > > Attachments: TS-2530.patch > > > With hosts A and B running ATS where both hosts have private IPs (10.0.0.1 & > 10.0.0.2) AND have a local loopback which have a public IP 27.1.1.1 we are > getting HTTP/1.1 400 Multi-Hop Cycle Detected when host A forwards a request > to host B. > ATS searches the incoming Via header for its own ip address > (Machine::instance()->ip_hex_string) to determine if the request has been > forwarded back to itself. > Cause: ATS is selecting the public IP address of the server to insert in the > Via header (even if it's not on a routable interface). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885458#comment-13885458
]
ASF subversion and git services commented on TS-2539:
-
Commit eb450fa809efb1d2586cad6b267982edc73014b2 in branch refs/heads/master
from [~i.galic]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=eb450fa ]
TS-2539: clean up Generated Perl files
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2539:
--
Fix Version/s: 4.2.0
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
> Fix For: 4.2.0
>
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2539:
-
Assignee: Leif Hedstrom
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>Assignee: Leif Hedstrom
> Fix For: 4.2.0
>
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2539:
--
Assignee: Igor Galić (was: Leif Hedstrom)
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2031) Two SSL certs with overlapping CNs stomps over each other without warnings
[ https://issues.apache.org/jira/browse/TS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885381#comment-13885381 ] Leif Hedstrom commented on TS-2031: --- Nah, it's not critical IMO. -- Leif > Two SSL certs with overlapping CNs stomps over each other without warnings > -- > > Key: TS-2031 > URL: https://issues.apache.org/jira/browse/TS-2031 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: Leif Hedstrom >Assignee: James Peach >Priority: Minor > Fix For: 4.2.0 > > Attachments: TS-2031.diff > > > If you have two certs that has the same CNs, the last one wins in the SNI > negotiation. This even takes precedence over "assigned" IPs (SNI trumps IP). > We should at least warn on this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2537) Segmentation Fault with cache files and aio
[
https://issues.apache.org/jira/browse/TS-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885354#comment-13885354
]
Thomas Berger commented on TS-2537:
---
Without the native linux AIO support, we don't could trigger any crash.
> Segmentation Fault with cache files and aio
> ---
>
> Key: TS-2537
> URL: https://issues.apache.org/jira/browse/TS-2537
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.1.2
>Reporter: Thomas Berger
> Labels: crash
> Fix For: 4.2.0
>
>
> We have multiple crashes with trafficserver if we use AIO.
> {code}
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x2ba879a1e030]
> /usr/bin/traffic_server(ink_aio_read(AIOCallback*, int)+0x26)[0x605796]
> /usr/bin/traffic_server(CacheVC::handleRead(int, Event*)+0x5c1)[0x5db1c1]
> /usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x55e)[0x5f23ae]
> /usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x86)[0x5dd176]
> /usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x8e)[0x4f6f1e]
> /usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0x102)[0x513812]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1a1)[0x5162f1]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x174a)[0x51789a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/gzip.so(+0x4c9e)[0x2ba884004c9e]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/header_filter.so(+0x2acf)[0x2ba87fc03acf]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x524)[0x503df4]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x95)[0x5028c5]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_add_to_list(int, void*)+0x14f)[0x50302f]
> /usr/bin/traffic_server(HttpSM::attach_client_session(HttpClientSession*,
> IOBufferReader*)+0x434)[0x503894]
> /usr/bin/traffic_server(HttpClientSession::state_keep_alive(int, void*)+0x8b)
> [0x4f873b]
> /usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x2e)
> [0x6157de]
> /usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
> EThread*)+0x807)[0x6078f7]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x4e7)[0x60f6e7]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x15a)[0x62c10a]
> /usr/bin/traffic_server(EThread::execute()+0x954)[0x62ccb4]
> /usr/bin/traffic_server[0x62b174]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x2ba879a15b50]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ba87a426a7d]
> {code}
> If we deactivate the cache files, we have no cache, but also no crashes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885327#comment-13885327
]
Igor Galić commented on TS-2539:
so you tested this and it works out fine?
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885292#comment-13885292
]
Arno Toell commented on TS-2539:
err. No, you don't. Forget what I said, and yes, I hate automake.
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885289#comment-13885289
]
Arno Toell commented on TS-2539:
Yes, but you probably want to do in Makefile.in, not .am :)
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885289#comment-13885289
]
Arno Toell edited comment on TS-2539 at 1/29/14 12:25 PM:
--
Yes, but wouldn't you have to do that in Makefile.in, not .am?
was (Author: at):
Yes, but you probably want to do in Makefile.in, not .am :)
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2539) Generated Perl files are not cleaned up
[
https://issues.apache.org/jira/browse/TS-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885288#comment-13885288
]
Igor Galić commented on TS-2539:
I have a patch, I hope that's good enough:
{code}
diff --git lib/perl/Makefile.am lib/perl/Makefile.am
index 496f217..f2457c5 100644
--- lib/perl/Makefile.am
+++ lib/perl/Makefile.am
@@ -29,7 +29,7 @@ Makefile-pl: Makefile.PL
$(PERL) Makefile.PL INSTALLDIRS=$(INSTALLDIRS) PREFIX=$(prefix)
distclean-local:
- -rm -f Makefile-pl
+ -rm -rf Makefile-pl MYMETA.* blip
#test: check
{code}
> Generated Perl files are not cleaned up
> ---
>
> Key: TS-2539
> URL: https://issues.apache.org/jira/browse/TS-2539
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Arno Toell
>
> Similar to TS-2532, also the generated files for the Perl bindings need to be
> cleaned up when calling the make (dist)clean targets. The Makefile does not
> cleanup these files:
> {code}
> trafficserver/lib/perl/MYMETA.json
> trafficserver/lib/perl/MYMETA.yml
> trafficserver/lib/perl/blib/lib/Apache/TS.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
> trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
> trafficserver/lib/perl/blib/man3/Apache::TS.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
> trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2031) Two SSL certs with overlapping CNs stomps over each other without warnings
[ https://issues.apache.org/jira/browse/TS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885281#comment-13885281 ] Igor Galić commented on TS-2031: Do we want to backport this to 4.1.3? > Two SSL certs with overlapping CNs stomps over each other without warnings > -- > > Key: TS-2031 > URL: https://issues.apache.org/jira/browse/TS-2031 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: Leif Hedstrom >Assignee: James Peach >Priority: Minor > Fix For: 4.2.0 > > Attachments: TS-2031.diff > > > If you have two certs that has the same CNs, the last one wins in the SNI > negotiation. This even takes precedence over "assigned" IPs (SNI trumps IP). > We should at least warn on this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2539) Generated Perl files are not cleaned up
Arno Toell created TS-2539:
--
Summary: Generated Perl files are not cleaned up
Key: TS-2539
URL: https://issues.apache.org/jira/browse/TS-2539
Project: Traffic Server
Issue Type: Bug
Reporter: Arno Toell
Similar to TS-2532, also the generated files for the Perl bindings need to be
cleaned up when calling the make (dist)clean targets. The Makefile does not
cleanup these files:
{code}
trafficserver/lib/perl/MYMETA.json
trafficserver/lib/perl/MYMETA.yml
trafficserver/lib/perl/blib/lib/Apache/TS.pm
trafficserver/lib/perl/blib/lib/Apache/TS/AdminClient.pm
trafficserver/lib/perl/blib/lib/Apache/TS/Config.pm
trafficserver/lib/perl/blib/lib/Apache/TS/Config/Records.pm
trafficserver/lib/perl/blib/man3/Apache::TS.3pm
trafficserver/lib/perl/blib/man3/Apache::TS::AdminClient.3pm
trafficserver/lib/perl/blib/man3/Apache::TS::Config::Records.3pm
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13884481#comment-13884481 ] Ron Barber edited comment on TS-2306 at 1/29/14 11:05 AM: -- Patch attached: Prevent producer from running "wide open" if there is no space in the write buffer, thereby allowing the consumer the chance to run to consume its data. Any delta in ats performance for SSL origins isdifficult to determine since without the patch data does not flow. I found performance through ats to be on par with curling directly to the origin. was (Author: rwbarber2): Prevent producer from running "wide open" if there is no space in the write buffer, thereby allowing the consumer the chance to run to consume its data. Any delta in ats performance for SSL origins isdifficult to determine since without the patch data does not flow. I found performance through ats to be on par with curling directly to the origin. > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran > Fix For: 4.2.0 > > Attachments: TS-2306.patch > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for http://localhost:8081/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8080/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
