Environment
- Current setup: API Gateway V1 (REST API) → Native compiled Spring Boot backend on AWS Lambda
- Current version:
aws-serverless-java-container-springboot3 of version 2.1.5
- Migration target: I'm looking at Spring Boot 4 migration and for this reason I'm checking if I have any problems with using
aws-serverless-java-container-springboot4 of version 3.0.0-SNAPSHOT
Issue
When migrating from the springboot3 to springboot4 container, I've discovered that the API Gateway V1 request context attributes are no longer being populated on the HttpServletRequest object.
Current Behavior (springboot3)
In the springboot3 container, generateRequest1 populates several request attributes including RequestReader.API_GATEWAY_CONTEXT_PROPERTY
Code reference: AwsSpringHttpProcessingUtils.java#L118
...
if (v1Request.getRequestContext() != null) {
httpRequest.setAttribute(RequestReader.API_GATEWAY_CONTEXT_PROPERTY, v1Request.getRequestContext());
httpRequest.setAttribute(RequestReader.ALB_CONTEXT_PROPERTY, v1Request.getRequestContext().getElb());
}
httpRequest.setAttribute(RequestReader.API_GATEWAY_STAGE_VARS_PROPERTY, v1Request.getStageVariables());
httpRequest.setAttribute(RequestReader.API_GATEWAY_EVENT_PROPERTY, v1Request);
httpRequest.setAttribute(RequestReader.LAMBDA_CONTEXT_PROPERTY, lambdaContext);
...
Expected Behavior (springboot4)
The springboot4 container's generateRequest1 method has been simplified and now only creates an AwsProxyHttpServletRequest without setting these attributes.
Code reference: AwsSpringHttpProcessingUtils.java#L118
AwsProxyHttpServletRequest httpServletRequest = new AwsProxyHttpServletRequest(v1Request, lambdaContext, securityWriter.writeSecurityContext(v1Request, lambdaContext));
httpServletRequest.setServletContext(servletContext);
return httpServletRequest;
Impact
This breaks existing code that relies on accessing the API Gateway context through RequestReader.API_GATEWAY_CONTEXT_PROPERTY. In my case, I extract the authorization token from the request context.
Questions
- Is this change intentional or is it a bug?
- If intentional, what is the recommended approach for accessing the API Gateway context in springboot4?
If this is a bug, I'm happy to submit a pull request that restores the attribute population behavior from the springboot3 version.
Workaround
It is still possible to get the context from the underlying request, but it is a bit cumbersome and requires unwrapping the request in some places (for example in the spring security FilterChain). And it won't work with spring's @RequestAttribute annotation.
Here is an example in Kotlin
if (request is HttpServletRequestWrapper && request.request is AwsProxyHttpServletRequest) {
val underlyingRequest = request.request as AwsProxyHttpServletRequest
val requestContext = underlyingRequest.awsProxyRequest.requestContext
return requestContext.authorizer?.principalId ?: "anonymous"
}
Environment
aws-serverless-java-container-springboot3of version2.1.5aws-serverless-java-container-springboot4of version3.0.0-SNAPSHOTIssue
When migrating from the springboot3 to springboot4 container, I've discovered that the API Gateway V1 request context attributes are no longer being populated on the
HttpServletRequestobject.Current Behavior (springboot3)
In the springboot3 container,
generateRequest1populates several request attributes includingRequestReader.API_GATEWAY_CONTEXT_PROPERTYCode reference: AwsSpringHttpProcessingUtils.java#L118
Expected Behavior (springboot4)
The springboot4 container's
generateRequest1method has been simplified and now only creates anAwsProxyHttpServletRequestwithout setting these attributes.Code reference: AwsSpringHttpProcessingUtils.java#L118
Impact
This breaks existing code that relies on accessing the API Gateway context through
RequestReader.API_GATEWAY_CONTEXT_PROPERTY. In my case, I extract the authorization token from the request context.Questions
If this is a bug, I'm happy to submit a pull request that restores the attribute population behavior from the springboot3 version.
Workaround
It is still possible to get the context from the underlying request, but it is a bit cumbersome and requires unwrapping the request in some places (for example in the spring security FilterChain). And it won't work with spring's
@RequestAttributeannotation.Here is an example in Kotlin