cloudfront: Maximum number of allowlisted headers in Cache Policy is incorrectly set to 10

[encron]

After 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

[njlynch]

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]

Tagging @robertd as an FYI.

[encron]

Hey @njlynch, thanks for the fast follow-up! I figured verifying the account's limits itself might not be possible but just removing the validation in cdk itself is totally fine for me 👍

If anyone else is running into this, I downgraded our library to v1.92.0 to circumvent the validation.

[robertd]

@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.

[robertd]

@njlynch how come this one didn’t get merged in but #13907 did? Is mergify acting up again? :)

I guess @encron will have to wait until 1.97.0 then. :)

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.