Bug: Event handler with unsupported content-type headers raises an exception instead of returning a 4xx error

[chriselion]

Expected Behaviour

Passing unsupported content-type headers (for example, "headers": {"content-type": "text/xml"}) to an event handler (tested with ALBResolver, but probably affects others) should result in some sort of client error, for example 422.

Current Behaviour

Currently, an uncaught exception is raised, resulting in a 500 status code:

request returned status 500
  error: Traceback (most recent call last):
  File "/Users/celion/.cache/uv/environments-v2/validation-repro-e88f9191e633f920/lib/python3.12/site-packages/aws_lambda_powertools/event_handler/api_gateway.py", line 2734, in _call_route
    route(router_middlewares=self._router_middlewares, app=self, route_arguments=route_arguments),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/celion/.cache/uv/environments-v2/validation-repro-e88f9191e633f920/lib/python3.12/site-packages/aws_lambda_powertools/event_handler/api_gateway.py", line 509, in __call__
    return self._middleware_stack(app)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/celion/.cache/uv/environments-v2/validation-repro-e88f9191e633f920/lib/python3.12/site-packages/aws_lambda_powertools/event_handler/api_gateway.py", line 1639, in __call__
    return self.current_middleware(app, self.next_middleware)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/celion/.cache/uv/environments-v2/validation-repro-e88f9191e633f920/lib/python3.12/site-packages/aws_lambda_powertools/event_handler/middlewares/base.py", line 121, in __call__
    return self.handler(app, next_middleware)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/celion/.cache/uv/environments-v2/validation-repro-e88f9191e633f920/lib/python3.12/site-packages/aws_lambda_powertools/event_handler/middlewares/openapi_validation.py", line 102, in handler
    received_body=self._get_body(app),
                  ^^^^^^^^^^^^^^^^^^^
  File "/Users/celion/.cache/uv/environments-v2/validation-repro-e88f9191e633f920/lib/python3.12/site-packages/aws_lambda_powertools/event_handler/middlewares/openapi_validation.py", line 132, in _get_body
    raise NotImplementedError("Only JSON body or Form() are supported")
NotImplementedError: Only JSON body or Form() are supported

Code snippet

# /// script
# dependencies = [
#   "aws-lambda-powertools==3.24.0",
#   "pydantic"
# ]
# ///

import pydantic
import aws_lambda_powertools
from aws_lambda_powertools.event_handler import ALBResolver

class MyRequest(pydantic.BaseModel):
    foo: str = ""

class MyResponse(pydantic.BaseModel):
    bar: str

app = ALBResolver(enable_validation=True)

@app.put("/test/")
def test_endpoint(
    body: MyRequest,
) -> MyResponse:
    return MyResponse(bar=body.foo)


def main():
    print(f"Running on aws-lambda-powertools=={aws_lambda_powertools.__version__} pydantic=={pydantic.__version__}")
    event = {
        "httpMethod": "PUT",
        "path": "/test/",
        "requestId": "some_request_id",
        "requestContext": {"elb": {"targetGroupArn": ":target:"}},
        # Set non-JSON non-form headers
        "headers": {"content-type": "text/xml"}
    }

    try:
        response = app.resolve(event, context=None)
        print(f"request returned status {response['statusCode']}")
        if response["statusCode"] != 200:
            print(f"  error: {response['body']}")
    except Exception as e:
        print(f"Raise an exception resolving event: {e}")

if __name__ == "__main__":
    main()

Possible Solution

The relevant code is here:

powertools-lambda-python/aws_lambda_powertools/event_handler/middlewares/openapi_validation.py

Lines 117 to 132 in 705e416

	def _get_body(self, app: EventHandlerInstance) -> dict[str, Any]:
	"""
	Get the request body from the event, and parse it according to content type.
	"""
	content_type = app.current_event.headers.get("content-type", "").strip()
	# Handle JSON content
	if not content_type or content_type.startswith(APPLICATION_JSON_CONTENT_TYPE):
	return self._parse_json_data(app)
	# Handle URL-encoded form data
	elif content_type.startswith(APPLICATION_FORM_CONTENT_TYPE):
	return self._parse_form_data(app)
	else:
	raise NotImplementedError("Only JSON body or Form() are supported")

An easy fix would be to raise a different exception type - maybe RequestValidationError?

Steps to Reproduce

No special installation steps are required. I can reproduce the error with the latest release (3.24.0)

Powertools for AWS Lambda (Python) version

3.24.0 (current latest)

AWS Lambda function runtime

3.12

Packaging format used

PyPi

Debugging logs

n/a, can reproduce locally

[dreamorosi]

Hi @chriselion, thank you for opening this issue.

Would you like to send a pull request to fix this?

[chriselion]

@dreamorosi
Sure, I'll try to get to it soon. I mostly wanted to make sure my expectation about the behavior in that case was correct before I started on anything.

[dreamorosi]

Good point - let's get a second opinion: @svozza what do you think?

[leandrodamascena]

When defining a field in the request body, we intentionally only support application/json, as we need to serialize and dump the pydantic models and the only supported format is JSON.

We could consider adding support for other types, but this would requires additional dependencies, and I'm not sure of the best way to do this right now.

We could investigate the possibility of changing the exception type and make it a 422 response, but this might cause breaking change for those who depend on the current exception type. We can think about a flag and in this case we keep backwards compatibility. WDYT @chriselion ?

[svozza]

If I'm understanding this correctly I would think 415 Unsupported Media Type would be a more appropriate HTTP response.

[chriselion]

We could consider adding support for other types, but this would requires additional dependencies, and I'm not sure of the best way to do this right now.

That's definitely out of scope - I originally ran into this because of user error, and just want to make sure the status code reflects that.

We could investigate the possibility of changing the exception type and make it a 422 response, but this might cause breaking change for those who depend on the current exception type. We can think about a flag and in this case we keep backwards compatibility.

IMHO this is a bug (it's an uncaught exception), and you shouldn't have a flag to toggle fixing a bug :) To maintain compatibility with the current exception type, I could add a new exception type like class RequestUnsupportedContentType(NotImplementedError), raise that, and then add a check for that in _call_exception_handler():

powertools-lambda-python/aws_lambda_powertools/event_handler/api_gateway.py

Lines 2936 to 2986 in 705e416

	def _call_exception_handler(self, exp: Exception, route: Route) -> ResponseBuilder | None:
	handler = self.exception_handler_manager.lookup_exception_handler(type(exp))
	if handler:
	try:
	return self._response_builder_class(response=handler(exp), serializer=self._serializer, route=route)
	except ServiceError as service_error:
	exp = service_error
	if isinstance(exp, RequestValidationError):
	# For security reasons, we hide msg details (don't leak Python, Pydantic or file names)
	errors = [{"loc": e["loc"], "type": e["type"]} for e in exp.errors()]
	return self._response_builder_class(
	response=Response(
	status_code=HTTPStatus.UNPROCESSABLE_ENTITY,
	content_type=content_types.APPLICATION_JSON,
	body={"statusCode": HTTPStatus.UNPROCESSABLE_ENTITY, "detail": errors},
	),
	serializer=self._serializer,
	route=route,
	)
	# OpenAPIResponseValidationMiddleware will only raise ResponseValidationError when
	# 'self._response_validation_error_http_code' is not None or
	# when route has custom_response_validation_http_code
	if isinstance(exp, ResponseValidationError):
	# route validation must take precedence over app validation
	http_code = route.custom_response_validation_http_code or self._response_validation_error_http_code
	errors = [{"loc": e["loc"], "type": e["type"]} for e in exp.errors()]
	return self._response_builder_class(
	response=Response(
	status_code=http_code.value,
	content_type=content_types.APPLICATION_JSON,
	body={"statusCode": http_code, "detail": errors},
	),
	serializer=self._serializer,
	route=route,
	)
	if isinstance(exp, ServiceError):
	return self._response_builder_class(
	response=Response(
	status_code=exp.status_code,
	content_type=content_types.APPLICATION_JSON,
	body={"statusCode": exp.status_code, "message": exp.msg},
	),
	serializer=self._serializer,
	route=route,
	)
	return None

If I'm understanding this correctly I would think 415 Unsupported Media Type would be a more appropriate HTTP response.

Yeah, that makes sense to me. I'd say making the response code customizable (like it is with ResponseValidationError) is overkill, but if you'd prefer that, I'll do it.

[leandrodamascena]

IMHO this is a bug (it's an uncaught exception), and you shouldn't have a flag to toggle fixing a bug :) To maintain compatibility with the current exception type, I could add a new exception type like class RequestUnsupportedContentType(NotImplementedError), raise that, and then add a check for that in _call_exception_handler():

https://github.com/aws-powertools/powertools-lambda-python/blob/705e41600d2b74cf2fc319005dd9ec71b2dab1fc/aws_lambda_powertools/event_handler/api_gateway.py#

I agree that this was a bad design decision at the time we created it, but it's not a bug or an unhandled exception, since we intentionally raise it and it's an unrecoverable error if you don't change the entire payload.
But regardless of how we see this behavior, I like your idea of raising an error from NotImplementedError and then people using current exception handler can caught this.

Can you try to submit a PR with this fix?

Thanks a lot for helping us to improve the project.

[chriselion]

Sounds good, I'll try to get a PR in the next few days.