[jira] [Commented] (TS-2210) add API to get access to the client cert in the SSL Net VC

2014-02-10 Thread kang li (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896336#comment-13896336
 ] 

kang li commented on TS-2210:
-

Hi James,

The new API was more concise. I have also done a small test, the new style API 
worked well. But for SSL_CTX we need SSL to get the verify result and client 
certificate, and SSLNetVConnection store SSL as the domain. So I think return 
SSL would be more convenient:
{code}
 void *TSHttpSsnSSLConnectionGet(TSHttpSsn); // Returns SSL *
{code}
If SSL_CTX was needed, we could use SSL_get_SSL_CTX to get related SSL_CTX.

If the newer API was suitable, I would send the API review request.





 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: 5.0.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-2437) Add an API to expose SSL_CTX for applications

2014-02-10 Thread Wei Sun (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Sun updated TS-2437:


Attachment: TS-2437-lifecycle.diff

Regenerated a diff to use liefecycle hooks API, please take a look.

 Add an API to expose SSL_CTX for applications
 -

 Key: TS-2437
 URL: https://issues.apache.org/jira/browse/TS-2437
 Project: Traffic Server
  Issue Type: Task
  Components: SSL, TS API
Reporter: Wei Sun
Assignee: James Peach
 Fix For: 5.0.0

 Attachments: TS-2437-2.diff, TS-2437-lifecycle.diff, TS-2437.diff


 It'll be good to add an API to expose all the SSL_CTXs, so that plugins can 
 manipulate their specific ssl settings / call back, etc. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (TS-2210) add API to get access to the client cert in the SSL Net VC

2014-02-10 Thread kang li (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

kang li updated TS-2210:


Attachment: TS-2210-2.diff

 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: 5.0.0

 Attachments: 2210.diff, TS-2210-2.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] [Commented] (TS-1622) Add an API to query if a response header would be cacheable

2014-02-10 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896574#comment-13896574
 ] 

ASF subversion and git services commented on TS-1622:
-

Commit 77a0583913153849d4d2e7baf5de03ef396ca2da in branch refs/heads/master 
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=77a0583 ]

TS-1622 Add an API to query if a response header would be cacheable


 Add an API to query if a response header would be cacheable
 ---

 Key: TS-1622
 URL: https://issues.apache.org/jira/browse/TS-1622
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
  Labels: A
 Fix For: 5.0.0

 Attachments: TS-1622.diff


 It would be useful for a plugin to be able to take e.g. a response header (a 
 Hdr object) and ask the HttpSM if this response would be cacheable or not. It 
 should use the same logic (and configs) as the core does normally.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (TS-1622) Add an API to query if a response header would be cacheable

2014-02-10 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896575#comment-13896575
 ] 

ASF subversion and git services commented on TS-1622:
-

Commit 069c79ecf23d1e8e244d6c2fb626ec8df861743f in branch refs/heads/master 
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=069c79e ]

Added TS-1622 to CHANGES.


 Add an API to query if a response header would be cacheable
 ---

 Key: TS-1622
 URL: https://issues.apache.org/jira/browse/TS-1622
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
  Labels: A
 Fix For: 5.0.0

 Attachments: TS-1622.diff


 It would be useful for a plugin to be able to take e.g. a response header (a 
 Hdr object) and ask the HttpSM if this response would be cacheable or not. It 
 should use the same logic (and configs) as the core does normally.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (TS-2563) Set the SSL default verify paths when ssl.client.verify.server=1

2014-02-10 Thread Wei Sun (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Sun updated TS-2563:


Attachment: TS-2563.diff

 Set the SSL default verify paths when ssl.client.verify.server=1
 

 Key: TS-2563
 URL: https://issues.apache.org/jira/browse/TS-2563
 Project: Traffic Server
  Issue Type: Bug
Reporter: Wei Sun
 Attachments: TS-2563.diff


 When working at reverse proxy mode with the following remap rule:
 map https://xxx1.com https://xxx2.com
 ssl.client.verify.server=1
 If xxx2.com is providing trusted certificate and 
 'ssl.client.CA.cert.filename' is NULL, ats should be able to verify the 
 certificate in terms of the default provided CAs.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (TS-2563) Set the SSL default verify paths when ssl.client.verify.server=1

2014-02-10 Thread Wei Sun (JIRA)
Wei Sun created TS-2563:
---

 Summary: Set the SSL default verify paths when 
ssl.client.verify.server=1
 Key: TS-2563
 URL: https://issues.apache.org/jira/browse/TS-2563
 Project: Traffic Server
  Issue Type: Bug
Reporter: Wei Sun
 Attachments: TS-2563.diff

When working at reverse proxy mode with the following remap rule:
map https://xxx1.com https://xxx2.com

ssl.client.verify.server=1

If xxx2.com is providing trusted certificate and 'ssl.client.CA.cert.filename' 
is NULL, ats should be able to verify the certificate in terms of the default 
provided CAs.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (TS-2433) Size threshold for SSL request

2014-02-10 Thread James Peach (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896719#comment-13896719
 ] 

James Peach commented on TS-2433:
-

What's the rationale for this feature?

 Size threshold for SSL request
 --

 Key: TS-2433
 URL: https://issues.apache.org/jira/browse/TS-2433
 Project: Traffic Server
  Issue Type: Task
Reporter: Wei Sun
Assignee: Wei Sun
 Fix For: 5.0.0

 Attachments: TS-2433.diff


 A size threshold is expected for client request over SSL, if the max 
 requested data(SSL_read) exceeds the threshold, close the connection. 
 Default: no size limitation. We have this use case when using stunnel, expect 
 to have the same functionality in ATS.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (TS-2210) add API to get access to the client cert in the SSL Net VC

2014-02-10 Thread James Peach (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-2210:


Labels: Review  (was: )

 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
  Labels: Review
 Fix For: 5.0.0

 Attachments: 2210.diff, TS-2210-2.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] [Commented] (TS-2437) Add an API to expose SSL_CTX for applications

2014-02-10 Thread James Peach (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896728#comment-13896728
 ] 

James Peach commented on TS-2437:
-

Will review. Does the lifecycle hook get called early enough for your needs?

 Add an API to expose SSL_CTX for applications
 -

 Key: TS-2437
 URL: https://issues.apache.org/jira/browse/TS-2437
 Project: Traffic Server
  Issue Type: Task
  Components: SSL, TS API
Reporter: Wei Sun
Assignee: James Peach
  Labels: Review
 Fix For: 5.0.0

 Attachments: TS-2437-2.diff, TS-2437-lifecycle.diff, TS-2437.diff


 It'll be good to add an API to expose all the SSL_CTXs, so that plugins can 
 manipulate their specific ssl settings / call back, etc. 



--
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

2014-02-10 Thread James Peach (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896726#comment-13896726
 ] 

James Peach commented on TS-2210:
-

This sounds fine.

 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
  Labels: Review
 Fix For: 5.0.0

 Attachments: 2210.diff, TS-2210-2.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-2437) Add an API to expose SSL_CTX for applications

2014-02-10 Thread James Peach (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-2437:


Labels: Review  (was: )

 Add an API to expose SSL_CTX for applications
 -

 Key: TS-2437
 URL: https://issues.apache.org/jira/browse/TS-2437
 Project: Traffic Server
  Issue Type: Task
  Components: SSL, TS API
Reporter: Wei Sun
Assignee: James Peach
  Labels: Review
 Fix For: 5.0.0

 Attachments: TS-2437-2.diff, TS-2437-lifecycle.diff, TS-2437.diff


 It'll be good to add an API to expose all the SSL_CTXs, so that plugins can 
 manipulate their specific ssl settings / call back, etc. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (TS-2563) Set the SSL default verify paths when ssl.client.verify.server=1

2014-02-10 Thread James Peach (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-2563:


Labels: Review  (was: )

 Set the SSL default verify paths when ssl.client.verify.server=1
 

 Key: TS-2563
 URL: https://issues.apache.org/jira/browse/TS-2563
 Project: Traffic Server
  Issue Type: Bug
Reporter: Wei Sun
  Labels: Review
 Fix For: 5.0.0

 Attachments: TS-2563.diff


 When working at reverse proxy mode with the following remap rule:
 map https://xxx1.com https://xxx2.com
 ssl.client.verify.server=1
 If xxx2.com is providing trusted certificate and 
 'ssl.client.CA.cert.filename' is NULL, ats should be able to verify the 
 certificate in terms of the default provided CAs.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (TS-2563) Set the SSL default verify paths when ssl.client.verify.server=1

2014-02-10 Thread James Peach (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-2563:


Fix Version/s: 5.0.0
 Assignee: James Peach

 Set the SSL default verify paths when ssl.client.verify.server=1
 

 Key: TS-2563
 URL: https://issues.apache.org/jira/browse/TS-2563
 Project: Traffic Server
  Issue Type: Bug
Reporter: Wei Sun
Assignee: James Peach
  Labels: Review
 Fix For: 5.0.0

 Attachments: TS-2563.diff


 When working at reverse proxy mode with the following remap rule:
 map https://xxx1.com https://xxx2.com
 ssl.client.verify.server=1
 If xxx2.com is providing trusted certificate and 
 'ssl.client.CA.cert.filename' is NULL, ats should be able to verify the 
 certificate in terms of the default provided CAs.



--
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

2014-02-10 Thread James Peach (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896760#comment-13896760
 ] 

James Peach commented on TS-2210:
-

When I researched this earlier, I thought that {{SSL_SESSION *}} would be the 
appropriate pointer to return, but the OpenSSL APIs are really not designed for 
that to be useful AFAICT.

 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
  Labels: Review
 Fix For: 5.0.0

 Attachments: 2210.diff, TS-2210-2.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] [Commented] (TS-2469) traffic_shell links against libreadline which is gpl licensed

2014-02-10 Thread Bryan Call (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896903#comment-13896903
 ] 

Bryan Call commented on TS-2469:


What is the status on this bug?  Can it be closed?

 traffic_shell links against libreadline which is gpl licensed
 -

 Key: TS-2469
 URL: https://issues.apache.org/jira/browse/TS-2469
 Project: Traffic Server
  Issue Type: Bug
Reporter: Ben Aitchison
Assignee: Zhao Yongming
Priority: Minor
  Labels: traffic_shell
 Fix For: 4.1.3, 4.2.0

 Attachments: removereadline.txt


 libreadline is gpl licensed which is infectious.  libedit is a free 
 alternative, and is already supported in the configure scripts so libreadline 
 support should be removed.
 it seems traffic_shell is the only thing using libreadline/libedit currently.



--
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

2014-02-10 Thread Manjesh Nilange (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896922#comment-13896922
 ] 

Manjesh Nilange commented on TS-2353:
-

Can this patch/feature be used for plugin initialization? That'd be nice. 

 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-with-config.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] [Created] (TS-2564) Segmentation fault in 4.2.0-rc0

2014-02-10 Thread Bryan Call (JIRA)
Bryan Call created TS-2564:
--

 Summary: Segmentation fault in 4.2.0-rc0
 Key: TS-2564
 URL: https://issues.apache.org/jira/browse/TS-2564
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call


Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
4.2.0-rc0:

{code}
(gdb) bt
#0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
detach_all_dups=false) at MIME.cc:1538
#2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized out) 
at MIME.cc:1586
#3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4  field_delete (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) 
at ../../proxy/hdrs/MIME.h:1115
#5  HttpTransact::merge_response_header_with_cached_header 
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
HttpTransact.cc:4914
{code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (TS-2564) Segmentation fault in 4.2.0-rc0

2014-02-10 Thread Bryan Call (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-2564:
---

Fix Version/s: 4.2.0

 Segmentation fault in 4.2.0-rc0
 ---

 Key: TS-2564
 URL: https://issues.apache.org/jira/browse/TS-2564
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call
 Fix For: 4.2.0


 Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
 4.2.0-rc0:
 {code}
 (gdb) bt
 #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
 field=value optimized out, detach_all_dups=false) at MIME.cc:469
 #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
 detach_all_dups=false) at MIME.cc:1538
 #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
 mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized 
 out) at MIME.cc:1586
 #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
 #4  field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
 #5  HttpTransact::merge_response_header_with_cached_header 
 (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
 HttpTransact.cc:4914
 {code}



--
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

2014-02-10 Thread James Peach (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897005#comment-13897005
 ] 

James Peach commented on TS-2353:
-

For that you want to set {{proxy.config.plugin.load_elevated}}.

 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-with-config.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-2564) Segmentation fault in 4.2.0-rc0

2014-02-10 Thread Bryan Call (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897079#comment-13897079
 ] 

Bryan Call commented on TS-2564:


In frame 5:

{code}
#5  HttpTransact::merge_response_header_with_cached_header 
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
HttpTransact.cc:4914

  cached_header-field_delete(dname, dlen);

(gdb) p field
$19 = (MIMEField *) 0x2acd57070158
(gdb) p field-m_next_dup
$20 = (MIMEField *) 0x2acd57070178
{code}

But in frame 2 it is trying to delete another field:

{code}
#2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized out) 
at MIME.cc:1586

  mime_hdr_field_detach(mh, field, 0);

(gdb) p next
$1 = (MIMEField *) 0x2b723a7d9ca8
(gdb) p *next
Cannot access memory at address 0x2b723a7d9ca8
{code}

 Segmentation fault in 4.2.0-rc0
 ---

 Key: TS-2564
 URL: https://issues.apache.org/jira/browse/TS-2564
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call
Priority: Blocker
 Fix For: 4.2.0


 Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
 4.2.0-rc0:
 {code}
 (gdb) bt
 #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
 field=value optimized out, detach_all_dups=false) at MIME.cc:469
 #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
 detach_all_dups=false) at MIME.cc:1538
 #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
 mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized 
 out) at MIME.cc:1586
 #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
 #4  field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
 #5  HttpTransact::merge_response_header_with_cached_header 
 (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
 HttpTransact.cc:4914
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Comment Edited] (TS-2564) Segmentation fault in 4.2.0-rc0

2014-02-10 Thread Bryan Call (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897079#comment-13897079
 ] 

Bryan Call edited comment on TS-2564 at 2/10/14 9:57 PM:
-

In frame 5:

{code}
#5  HttpTransact::merge_response_header_with_cached_header 
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
HttpTransact.cc:4914

  cached_header-field_delete(dname, dlen);

(gdb) p field
$19 = (MIMEField *) 0x2acd57070158
(gdb) p field-m_next_dup
$20 = (MIMEField *) 0x2acd57070178
(gdb) p *field-m_next_dup-m_next_dup
Cannot access memory at address 0x0
{code}

But in frame 2 it is trying to delete another field:

{code}
#2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized out) 
at MIME.cc:1586

  mime_hdr_field_detach(mh, field, 0);

(gdb) p next
$1 = (MIMEField *) 0x2b723a7d9ca8
(gdb) p *next
Cannot access memory at address 0x2b723a7d9ca8
{code}


was (Author: bcall):
In frame 5:

{code}
#5  HttpTransact::merge_response_header_with_cached_header 
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
HttpTransact.cc:4914

  cached_header-field_delete(dname, dlen);

(gdb) p field
$19 = (MIMEField *) 0x2acd57070158
(gdb) p field-m_next_dup
$20 = (MIMEField *) 0x2acd57070178
{code}

But in frame 2 it is trying to delete another field:

{code}
#2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized out) 
at MIME.cc:1586

  mime_hdr_field_detach(mh, field, 0);

(gdb) p next
$1 = (MIMEField *) 0x2b723a7d9ca8
(gdb) p *next
Cannot access memory at address 0x2b723a7d9ca8
{code}

 Segmentation fault in 4.2.0-rc0
 ---

 Key: TS-2564
 URL: https://issues.apache.org/jira/browse/TS-2564
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call
Priority: Blocker
 Fix For: 4.2.0


 Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
 4.2.0-rc0:
 {code}
 (gdb) bt
 #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
 field=value optimized out, detach_all_dups=false) at MIME.cc:469
 #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
 detach_all_dups=false) at MIME.cc:1538
 #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
 mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized 
 out) at MIME.cc:1586
 #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
 #4  field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
 #5  HttpTransact::merge_response_header_with_cached_header 
 (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
 HttpTransact.cc:4914
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Resolved] (TS-2469) traffic_shell links against libreadline which is gpl licensed

2014-02-10 Thread Leif Hedstrom (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom resolved TS-2469.
---

Resolution: Fixed

Yep, closing.

 traffic_shell links against libreadline which is gpl licensed
 -

 Key: TS-2469
 URL: https://issues.apache.org/jira/browse/TS-2469
 Project: Traffic Server
  Issue Type: Bug
Reporter: Ben Aitchison
Assignee: Zhao Yongming
Priority: Minor
  Labels: traffic_shell
 Fix For: 4.1.3, 4.2.0

 Attachments: removereadline.txt


 libreadline is gpl licensed which is infectious.  libedit is a free 
 alternative, and is already supported in the configure scripts so libreadline 
 support should be removed.
 it seems traffic_shell is the only thing using libreadline/libedit currently.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Assigned] (TS-2564) Segmentation fault in 4.2.0-rc0

2014-02-10 Thread David Carlin (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Carlin reassigned TS-2564:


Assignee: David Carlin

 Segmentation fault in 4.2.0-rc0
 ---

 Key: TS-2564
 URL: https://issues.apache.org/jira/browse/TS-2564
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call
Assignee: David Carlin
Priority: Blocker
 Fix For: 4.2.0


 Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
 4.2.0-rc0:
 {code}
 (gdb) bt
 #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
 field=value optimized out, detach_all_dups=false) at MIME.cc:469
 #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
 detach_all_dups=false) at MIME.cc:1538
 #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
 mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized 
 out) at MIME.cc:1586
 #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
 #4  field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
 #5  HttpTransact::merge_response_header_with_cached_header 
 (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
 HttpTransact.cc:4914
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (TS-2564) Segmentation fault in 4.2.0-rc0

2014-02-10 Thread David Carlin (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Carlin updated TS-2564:
-

Assignee: Bryan Call  (was: David Carlin)

 Segmentation fault in 4.2.0-rc0
 ---

 Key: TS-2564
 URL: https://issues.apache.org/jira/browse/TS-2564
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
 Fix For: 4.2.0


 Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
 4.2.0-rc0:
 {code}
 (gdb) bt
 #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
 field=value optimized out, detach_all_dups=false) at MIME.cc:469
 #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
 detach_all_dups=false) at MIME.cc:1538
 #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
 mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized 
 out) at MIME.cc:1586
 #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
 #4  field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
 #5  HttpTransact::merge_response_header_with_cached_header 
 (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
 HttpTransact.cc:4914
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0

2014-02-10 Thread Bryan Call (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897395#comment-13897395
 ] 

Bryan Call commented on TS-2564:


Details are below on the backtrace.  It looks like it is coring for request 
going to a group where they are using negative max-age values and multiple 
Cache-Control headers (yes, I know they are wrong).  We are not seeing this on 
our 4.0.2 servers (with some 4.1 backported patches).

{code}
(gdb) bt
#0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
detach_all_dups=false) at MIME.cc:1538
#2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized out) 
at MIME.cc:1586


  mime_hdr_field_detach(mh, field, 0);


(gdb) p next
$1 = (MIMEField *) 0x2b723a7d9ca8
(gdb) p *next
Cannot access memory at address 0x2b723a7d9ca8

#3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4  field_delete (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) 
at ../../proxy/hdrs/MIME.h:1115

field_delete(field);



#5  HttpTransact::merge_response_header_with_cached_header 
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
HttpTransact.cc:4914

  cached_header-field_delete(dname, dlen);



(gdb) p field
$19 = (MIMEField *) 0x2acd57070158
(gdb) p *field
$16 = {
  m_ptr_name = 0x2acebefa0068 Cache-Control: public\r\nCache-Control: 
max-age=-1706125\r\nX-Cache: MISS from x\r\nX-Cache-Lookup: HIT from 
xx:3128\r\nX-Cache: MISS from x\r\nX-...,
  m_ptr_value = 0x2acebefa0077 public\r\nCache-Control: 
max-age=-1706125\r\nX-Cache: MISS from xx\r\nX-Cache-Lookup: HIT from 
x:3128\r\nX-Cache: MISS from xx\r\nX-Cache-Lookup: H..., m_next_dup = 
0x2acd57070178, m_wks_idx = 10, m_len_name = 13, m_len_value = 6, 
m_n_v_raw_printable = 1 '\001', m_n_v_raw_printable_pad = 4 '\004',
  m_readiness = 2 '\002', m_flags = 3 '\003’}

(gdb) p field-m_next_dup
$20 = (MIMEField *) 0x2acd57070178
(gdb) p *field-m_next_dup
$18 = {
  m_ptr_name = 0x2acebefa007f Cache-Control: max-age=-1706125\r\nX-Cache: MISS 
from x\r\nX-Cache-Lookup: HIT from x:3128\r\nX-Cache: MISS from 
x\r\nX-Cache-Lookup: HIT from ...,
  m_ptr_value = 0x2acebefa008e max-age=-1706125\r\nX-Cache: MISS from 
x\r\nX-Cache-Lookup: HIT from xx:3128\r\nX-Cache: MISS from 
xx\r\nX-Cache-Lookup: HIT from is1.hkac.sg3.ya..., m_next_dup = 0x0, 
m_wks_idx = 10, m_len_name = 13, m_len_value = 16, m_n_v_raw_printable = 1 
'\001', m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002',
  m_flags = 2 '\002'}

(gdb) p *field-m_next_dup-m_next_dup
Cannot access memory at address 0x0

#6  0x0053f023 in 
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2accc168aa78) at 
HttpTransact.cc:4660
#7  0x0054ebd2 in 
HttpTransact::handle_cache_operation_on_forward_server_response 
(s=0x2accc168aa78) at HttpTransact.cc:4463

  if ((s-cache_info.action == CACHE_DO_UPDATE) || (s-cache_info.action == 
CACHE_DO_SERVE_AND_UPDATE)) {
DebugTxn(http_trans, [hcoofsr] merge and update cached copy);
merge_and_update_headers_for_cache_update(s);  — this line
{code}

 Segmentation fault in 4.2.0-rc0
 ---

 Key: TS-2564
 URL: https://issues.apache.org/jira/browse/TS-2564
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
 Fix For: 4.2.0


 Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
 4.2.0-rc0:
 {code}
 (gdb) bt
 #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
 field=value optimized out, detach_all_dups=false) at MIME.cc:469
 #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out, 
 detach_all_dups=false) at MIME.cc:1538
 #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
 mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized 
 out) at MIME.cc:1586
 #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
 #4  field_delete (cached_header=0x2acde002fa40, 
 response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
 #5  HttpTransact::merge_response_header_with_cached_header 
 (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
 HttpTransact.cc:4914
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (TS-2565) ALPN: configure protocol selection

2014-02-10 Thread James Peach (JIRA)
James Peach created TS-2565:
---

 Summary: ALPN: configure protocol selection
 Key: TS-2565
 URL: https://issues.apache.org/jira/browse/TS-2565
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration, SSL
Reporter: James Peach


Once there is a meaningful set of protocols that uses ALPN, we should have a 
way for operators to configure the ALP protocol selection. For example, some 
sites might want to prefer HTTP1 to HTTP2, some sites might want the reverse.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (TS-2531) The default remap rule doesn't match a forward proxy request

2014-02-10 Thread Bryan Call (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897510#comment-13897510
 ] 

Bryan Call commented on TS-2531:


The use case is a reverse proxy and a malformed request that has the host in 
the request line instead of the Host: header.

Example remap.config:
map http://foo.yahoo.com https://www.yahoo.com
map / https://www.yahoo.com

Request that works:
GET http://foo.yahoo.com HTTP/1.1

HTTP/1.1 200 OK


Request that doesn't:
GET http://bar.yahoo.com HTTP/1.1

HTTP/1.1 404 Not Found

 The default remap rule doesn't match a forward proxy request
 

 Key: TS-2531
 URL: https://issues.apache.org/jira/browse/TS-2531
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Bryan Call
 Attachments: 0001-fix-bug-TS_2531.patch


 when doing a forward proxy request it won't math the default rule, but will 
 match other rules that specify the hostname.
 Example request:
 GET http://foo.yahoo.com HTTP/1.1
 Host: foo.yahoo.com
 remap.config:
 map / http://www.yahoo.com
 Response:
 HTTP/1.1 404 Not Found
 ...
 
 However, this works:
 remap.config:
 map http://foo.yahoo.com http://www.yahoo.com



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)