aws_sdk_cloudfront

Module types

Source
Expand description

Data structures used by operation inputs/outputs.

Modules§

  • Builders
  • Error types that Amazon CloudFront can respond with.

Structs§

  • A list of key groups, and the public keys in each key group, that CloudFront can use to verify the signatures of signed URLs and signed cookies.

  • A list of Amazon Web Services accounts and the active CloudFront key pairs in each account that CloudFront can use to verify the signatures of signed URLs and signed cookies.

  • Amazon Web Services services in China customers must file for an Internet Content Provider (ICP) recordal if they want to serve content publicly on an alternate domain name, also known as a CNAME, that they've added to CloudFront. AliasICPRecordal provides the ICP recordal status for CNAMEs associated with distributions. The status is returned in the CloudFront response; you can't configure it yourself.

    For more information about ICP recordals, see Signup, Accounts, and Credentials in Getting Started with Amazon Web Services services in China.

  • A complex type that contains information about CNAMEs (alternate domain names), if any, for this distribution.

  • A complex type that controls which HTTP methods CloudFront processes and forwards to your Amazon S3 bucket or your custom origin. There are three choices:

    • CloudFront forwards only GET and HEAD requests.

    • CloudFront forwards only GET, HEAD, and OPTIONS requests.

    • CloudFront forwards GET, HEAD, OPTIONS, PUT, PATCH, POST, and DELETE requests.

    If you pick the third choice, you may need to restrict access to your Amazon S3 bucket or to your custom origin so users can't perform operations that you don't want them to. For example, you might not want users to have permissions to delete objects from your origin.

  • A complex type that describes how CloudFront processes requests.

    You must create at least as many cache behaviors (including the default cache behavior) as you have origins if you want CloudFront to serve objects from all of the origins. Each cache behavior specifies the one origin from which you want CloudFront to get objects. If you have two origins and only the default cache behavior, the default cache behavior will cause CloudFront to get objects from one of the origins, but the other origin is never used.

    For the current quota (formerly known as limit) on the number of cache behaviors that you can add to a distribution, see Quotas in the Amazon CloudFront Developer Guide.

    If you don't want to specify any cache behaviors, include only an empty CacheBehaviors element. Don't specify an empty individual CacheBehavior element, because this is invalid. For more information, see CacheBehaviors.

    To delete all cache behaviors in an existing distribution, update the distribution configuration and include only an empty CacheBehaviors element.

    To add, change, or remove one or more cache behaviors, update the distribution configuration and specify all of the cache behaviors that you want to include in the updated distribution.

    For more information about cache behaviors, see Cache Behavior Settings in the Amazon CloudFront Developer Guide.

  • A complex type that contains zero or more CacheBehavior elements.

  • A cache policy.

    When it's attached to a cache behavior, the cache policy determines the following:

    • The values that CloudFront includes in the cache key. These values can include HTTP headers, cookies, and URL query strings. CloudFront uses the cache key to find an object in its cache that it can return to the viewer.

    • The default, minimum, and maximum time to live (TTL) values that you want objects to stay in the CloudFront cache.

    The headers, cookies, and query strings that are included in the cache key are also included in requests that CloudFront sends to the origin. CloudFront sends a request when it can't find a valid object in its cache that matches the request's cache key. If you want to send values to the origin but not include them in the cache key, use OriginRequestPolicy.

  • A cache policy configuration.

    This configuration determines the following:

    • The values that CloudFront includes in the cache key. These values can include HTTP headers, cookies, and URL query strings. CloudFront uses the cache key to find an object in its cache that it can return to the viewer.

    • The default, minimum, and maximum time to live (TTL) values that you want objects to stay in the CloudFront cache.

    The headers, cookies, and query strings that are included in the cache key are also included in requests that CloudFront sends to the origin. CloudFront sends a request when it can't find a valid object in its cache that matches the request's cache key. If you want to send values to the origin but not include them in the cache key, use OriginRequestPolicy.

  • An object that determines whether any cookies in viewer requests (and if so, which cookies) are included in the cache key and in requests that CloudFront sends to the origin.

  • An object that determines whether any HTTP headers (and if so, which headers) are included in the cache key and in requests that CloudFront sends to the origin.

  • A list of cache policies.

  • An object that determines whether any URL query strings in viewer requests (and if so, which query strings) are included in the cache key and in requests that CloudFront sends to the origin.

  • Contains a cache policy.

  • A complex type that controls whether CloudFront caches the response to requests using the specified HTTP methods. There are two choices:

    • CloudFront caches responses to GET and HEAD requests.

    • CloudFront caches responses to GET, HEAD, and OPTIONS requests.

    If you pick the second choice for your Amazon S3 Origin, you may need to forward Access-Control-Request-Method, Access-Control-Request-Headers, and Origin headers for the responses to be cached correctly.

  • CloudFront origin access identity.

  • Origin access identity configuration. Send a GET request to the /CloudFront API version/CloudFront/identity ID/config resource.

  • Lists the origin access identities for CloudFront.Send a GET request to the /CloudFront API version/origin-access-identity/cloudfront resource. The response includes a CloudFrontOriginAccessIdentityList element with zero or more CloudFrontOriginAccessIdentitySummary child elements. By default, your entire list of origin access identities is returned in one single page. If the list is long, you can paginate it using the MaxItems and Marker parameters.

  • Summary of the information about a CloudFront origin access identity.

  • An alias (also called a CNAME) and the CloudFront distribution and Amazon Web Services account ID that it's associated with. The distribution and account IDs are partially hidden, which allows you to identify the distributions and accounts that you own, but helps to protect the information of ones that you don't own.

  • A list of aliases (also called CNAMEs) and the CloudFront distributions and Amazon Web Services accounts that they are associated with. In the list, the distribution and account IDs are partially hidden, which allows you to identify the distributions and accounts that you own, but helps to protect the information of ones that you don't own.

  • A field-level encryption content type profile.

  • The configuration for a field-level encryption content type-profile mapping.

  • Field-level encryption content type-profile.

  • A continuous deployment policy.

  • Contains the configuration for a continuous deployment policy.

  • Contains a list of continuous deployment policies.

  • A summary of the information about your continuous deployment policies.

  • This configuration determines which HTTP requests are sent to the staging distribution. If the HTTP request contains a header and value that matches what you specify here, the request is sent to the staging distribution. Otherwise the request is sent to the primary distribution.

  • Contains the percentage of traffic to send to a staging distribution.

  • Contains a list of cookie names.

  • This field is deprecated. We recommend that you use a cache policy or an origin request policy instead of this field.

    If you want to include cookies in the cache key, use CookiesConfig in a cache policy. See CachePolicy.

    If you want to send cookies to the origin but not include them in the cache key, use CookiesConfig in an origin request policy. See OriginRequestPolicy.

    A complex type that specifies whether you want CloudFront to forward cookies to the origin and, if so, which ones. For more information about forwarding cookies to the origin, see Caching Content Based on Cookies in the Amazon CloudFront Developer Guide.

  • A complex type that controls:

    • Whether CloudFront replaces HTTP status codes in the 4xx and 5xx range with custom error messages before returning the response to the viewer.

    • How long CloudFront caches HTTP status codes in the 4xx and 5xx range.

    For more information about custom error pages, see Customizing Error Responses in the Amazon CloudFront Developer Guide.

  • A complex type that controls:

    • Whether CloudFront replaces HTTP status codes in the 4xx and 5xx range with custom error messages before returning the response to the viewer.

    • How long CloudFront caches HTTP status codes in the 4xx and 5xx range.

    For more information about custom error pages, see Customizing Error Responses in the Amazon CloudFront Developer Guide.

  • A complex type that contains the list of Custom Headers for each origin.

  • A custom origin. A custom origin is any origin that is not an Amazon S3 bucket, with one exception. An Amazon S3 bucket that is configured with static website hosting is a custom origin.

  • A complex type that describes the default cache behavior if you don't specify a CacheBehavior element or if request URLs don't match any of the values of PathPattern in CacheBehavior elements. You must create exactly one default cache behavior.

  • A distribution tells CloudFront where you want content to be delivered from, and the details about how to track and manage content delivery.

  • A distribution configuration.

  • A distribution Configuration and a list of tags to be associated with the distribution.

  • A list of distribution IDs.

  • A distribution list.

  • A summary of the information about a CloudFront distribution.

  • Complex data type for field-level encryption profiles that includes all of the encryption entities.

  • Complex data type for field-level encryption profiles that includes the encryption key and field pattern specifications.

  • Contains information about the Amazon Kinesis data stream where you are sending real-time log data in a real-time log configuration.

  • A complex data type that includes the profile configurations and other options specified for field-level encryption.

  • A complex data type that includes the profile configurations specified for field-level encryption.

  • List of field-level encryption configurations.

  • A complex data type for field-level encryption profiles.

  • A complex data type of profiles for the field-level encryption.

  • List of field-level encryption profiles.

  • The field-level encryption profile summary.

  • A summary of a field-level encryption item.

  • A complex data type that includes the field patterns to match for field-level encryption.

  • This field is deprecated. We recommend that you use a cache policy or an origin request policy instead of this field.

    If you want to include values in the cache key, use a cache policy. For more information, see Creating cache policies in the Amazon CloudFront Developer Guide.

    If you want to send values to the origin but not include them in the cache key, use an origin request policy. For more information, see Creating origin request policies in the Amazon CloudFront Developer Guide.

    A complex type that specifies how CloudFront handles query strings, cookies, and HTTP headers.

  • A CloudFront function that is associated with a cache behavior in a CloudFront distribution.

  • A list of CloudFront functions that are associated with a cache behavior in a CloudFront distribution. Your functions must be published to the LIVE stage to associate them with a cache behavior.

  • Contains configuration information about a CloudFront function.

  • A list of CloudFront functions.

  • Contains metadata about a CloudFront function.

  • Contains configuration information and metadata about a CloudFront function.

  • A complex type that controls the countries in which your content is distributed. CloudFront determines the location of your users using MaxMind GeoIP databases.

  • Contains a list of HTTP header names.

  • The import source for the key value store.

  • An invalidation.

  • An invalidation batch.

  • The InvalidationList complex type describes the list of invalidation objects. For more information about invalidation, see Invalidating Objects (Web Distributions Only) in the Amazon CloudFront Developer Guide.

  • A summary of an invalidation request.

  • A key group.

    A key group contains a list of public keys that you can use with CloudFront signed URLs and signed cookies.

  • A key group configuration.

    A key group contains a list of public keys that you can use with CloudFront signed URLs and signed cookies.

  • A list of key groups.

  • Contains information about a key group.

  • A list of CloudFront key pair identifiers.

  • The key value store. Use this to separate data from function code, allowing you to update data without having to publish a new version of a function. The key value store holds keys and their corresponding values.

  • The key value store association.

  • The key value store associations.

  • The key value store list.

  • A list of identifiers for the public keys that CloudFront can use to verify the signatures of signed URLs and signed cookies.

  • Contains information about the Amazon Kinesis data stream where you are sending real-time log data.

  • A complex type that contains a Lambda@Edge function association.

  • A complex type that specifies a list of Lambda@Edge functions associations for a cache behavior.

    If you want to invoke one or more Lambda@Edge functions triggered by requests that match the PathPattern of the cache behavior, specify the applicable values for Quantity and Items. Note that there can be up to 4 LambdaFunctionAssociation items in this list (one for each possible value of EventType) and each EventType can be associated with only one function.

    If you don't want to invoke any Lambda@Edge functions for the requests that match PathPattern, specify 0 for Quantity and omit Items.

  • A complex type that controls whether access logs are written for the distribution.

  • A monitoring subscription. This structure contains information about whether additional CloudWatch metrics are enabled for a given CloudFront distribution.

  • An origin.

    An origin is the location where content is stored, and from which CloudFront gets content to serve to viewers. To specify an origin:

    • Use S3OriginConfig to specify an Amazon S3 bucket that is not configured with static website hosting.

    • Use CustomOriginConfig to specify all other kinds of origins, including:

      • An Amazon S3 bucket that is configured with static website hosting

      • An Elastic Load Balancing load balancer

      • An Elemental MediaPackage endpoint

      • An Elemental MediaStore container

      • Any other HTTP server, running on an Amazon EC2 instance or any other kind of host

    For the current maximum number of origins that you can specify per distribution, see General Quotas on Web Distributions in the Amazon CloudFront Developer Guide (quotas were formerly referred to as limits).

  • A CloudFront origin access control, including its unique identifier.

  • A CloudFront origin access control configuration.

  • A list of CloudFront origin access controls.

  • A CloudFront origin access control.

  • A complex type that contains HeaderName and HeaderValue elements, if any, for this distribution.

  • An origin group includes two origins (a primary origin and a second origin to failover to) and a failover criteria that you specify. You create an origin group to support origin failover in CloudFront. When you create or update a distribution, you can specify the origin group instead of a single origin, and CloudFront will failover from the primary origin to the second origin under the failover conditions that you've chosen.

  • A complex data type that includes information about the failover criteria for an origin group, including the status codes for which CloudFront will failover from the primary origin to the second origin.

  • An origin in an origin group.

  • A complex data type for the origins included in an origin group.

  • A complex data type for the origin groups specified for a distribution.

  • An origin request policy.

    When it's attached to a cache behavior, the origin request policy determines the values that CloudFront includes in requests that it sends to the origin. Each request that CloudFront sends to the origin includes the following:

    • The request body and the URL path (without the domain name) from the viewer request.

    • The headers that CloudFront automatically includes in every origin request, including Host, User-Agent, and X-Amz-Cf-Id.

    • All HTTP headers, cookies, and URL query strings that are specified in the cache policy or the origin request policy. These can include items from the viewer request and, in the case of headers, additional ones that are added by CloudFront.

    CloudFront sends a request when it can't find an object in its cache that matches the request. If you want to send values to the origin and also include them in the cache key, use CachePolicy.

  • An origin request policy configuration.

    This configuration determines the values that CloudFront includes in requests that it sends to the origin. Each request that CloudFront sends to the origin includes the following:

    • The request body and the URL path (without the domain name) from the viewer request.

    • The headers that CloudFront automatically includes in every origin request, including Host, User-Agent, and X-Amz-Cf-Id.

    • All HTTP headers, cookies, and URL query strings that are specified in the cache policy or the origin request policy. These can include items from the viewer request and, in the case of headers, additional ones that are added by CloudFront.

    CloudFront sends a request when it can't find an object in its cache that matches the request. If you want to send values to the origin and also include them in the cache key, use CachePolicy.

  • An object that determines whether any cookies in viewer requests (and if so, which cookies) are included in requests that CloudFront sends to the origin.

  • An object that determines whether any HTTP headers (and if so, which headers) are included in requests that CloudFront sends to the origin.

  • A list of origin request policies.

  • An object that determines whether any URL query strings in viewer requests (and if so, which query strings) are included in requests that CloudFront sends to the origin.

  • Contains an origin request policy.

  • CloudFront Origin Shield.

    Using Origin Shield can help reduce the load on your origin. For more information, see Using Origin Shield in the Amazon CloudFront Developer Guide.

  • A complex type that contains information about the SSL/TLS protocols that CloudFront can use when establishing an HTTPS connection with your origin.

  • Contains information about the origins for this distribution.

  • This object determines the values that CloudFront includes in the cache key. These values can include HTTP headers, cookies, and URL query strings. CloudFront uses the cache key to find an object in its cache that it can return to the viewer.

    The headers, cookies, and query strings that are included in the cache key are also included in requests that CloudFront sends to the origin. CloudFront sends a request when it can't find an object in its cache that matches the request's cache key. If you want to send values to the origin but not include them in the cache key, use OriginRequestPolicy.

  • A complex type that contains information about the objects that you want to invalidate. For more information, see Specifying the Objects to Invalidate in the Amazon CloudFront Developer Guide.

  • A public key that you can use with signed URLs and signed cookies, or with field-level encryption.

  • Configuration information about a public key that you can use with signed URLs and signed cookies, or with field-level encryption.

  • A list of public keys that you can use with signed URLs and signed cookies, or with field-level encryption.

  • Contains information about a public key.

  • Query argument-profile mapping for field-level encryption.

  • Configuration for query argument-profile mapping for field-level encryption.

  • Query argument-profile mapping for field-level encryption.

  • This field is deprecated. We recommend that you use a cache policy or an origin request policy instead of this field.

    If you want to include query strings in the cache key, use QueryStringsConfig in a cache policy. See CachePolicy.

    If you want to send query strings to the origin but not include them in the cache key, use QueryStringsConfig in an origin request policy. See OriginRequestPolicy.

    A complex type that contains information about the query string parameters that you want CloudFront to use for caching for a cache behavior.

  • Contains a list of query string names.

  • A real-time log configuration.

  • A list of real-time log configurations.

  • A subscription configuration for additional CloudWatch metrics.

  • A response headers policy.

    A response headers policy contains information about a set of HTTP response headers.

    After you create a response headers policy, you can use its ID to attach it to one or more cache behaviors in a CloudFront distribution. When it's attached to a cache behavior, the response headers policy affects the HTTP headers that CloudFront includes in HTTP responses to requests that match the cache behavior. CloudFront adds or removes response headers according to the configuration of the response headers policy.

    For more information, see Adding or removing HTTP headers in CloudFront responses in the Amazon CloudFront Developer Guide.

  • A list of HTTP header names that CloudFront includes as values for the Access-Control-Allow-Headers HTTP response header.

    For more information about the Access-Control-Allow-Headers HTTP response header, see Access-Control-Allow-Headers in the MDN Web Docs.

  • A list of HTTP methods that CloudFront includes as values for the Access-Control-Allow-Methods HTTP response header.

    For more information about the Access-Control-Allow-Methods HTTP response header, see Access-Control-Allow-Methods in the MDN Web Docs.

  • A list of origins (domain names) that CloudFront can use as the value for the Access-Control-Allow-Origin HTTP response header.

    For more information about the Access-Control-Allow-Origin HTTP response header, see Access-Control-Allow-Origin in the MDN Web Docs.

  • A list of HTTP headers that CloudFront includes as values for the Access-Control-Expose-Headers HTTP response header.

    For more information about the Access-Control-Expose-Headers HTTP response header, see Access-Control-Expose-Headers in the MDN Web Docs.

  • A response headers policy configuration.

    A response headers policy configuration contains metadata about the response headers policy, and configurations for sets of HTTP response headers.

  • The policy directives and their values that CloudFront includes as values for the Content-Security-Policy HTTP response header.

    For more information about the Content-Security-Policy HTTP response header, see Content-Security-Policy in the MDN Web Docs.

  • Determines whether CloudFront includes the X-Content-Type-Options HTTP response header with its value set to nosniff.

    For more information about the X-Content-Type-Options HTTP response header, see X-Content-Type-Options in the MDN Web Docs.

  • A configuration for a set of HTTP response headers that are used for cross-origin resource sharing (CORS). CloudFront adds these headers to HTTP responses that it sends for CORS requests that match a cache behavior associated with this response headers policy.

    For more information about CORS, see Cross-Origin Resource Sharing (CORS) in the MDN Web Docs.

  • An HTTP response header name and its value. CloudFront includes this header in HTTP responses that it sends for requests that match a cache behavior that's associated with this response headers policy.

  • A list of HTTP response header names and their values. CloudFront includes these headers in HTTP responses that it sends for requests that match a cache behavior that's associated with this response headers policy.

  • Determines whether CloudFront includes the X-Frame-Options HTTP response header and the header's value.

    For more information about the X-Frame-Options HTTP response header, see X-Frame-Options in the MDN Web Docs.

  • A list of response headers policies.

  • Determines whether CloudFront includes the Referrer-Policy HTTP response header and the header's value.

    For more information about the Referrer-Policy HTTP response header, see Referrer-Policy in the MDN Web Docs.

  • The name of an HTTP header that CloudFront removes from HTTP responses to requests that match the cache behavior that this response headers policy is attached to.

  • A list of HTTP header names that CloudFront removes from HTTP responses to requests that match the cache behavior that this response headers policy is attached to.

  • A configuration for a set of security-related HTTP response headers. CloudFront adds these headers to HTTP responses that it sends for requests that match a cache behavior associated with this response headers policy.

  • A configuration for enabling the Server-Timing header in HTTP responses sent from CloudFront. CloudFront adds this header to HTTP responses that it sends in response to requests that match a cache behavior that's associated with this response headers policy.

    You can use the Server-Timing header to view metrics that can help you gain insights about the behavior and performance of CloudFront. For example, you can see which cache layer served a cache hit, or the first byte latency from the origin when there was a cache miss. You can use the metrics in the Server-Timing header to troubleshoot issues or test the efficiency of your CloudFront configuration. For more information, see Server-Timing header in the Amazon CloudFront Developer Guide.

  • Determines whether CloudFront includes the Strict-Transport-Security HTTP response header and the header's value.

    For more information about the Strict-Transport-Security HTTP response header, see Strict-Transport-Security in the MDN Web Docs.

  • Contains a response headers policy.

  • Determines whether CloudFront includes the X-XSS-Protection HTTP response header and the header's value.

    For more information about the X-XSS-Protection HTTP response header, see X-XSS-Protection in the MDN Web Docs.

  • A complex type that identifies ways in which you want to restrict distribution of your content.

  • A complex type that contains information about the Amazon S3 bucket from which you want CloudFront to get your media files for distribution.

  • A complex type that contains information about the Amazon S3 origin. If the origin is a custom origin or an S3 bucket that is configured as a website endpoint, use the CustomOriginConfig element instead.

  • Session stickiness provides the ability to define multiple requests from a single viewer as a single session. This prevents the potentially inconsistent experience of sending some of a given user's requests to your staging distribution, while others are sent to your primary distribution. Define the session duration using TTL values.

  • A list of Amazon Web Services accounts and the active CloudFront key pairs in each account that CloudFront can use to verify the signatures of signed URLs and signed cookies.

  • The CloudFront domain name of the staging distribution.

  • A complex data type for the status codes that you specify that, when returned by a primary origin, trigger CloudFront to failover to a second origin.

  • A streaming distribution tells CloudFront where you want RTMP content to be delivered from, and the details about how to track and manage content delivery.

  • The RTMP distribution's configuration information.

  • A streaming distribution Configuration and a list of tags to be associated with the streaming distribution.

  • A streaming distribution list.

  • A summary of the information for a CloudFront streaming distribution.

  • A complex type that controls whether access logs are written for this streaming distribution.

  • A complex type that contains Tag key and Tag value.

  • A complex type that contains zero or more Tag elements.

  • A complex type that contains zero or more Tag elements.

  • Contains the result of testing a CloudFront function with TestFunction.

  • The traffic configuration of your continuous deployment.

  • A list of key groups whose public keys CloudFront can use to verify the signatures of signed URLs and signed cookies.

  • A list of Amazon Web Services accounts whose public keys CloudFront can use to verify the signatures of signed URLs and signed cookies.

  • A complex type that determines the distribution's SSL/TLS configuration for communicating with viewers.

    If the distribution doesn't use Aliases (also known as alternate domain names or CNAMEs)—that is, if the distribution uses the CloudFront domain name such as d111111abcdef8.cloudfront.net—set CloudFrontDefaultCertificate to true and leave all other fields empty.

    If the distribution uses Aliases (alternate domain names or CNAMEs), use the fields in this type to specify the following settings:

    • Which viewers the distribution accepts HTTPS connections from: only viewers that support server name indication (SNI) (recommended), or all viewers including those that don't support SNI.

      • To accept HTTPS connections from only viewers that support SNI, set SSLSupportMethod to sni-only. This is recommended. Most browsers and clients support SNI.

      • To accept HTTPS connections from all viewers, including those that don't support SNI, set SSLSupportMethod to vip. This is not recommended, and results in additional monthly charges from CloudFront.

    • The minimum SSL/TLS protocol version that the distribution can use to communicate with viewers. To specify a minimum version, choose a value for MinimumProtocolVersion. For more information, see Security Policy in the Amazon CloudFront Developer Guide.

    • The location of the SSL/TLS certificate, Certificate Manager (ACM) (recommended) or Identity and Access Management (IAM). You specify the location by setting a value in one of the following fields (not both):

      • ACMCertificateArn

      • IAMCertificateId

    All distributions support HTTPS connections from viewers. To require viewers to use HTTPS only, or to redirect them from HTTP to HTTPS, use ViewerProtocolPolicy in the CacheBehavior or DefaultCacheBehavior. To specify how CloudFront should use SSL/TLS to communicate with your custom origin, use CustomOriginConfig.

    For more information, see Using HTTPS with CloudFront and Using Alternate Domain Names and HTTPS in the Amazon CloudFront Developer Guide.

Enums§

  • When writing a match expression against CachePolicyCookieBehavior, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against CachePolicyHeaderBehavior, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against CachePolicyQueryStringBehavior, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against CachePolicyType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against CertificateSource, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ContinuousDeploymentPolicyType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against EventType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against Format, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against FrameOptionsList, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against FunctionRuntime, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against FunctionStage, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against GeoRestrictionType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against HttpVersion, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against IcpRecordalStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ImportSourceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ItemSelection, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against Method, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against MinimumProtocolVersion, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginAccessControlOriginTypes, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginAccessControlSigningBehaviors, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginAccessControlSigningProtocols, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginProtocolPolicy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginRequestPolicyCookieBehavior, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginRequestPolicyHeaderBehavior, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginRequestPolicyQueryStringBehavior, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against OriginRequestPolicyType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against PriceClass, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RealtimeMetricsSubscriptionStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ReferrerPolicyList, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ResponseHeadersPolicyAccessControlAllowMethodsValues, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ResponseHeadersPolicyType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against SslProtocol, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against SslSupportMethod, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ViewerProtocolPolicy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.