cloudfront: Maximum number of allowlisted headers in Cache Policy is incorrectly set to 10
See original GitHub issueAfter upgrading our CDK CLI version and library for cloudfront we ran into the following error:
Error: Maximum allowed headers in Cache Policy is 10; got 13.
This seems to be enforced via https://github.com/aws/aws-cdk/blob/master/packages/@aws-cdk/aws-cloudfront/lib/cache-policy.ts#L234.
The maximum amount of 10 headers is in fact a soft limit that can be increased through AWS support (which we did) and should therefore not be treated as a hard limit here. See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-policies.
It seems this if
check is not in place for cookies or querystrings though, so there are no issues there.
Reproduction Steps
Create a cache policy with more than 10 whitelisted headers in the headerBehavior
.
const exampleCachePolicy = new cloudfront.CachePolicy(this, 'ExampleCachePolicy', {
cachePolicyName: 'example-policy',
headerBehavior: cloudfront.CacheHeaderBehavior.allowList(
'Header-1',
'Header-2',
'Header-3',
'Header-4',
'Header-5',
'Header-6',
'Header-7',
'Header-8',
'Header-9',
'Header-10',
'Header-11'
),
});
What did you expect to happen?
The cache policy’s creation/update should be based on the account’s proper quotas instead of failing on the hardcoded check within the cdk lib. F.e. if the account had its quota increased to 20, it should only fail if there are >20 headers in the allowList
.
What actually happened?
The cdk diff
fails with Error: Maximum allowed headers in Cache Policy is 10; got 11.
Environment
- CDK CLI Version : 1.95.1 (build ed2bbe6)
- Framework Version:
- Node.js Version: v15.12.0
- OS : Debian
- Language (Version): TypeScript
This is 🐛 Bug Report
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:6 (5 by maintainers)
Thanks for the report; when the validation was created, we missed the fact it was a soft (increasable) limit. We unfortunately can’t dynamically validate the limit client-side based on each account’s limits, but we can remove the validation entirely and leave it to CloudFormation to enforce.
@njlynch @encron Sorry about that. I’ve somehow missed that this was a soft limit. Also, PR #13907 has been created to revert similar checks in Origin Request Policy.