Skip to content

Improve error bodies and move to release-please with NuGet OIDC - #46

Merged
perkops merged 7 commits into
mainfrom
fix/error-body-read-as-string-for-non-text-media-types
Sep 30, 2026
Merged

perkops merged 7 commits into
mainfrom
fix/error-body-read-as-string-for-non-text-media-types

Conversation

@perkops

@perkops perkops commented Sep 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Read error bodies as text whatever their media type
  • Add typed error content, content type and headers to binary responses
  • Decode non-ASCII download file names via RFC 5987 filename*
  • Replace GitFlow promotion and NBGV with release-please
  • Publish to NuGet via Trusted Publishing (OIDC) instead of an API key

Changes

✨ Features

  • Add ErrorContentObject deserialized via AddErrorResponse
  • Fill ContentType and ContentLength on binary error responses
  • Expose response and content Headers on binary responses
  • Prefer Content-Disposition filename* over filename for FileName
  • Add new members via a constructor overload; interfaces unchanged

🐛 Fixes

  • Read error bodies with non-text media types as a string
  • Decode error bodies by the Content-Type charset, UTF-8 by default
  • Keep byte[] handling for non-text success bodies

👷 CI/CD

  • Add release-please workflow publishing to NuGet via NuGet/login OIDC
  • Rename pre-integration workflow to build and run it on main pushes
  • Pin GitHub Actions to commit SHAs
  • Remove post-integration and manual release workflows

🔧 Configuration

  • Add release-please config and manifest for a single package
  • Replace Nerdbank.GitVersioning with a Version in Directory.Build.props
  • Ignore the local issues folder

📝 Documentation

  • Document binary error handling, file names and 3xx behavior
  • Document error bodies with non-text media types in the README

🔥 Removal

  • Remove version.json and the retired GitFlow docs and images

davidkallesen and others added 7 commits September 29, 2026 12:49
…ypes

BuildResponseAsync read bodies with non-JSON, non-text media types as a
byte[] and left Content empty, also for error statuses. An error such as
a 503 with application/xml or application/octet-stream therefore reached
the caller with an empty Content.

Error responses are now always read as a string, decoded by the
Content-Type charset (UTF-8 when none is given). Success responses keep
the existing byte[] behavior for non-text media types.
…binary responses

BuildBinaryResponseAsync and BuildStreamBinaryResponseAsync returned only a
raw string on errors: no content type, no headers and no way to read a
registered error type. FileName also ignored the RFC 5987 filename*
parameter, so non-ASCII names arrived mangled.

- Add ErrorContentObject, deserialized with the type registered for the
  status code (AddErrorResponse<T>); null when none is registered or
  deserialization fails. ErrorContent keeps the raw text.
- Fill ContentType and ContentLength on errors, and expose Headers
  (response and content headers) on success and error.
- Prefer ContentDisposition.FileNameStar over FileName.

The new members are on the classes only, through a new constructor
overload; the existing constructors and the interfaces are unchanged.
IsSuccess still follows the HTTP 2xx status.
@perkops
perkops merged commit 1d3bfa5 into main Sep 30, 2026
4 checks passed
@perkops
perkops deleted the fix/error-body-read-as-string-for-non-text-media-types branch September 30, 2026 07:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants