Follow-up from the review of #174 (fixes #173).
Problem
LambdaProxyMiddleware normalizes the HTTP method case on lookup but not on registration:
So a lambda-proxy.yml entry written as /v1/pets@GET registers under key GET, while every incoming request looks up get. The matcher is never found and the route silently never works.
Impact
Before #174 this surfaced as an NPE. After #174 it degrades to a clean ERR10086 / HTTP 400, which is the correct handling for a genuine routing miss — but it also means a mis-cased config entry now fails quietly instead of loudly. The route is simply dead, with only an ERR10086 to show for it, and nothing points at the casing as the cause.
This is likely the underlying reason users hit #173 in the first place.
Suggested fix
Normalize on registration so both sides agree:
var method = endpoint[1].toLowerCase();
Worth considering alongside it: log a warning at startup when a config key contains a non-lowercase method, so existing mis-cased configs surface at boot rather than at request time.
Adjacent nits in the same method
Not urgent, but in populateMethodToMatcherMap:
- The trailing
this.methodToMatcherMap.put(method, matcher); (L135) is a no-op — computeIfAbsent already inserts, and matcher is mutated in place.
endpoint[1] throws ArrayIndexOutOfBoundsException on a malformed config key with no @ separator. A validation check with a clear error message would fail more usefully at startup.
Follow-up from the review of #174 (fixes #173).
Problem
LambdaProxyMiddlewarenormalizes the HTTP method case on lookup but not on registration:executelooks up with a lowercased method:https://github.com/networknt/light-lambda-native/blob/master/src/main/java/com/networknt/aws/lambda/handler/middleware/proxy/LambdaProxyMiddleware.java#L95
populateMethodToMatcherMapkeys the map with the raw config value:https://github.com/networknt/light-lambda-native/blob/master/src/main/java/com/networknt/aws/lambda/handler/middleware/proxy/LambdaProxyMiddleware.java#L130
So a
lambda-proxy.ymlentry written as/v1/pets@GETregisters under keyGET, while every incoming request looks upget. The matcher is never found and the route silently never works.Impact
Before #174 this surfaced as an NPE. After #174 it degrades to a clean
ERR10086/ HTTP 400, which is the correct handling for a genuine routing miss — but it also means a mis-cased config entry now fails quietly instead of loudly. The route is simply dead, with only anERR10086to show for it, and nothing points at the casing as the cause.This is likely the underlying reason users hit #173 in the first place.
Suggested fix
Normalize on registration so both sides agree:
Worth considering alongside it: log a warning at startup when a config key contains a non-lowercase method, so existing mis-cased configs surface at boot rather than at request time.
Adjacent nits in the same method
Not urgent, but in
populateMethodToMatcherMap:this.methodToMatcherMap.put(method, matcher);(L135) is a no-op —computeIfAbsentalready inserts, andmatcheris mutated in place.endpoint[1]throwsArrayIndexOutOfBoundsExceptionon a malformed config key with no@separator. A validation check with a clear error message would fail more usefully at startup.