You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I saw curveball/core#92, but I must be missing something. I've got code like this:
// handler.tsimport{Application,invokeMiddlewares}from'@curveball/core';importhandlerfrom'@curveball/aws-lambda';import{fooRoutes}from'./components/foo/routes';constapp=newApplication();app.use(ctx=>invokeMiddlewares(ctx,fooRoutes));exportconstrouter=handler(app);// components/foo/routes.tsimportrouterfrom'@curveball/router';import{fooController}from'./controller';// just has a "get" methodexportconstfooRoutes=[router('/:id/foo',fooController),];
The relevant bit of serverless.yml looks like so:
functions:
my-function:
handler: src/handler.routerevents:
- http:
# sends everything through to the routerpath: /{proxy+}method: any
When I visit localhost:3000/12345/foo, I get the expected result.
When I visit any other path (note: I've defined none), I get a 200 and an empty page. I would expect a 404 or a 405. Is handling of nonexistent routes not automagic? Did I miss a step?
If it's not handled automatically, is there a recommend best practice? (I didn't try too long, but a wildcard route didn't seem to do the trick either.)
Thanks!
The text was updated successfully, but these errors were encountered:
When @curveball/core executes all middlewares, and reaches all the way to the end it runs a 'NotFound' middleware.
tt
This middleware throws an exception. The 'normal curveball http server' path catches any exception, and emits a plain text error + http status code.
The @curveball/aws-lambda path does not catch this exception and do anything with this. Normally this would simply cause the lambda execution to fail, but I suspect that the serverless framework catches it, and return the 200 maybe? It is weird that it would do that!
A quick solution to this is to add the @curveball/problem middleware. This middleware catches errors and turns them into nicer looking application/problem+json errors.
I do think that @curveball/aws-lambda should behave as the regular server though, and emit errors that have a httpStatus property, but it also makes sense to me that other uncaught exceptions should bubble up to AWS Lambda itself as a critical failure, so it will show up as such in monitoring utilities.
tl;dr:
There is a bug here.
A quick workaround is to use @curveball/problem.
The fix for this should not catch non-http errors, so if the parent framework eats up exceptions and turns them into 200 OK, that's still pretty weird to me!
evert
changed the title
Best practice for nonexistent routes, methods, etc?
aws-lambda should catch exceptions with 'httpCode' information, and correctly emit http errors (if no error middleware is used).
Mar 2, 2021
You got me thinking and I tried a few more things. Not sure if any of this is helpful, but I doubt it can hurt!
Note that the example I gave above has serverless passing everything through via the path: /{proxy+} configuration. For everything that follows, I have set http events explicitly per below:
functions:
my-function:
handler: src/handler.routerevents:
- http:
path: /{id}/foomethod: any
- http:
path: /barmethod: any
For a path /unknown/to/both/serverless/and/curveball I get a 404 and a message Serverless-offline: route not found.
Suppose I forget to add a route to my curveball config for path /bar. In this case, Chrome gives me a 200 and a blank page. Firefox gives me a 200 and asks me to download a zero-length file:
The problem middleware doesn't seem to do the trick for me. I've updated my code as follows, and I see no change in behavior:
Hello.
I saw curveball/core#92, but I must be missing something. I've got code like this:
The relevant bit of serverless.yml looks like so:
When I visit
localhost:3000/12345/foo
, I get the expected result.When I visit any other path (note: I've defined none), I get a 200 and an empty page. I would expect a 404 or a 405. Is handling of nonexistent routes not automagic? Did I miss a step?
If it's not handled automatically, is there a recommend best practice? (I didn't try too long, but a wildcard route didn't seem to do the trick either.)
Thanks!
The text was updated successfully, but these errors were encountered: