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

2014-02-21 Thread kang li (JIRA)

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

kang li commented on TS-2210:
-

Hi James, 

Is there any update about the Jira ticket ? Do I need some extra modification.

 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] [Resolved] (TS-2579) FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?

2014-02-21 Thread Kit Chan (JIRA)

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

Kit Chan resolved TS-2579.
--

Resolution: Fixed

Tested a bit and worked fine 

 FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?
 --

 Key: TS-2579
 URL: https://issues.apache.org/jira/browse/TS-2579
 Project: Traffic Server
  Issue Type: Bug
Reporter: Kit Chan
Assignee: Kit Chan
 Fix For: 5.0.0


 I find that right now FetchSM and the TSFetchUrl/TSFetchPages api is ipv4 
 only but i don't think it needs to be.
 We should be able to support ipv6 as well. 



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


[jira] [Reopened] (TS-2579) FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?

2014-02-21 Thread Alan M. Carroll (JIRA)

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

Alan M. Carroll reopened TS-2579:
-


 FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?
 --

 Key: TS-2579
 URL: https://issues.apache.org/jira/browse/TS-2579
 Project: Traffic Server
  Issue Type: Bug
Reporter: Kit Chan
Assignee: Kit Chan
 Fix For: 5.0.0


 I find that right now FetchSM and the TSFetchUrl/TSFetchPages api is ipv4 
 only but i don't think it needs to be.
 We should be able to support ipv6 as well. 



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


[jira] [Commented] (TS-2579) FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?

2014-02-21 Thread Alan M. Carroll (JIRA)

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

Alan M. Carroll commented on TS-2579:
-

I think this is broken, because the member variable FetchSM::_addr is now a 
dangling pointer. It points at a sockaddr that has no lifetime guarantee and 
could go invalid as soon as the API call returns. You probably want an 
IpEndpoint instead.

 FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?
 --

 Key: TS-2579
 URL: https://issues.apache.org/jira/browse/TS-2579
 Project: Traffic Server
  Issue Type: Bug
Reporter: Kit Chan
Assignee: Kit Chan
 Fix For: 5.0.0


 I find that right now FetchSM and the TSFetchUrl/TSFetchPages api is ipv4 
 only but i don't think it needs to be.
 We should be able to support ipv6 as well. 



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


[jira] [Commented] (TS-2581) Add / modify APIs to allow easy freelist allocation of iobuffer's from C/C++ plugins

2014-02-21 Thread Phil Sorber (JIRA)

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

Phil Sorber commented on TS-2581:
-

Further research shows that the TSIOBuffer you get back is a couple 
abstractions above the properly sized chunk of data you really want. We should 
create a new API that gets data from ioBufAllocator[SIZE] instead. We should 
also pay attention to track the size so that we know which allocator to place 
it back on when done.

 Add / modify APIs to allow easy freelist allocation of iobuffer's from C/C++ 
 plugins
 

 Key: TS-2581
 URL: https://issues.apache.org/jira/browse/TS-2581
 Project: Traffic Server
  Issue Type: New Feature
  Components: TS API
Reporter: Leif Hedstrom

 This would allow for efficient allocations in plugins, such that they can do 
 an in-place new() on a chunk of memory (iobuffer). 
 The API / features should make it easy and possible to asks for an iobuffer 
 of at least size x. It can return a bigger one, at which point, you'd waste 
 some. But this allows us to reuse / repurpose the existing iobuffer 
 allocation.
 Phil points out that there are existing iobuffer allocation APIs, so maybe 
 something in conjunction with that is appropriate. I would like for this to 
 be easy on the plugin user though, such that it's as simple as malloc/free 
 chains.



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


[jira] [Work started] (TS-2579) FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?

2014-02-21 Thread Kit Chan (JIRA)

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

Work on TS-2579 started by Kit Chan.

 FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?
 --

 Key: TS-2579
 URL: https://issues.apache.org/jira/browse/TS-2579
 Project: Traffic Server
  Issue Type: Bug
Reporter: Kit Chan
Assignee: Kit Chan
 Fix For: 5.0.0


 I find that right now FetchSM and the TSFetchUrl/TSFetchPages api is ipv4 
 only but i don't think it needs to be.
 We should be able to support ipv6 as well. 



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


[jira] [Commented] (TS-2579) FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?

2014-02-21 Thread Kit Chan (JIRA)

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

Kit Chan commented on TS-2579:
--

Let me work on this here.

 FetchSM and TSFetchUrl/TSFetchPages api ipv4 only?
 --

 Key: TS-2579
 URL: https://issues.apache.org/jira/browse/TS-2579
 Project: Traffic Server
  Issue Type: Bug
Reporter: Kit Chan
Assignee: Kit Chan
 Fix For: 5.0.0


 I find that right now FetchSM and the TSFetchUrl/TSFetchPages api is ipv4 
 only but i don't think it needs to be.
 We should be able to support ipv6 as well. 



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


[jira] [Created] (TS-2582) make traffic_cop debugging easier

2014-02-21 Thread James Peach (JIRA)
James Peach created TS-2582:
---

 Summary: make traffic_cop debugging easier
 Key: TS-2582
 URL: https://issues.apache.org/jira/browse/TS-2582
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cop
Reporter: James Peach


It's somewhat tedious to debug {{traffic_cop}}, since you have to make a build 
configuration change and then examine a hard-coded log file. It would be easier 
to (optionally) log to standard output.



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


[jira] [Updated] (TS-2582) make traffic_cop debugging easier

2014-02-21 Thread James Peach (JIRA)

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

James Peach updated TS-2582:


 Priority: Minor  (was: Major)
Fix Version/s: 5.0.0
 Assignee: James Peach

 make traffic_cop debugging easier
 -

 Key: TS-2582
 URL: https://issues.apache.org/jira/browse/TS-2582
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cop
Reporter: James Peach
Assignee: James Peach
Priority: Minor
 Fix For: 5.0.0


 It's somewhat tedious to debug {{traffic_cop}}, since you have to make a 
 build configuration change and then examine a hard-coded log file. It would 
 be easier to (optionally) log to standard output.



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


[jira] [Resolved] (TS-2582) make traffic_cop debugging easier

2014-02-21 Thread James Peach (JIRA)

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

James Peach resolved TS-2582.
-

Resolution: Fixed

 make traffic_cop debugging easier
 -

 Key: TS-2582
 URL: https://issues.apache.org/jira/browse/TS-2582
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cop
Reporter: James Peach
Assignee: James Peach
Priority: Minor
 Fix For: 5.0.0


 It's somewhat tedious to debug {{traffic_cop}}, since you have to make a 
 build configuration change and then examine a hard-coded log file. It would 
 be easier to (optionally) log to standard output.



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


[jira] [Commented] (TS-2582) make traffic_cop debugging easier

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

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

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

Commit a08f5da2b764966446a5a7e26a15b5971b6d55e6 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a08f5da ]

TS-2582: add traffic_cop debugging mode

Replace custom traffic_cop option parsing with the standard libts
API. This has the side-effect of now requireing a double-dash for
long options.

Instead of a build-time option to enable traffic_cop debugging, add
a command line option that simply logs debug messages to standard
output. Add another command line option to enable the debug log
level.


 make traffic_cop debugging easier
 -

 Key: TS-2582
 URL: https://issues.apache.org/jira/browse/TS-2582
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cop
Reporter: James Peach
Assignee: James Peach
Priority: Minor
 Fix For: 5.0.0


 It's somewhat tedious to debug {{traffic_cop}}, since you have to make a 
 build configuration change and then examine a hard-coded log file. It would 
 be easier to (optionally) log to standard output.



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


[jira] [Commented] (TS-2058) Traffic server fails to start with lots of SNI ssl certs defined

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

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

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

Commit 5e8f122884b86dee1a4a59a29faf23537e44c986 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5e8f122 ]

TS-2058: add an integration test for SSL certificate loading

Add the test-multicert-loading integration test to verify that SSL
certificate loading does not delay the proxy coming up and serving
traffic.


 Traffic server fails to start with lots of SNI ssl certs defined
 

 Key: TS-2058
 URL: https://issues.apache.org/jira/browse/TS-2058
 Project: Traffic Server
  Issue Type: Bug
  Components: Performance, SSL
Reporter: Kris Lindgren
Assignee: James Peach
 Fix For: 5.0.0

 Attachments: TS-2058-hacked-up.diff


 Running into an issue with SNI under 3.2.4 - with 100k ssl certs defined in 
 ssl_multicert.config with the following format: ssl_cert_name=cert  Traffic 
 server will never start.  It looks like it keeps getting killed by 
 traffic_cop.
 It looks like succesfull startup will take ~2minutes for 100k ssl certs on my 
 machine and about 15 seconds for 40k ssl certs.  I would like to try to get 
 to one million ssl certs defined with traffic server able to start 
 successfully.  Anything that could be done to increase the speed and allow 
 that amount of SSL certs defined to start successfully would be much 
 appreciated.



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