# Content-Type of HTTP In node
**URL:** https://discourse.nodered.org/t/content-type-of-http-in-node/30720
**Category:** General
**Created:** [26 July 2020 10:23 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720 "2020-07-26T10:23:07Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@augjoh](https://discourse.nodered.org/u/augjoh)
#### Post date: [26 July 2020 10:23 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/1 "2020-07-26T10:23:07Z")
Our project runs node-red standalone and provides an OCSP (RFC 6960) service. The OCSP requests are received using an `HTTP In` node. When receiving an HTTP POST request with `Content-Type: application/ocsp-request`, the body of the HTTP request is modified by node-red resp. express. Unfortunately this corrupts the DER (Distinguished Encoding Rules) encoded body of the request. When the same request is posted with `Content-Type: application/octet-stream` there is no modification of the request body.
How can node-red be configured to pass HTTP POST requests with `Content-Type: application/ocsp-request` as-is?
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [26 July 2020 11:24 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/2 "2020-07-26T11:24:05Z")
There is an example of setting headers in the [cookbook](https://cookbook.nodered.org/http/set-request-header)
---
### Author:  [@augjoh](https://discourse.nodered.org/u/augjoh)
#### Post date: [26 July 2020 11:31 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/3 "2020-07-26T11:31:19Z")
Hi Steve, this issue is not about creating HTTP headers, but receiving broken content within node-red, based on the value of HTTP `Content-Type` header.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [26 July 2020 11:42 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/4 "2020-07-26T11:42:08Z")
> [@augjoh](#):
>
> this issue is not about creating HTTP headers
It was my opinion from this statement....
> [@augjoh](#):
>
> How can node-red be configured to pass HTTP POST requests with `Content-Type: application/ocsp-request`
... That you needed to know how to set a header in your post request.
Anyhow...
I seen a post a few days ago about a similar issue and if memory serves me it was accepted that the request type in question should probably be returned as binary.
See [this thread](https://discourse.nodered.org/t/http-request-node-invalid-message-body-was-specified-to-be-cbor-but-could-not-decode-message-failed-to-parse/30503/9) perhaps this header should also be handled as binary?
---
### Author:  [@janvda](https://discourse.nodered.org/u/janvda)
#### Post date: [26 July 2020 12:04 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/5 "2020-07-26T12:04:47Z")
> [@Steve-Mcl](#):
>
> I seen a post a few days ago about a similar issue and if memory serves me it was accepted that the request type in question should probably be returned as binary.
>
> See [this thread](https://discourse.nodered.org/t/http-request-node-invalid-message-body-was-specified-to-be-cbor-but-could-not-decode-message-failed-to-parse/30503/9) perhaps this header should also be handled as binary?
... yes indeed this problem is similar to the problem I noticed in that thread. The `HTTP in` is stringifying the body in case content type is `application/XXX` where `XXX` is different from `octet-stream`.
So as work around (if possible) use `Content-Type: application/octet-stream`.
---
### Author:  [@augjoh](https://discourse.nodered.org/u/augjoh)
#### Post date: [26 July 2020 12:14 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/6 "2020-07-26T12:14:59Z")
There is no way to change the client's implementation to use a different `Content-Type`.
I've figured that it might be possible to use the following code to configure the express application:
```auto
app.use(bodyParser.raw({ type: 'application/ocsp-request' }))
```
But I couldn't figure out how to get a reference to the express application in node-red.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [26 July 2020 12:24 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/7 "2020-07-26T12:24:35Z")
You could edit node-red core as a trial and then perhaps raise a PR (with approval from Dave or Nick)
This is the place you need to handle your header type...
>
---
### Author:  [@knolleary](https://discourse.nodered.org/u/knolleary)
#### Post date: [26 July 2020 13:47 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/8 "2020-07-26T13:47:03Z")
It isn't sustainable to keep adding exceptions to the logic that is trying to do the right thing for 90% of cases.
It would be better to add an option to the node to explicitly leave the payload as the raw Buffer and skip all the parsing.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [26 July 2020 13:51 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/9 "2020-07-26T13:51:55Z")
Makes sense.
@augjoh / @janvda perhaps you could raise a PR to handle this like Nick suggests - to get it moving?
---
### Author:  [@augjoh](https://discourse.nodered.org/u/augjoh)
#### Post date: [21 August 2020 22:55 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/10 "2020-08-21T22:55:26Z")
@steve / @janvda I cannot provide a PR for this issue, but I'll test if someone creates one.
I've found a workaround for this problem, in settings.js add:
```auto
httpNodeMiddleware: function(req,res,next) {
switch (req.get('content-type')) {
case 'application/timestamp-query':
case 'application/ocsp-request':
req.headers['content-type'] = 'application/octet-stream';
break;
}
next();
},
```
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [20 October 2020 22:55 UTC](https://discourse.nodered.org/t/content-type-of-http-in-node/30720/11 "2020-10-20T22:55:28Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.