# Extend http request node output for https requests
**URL:** https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956
**Category:** Feature Requests
**Tags:** http-request
**Created:** [7 October 2021 06:57 UTC](https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956 "2021-10-07T06:57:41Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@mailsvb](https://discourse.nodered.org/u/mailsvb)
#### Post date: [7 October 2021 06:57 UTC](https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956/1 "2021-10-07T06:57:42Z")
Hi,
as per the contribution guidelines, I would like to raise this topic here.
I would like to suggest to extend the ouput of the http request node, when doing https requests, with the peer certificate information (which is provided in the socket object of the response).
Personally, I have a use case where I want to monitor the lifetime of a certificate, when sending requests to specific servers.
---
### Author:  [@hardillb](https://discourse.nodered.org/u/hardillb)
#### Post date: [7 October 2021 09:20 UTC](https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956/2 "2021-10-07T09:20:56Z")
As a concept it sounds OK.
A couple of things we should probably work out up front would be what exactly would be exposed, where and if it should be optional.
- I think it should be optional, but not sure if it should be toggled in the http-request node or in the tls config node (this is shared with other nodes, but getting server details may apply to other nodes as well, but the implementation of the certificate retrieval would still have to be in each node.)
- An object msg.peerCertificate with the output of [TLSSocket.getPeerCertifiate()](https://nodejs.org/api/tls.html#tls_tlssocket_getpeercertificate_detailed)?
Having said all that a really quick test with the got library we use in the http-request node is not promising
```auto
const got = require('got')
got('https://www.hardill.me.uk',{})
.then( res => {
console.log("good")
console.log(res.socket.getPeerCertificate())
})
.catch(err => {
console.log(err)
})
```
returns `null` implying that the socket has already been destroyed by the time it's passed to the response handler.
---
### Author:  [@mailsvb](https://discourse.nodered.org/u/mailsvb)
#### Post date: [7 October 2021 13:44 UTC](https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956/3 "2021-10-07T13:44:49Z")
My suggestion would be to make it pure optional (not configurable). As you said, it would need to be introduced to all nodes that handle a TLS connection.
We could simply add the object to msg.peerCertificate
In regards to how to get the information at all. I was having success when turning got to use the stream API. This way we get notified on the secureConnect event and can store the certificate data.
```auto
const got = require('got')
const g = got('https://www.hardill.me.uk',{ "isStream": true })
g.on('response', res => {
console.log(res.statusCode)
});
g.on('socket', (socket) => {
socket.on('secureConnect', () => console.log(socket.getPeerCertificate()))
})
g.on('error', err => {
console.log(err)
});
```
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [7 October 2021 15:49 UTC](https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956/4 "2021-10-07T15:49:39Z")
This seems like a fairly specialist need and wouldn't likly be needed by everyone - wouldn't it be better as a separate node?
---
### Author:  [@mailsvb](https://discourse.nodered.org/u/mailsvb)
#### Post date: [7 October 2021 21:12 UTC](https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956/5 "2021-10-07T21:12:52Z")
I did this a while ago. I used the http request node as a starting point and created a separate node ([node-red-contrib-https - npm](https://www.npmjs.com/package/node-red-contrib-https)). Since then, the http request node has evolved. I like the extended features and options the http request node has received.
IMHO it would be simpler to extend the existing node. Especially, since it is only about information that is anyhow available already.
---
### Author:  [@mailsvb](https://discourse.nodered.org/u/mailsvb)
#### Post date: [7 October 2021 21:35 UTC](https://discourse.nodered.org/t/extend-http-request-node-output-for-https-requests/51956/6 "2021-10-07T21:35:09Z")
I have created a draft of the proposed changes:
>
>
> \