Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

RFC: RestSharp.Maui companion package for platform-specific quirks

未关闭
#2,388 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
csharp
领域
mobile-dev

调研方向

首先查看依赖的 issue #2387 以及 #2168 中的设计讨论,然后比较针对 #2168 和 #2385 提议的覆盖范围。未指定实现文件或测试。完成意味着需要决定是否创建配套 package、其命名方式、TFM 矩阵以及初始范围。

由索引模型根据 Issue 内容生成。

描述

feature-request rfc

Motivation

A growing set of MAUI / mobile-specific gotchas can't be fixed in core RestSharp because:

  • Core targets netstandard2.0 / net8.0+ and must remain free of iOS / Android workload dependencies.
  • Platform fixes often require calling into Foundation / NSURLSession / Java.Net types that only exist under TFM-specific workloads (net9.0-ios, net9.0-android, etc.).
  • Documenting the workarounds (see #2387) helps, but every consumer ends up copy-pasting the same recipe.

A small TFM-targeted companion package could collect these recipes as one-liner extension methods.

Proposed surface

// RestSharp.Maui
public static class RestClientOptionsExtensions {
    /// <summary>
    /// Configures the underlying handler to suppress NSURLSession's cookie storage,
    /// so Set-Cookie headers reach RestSharp's per-request parser intact.
    /// Multi-tenant safe — no shared cookie state at any layer.
    /// </summary>
    public static RestClientOptions UseIosCookieFix(this RestClientOptions options);

    // Room for future fixes:
    // - UseIosCertificatePinning(...)
    // - UseAndroidNetworkSecurityConfig(...)
    // - UseEphemeralNetworking()
}

Usage in a MAUI app:

var options = new RestClientOptions(baseUrl).UseIosCookieFix();

Open questions

  1. Naming. RestSharp.Maui vs RestSharp.Platforms vs separate RestSharp.iOS + RestSharp.Android packages. I lean toward RestSharp.Maui — single package, MAUI is the dominant consumer of platform-specific HTTP quirks.
  2. TFM matrix. Probably net8.0-ios, net9.0-ios, net10.0-ios, net8.0-android, net9.0-android, net10.0-android, plus netstandard2.0 no-op fallbacks so consumers can reference it from shared projects without conditional compilation.
  3. Maintenance burden. Every iOS / Android SDK bump may need a sanity check. Worth it only if 2-3+ platform fixes accumulate. Today we'd ship with just UseIosCookieFix.
  4. Discovery. Would need a README pointer and a docs section explaining when to reach for it. Risk: people who don't read docs still hit the original bug.

Decision needed

  • Ship now with a single helper (UseIosCookieFix) covering #2168 / #2385?
  • Wait until 2-3 platform fixes accumulate to justify the package?
  • Reject and keep all platform recipes in docs only?

Tracking: depends on #2387 (docs landing first) and follows from the design discussion in #2168.

主要语言
C#
星标
9.8k
派生
2.3k
PR 合并指标
30 天内没有已合并 PR

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

restsharp/RestSharp 的其他 Issue

查看 restsharp/RestSharp 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。