fix(cloudfront-origins): validate httpPort and httpsPort range in HttpOrigin

[kawaaaas]

Issue # (if applicable)

None

Reason for this change

HttpOrigin accepts httpPort and httpsPort as number props but performs no validation on them. Invalid values (e.g., 0, negative numbers, ports reserved by other services, values greater than 65535, or non-integer values) pass through synth and only fail at CloudFormation deploy time with a generic error.

Per the CloudFront Developer Guide, valid values for both ports are 80, 443, or 1024-65535.

Description of changes

Added synth-time validation in HttpOrigin for httpPort and httpsPort as a private validatePortNumber method, mirroring the pattern already used in VpcOrigin:

• The port must be 80, 443, or an integer between 1024 and 65535 (inclusive), matching the documented CloudFront constraint.
• Wraps the check with Token.isUnresolved(...) so CDK tokens (e.g., CfnParameter values) are passed through.
• Throws UnscopedValidationError with a descriptive message including the received value.

Describe any new or updated permissions being added

None.

Description of how you validated changes

Added 16 new unit test cases in aws-cloudfront-origins/test/http-origin.test.ts covering, for both httpPort and httpsPort.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[github-actions]

👋 It looks like your PR description follows the template but is missing a valid issue number in the first section.

PRs without a linked issue will receive lower priority for review and merging. Please update the description to include a reference like Closes #123. If no existing issue matches your change, create one first.

[aws-cdk-automation]

(This review is outdated)

[kawaaaas]

Exemption Request

This PR only adds synth-time input validation in HttpOrigin. The new code throws UnscopedValidationError before any CloudFormation template is produced, so there is no deployable behavior change to capture in an integration test or .snapshot.

The same pattern was previously introduced for VpcOrigin (validatePortNumber in aws-cloudfront/lib/vpc-origin.ts) without an integration test, for the same reason. Unit tests covering the boundary values (80, 443, 1024, 65535) and invalid values (0, -1, 79, 81, 442, 444, 1023, 65536, non-integer) have been added in aws-cloudfront-origins/test/http-origin.test.ts.

[leonmk-aws]

Thank you for your contribution

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-07-15 14:26 UTC · Rule: default-squash · triggered by rule automatic merge
• ✅ Checks skipped · PR is already up-to-date
• ✅ Merged — 2026-07-15 14:26 UTC · at ab28966293588edd748a3387f126029777c236fa · squash

This pull request spent 13 seconds in the queue, including 2 seconds running CI.

Required conditions to merge

• github-review-approved [🛡 GitHub branch protection]
  • fix(cloudfront-origins): validate httpPort and httpsPort range in HttpOrigin #37872
• any of [🛡 GitHub branch protection]:
  • check-success = validate-pr
  • check-neutral = validate-pr
  • check-skipped = validate-pr
• any of [🛡 GitHub branch protection]:
  • check-success = build
  • check-neutral = build
  • check-skipped = build

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.