fix: Set content type header for server function errors #4215

spencewenski · 2025-08-06T23:10:15Z

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_TYPE associated constant needs to make its way to where the response object is constructed. This PR achieves this with the following changes:

Add content_method to the Res trait to allow setting the Content-Type header for server function error responses.
Call the Res::content_method from the server function handler when an error is returned from the app's server fn impl.

Note: As mentioned in #4209, this issue also affects Leptos's middleware handlers. Unfortunately, resolving this for middleware requires a semver-incompatible change. The following PR contains a potential approach: #4249

Closes #4209

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.

spencewenski · 2025-08-06T23:10:45Z

server_fn/src/lib.rs

-                        )
+                            );
+                        let content_type =
+                    <Self::Error as FromServerFnError>::Encoder::CONTENT_TYPE;


This formatting is kind of weird, but it's what cargo fmt wants.

I think I'd prefer to modify error_response() to take and set the content type from the codec, then we wouldn't need to define a content_type function on Response

I would also prefer that, but I was trying to avoid introducing a breaking change. Would you prefer to modify error_response even though it would be a breaking change?

Yeah, it'll be better to have the better api and do the breaking change.

Alright, sounds good. I’ll update when I get a chance.

Updated the PR, please take a look when you get a chance. I made a few additional breaking changes that I thought made sense and also resolve the middleware issue I originally tried fixing in #4216.

server_fn/src/response/mod.rs

benwis · 2025-08-06T23:26:43Z

Have you looked at how the Errors are typically returned? If I recall correctly, they're usually not encoded/decoded using the standard logic and may not be valid JSON

spencewenski · 2025-08-06T23:53:03Z

Have you looked at how the Errors are typically returned? If I recall correctly, they're usually not encoded/decoded using the standard logic and may not be valid JSON

I think they're encoded by the FromServerFnError::Encoder associated type now, right? At least for errors returned in the body of the server function.

leptos/server_fn/src/error.rs

Line 572 in b986fe1

fn ser(&self) -> Bytes {

benwis

Thanks for taking the time to look into this, it can certainly get a bit tricky parsing the different layers of server fn code.

I think I'd prefer to modify error_response() here to take the codec's content_type and set it on the response. This way we shouldn't need a new associated fn on the Request and Response types

spencewenski · 2025-08-08T00:14:25Z

server_fn/Cargo.toml

  "futures",
 ], optional = true, workspace = true, default-features = true }
 thiserror = { workspace = true, default-features = true }
+bon = { workspace = true }


I'd be open to using typed-builder instead, or manually writing the necessary builder code.

spencewenski · 2025-08-08T19:16:41Z

I think the following semver error is a false positive; I was able to implement it in one of the example crates.

--- failure trait_newly_sealed: pub trait became sealed ---

Description:
A publicly-visible trait became sealed, so downstream crates are no longer able to implement it
        ref: https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.42.0/src/lints/trait_newly_sealed.ron

Failed in:
  trait server_fn::middleware::Service in file /home/runner/work/leptos/leptos/server_fn/src/middleware/mod.rs:46

https://github.com/leptos-rs/leptos/actions/runs/16836198701/job/47702412558?pr=4215#step:4:320

spencewenski · 2025-08-11T16:18:46Z

Hey, @benwis , can you take a look at the updated PR when you get a chance? Thanks!

benwis · 2025-08-14T03:11:01Z

Sorry it's been a few days, had some work to tackle. I'm somewhat puzzled by the direction this took, I didn't think another trait like ServerFnErrorResponseParts should be needed. In the previous Iteration I believe you attached the content-type header by referencing the already set value from the currently selected codec.

    let content_type =
                    <Self::Error as FromServerFnError>::Encoder::CONTENT_TYPE;

Why not just pass the above as a value to error_response() here: 9ac211f
It's quite possible I've missed something though.

spencewenski · 2025-08-14T03:22:13Z

Sorry it's been a few days, had some work to tackle. I'm somewhat puzzled by the direction this took, I didn't think another trait like ServerFnErrorResponseParts should be needed. In the previous Iteration I believe you attached the content-type header by referencing the already set value from the currently selected codec.
    let content_type =
                    <Self::Error as FromServerFnError>::Encoder::CONTENT_TYPE;
Why not just pass the above as a value to error_response() here: 9ac211f It's quite possible I've missed something though.

ServerFnErrorResponseParts is a struct returned by FromServerFnError::ser that contains the data required to return the error response, including the serialized error as Bytes and the content type. I wanted to create a struct to contain this data instead of adding a content_type parameter to Res::error_response so that more data could be returned by FromServerFnError::ser and passed to Res::error_response in the future without needing another API-breaking change. The content type is still coming from <Self::Error as FromServerFnError>::Encoder::CONTENT_TYPE, it's just coming from the FromServerFnError::ser directly in the ServerFnErrorResponseParts struct instead of needing to get it separately.

Returning the data from FromServerFnError::ser also resolves the related issue with the server fn middleware from my other PR in a cleaner way.

server_fn/src/error.rs

server_fn/src/middleware/mod.rs

server_fn/src/response/generic.rs

benwis

A few minor nits and a couple deeper questions as we mess with these traits

benwis · 2025-08-22T22:04:12Z

I did, but it doesn’t have to be part of this PR. I think this is basically ready to merge now. I don’t know if we have a section for custom errors for server fns in the book, but I’d put it there. Maybe in the server_fns_axum example

…

On Fri, Aug 22, 2025, at 3:02 PM, Spencer Ferris wrote: ***@***.**** commented on this pull request. In server_fn/src/response/generic.rs <#4215 (comment)>: > Response::builder() .status(http::StatusCode::INTERNAL_SERVER_ERROR) .header(SERVER_FN_ERROR_HEADER, path) - .body(err.into()) + .header(header::CONTENT_TYPE, err.content_type) + .body(err.body.into()) .unwrap() I assume by "this" you mean the CatchPanic layer? Where would you like it be mentioned? In a doc comment for the trait method? Or somewhere else? — Reply to this email directly, view it on GitHub <#4215 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBTCMJ7J2EOQ7O2PY7K233O6HN5AVCNFSM6AAAAACDJLEYTWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCNBWGMYTKMBSG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

gbj · 2025-08-24T18:55:48Z

In general I'm fine with this. I would prefer to use typed-builder rather than adding bon to the dependency tree, since typed-builder is already used in any leptos project.

It can't be merged until 0.9, given the breaking changes, and there are no plans for 0.9 in the near future, since releasing new breaking versions causes churn that can take the ecosystem a while to catch up to and is therefore kind of annoying for users.

I do think it's possible to do it with relatively fewer changes, by using default trait methods. See #4247 for a non-breaking approach, which we could merge into 0.8. (Assuming cargo-semver-checks doesn't disagree with me, which is always possible.)

spencewenski · 2025-08-24T21:26:26Z

In general I'm fine with this. I would prefer to use typed-builder rather than adding bon to the dependency tree, since typed-builder is already used in any leptos project.

It can't be merged until 0.9, given the breaking changes, and there are no plans for 0.9 in the near future, since releasing new breaking versions causes churn that can take the ecosystem a while to catch up to and is therefore kind of annoying for users.

I do think it's possible to do it with relatively fewer changes, by using default trait methods. See #4247 for a non-breaking approach, which we could merge into 0.8. (Assuming cargo-semver-checks doesn't disagree with me, which is always possible.)

Thanks, @gbj , the non-breaking approach you mentioned is essentially what I did originally. I would like for this to be able to be released relatively soon, so if 0.9 is not planned any time soon I’d prefer to take the non-breaking approach. The breaking approach could be done later when if/when 0.9 is planned. Any objections on that, @benwis ?

benwis · 2025-08-24T21:38:05Z

In general I'm fine with this. I would prefer to use typed-builder rather than adding bon to the dependency tree, since typed-builder is already used in any leptos project.
It can't be merged until 0.9, given the breaking changes, and there are no plans for 0.9 in the near future, since releasing new breaking versions causes churn that can take the ecosystem a while to catch up to and is therefore kind of annoying for users.
I do think it's possible to do it with relatively fewer changes, by using default trait methods. See #4247 for a non-breaking approach, which we could merge into 0.8. (Assuming cargo-semver-checks doesn't disagree with me, which is always possible.)

Thanks, @gbj , the non-breaking approach you mentioned is essentially what I did originally. I would like for this to be able to be released relatively soon, so if 0.9 is not planned any time soon I’d prefer to take the non-breaking approach. The breaking approach could be done later when if/when 0.9 is planned. Any objections on that, @benwis ?

It makes sense to me, sorry to make this a bit complicated. I'm hoping to get a patch release out soon and would love to have at least this partial release in it.

This reverts commit dda564b.

This reverts commit 058a4fe.

This reverts commit fe08880.

This reverts commit 9949f79.

This reverts commit 43e76de.

This reverts commit 6b6cafe.

This reverts commit a507872.

@gbj

Also adds some comments from @gbj's sample [PR](leptos-rs#4247)

spencewenski · 2025-08-25T04:28:55Z

I updated the PR to go back to the original semver-compatible approach and included some (reworded) comment's from @gbj's sample PR. I also opened a separate PR for the semver-incompatible approach. It's based on main so it will need an update to remove the Res::content_type method. Feel free to take that PR and update it or let me know if you start working on 0.9 and I'd be happy to update it. Or, ignore it and take a different approach to solving the issue. 😂

If things look good please merge when you get the chance because I do not have merge permissions.

spencewenski · 2025-08-25T15:08:50Z

The semver check is failing due to a different change that’s already in main.

variant ReloadWSProtocol:Auto in /home/runner/work/leptos/leptos/leptos_config/src/lib.rs:286
semver requires new major version

https://github.com/leptos-rs/leptos/actions/runs/17198851352/job/48793426173?pr=4215

spencewenski · 2025-08-27T07:00:08Z

Looks like the breaking change was reverted in main, so I synced my branch and all checks are passing now.

spencewenski · 2025-08-29T02:19:59Z

Hey @benwis , can you merge this PR when you get a chance? I don't have merge permissions.

gbj · 2025-08-29T12:56:36Z

Thanks for all your work, and for your patience and flexibility!

…) (#4215)

…tos-rs#4209) (leptos-rs#4215)

spencewenski commented Aug 6, 2025

View reviewed changes

server_fn/src/response/mod.rs Outdated Show resolved Hide resolved

spencewenski added 2 commits August 6, 2025 16:14

Use CONTENT_TYPE header from actix re-export

ed942bf

Add - in doc comment

bd317c8

This was referenced Aug 6, 2025

fix!: Set content type if error occurs in Leptos middleware #4216

Closed

Server functions do not set content-type header when an error is returned #4209

Closed

benwis requested changes Aug 7, 2025

View reviewed changes

spencewenski added 2 commits August 7, 2025 16:55

Per PR suggestion, fix with an API-breaking change

a507872

Rename BoxedService#ser field and use bon-3.0.0

6b6cafe

spencewenski changed the title ~~fix: Set content type header for server function errors~~ fix!: Set content type header for server function errors Aug 8, 2025

spencewenski requested a review from benwis August 8, 2025 00:13

spencewenski commented Aug 8, 2025

View reviewed changes

autofix-ci bot and others added 3 commits August 8, 2025 00:18

[autofix.ci] apply automated fixes

43e76de

Fix actix stream/websocket responses

9949f79

Fix stream/websocket responses in a couple other places

fe08880

Replace todo doc comment with actual comment

058a4fe

benwis reviewed Aug 14, 2025

View reviewed changes

server_fn/src/error.rs Outdated Show resolved Hide resolved

benwis reviewed Aug 14, 2025

View reviewed changes

server_fn/src/middleware/mod.rs Outdated Show resolved Hide resolved

benwis reviewed Aug 14, 2025

View reviewed changes

server_fn/src/response/generic.rs Show resolved Hide resolved

benwis requested changes Aug 14, 2025

View reviewed changes

Update doc comments

dda564b

benwis approved these changes Aug 19, 2025

View reviewed changes

gbj added this to the 0.9 milestone Aug 24, 2025

gbj mentioned this pull request Aug 24, 2025

Set correct Content-Type for server fn errors (non-breaking) (closes #4209) #4247

Closed

spencewenski added 9 commits August 24, 2025 20:49

Revert "Update doc comments"

198824d

This reverts commit dda564b.

Revert "Replace todo doc comment with actual comment"

8f3e65b

This reverts commit 058a4fe.

Revert "Fix stream/websocket responses in a couple other places"

427258f

This reverts commit fe08880.

Revert "Fix actix stream/websocket responses"

d446fa2

This reverts commit 9949f79.

Revert "[autofix.ci] apply automated fixes"

c2afd96

This reverts commit 43e76de.

Revert "Rename BoxedService#ser field and use bon-3.0.0"

8a1f474

This reverts commit 6b6cafe.

Revert "Per PR suggestion, fix with an API-breaking change"

b9c81d1

This reverts commit a507872.

Merge branch 'main' into server-fn-err-content-type-fix

3758db9

Revert commits to go back to the original semver-compatible approach

02a9810

Also adds some comments from @gbj's sample [PR](leptos-rs#4247)

spencewenski mentioned this pull request Aug 25, 2025

fix!: Set content type header for server function errors #4249

Open

spencewenski changed the title ~~fix!: Set content type header for server function errors~~ fix: Set content type header for server function errors Aug 25, 2025

Merge branch 'main' into server-fn-err-content-type-fix

b03565e

gbj merged commit 3b058e7 into leptos-rs:main Aug 29, 2025
283 checks passed

gbj pushed a commit that referenced this pull request Aug 29, 2025

fix: set Content-Type header for server function errors (closes #4209…

f06e058

…) (#4215)

maccesch pushed a commit to maccesch/leptos that referenced this pull request Nov 24, 2025

fix: set Content-Type header for server function errors (closes lep…

d63c78d

…tos-rs#4209) (leptos-rs#4215)

Uh oh!

fix: Set content type header for server function errors #4215

fix: Set content type header for server function errors #4215

Uh oh!

Conversation

spencewenski commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Uh oh!

spencewenski Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

benwis Aug 7, 2025

Choose a reason for hiding this comment

Uh oh!

spencewenski Aug 7, 2025

Choose a reason for hiding this comment

Uh oh!

benwis Aug 7, 2025

Choose a reason for hiding this comment

Uh oh!

spencewenski Aug 7, 2025

Choose a reason for hiding this comment

Uh oh!

spencewenski Aug 8, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

benwis commented Aug 6, 2025

Uh oh!

spencewenski commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benwis left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spencewenski Aug 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spencewenski commented Aug 8, 2025

Uh oh!

spencewenski commented Aug 11, 2025

Uh oh!

benwis commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

spencewenski commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

benwis left a comment

Choose a reason for hiding this comment

Uh oh!

benwis commented Aug 22, 2025 via email

Uh oh!

gbj commented Aug 24, 2025

Uh oh!

spencewenski commented Aug 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benwis commented Aug 24, 2025

Uh oh!

spencewenski commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

spencewenski commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

spencewenski commented Aug 27, 2025

Uh oh!

spencewenski commented Aug 29, 2025

Uh oh!

Uh oh!

gbj commented Aug 29, 2025

Uh oh!

spencewenski commented Aug 6, 2025 •

edited

Loading

spencewenski commented Aug 6, 2025 •

edited

Loading

benwis left a comment •

edited

Loading

spencewenski Aug 8, 2025 •

edited

Loading

benwis commented Aug 14, 2025 •

edited

Loading

spencewenski commented Aug 14, 2025 •

edited

Loading

spencewenski commented Aug 24, 2025 •

edited

Loading

spencewenski commented Aug 25, 2025 •

edited

Loading

spencewenski commented Aug 25, 2025 •

edited

Loading