fix: preserve user-specified Content-Type header in Response #1818
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #1817 - Response
Content-Typeheader is overwritten bymapResponseBody()Problem
When using
elide servewith a fetch handler that returns aResponsewith a customContent-Typeheader, the header was being unconditionally overwritten based on body type:Note: This only affects the declarative fetch handler pattern (
elide serve). Thenode:httpimperative pattern (used by apps like compare-gpt-elide) is not affected.Regression Source
Bug introduced in PR #1736 ("feat: new server engine"). The
mapResponseBody()function was added with unconditionalheaders.set("Content-Type", ...)calls.Solution
Modified
mapResponseBody()to check ifContent-Typeis already set before applying defaults:This preserves user-specified Content-Type headers while still providing sensible defaults when none is specified.
Testing
Added regression tests in
FetchIntrinsicTest.kt:response should preserve user-specified Content-Type headerresponse should use default Content-Type when not specifiedresponse should preserve custom headersManual testing:
elide serve- customContent-Type: text/htmlnow preservedX-Customwere already working (only Content-Type was affected)Changelog