Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom 404 code in handler causes failure at handler.lua:146 #132

Open
midn1 opened this issue Mar 21, 2023 · 3 comments
Open

Custom 404 code in handler causes failure at handler.lua:146 #132

midn1 opened this issue Mar 21, 2023 · 3 comments

Comments

@midn1
Copy link

midn1 commented Mar 21, 2023

As in title, doing response:statusCode(404) within a handler for a custom 404 response causes the response:writeDefaultErrorMessage call at handler.lua:146 to crash the program.

Specifically, it tries to do a write when the response was already written.

This doesn't seem like a very niche requirement to me

@Tieske
Copy link
Contributor

Tieske commented Mar 22, 2023

Yes, I have seen that as well. The problem is with the Handler implementation which mixes a set of different roles. To fix this however would be a breaking change.

My 2cts; the router I added in #131 should not actually be a plugin, but it should replace the Handler. It should become the entry point for any request, and it should be possible to add plugins on a per-path basis. For example;

  • /static -> File handler plugin, Compress plugin
  • /downloads -> Download plugin, Compress plugin
  • /api -> call-back based

etc.

But that would require breaking changes. Though would make for a great 1.0 version.

wdyt @EvandroLG ?

@midn1
Copy link
Author

midn1 commented Mar 22, 2023

Though I'd prefer the ability to handle requests completely on my own, I wouldn't mind a fixed-function routing system either.

If you're going for the latter, route redirections will be a must (so I'd be able to, again, redirect to a 404 page)

@Tieske
Copy link
Contributor

Tieske commented Mar 22, 2023

that router does prefix matching, so a single path "/" would allow you to handle everything.

Not entirely sure what you mean with;

route redirections will be a must (so I'd be able to, again, redirect to a 404 page)

care to elaborate?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants