Skip to content

HTTP Method Case Mismatch Causes Configured Routes To Never Match #175

Description

@stevehu

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions