fix!: Set content type header for server function errors #4249
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Problem ------- When a server function return an error, the content type header is not set. Solution -------- Use the `FromServerFnError::Encoder::CONTENT_TYPE` associated constant to set the content type header on the returned API response. Note: A similar issue occurs if an error is [returned in Leptos's middleware chain](https://github.com/leptos-rs/leptos/blob/b986fe11dc63a803d026f9ccae804e880c2a702b/server_fn/src/middleware/mod.rs#L77). However, I believe resolving that will require adding a field to the `BoxedService`, which would be an API-breaking change.
|
Todo: Use |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
When a server function returns an error, the content-type header is not set.
Solution
In order to set the content-type header in the response, the
FromServerFnError::Encoder::CONTENT_TYPEassociated constant needs to make its way to where the response object is constructed. This PR achieves this with the following changes:FromServerFnError#sertrait method to return the content type as well as the serialized error response bytes. This is returned in a newServerFnErrorResponsePartsstruct that contains both values and is marked#[non_exhaustive]to allow adding new fields in the future without breaking semver.BoxedService#serfield to be a function that returnsServerFnErrorResponsePartsto match the updatedFromServerFnError#sertrait method. The field is also renamed toerr_ser.BoxedServiceas#[non_exhaustive]to allow adding new fields in the future without breaking semver.Res#error_responsetrait method to takeServerFnErrorResponsePartsinstead ofBytes.Res#error_responseto set the content-type header using the value fromServerFnErrorResponseParts.bonto auto-generate a builder API for theServerFnErrorResponsePartsstruct.Note: I wasn't entirely sure how to handle
ServerFnErrorResponsePartsbeing used in stream/websocket responses, so I simply extracted thebodyfield in order to match the existing behavior.This is a semver-incompatible version of #4215
Closes #4209