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]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

• nanoFramework.System.Net.Http/Http/Headers/HttpHeaders.cs is excluded by none and included by none

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 427712e6-4d44-4640-a27e-dcf7702e66fc

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch networkfusion/write-http-header

---

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).