Skip to content

fix(responder): preserve custom Content-Type header in Data - #69

Open
AdamMagued wants to merge 1 commit into
go-chi:masterfrom
AdamMagued:preserve-data-content-type
Open

AdamMagued wants to merge 1 commit into
go-chi:masterfrom
AdamMagued:preserve-data-content-type

Conversation

@AdamMagued

Copy link
Copy Markdown

Fixes #16

Problem

render.Data unconditionally overwrote the Content-Type header on http.ResponseWriter with application/octet-stream. This made it impossible for handlers to set a custom content type (such as image/png, application/pdf, or custom binary media types) when writing binary responses through render.Data.

Solution

Only set the default application/octet-stream Content-Type when w.Header().Get("Content-Type") is empty. If a handler or middleware has already specified a Content-Type on the response writer, that content type is preserved.

Testing

Added unit tests in responder_test.go:

  • Verifies that Data defaults to application/octet-stream when no Content-Type is set.
  • Verifies that custom Content-Type headers (e.g. image/png, application/pdf, text/csv; charset=utf-8) are preserved.
  • Verifies that status codes configured via render.Status are preserved alongside custom headers.
  • Verifies empty payload handling.

Data previously overwrote any existing Content-Type header on the ResponseWriter with application/octet-stream. This prevented handlers from using Data to render custom binary payloads such as images or PDFs.

Only set application/octet-stream when Content-Type is not already set. Add unit tests for default and custom Content-Type handling.

Fixes go-chi#16
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.

Allow custom Content-Type for render.Data

1 participant