The statusText property of the response object in the endpoint should be preserved.

[izure1]

Astro Info

Astro                    v4.0.3
Node                     v18.18.2
System                   Windows (x64)
Package Manager          npm
Output                   hybrid
Adapter                  @astrojs/node
Integrations             @astrojs/react
                         @astrojs/tailwind

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

The statusText value of the new Response returned from the endpoint is not preserved. Here is an example code:

// /api/custom.ts
const { message } = error
return new Response(null, {
  status: 500,
  statusText: 'custom error message'
})

Afterwards, when checking the endpoint value with fetch in the browser, the statusText property of the response is changed to Internal Server Error.

I'm not sure if this is the intended behavior.

What's the expected result?

The specified statusText value provided by the user should be displayed.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-1dagae?file=src%2Fpages%2Findex.astro

Participation

• I am willing to submit a pull request for this issue.

[lilnasy]

• Related Content-Type missing when returning new Response with 404 status #8627

Implicit rerouting (basically returning any response with a status code of 404 or 500 implicitly reroutes) has several caveats. This is one of them. If you can't avoid using it, I'd recommend using locals to pass data to the 500 route instead.

Docs: Storing data in context.locals

[izure1]

Thank you for your feedback :)

I am currently writing code using the fetch API in the browser to asynchronously receive data from an endpoint.
If the response.ok value is false, I intend to output the response.statusText value to the user as an error message.
Therefore, I expect that this function can be easily implemented as long as the statusText attribute is maintained.

[lilnasy]

Thanks for explaining your use case, it really helps! You might run into issues after deploying to production because statusText does not exist in http 2 or 3. If your platform hosts your app on these newer protocols, statusText will be removed. For your use case a response header might be better.