There is not good way to catch "File not found" errors on static assets

[tristan957]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

So if you setup the ServeStaticModule and provide serveStaticOptions: { fallthrough: false }, the module reports a 500 (Internal Server) error.

I don't know why this is not coming clearly to me, but I want to change the 500 error to a 404, because the file was not found.

I tried to use a global Internal Server filter and match the route in the case of 500 errors, but that wasn't possible because for some reason the filter doesn't get hit. I must be missing something higher level about NestJS.

Expected behavior

I expect there to be an ergonomic way to handle errors when fallthrough is set to false.

Minimal reproduction of the problem with instructions

Use the example in the nest repo: https://github.com/nestjs/nest/blob/master/sample/24-serve-static/src/app.module.ts#L8

and configure your ServeStaticModule to also serve your home directory (just an example) include serveStaticOptions: { fallthrough: false }. Then after you have set up the mount point, start the server and enter a URL under the mount point that would not exist in your home directory. Your browser should report a 500 error.

What is the motivation / use case for changing the behavior?

It currently seems either impossible or not easily discoverable on how a developer can catch the serve-static 500 error and change it to a 404 for when a file is not found.

Environment

Nest version: 7.0.2



Honestly maybe this is an issue for the serve-static repo. I am unsure.

[kamilmysliwiec]

It currently seems either impossible or not easily discoverable on how a developer can catch the serve-static 500 error and change it to a 404 for when a file is not found.

Have you tried creating a global exception filter?

[tristan957]

Yes. Sorry if that was not clear from the original issue. My exception filter aimed at catching these 500 errors in order to convert them to 404s.

The global exception filter does not get hit. I know this because my log statements did not come across the console. I can confirm that an instance of the exception filter was created, just not used. To create the global exception filter, I added a provider to my module using the documentation specified at docs.nestjs.com.

[kamilmysliwiec]

Please, provide a minimal repository which reproduces your issue.

[danielkbx]

Just ran into the same issue. Even if an exception filter would be working, I think, a 404 would be the correct HTTP response code.

[tristan957]

I'll see about getting a reproducible repo tonight.

[cyrilselasi]

@kamilmysliwiec Run into the same issue. Was able to catch the error and handle it appropriately here:

@Catch()
export class ServeStaticExceptionFilter implements ExceptionFilter {

  catch( exception: any, host: ArgumentsHost ): any {

    const ctx = host.switchToHttp();
    const response = ctx.getResponse<Response>();
    const status = exception instanceof HttpException ? exception.getStatus() : HttpStatus.INTERNAL_SERVER_ERROR;

    if ( exception.code === "ENOENT" ) ) {
      response.sendStatus( HttpStatus.NOT_FOUND );

    }
    response.sendStatus( status );

    }
}

Main gotcha for me was the Catch decorator, since the error thrown is not an HttpException, be sure to leave catch everything.

[tristan957]

@cyrilselasi have you found a good way to use the filter only on the route where you are serving static content?

[cyrilselasi]

Not yet, I have it set as a global filter at the moment. That's working fine for my case

[micaelmbagira]

@kamilmysliwiec @tristan957 here is a repo that reproduces the issue https://github.com/micaelmbagira/nestjs-service-static-139.

[cedx]

Same issue here. Returning a 404 status code instead of catching the error 500 with a global exception filter is definitely the best option.

[kamilmysliwiec]

PRs are more than welcome (if anyone is interested) :)

[tristan957]

@kamilmysliwiec I think maybe all I will try later today. Does not seem too hard to add at least (if I understand the code correctly) for the Express side of things which I use.