# Debug of msg.req of "HTTP IN" node does not show msg.req.headres, but msg.req.rawheaders

**URL:** https://discourse.nodered.org/t/debug-of-msg-req-of-http-in-node-does-not-show-msg-req-headres-but-msg-req-rawheaders/78023
**Category:** General
**Created:** [28 April 2023 19:25 UTC](https://discourse.nodered.org/t/debug-of-msg-req-of-http-in-node-does-not-show-msg-req-headres-but-msg-req-rawheaders/78023 "2023-04-28T19:25:45Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![jfmateos](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jfmateos/32/79361_2.png) [@jfmateos](https://discourse.nodered.org/u/jfmateos)
#### Post date: [28 April 2023 19:25 UTC](https://discourse.nodered.org/t/debug-of-msg-req-of-http-in-node-does-not-show-msg-req-headres-but-msg-req-rawheaders/78023/1 "2023-04-28T19:25:45Z")

</div>

I have an HTTP IN node, linked to 2 debug nodes.  
The first one debugs msq.req, and it does not show any msg.req.headers property (it contains a rawHeaders one).  
Nevertheless, debugging msg.req.headers shows that the property headers should exist in msg.req.  
Could you help me understand this apparent incoherence?

 ![imagen](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/b/4/b4d7b1335a6cb1386246d3b928146e245fb02439.png)

---

<div class="post-metadata">

### Author: ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [28 April 2023 19:35 UTC](https://discourse.nodered.org/t/debug-of-msg-req-of-http-in-node-does-not-show-msg-req-headres-but-msg-req-rawheaders/78023/2 "2023-04-28T19:35:45Z")

</div>

Welcome to the forums @jfmateos

This quite possibly, could be due to the fact the `debug` node, will only siphon out to the debug panel so much data.

the `req` object for express is HUGE! as it contains stream objects, and the countless number of objects attached to that.

This is just a guess, so could be wrong. i.e the `headers` object is far deeper in the JSON representation than what you see - enough to make it truncate in the debug pane

---

<div class="post-metadata">

### Author: ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [28 April 2023 19:47 UTC](https://discourse.nodered.org/t/debug-of-msg-req-of-http-in-node-does-not-show-msg-req-headres-but-msg-req-rawheaders/78023/3 "2023-04-28T19:47:24Z")

</div>

Working from memory, this has been addressed in next version (should be an issue or PR in the repo). I forget the reason but something makes me think about proxy objects? Nick may remember.

---

<div class="post-metadata">

### Author: ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)
#### Post date: [28 April 2023 19:51 UTC](https://discourse.nodered.org/t/debug-of-msg-req-of-http-in-node-does-not-show-msg-req-headres-but-msg-req-rawheaders/78023/4 "2023-04-28T19:51:11Z")

</div>

In Node 16 (or maybe later), node.js made `req.headers` a non-enumerable property - this was done as a small performance improvement to avoid all the overhead of parsing the headers for every request when they may not be needed.

This means when we loop over the properties it doesn't show up and why it doesn't appear in the debug sidebar.

In 3.1 we force them to be evaluated so they show up.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)
#### Post date: [12 May 2023 19:51 UTC](https://discourse.nodered.org/t/debug-of-msg-req-of-http-in-node-does-not-show-msg-req-headres-but-msg-req-rawheaders/78023/5 "2023-05-12T19:51:31Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
