Creating a new Response with a Status Code of 404 leads to an infinite loop when the /404.astro page is absent.

[gitcaduff]

What version of astro are you using?

2.10.9

Are you using an SSR adapter? If so, which one?

Node

What package manager are you using?

npm

What operating system are you using?

Mac

What browser are you using?

Chrome

Describe the Bug

In the past, with an older version of Astro (until 2.8.4), it was feasible to generate Responses bearing the 404 status code. However, in the current setup (version 2.9.0 and above), this process triggers an infinite loop due to Astro's subsequent search for the missing /404.astro page. To circumvent this loop, I opt not to furnish a /404.astro page. This choice stems from my desire to refrain from redirecting users to a dedicated 404 page. Instead, I intend to furnish a 404 Code directly while retaining the requested URL's context.

return new Response("custom 404 html content", {
   status: 404
});

What's the expected result?

I would expect to be able to return any page with a 404 code.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/stackblitz-starters-6pmtt6?file=response-with-404-code%2Fsrc%2Fpages%2F[...path].astro

Participation

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

[lilnasy]

@gitcaduff Could not reproduce the issue. The custom 404 response gets served.

Could you check?

[gitcaduff]

Hi @lilnasy, thanks for your ultrafast reply!
I did just check it. It works as expected with "astro preview" but fails with "astro dev".

[gitcaduff]

@lilnasy it seems that the problem got back with Astro 4.5.x
if we run "astro dev" Astro tries to find the 404.astro, that does not exist. The result: an infinite loop.
thx

[lilnasy]

Could you open a new issue with a small reproduction project that runs into the loop?

[gitcaduff]

Could you open a new issue with a small reproduction project that runs into the loop?

Done: #10581

[kyr0]

This almost killed my whole Firebase budget, as a verifyToken call is done for the JWT token in my middleware. It still seems to happen in 4.5.17 or is a regression? Definitely not fixed. I have no static 404 page route. My middleware simply is doing this now, after I removed every of my code, step-by-step, and after countless of debugging hours, believing that the issue is caused somewhere by my code, test code etc., it's still happening with the most simple setup:

export const onRequest: MiddlewareHandler = async (
  { request },
  next,
): Promise<Response> => {
  // pre-flight request
  if (request.method === "OPTIONS") {
    console.log("Middleware allowed pre-flight request, 200 OK");
    return new Response(null, { status: 200 });
  }

  try {

    console.log("Middleware blocked request with no valid auth");
    return new Response("Not found", { status: 404 });
  } catch (error) {
    console.log("Middleware error", error.message, error.stack);
    logException(error);
    return new Response("Internal Server Error", { status: 500 });
  }
};

Once I access http://localhost:4321/, it's over:

Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 1ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
Middleware blocked request with no valid auth 2
01:29:10 [404] / 0ms
^C

[kyr0]

Btw there is no way now to return any 404 in the middleware, it always ends up in an infinite loop, even if I create a static 404 page. I'm now forced to diverge from security best practices and return a 403 instead. This way there is no endless loop.

[lilnasy]

@kyr0 The issue is a systematic one, explained in-depth here: withastro/roadmap#681.

There are likely multiple manifestations of it still in the codebase. It seems like middleware returning 404 responses is still problematic.

Could you open a new issue for it?

[kyr0]

@lilnasy Ah, now I found your comment here - sry; pls. ignore my extra text in the other issue about this being the case still #10735