---
title: "Comment by QRiQRa Team on \"Duplicate HTTP Headers Sent as an Array: How to Debug Them\" | Hashnode"
description: "Looking at the raw bytes is the step that is easy to skip, and the post makes a clear case for why the header object in a framework is not enough. A value can l"
url: "https://hashnode.com/posts/debugging-duplicate-headers-sent-as-an-array/6af5320bc176a971010f75d2/comment/6af69ed54730a4f142fc9a99"
---

[Discussion](https://hashnode.com/posts/debugging-duplicate-headers-sent-as-an-array/6af5320bc176a971010f75d2)

Comment [Duplicate HTTP Headers Sent as an Array: How to Debug Them](https://hashnode.com/posts/debugging-duplicate-headers-sent-as-an-array/6af5320bc176a971010f75d2)

[QRiQRa Team](https://hashnode.com/@qriqra)

[16h ago](https://hashnode.com/posts/debugging-duplicate-headers-sent-as-an-array/6af5320bc176a971010f75d2/comment/6af69ed54730a4f142fc9a99)

Looking at the raw bytes is the step that is easy to skip, and the post makes a clear case for why the header object in a framework is not enough. A value can look fine in your code while the client is already emitting two lines with the same name. I also appreciated the reminder that a global interceptor and a call site can each add the same field. A small checklist I would keep: inspect the wire, search every place the header is set, and write down one rule for array versus comma-joined values before guessing at the server.