#How do you make 404 pages show up as '/404/index.html' instead of '404.html'?

40 messages · Page 1 of 1 (latest)

umbral bloom
#

Building a totally static website using Astro 4.15.4. And by totally static, I mean I'm using Astro to generate my .htaccess file. My server will have absolutely no custom code on it.

I'd like the 404 page to work like every other page on the site using the default of 'directory' for config's build.format. Thus, I expect my 404 page to be output at "/404/index.html".

As of now, I cannot find any way to do this. Instead, it always renders as "/404.html" or outputs something weirder still. It seems as though Astro is hard-wired to do this: https://docs.astro.build/en/basics/astro-pages/#custom-404-error-page

These are the failing methods I have tried so far:

  • pages/404.astro - outputs "404.html"
  • pages/404.mdx - outputs "404.html"
  • pages/404/index.astro - outputs "404.html"
  • pages/[404].astro and set getStaticPaths to output "404" - outputs "/404.html".
  • pages/[...404].astro and set getStaticPaths to output "404" - outputs "/404.html".
  • pages/[...404].astro and set getStaticPaths to output "404/index.html" - outputs "/404/index.html/index.html".
  • content/pages/404.mdx and then use a collection renderer for "pages" (via [...pages].astro) which renders most of the rest of my pages, getStaticPaths set to "404" - outputs "/404.html"

I'm at a loss. It seems that if anything even vaguely looks like /404/ in the output, it gets turned into 404.html.

#

Astro has been great so far, with me being able to solve most of my problems without too much effort. This is the first roadblock where it seems there is no way to configure an option. Thanks for your help.

umbral bloom
#

I have found a way to render the output to the expected path. You have to create a [...404].js (or .ts) file in pages. Then, you have to set the getStaticPaths to do params: { 404: "404/index.html" }. This renders to the expected location. However, now the output data is entirely my responsibility, as I have to export a string, which should be HTML in this case, from the GET function. However, this is less-than-optimal because it doesn't look like the ability to render a .astro file directly to a string of HTML is supported yet. There's a Stage 3 PR for this here:

#

Any chance there's a way to just tell Astro to not apply an exception for 404 and 500?

ashen rapids
umbral bloom
#

Thanks for the insight, @ashen rapids . I tried this and it will indeed render the HTML, and indeed the mdx with additional work. However, something about doing this means that any imported styles (and probably scripts) never actually make it to the page output, as you would expect for any other method. Neither my globally imported style css, nor the css module I import and reference in my layout actually make it to the final html output.

umbral bloom
#

Anybody else? Should I make this a feature request or something?

ashen rapids
umbral bloom
#

@ashen rapids This does not work. It renders the page to "/404/index.html/index.html". If you put the file at "src/pages/404/index.astro", the output is at '/404.html'.

As explained in the previous post, the reason I want to do this is to make all my pages (of which 404 is one) to work consistently, with the same kinds of access to collections and the same url structure as everything else on my site. Please understand that I'm designing my site to have an absolutely consistent url structure. If there is a partial url in an existing url, that partial url will also be a valid page, showing what would logically exist there. (This is essential for my breadcrumbs to work correctly, as well as being consistent for the user's benefit.)

Also, my server does not default to looking up 404 error documents at 404.html. Yes, I could make it point there, but that's not the point. In this case, Astro is making assumptions about the server technology that my static site will run on. In my opinion, it should not be opinionated in that way, just as it is relatively unopinionated about most things in its API.

ashen rapids
#

At least in the stackblitz it works.

image.png
#

Sorry isn't the screenshot you posted showing exactly the same result?

umbral bloom
#

Look at the trailing slash

ashen rapids
#

Actually, that probably won't work

umbral bloom
#

Forgive me if I'm mistaken, but isn't Astro.rewrite() for the server-side implementation? I'm generating a static site.

ashen rapids
#

No it won't

#

I think

umbral bloom
#

I mean, I tested it.

ashen rapids
#

I mean, that's gonna be a problem on any page. That's why people would usually make the route something like /pokemon/404 instead of just /404

umbral bloom
#

Your stackblitz implementation only appears to work because the server allows you to ignore the trailing slash. If you wanted to actually link to the page, you would have to link to '/404/index.html', instead of being able to link to '/404/', and that's only if your server allows you to drop the trailing slash.

ashen rapids
#

404.html is pretty standard, so my feeling is that wanting to have a different behaviour for this is breaking well established standards

#

But yeah if you defenitely want things this way, then I'm out of my depth sorry

umbral bloom
#

I've had websites on the internet for about 20 years with a page at "/404/", which is probably longer than the 404.html standard existed. I can get around this, of course. I could just have a post-render script physically move the 404.html file to 404/index.html. The point here is that Astro is doing something based on an assumption that is sometimes wrong, and provides no way to turn it off. It's making the exception behavior (making 404 and 500 strings work completely different from every other string), the standard.

ashen rapids
#

setting the trailing slash in the astro config to never, stops it from matching

image.png
#

But as I said above. My "solution" is merely a workaround

umbral bloom
#

Well thanks for taking another look.

ashen rapids
#

If you're fine using plain html pages another option would be to put it in public/404/astro.html which should be copied as is to the dist folder after build

umbral bloom
#

Not fine with that. I need to have it generate css and all the other components I might use on the page.

#

Which is why I can't use the container api as it doesn't yet push css to the output

ashen rapids
#

And one final option would maybe to use one of astro's build hooks to create the file during the build process. Could potentially use the container API to generate it at the end of the build

#

ah didn't know it did that, well, I think that's all I got sry 😅

umbral bloom
#

If there's a hook that happens when Astro is attempting to place a rendered file at a location, I could find the cases where it tries to put it at 404.html and 500.html and tell it to not do that. Maybe? Is there such a hook?

ashen rapids
#

I don't know that part of astro very well, but people have been doing pretty crazy things with hooks in integrations so what you want is probably somehow possible

umbral bloom
#

I will look into it.

umbral bloom
#

It's weird. According to the data I am seeing in integrations, the page generates where I expect it to, then it gets moved after the generation happens.