Allow custom HTTP headers

[networkfusion]

Description

Allow custom HTTP headers

Motivation and Context

• Fixes Can Not Add Header To HttpClient Home#1618

How Has This Been Tested?

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (add new Unit Test(s) or improved existing one(s), has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).
• I have added new tests to cover my changes.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: nanoframework/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 57b5e546-72fc-44c5-a99d-85dd0b9a919a

📥 Commits

Reviewing files that changed from the base of the PR and between a1719f7 and e5db088.

📒 Files selected for processing (1)

• nanoFramework.System.Net.Http/Http/Headers/HttpHeaders.cs

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Resolved HTTP headers handling behavior to ensure proper and consistent processing when adding and merging header values in HTTP network requests and responses.

• Improvements

  • Enhanced internal header storage configuration to provide more reliable behavior during various header operations.

Walkthrough

The HttpHeaders class now constructs WebHeaderCollection with false instead of true, modifying the internal header storage semantics to affect how headers are validated and merged.

Changes

Cohort / File(s)	Summary
HttpHeaders constructor configuration nanoFramework.System.Net.Http/Http/Headers/HttpHeaders.cs	Changed WebHeaderCollection constructor parameter from true to false, disabling restricted header enforcement in the internal header storage mechanism.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related issues

• #1618: This change directly addresses the reported issue where standard HTTP headers (User-Agent, Accept, etc.) cannot be added to HttpClient due to "restricted header" errors; passing false to WebHeaderCollection disables the header validation that was blocking these operations.

---

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Allow custom HTTP headers' is vague and doesn't clearly convey the core change: modifying header storage behavior from restricted to unrestricted.	Consider a more specific title like 'Fix HTTP header restrictions' or 'Enable standard HTTP headers' to better reflect the actual code change.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description is related to the changeset, linking to issue #1618 which addresses the inability to add standard HTTP headers.
Linked Issues check	✅ Passed	The code change (changing WebHeaderCollection initialization parameter from true to false) directly addresses issue #1618 by disabling header restrictions.
Out of Scope Changes check	✅ Passed	The single-line change to HttpHeaders.cs is directly scoped to fixing the header restriction issue identified in #1618, with no extraneous modifications.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[josesimoes]

@hamiddd1980 can you please validate if this fixes the issue you've reported?

[Ellerbach]

/Looks good :-)

[Copilot]

Pull request overview

This PR changes how System.Net.Http.Headers.HttpHeaders stores headers so that callers can add headers that were previously blocked by WebHeaderCollection’s restricted-header validation logic.

Changes:

• Initialize HttpHeaders._headerStore with new WebHeaderCollection(false) instead of true, disabling restricted-header checks for these collections.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Switching the backing store to new WebHeaderCollection(false) disables the restricted-header checks (see WebHeaderCollection.ThrowOnRestrictedHeader()), which changes behavior for known headers like Accept, Connection, Host, Content-Length, etc., not just custom X-* headers. Given HeaderInfoTable treats unknown headers as non-restricted, custom headers were already allowed before this change; please either update the PR title/description to reflect the broader behavior change, or narrow the change to only what’s needed for the reported issue.

[Copilot]

With restricted-header validation disabled, callers can now set headers that other parts of this library treat as managed/internal. For example, HttpContentHeaders.ContentLength reads/parses the Content-Length header from _headerStore and will throw if a user sets a non-numeric value via content.Headers.Add("Content-Length", ...). Consider keeping restrictions for headers that must remain controlled (e.g., Content-Length, Host, Transfer-Encoding) or adding explicit validation/guardrails in HttpHeaders.Add to prevent inconsistent state.

Suggested change

	internal WebHeaderCollection _headerStore = new WebHeaderCollection(false);
	internal WebHeaderCollection _headerStore = new WebHeaderCollection(true);

[Copilot]

This line changes header-validation behavior globally for HttpRequestHeaders, HttpResponseHeaders, and HttpContentHeaders, but there are no unit tests asserting the new expected behavior. Please add tests that (1) verify previously-blocked standard headers (e.g., Accept) can now be added, and (2) define the intended behavior for managed headers like Content-Length (either still rejected or validated).

[josesimoes]

Copilot comment is correct. The check can't simply be turned off! This requires another approach.