Repository navigation
request 2.65.0 getPeerCertificate() always returns null on node 4.2.1, works on 0.12.7 #3545
Description
This seems to be a regression between node 4.2.1 and node 0.1.2:
var request = require('request')
request({
url: 'https://github.com'
}, function (err, res, body) {
console.log('err', err)
console.log('peerCertificate:',res.req.connection.getPeerCertificate());
console.log('authorized:',res.req.connection.authorized);
console.log('authorizationError:',res.req.connection.authorizationError);
});
First node 0.12.7:
# grep ver node_modules/request/package.json
"version": "2.65.0"
# node --version
v0.12.7
# node testssl.js
err null
peerCertificate: { subject:
{ businessCategory: 'Private Organization',
'1.3.6.1.4.1.311.60.2.1.3': 'US',
'1.3.6.1.4.1.311.60.2.1.2': 'Delaware',
serialNumber: '5157550',
street: '548 4th Street',
postalCode: '94107',
C: 'US',
ST: 'California',
L: 'San Francisco',
O: 'GitHub, Inc.',
CN: 'github.com' }
...
Then node 4.2.1:
# node --version
v4.2.1
# grep ver node_modules/request/package.json
"version": "2.65.0"
# node testssl.js
err null
peerCertificate: null
authorized: true
authorizationError: null
Activity
bnoordhuis commentedon Oct 27, 2015
Do you also see it when you use the https or tls module directly? request is a third-party library.
bnoordhuis commentedon Oct 27, 2015
WFM with master, by the way:
mikemaccana commentedon Oct 27, 2015
Thanks @bnoordhuis! Yep tls is fine here. I'd thought it was a node issue since the request version is the same, but given that the tls module itself is fine it looks like this is a request issue?
mikemaccana commentedon Oct 27, 2015
Moving to request: request/request#1867
DaftMonk commentedon Nov 8, 2015
After some digging through the request source code, I don't believe the issue is with request.
In node 4.2.1, after the response connection is closed (once the
closeevent is fired on the IncomingMessage), getPeerCertificate returns null. However, if you call getPeerCertificate before the response is closed, it returns the peer certificate as expected.In node 0.12.x, calling getPeerCertificate even after the connection has closed returns the peer certificate.
This seem to be a regression between node 0.12 and 4.x (or maybe an intentional change that isn't clearly documented), and is especially noticeable with the request library, because the request callback is always called after the connection has been closed.
One workaround is to grab the response before the close event is fired. You can do this like so:
bnoordhuis commentedon Nov 9, 2015
I can confirm that
.getPeerCertificate()works after close with v0.10 and v0.12 but not v4.x+. Test case:/cc @indutny - No opinion on whether it's a good idea to bring back the old behavior. I'm not sure from looking at the code it that's feasible without negating the memory savings.
indutny commentedon Nov 10, 2015
@bnoordhuis this is rather unfortunate and fortunate at the same time. This gave us a pretty solid cut off in RSS usage. I think we could introduce an option to keep the
SSLinstance alive afterclose, but it will come at the increased memory usage cost.Will this work for you, @mikemaccana ?
bnoordhuis commentedon Nov 10, 2015
I would lean towards just documenting it. I don't think we need more complexity in the tls module and the current behavior doesn't strike me as unreasonable: Connection closed? Then so is the TLS metadata.
It's unfortunate this slipped through but it's not as if the old behavior was documented or even intentional (witness the paucity of regression tests for this feature.) It was just an accident of the implementation.
indutny commentedon Nov 10, 2015
Sounds about right @bnoordhuis . Is anyone interested in contributing this? ;)
DaftMonk commentedon Nov 10, 2015
I'll write something for it a bit later.
mikemaccana commentedon Nov 10, 2015
Ditto. As long as the correct approach is documented (eg, holding connection open it seems) in happy.
mikemaccana commentedon Nov 10, 2015
I'm, ahem.
bnoordhuis commentedon Nov 10, 2015
Documented in eff8c3e.