[✨ Triage] dotnet/runtime#125984 by TonyValenti - [API Proposal]: Additional HttpStatusCode Members

[MihuBot]

Triage for dotnet/runtime#125984.
Repo filter: All networking issues.
MihuBot version: 246635.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

dotnet/runtime#125984: [API Proposal]: Additional HttpStatusCode Members by TonyValenti
Extracted 5 search queries: HttpStatusCode enum missing 425 TooEarly, HttpStatusCode missing 524 Timeout status code, HttpStatusCode 520 UnknownWebServerError not defined, Add new HTTP status codes to System.Net.Http.HttpStatusCode enum, API proposal to extend HttpStatusCode enum with non-standard codes (520, 524)
Found 17 candidate issues

• Issue #15650 (Nov 2015) - Update HttpStatusCode enum with updates
  Summary: Large, tracked proposal to add many official status codes from various RFCs (e.g. 102, 207, 226, 308, 421, 422, 428, 429, 431, 451, 506–511, etc.). Discussed pros/cons of adding enum members vs other designs; some members were later added to the runtime. This is the main, canonical effort historically used to consolidate additions.

• Issue #24724 (Jan 2018) - Update Official HttpStatusCode
  Summary: Duplicate/alternate PR that was redirected into #15650. Shows the community push to add RFC-defined codes (moved back to #15650).

• Issue #24503 (Dec 2017) - HttpStatusCode to implement RFC 6585
  Summary: Request to include RFC 6585 codes (e.g. 428, 429, 431, 511). Marked as duplicate of #15650; the thread reinforces that standard/IETF codes were the primary justification for additions.

• Issue #20641 (Mar 2017) - Add value to HttpStatusCode enum: TooManyRequests (=HTTP 429)
  Summary: Request to add 429 specifically; triaged as duplicate of #15650. Noted that new API additions require coordination but that contributions were welcome for “future” work. 429 was ultimately added in later releases.

• Issue #54321 (Jun 2021) - HttpStatusCode is missing code 429 (TooManyRequests)
  Summary: User observed older platform refs missing 429; responders noted TooManyRequests was added in PR #26727 for .NET Core 2.1 and recommended (short-term) casting (HttpStatusCode)429 when necessary. Shows practical workaround and that 429 is now part of modern runtimes.

• Issue #70996 (Jun 2022) - [API Proposal]: System.Net.HttpStatusCode.UnprocessableContent
  Summary: Proposal to add an alias for 422 (Unprocessable Content). Triage accepted and API-review approved; maintainers said they'd take a contribution. Demonstrates that adding RFC-standard codes/aliases is accepted when standardized (RFC 9110 in this case).

• Issue #30592 (Aug 2019) - Proposal: Add RawStatusCode to HttpResponseMessage
  Summary: Suggested adding an int RawStatusCode to avoid enum friction; discussion noted augmenting the enum was another approach. The proposal didn’t gain traction; community pointed out you can cast the enum to int or extend behavior. Shows alternative patterns to cope with missing enum members.

• Issue #911 (Jan 2018) and PR #32455 (Feb 2020, merged) - Proposal: HttpRequestException w/ Status Code / Add StatusCode to HttpRequestException
  Summary: Long discussion about surfacing status code on exceptions thrown by EnsureSuccessStatusCode. Result: a nullable StatusCode property was added to HttpRequestException (PR #32455). Relevant: callers can inspect StatusCode on exceptions (and enums can still be cast to ints).

• Issue #23648 (Sep 2017) - StatusCode in HttpRequestException
  Summary: Early iteration of the same problem as #911; discussion noted that HttpRequestException is used in cases without a response too. Ultimately the need for status in EnsureSuccessStatusCode-related exceptions led to the change implemented in #32455.

• Issue #38831 (Dec 2021) - [Refactor] StatusCodes: apply 1DR, improve doc (aspnetcore)
  Summary: ASP.NET Core intentionally uses its own StatusCodes (integers/constants) rather than System.Net.HttpStatusCode because the enum has naming/duplication issues and enums don’t map well to the open integer range of HTTP status codes. Team declined a PR that tried to switch to System.Net.HttpStatusCode. This is relevant to design choices: some teams prefer integer constants over extending an enum.

• Issue #25495 / #25499 (Mar 2018) - HttpStatusCode compatibility across framework
  Summary: Users complained about needing casts across framework boundaries; discussion noted differences between System.Net.HttpStatusCode and ASP.NET types. Reinforces the practical friction that motivated earlier proposals to extend the enum or provide integer alternatives.

Notes relevant to the new proposal (425, 520, 524)

• Historical precedent: the runtime team has accepted RFC/IANA-standardized codes (see #15650, #70996), and many RFC-backed codes were added across releases. Contributions to add standardized codes have been accepted when justified.
• Non-standard/cloud-provider codes: 520 and 524 are Cloudflare-specific / non-IANA codes. Past discussion (e.g. the 418 debate) shows maintainers are cautious about adding non-standard or “unofficial” codes to the enum. Expect stronger scrutiny/justification for non-IANA values.
• Workarounds: you can cast integers to HttpStatusCode ((HttpStatusCode)524) or use integer-constant helpers (like Microsoft.AspNetCore.Http.StatusCodes) or add your own static constants if you need to avoid waiting for runtime additions.
• Exception surface: if you need to access the raw numeric code from exceptions, HttpRequestException.StatusCode is available (added via #32455).

If you want, I can:

• Check whether 425 is already present in the current runtime version; and whether 520/524 appear anywhere in runtime sources or docs.
• Draft the small PR to add a RFC-backed member (TooEarly = 425) and prepare notes/justification for the non-standard 520/524 if you want to pursue those as well.