Add Microsoft.Cdn 2026-09-01-preview API version

[Jay (HandsomeJay)]

ARM (Control Plane) API Specification Update Pull Request

Tip

Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram

Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR

What's the purpose of this PR? Check the specific option that applies. This is mandatory!

• New resource provider.
• New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
• Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
• Update existing version to fix OpenAPI spec quality issues in S360.
• Convert existing OpenAPI spec to TypeSpec spec (do not combine this with implementing changes for a new API version).
• Other, please clarify:
  • edit this with your clarification

Due diligence checklist

To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

• I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
• I have reviewed following Resource Provider guidelines, including
  ARM resource provider contract and
  REST guidelines (estimated time: 4 hours).
  I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.
• A release plan has been created. If not, please create one as it will help guide you through the REST API and SDK creation process.

Additional information

Viewing API changes

For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures

If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

• First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
• If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
• To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
• For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
  and https://aka.ms/ci-fix.
• For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
• If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
  This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
• If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.
• For guidance on SDK breaking change review, refer to https://aka.ms/ci-fix.

[github-actions]

Next Steps to Merge

Next steps that must be taken to merge this PR:

• ❌ This PR targets either the main branch of the public specs repo or the RPSaaSMaster branch of the private specs repo. These branches are not intended for iterative development. Therefore, you must acknowledge you understand that after this PR is merged, the APIs are considered shipped to Azure customers. Any further attempts at in-place modifications to the APIs will be subject to Azure's versioning and breaking change policies. Additionally, for control plane APIs, you must acknowledge that you are following all the best practices documented by ARM at aka.ms/armapibestpractices. If you do intend to release the APIs to your customers by merging this PR, add the PublishToCustomers label to your PR in acknowledgement of the above. Otherwise, retarget this PR onto a feature branch, i.e. with prefix release- (see aka.ms/azsdk/api-versions#release--branches).

Comment generated by summarize-checks workflow run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 6 pipeline(s).
3 pipeline(s) were filtered out due to trigger conditions.
Some pipeline(s) encountered errors during trigger evaluation.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
Swagger	Microsoft.Cdn-Cdn
Python	azure-mgmt-cdn
Go	sdk/resourcemanager/cdn/armcdn
JavaScript	@azure/arm-cdn
C#	Azure.ResourceManager.Cdn
Java	com.azure.resourcemanager:azure-resourcemanager-cdn

---

Comment generated by After APIView workflow run.

[microsoft-github-policy-service]

Hi @Jay (@HandsomeJay). Your PR has had no activity for 14 days and is marked as stale. If no further updates are made within 14 days, this PR will automatically be closed. To keep this PR active, please leave a comment as the PR author or remove the no-recent-activity label.

[github-actions]

Contributor readiness: required access

Warning

Access issues can block approvals, Azure DevOps pipelines, or labeling.

User / area	Access issue	PR impact
🔴 HandsomeJay	Azure membership not public.	Not determined.
🔴 shaambala	Azure membership not public. No repository write access.	Not determined.
🔴 shaambala_microsoft	Azure membership not public. No repository write access.	Not determined.
🔴 shaambala-ms	Azure membership not public. No repository write access.	Not determined.
🔴 vincent1114	Azure membership not public.	Not determined.
🔴 yunheMsft	Azure membership not public.	Not determined.
🔴 Zaaaaaa	Azure membership not public.	Not determined.
🟡 vincenthu@microsoft.com	Author/committer account unavailable; add or verify this email on a GitHub account. Affects 2 commits: fa70919, ba5feea.	Not determined.
🟡 wenjiexia@microsoft.com	Author/committer account unavailable; add or verify this email on a GitHub account. Affects 1 commit: 1b364de.	Not determined.
🟡 zhefeng@microsoft.com	Author/committer account unavailable; add or verify this email on a GitHub account. Affects 12 commits: 15de1d3, 0c0a923, b79a455, 3799807, e563562, 568fe20, f5d6684, 4005fc7, 02435c8, ff948f3, beeb427, a50858f.	Not determined.

Internal contributors: set up / renew access. Recheck: /azsdk check-access.

Non-blocking check; fix access issues to unblock affected actions.

Last updated: 2026-10-18T05:41:09.949Z

[github-actions]

TypeSpec suppressions requiring review

Status: ✅ Approved — 4 suppressions

This PR adds or updates the TypeSpec suppressions listed below. Suppressions are strongly discouraged — they bypass linter rules that protect API quality and consistency. Authors should avoid adding new suppressions and prefer fixing the underlying issue; reviewers should approve only when there is a clear, compelling justification and no reasonable alternative. Review each linked rule and source location, then apply typespec-suppressions-approved only if every justification is acceptable. The Status column shows ✅ once the label is applied and ❌ while approval is pending.

New suppressions (4)

Status	Rule	Source	Justification
✅	@azure-tools/typespec-azure-core/no-closed-literal-union Unions of literals should include the base scalar type to mark them as open enum.	models.tsp#L3667	Authorization policies only support Header; arbitrary locations, query strings, and cookies must not be accepted.
✅	@azure-tools/typespec-azure-resource-manager/arm-delete-operation-response-codes Ensure delete operations have the appropriate status codes.	AuthPolicy.tsp#L75	For backward compatibility: preserve the bodyless 200 response used by existing clients for synchronous AuthPolicy deletion.
✅	@azure-tools/typespec-azure-resource-manager/arm-put-operation-response-codes Ensure put operations have the appropriate status codes.	AuthPolicy.tsp#L43	For backward compatibility: preserve the bodyless 202 response used by existing clients for asynchronous AuthPolicy replacement.
✅	@azure-tools/typespec-azure-resource-manager/arm-resource-provisioning-state Check for properly configured provisioningState property.	models.tsp#L3475	The existing Azure Front Door state model defines the service's provisioning state contract.

For an overview of TypeSpec linting rules click here.
For a mapping from ARM lintdiff rules to corresponding TypeSpec linting rules click here.

💬 Have feedback on the TypeSpec suppression flow? Let us know.

[Zaaaaaa]

The suppressions have the following service-specific justifications:

1.  no-closed-literal-union  for  AuthLocation 
   This suppression is new because AuthPolicy is newly represented in the public TypeSpec surface, but the restriction reflects existing deployed RP behavior.  AuthLocation  is an input-constrained value, and the RP currently accepts only  Header ; unsupported locations such as  Query ,  Cookie , and unknown values are rejected. Adding the  string  fallback required for an open union would cause the REST contract and generated SDKs to accept values that the service cannot process. If additional locations are supported in the future, they will be introduced through a new API version so that clients using the existing closed contract do not receive unknown values.
2.  arm-delete-operation-response-codes  and  arm-put-operation-response-codes  for AuthPolicy
   The current AuthPolicy response codes follow the existing RP operation patterns used by the related CDN/AFD resource types: DELETE returns a bodyless  200  for synchronous completion, and PUT returns a bodyless  202  for asynchronous processing. Changing only AuthPolicy to use the recommended response codes in this API version would make its contract inconsistent with the other resource types and alter the existing client-visible behavior. We plan to align the PUT and DELETE response contracts with the ARM guidelines across all relevant resource types in a coordinated future API version, together with the required RP and SDK changes.
3.  arm-resource-provisioning-state  for  AuthPolicyProperties 
   AuthPolicy intentionally reuses the existing  AFDStateProperties  contract shared by other AFD resources. Its  AfdProvisioningState  reflects the values emitted by the RP, and the service has no cancellation path and does not return  Canceled . Adding  Canceled  only for AuthPolicy would document a value that the service never emits and make AuthPolicy inconsistent with the shared AFD state model. Updating the shared provisioning-state contract would affect existing resources and published API versions, so we plan to address it consistently across the affected AFD resources in a future API version.

[Ravi Eda (ravimeda)]

[EXISTING] 🔴 Blocking [RPC-Patch-V1-10] models.tsp — line 3429 — Mergeable PATCH schemas retain defaults and required fields.

Issue: At least fifteen default/required-field sites remain across the six inherited PATCH contracts—Routes, AFDCustomDomains, Endpoints, AFDOrigins, Rules, and SecurityPolicies—without counting constraints inside atomically replaced array elements. Route PATCH has a default on the supportedProtocols array property itself, as well as defaults for forwardingProtocol, linkToDefaultDomain, and httpsRedirect; recursively mergeable TLS settings require certificateType. Emitted primary anchor: $.definitions.RouteUpdatePropertiesParameters.properties.forwardingProtocol.default, openapi.json — line 17479. Perspective: SDK ergonomics.

Classification reasoning: The same models and violations are unchanged from 2026-08-01-preview; the prior models.tsp forwardingProtocol default is at line 3423.

Suggested fix: Introduce version-scoped PATCH-only shapes with optional mergeable fields and no defaults, preserving the existing creation models and all older API versions. For the current route PATCH shape:

forwardingProtocol?: ForwardingProtocol;
linkToDefaultDomain?: LinkToDefaultDomain;
httpsRedirect?: HttpsRedirect;

Remove the current-version PATCH supportedProtocols array-property default as well. Keep the scoped PatchBodyParametersSchema suppression until regenerated output passes validation; remove it only after the violating emitted shapes are fixed.

[Ravi Eda (ravimeda)]

ARM API Review

Posting findings from the ARM API Reviewer agent (critic-verified, 2 iteration(s), converged) against commit cf828ab. See inline comments for findings 6, 10, 11, and 12. Finding 1 concerns a line unchanged in this PR's diff and is posted as a top-level PR comment rather than inline.

Approval labels observed: none.

[Ravi Eda (ravimeda)]

[EXISTING] 🟠 Warning [EX-PAYLOAD] LogAnalytics_GetLogAnalyticsRankings.json — line 6 — Ranking examples use a string for an integer parameter.

Issue: Both LogAnalytics_GetLogAnalyticsRankings.json and LogAnalytics_GetWafLogAnalyticsRankings.json use "maxRanking": "5", while the operation parameter is integer/int32 (openapi.json — line 5712 and line 6087). This is a typed-example inconsistency, not evidence that HTTP query serialization differs. JSON path: $.parameters.maxRanking.

Classification reasoning: Both prior-version source examples have the same string at line 6, and the integer parameter contract is unchanged.

Suggested fix: Update both source examples and regenerate their emitted copies:

"maxRanking": 5

[Zaaaaaa]

All warning concern inherited examples from previous API versions and were not introduced by the new API surface in this PR. Given the current  2026-09-01-preview  release plan, we will track these example corrections and address them together in the next API version.

[Ravi Eda (ravimeda)]

[EXISTING] 🟠 Warning [EX-LRO-HEADERS] AFDEndpoints_Create.json — line 70 — Twenty-seven examples retain noncanonical polling-header casing.

Issue: The key azure-asyncoperation differs from the declared Azure-AsyncOperation spelling. The same lowercase key remains in 27 referenced source examples. HTTP header matching is case-insensitive; this is documentation/example consistency, not a runtime polling failure. Primary JSON path: $.responses['202'].headers['azure-asyncoperation'].

Classification reasoning: All 27 corresponding preceding-version examples contain the same lowercase key, including the cited example at line 70.

Suggested fix: Rename those source-example keys to Azure-AsyncOperation and regenerate, preserving their current URLs and operation-specific header families.

[Zaaaaaa]

All warning concern inherited examples from previous API versions and were not introduced by the new API surface in this PR. Given the current  2026-09-01-preview  release plan, we will track these example corrections and address them together in the next API version.

[Ravi Eda (ravimeda)]

[EXISTING] 🟠 Warning [EX-RESOURCE-ID] AFDEndpoints_Create.json — line 23 — Resource IDs retain noncanonical resource-group segment casing.

Issue: Referenced examples contain 135 response resource IDs across 73 files using /resourcegroups/ instead of /resourceGroups/. This excludes legitimate tenant-scoped EdgeNodes IDs. Azure's case-insensitive matching does not make these canonical documentation examples; this is not a claim of runtime rejection. Primary JSON path: $.responses['200'].body.id.

Classification reasoning: All 73 corresponding prior-version examples contain this casing, including the cited AFDEndpoints_Create response.

Suggested fix: Replace /resourcegroups/ with /resourceGroups/ in those source response IDs and regenerate emitted copies, preserving resource names and request-consistent identifiers.

[Zaaaaaa]

All warning concern inherited examples from previous API versions and were not introduced by the new API surface in this PR. Given the current  2026-09-01-preview  release plan, we will track these example corrections and address them together in the next API version.

[Ravi Eda (ravimeda)]

[EXISTING] 🟠 Warning [Section 6 — Null Values] AFDOrigins_CreateWithIncomingHostHeaderValidation.json — line 37 — Origin examples return null for non-nullable optional properties.

Issue: The 200, 201, and 202 response bodies set priority, sharedPrivateLinkResource, and weight to null (lines 37/39/40, 59/61/62, and 81/83/84). The priority and weight schemas are non-nullable integers, and sharedPrivateLinkResource is a non-nullable object reference. Primary JSON path: $.responses['200'].body.properties.priority. This is a published-example defect, not evidence that the deployed service returns these values.

Classification reasoning: The same prior-version source example contains these null values at the same lines; the current emitted copy is identical to the source.

Suggested fix: Omit priority, weight, and sharedPrivateLinkResource when unset in all three source response bodies, then regenerate the emitted example. Do not invent numeric values or change the service schema to accommodate the example.

[Zaaaaaa]

All warning concern inherited examples from previous API versions and were not introduced by the new API surface in this PR. Given the current  2026-09-01-preview  release plan, we will track these example corrections and address them together in the next API version.

[Zaaaaaa]

[EXISTING] 🔴 Blocking [RPC-Patch-V1-10] models.tsp — line 3429 — Mergeable PATCH schemas retain defaults and required fields.

Issue: At least fifteen default/required-field sites remain across the six inherited PATCH contracts—Routes, AFDCustomDomains, Endpoints, AFDOrigins, Rules, and SecurityPolicies—without counting constraints inside atomically replaced array elements. Route PATCH has a default on the supportedProtocols array property itself, as well as defaults for forwardingProtocol, linkToDefaultDomain, and httpsRedirect; recursively mergeable TLS settings require certificateType. Emitted primary anchor: $.definitions.RouteUpdatePropertiesParameters.properties.forwardingProtocol.default, openapi.json — line 17479. Perspective: SDK ergonomics.

Classification reasoning: The same models and violations are unchanged from 2026-08-01-preview; the prior models.tsp forwardingProtocol default is at line 3423.

Suggested fix: Introduce version-scoped PATCH-only shapes with optional mergeable fields and no defaults, preserving the existing creation models and all older API versions. For the current route PATCH shape:

forwardingProtocol?: ForwardingProtocol;
linkToDefaultDomain?: LinkToDefaultDomain;
httpsRedirect?: HttpsRedirect;

Remove the current-version PATCH supportedProtocols array-property default as well. Keep the scoped PatchBodyParametersSchema suppression until regenerated output passes validation; remove it only after the violating emitted shapes are fixed.

Thanks for identifying this. These PATCH findings are inherited from existing resource types and are not introduced by AuthPolicy. The new AuthPolicy resource intentionally follows the existing RP behavior for this version. To support the Ignite public preview, we plan to address the contract alignment across all affected resource types in the next API version rather than changing AuthPolicy in isolation. Could you please approve the current suppressions for  2026-09-01-preview ?

[Zaaaaaa]

all suppressions are expected