Merge pull request #228781 from duongau/cdnfreshness3

CDN freshness review (Batch 3)

Author: American-Dipper

articles/cdn/cdn-azure-diagnostic-logs.md

@@ -5,17 +5,15 @@ description: Learn how to use Azure diagnostic logs to save core analytics, whic
 services: cdn
 author: duongau
 manager: KumudD
-ms.assetid: 
 ms.service: azure-cdn
 ms.workload: tbd
 ms.tgt_pltfrm: na
 ms.topic: troubleshooting
-ms.date: 07/15/2020
+ms.date: 02/27/2023
 ms.author: duau 
 ms.custom: devx-track-azurepowershell
 ---
 
-
 # Diagnostic logs - Azure Content Delivery Network
 
 With Azure diagnostic logs, you can view core analytics and save them into one or more destinations including:
@@ -260,8 +258,8 @@ Not all metrics are available from all providers, although such differences are
 | RequestCountCacheHit | Count of all requests that resulted in a Cache hit. The asset was served directly from the POP to the client. | Yes | Yes | No  |
 | RequestCountCacheMiss | Count of all requests that resulted in a Cache miss. A Cache miss means the asset wasn't found on the POP closest to the client, and was retrieved from the origin. | Yes | Yes | No |
 | RequestCountCacheNoCache | Count of all requests to an asset that are prevented from being cached because of a user configuration on the edge. | Yes | Yes | No |
-| RequestCountCacheUncacheable | Count of all requests to assets that are prevented from being cached by the asset's Cache-Control and Expires headers. This count indicates that it shouldn't be cached on a POP or by the HTTP client. | Yes | Yes | No |
-| RequestCountCacheOthers | Count of all requests with cache status not covered by above. | No | Yes | No  |
+| RequestCountCacheUncacheable | Count of all requests to assets that are prevented from getting cached by the asset's Cache-Control and Expires headers. This count indicates that it shouldn't be cached on a POP or by the HTTP client. | Yes | Yes | No |
+| RequestCountCacheOthers | Count of all requests with cache status not covered by metrics listed previously. | No | Yes | No  |
 | EgressTotal | Outbound data transfer in GB | Yes |Yes |Yes |
 | EgressHttpStatus2xx | Outbound data transfer* for responses with 2xx HTTP status codes in GB. | Yes | Yes | No  |
 | EgressHttpStatus3xx | Outbound data transfer for responses with 3xx HTTP status codes in GB. | Yes | Yes | No  |
@@ -271,7 +269,7 @@ Not all metrics are available from all providers, although such differences are
 | EgressCacheHit | Outbound data transfer for responses that were delivered directly from the CDN cache on the CDN POPs/Edges. | Yes | Yes | No |
 | EgressCacheMiss. | Outbound data transfer for responses that weren't found on the nearest POP server, and retrieved from the origin server. | Yes | Yes | No |
 | EgressCacheNoCache | Outbound data transfer for assets that are prevented from being cached because of a user configuration on the edge. | Yes | Yes | No |
-| EgressCacheUncacheable | Outbound data transfer for assets that are prevented from being cached by the asset's Cache-Control and, or Expires headers. Indicates that it shouldn't be cached on a POP or by the HTTP client. | Yes | Yes | No |
+| EgressCacheUncacheable | Outbound data transfer for assets that are prevented from getting cached by the asset's Cache-Control and, or Expires headers. Indicates that it shouldn't be cached on a POP or by the HTTP client. | Yes | Yes | No |
 | EgressCacheOthers | Outbound data transfers for other cache scenarios. | No | Yes | No |
 
 *Outbound data transfer refers to traffic delivered from CDN POP servers to the client.
@@ -362,7 +360,7 @@ Example properties:
 
 ```
 
-## Additional resources
+## More resources
 
 * [Azure Diagnostic logs](../azure-monitor/essentials/platform-logs-overview.md)
 * [Core analytics via Azure CDN supplemental portal](./cdn-analyze-usage-patterns.md)

articles/cdn/cdn-cors.md

@@ -2,40 +2,40 @@
 title: Using Azure CDN with CORS | Microsoft Docs
 description: Learn how to use the Azure Content Delivery Network (CDN) to with Cross-Origin Resource Sharing (CORS).
 services: cdn
-documentationcenter: ''
-author: zhangmanling
-manager: erikre
-editor: ''
-
+author: duongau
+manager: kumud
 ms.assetid: 86740a96-4269-4060-aba3-a69f00e6f14e
 ms.service: azure-cdn
 ms.workload: tbd
 ms.tgt_pltfrm: na
 ms.topic: how-to
-ms.date: 01/23/2017
+ms.date: 02/27/2023
 ms.author: mazha
 
 ---
 # Using Azure CDN with CORS
+
 ## What is CORS?
-CORS (Cross Origin Resource Sharing) is an HTTP feature that enables a web application running under one domain to access resources in another domain. In order to reduce the possibility of cross-site scripting attacks, all modern web browsers implement a security restriction known as [same-origin policy](https://www.w3.org/Security/wiki/Same_Origin_Policy).  This prevents a web page from calling APIs in a different domain.  CORS provides a secure way to allow one origin (the origin domain) to call APIs in another origin.
+
+CORS (Cross Origin Resource Sharing) is an HTTP feature that enables a web application running under one domain to access resources in another domain. In order to reduce the possibility of cross-site scripting attacks, all modern web browsers implement a security restriction known as [same-origin policy](https://www.w3.org/Security/wiki/Same_Origin_Policy). This restriction prevents a web page from calling APIs in a different domain. CORS provides a secure way to allow one origin (the origin domain) to call APIs in another origin.
 
 ## How it works
+
 There are two types of CORS requests, *simple requests* and *complex requests.*
 
 ### For simple requests:
 
-1. The browser sends the CORS request with an additional **Origin** HTTP request header. The value of this header is the origin that served the parent page, which is defined as the combination of *protocol,* *domain,* and *port.*  When a page from https\://www.contoso.com attempts to access a user's data in the fabrikam.com origin, the following request header would be sent to fabrikam.com:
+1. The browser sends the CORS request with an extra **Origin** HTTP request header. The value of the request header is the origin that served the parent page, which is defined as the combination of *protocol,* *domain,* and *port.*  When a page from https\://www.contoso.com attempts to access a user's data in the fabrikam.com origin, the following request header would be sent to fabrikam.com:
 
    `Origin: https://www.contoso.com`
 
-2. The server may respond with any of the following:
+2. The server may respond with any of the following headers:
 
    * An **Access-Control-Allow-Origin** header in its response indicating which origin site is allowed. For example:
 
      `Access-Control-Allow-Origin: https://www.contoso.com`
 
-   * An HTTP error code such as 403 if the server does not allow the cross-origin request after checking the Origin header
+   * An HTTP error code such as 403 if the server doesn't allow the cross-origin request after checking the Origin header
 
    * An **Access-Control-Allow-Origin** header with a wildcard that allows all origins:
 
@@ -51,31 +51,34 @@ A complex request is a CORS request where the browser is required to send a *pre
 >
 
 ## Wildcard or single origin scenarios
-CORS on Azure CDN will work automatically with no additional configuration when the **Access-Control-Allow-Origin** header is set to wildcard (*) or a single origin.  The CDN will cache the first response and subsequent requests will use the same header.
 
-If requests have already been made to the CDN prior to CORS being set on your origin, you will need to purge content on your endpoint content to reload the content with the **Access-Control-Allow-Origin** header.
+CORS on Azure CDN works automatically without extra configurations when the **Access-Control-Allow-Origin** header is set to wildcard (*) or a single origin.  CDN cache the first response and subsequent requests use the same header.
+
+If requests have already been made to the CDN prior to CORS being set on your origin, you need to purge content on your endpoint content to reload the content with the **Access-Control-Allow-Origin** header.
 
 ## Multiple origin scenarios
-If you need to allow a specific list of origins to be allowed for CORS, things get a little more complicated. The problem occurs when the CDN caches the **Access-Control-Allow-Origin** header for the first CORS origin.  When a different CORS origin makes a subsequent request, the CDN will serve the cached **Access-Control-Allow-Origin** header, which won't match.  There are several ways to correct this.
+If you need to allow a specific list of origins to be allowed for CORS, things get a little more complicated. The problem occurs when the CDN caches the **Access-Control-Allow-Origin** header for the first CORS origin.  When a different CORS origin makes a subsequent request, the CDN serves the cached **Access-Control-Allow-Origin** header, which doesn't match. There are several ways to correct this problem.
 
 ### Azure CDN standard profiles
-On Azure CDN Standard from Microsoft, you can create a rule in the [Standard rules engine](cdn-standard-rules-engine-reference.md) to check the **Origin** header on the request. If it's a valid origin, your rule will set the **Access-Control-Allow-Origin** header with the desired value. In this case, the **Access-Control-Allow-Origin** header from the file's origin server is ignored and the CDN's rules engine completely manages the allowed CORS origins.
+On Azure CDN Standard from Microsoft, you can create a rule in the [Standard rules engine](cdn-standard-rules-engine-reference.md) to check the **Origin** header on the request. If it's a valid origin, your rule set the **Access-Control-Allow-Origin** header with the desired value. In this case, the **Access-Control-Allow-Origin** header from the file's origin server is ignored and the CDN's rules engine completely manages the allowed CORS origins.
 
 ![Rules example with standard rules engine](./media/cdn-cors/cdn-standard-cors.png)
 
 > [!TIP]
 > You can add additional actions to your rule to modify additional response headers, such as **Access-Control-Allow-Methods**.
 > 
 
-On **Azure CDN Standard from Akamai**, the only mechanism to allow for multiple origins without the use of the wildcard origin is to use [query string caching](cdn-query-string.md). Enable the query string setting for the CDN endpoint and then use a unique query string for requests from each allowed domain. Doing so will result in the CDN caching a separate object for each unique query string. This approach is not ideal, however, as it will result in multiple copies of the same file cached on the CDN.  
+On **Azure CDN Standard from Akamai**, the only mechanism to allow for multiple origins without the use of the wildcard origin is to use [query string caching](cdn-query-string.md). Enable the query string setting for the CDN endpoint and then use a unique query string for requests from each allowed domain. Doing so results in the CDN caching a separate object for each unique query string. This approach isn't ideal, however, as it results in multiple copies of the same file cached on the CDN.  
 
 ### Azure CDN Premium from Verizon
-Using the Verizon Premium rules engine, You'll need to [create a rule](./cdn-verizon-premium-rules-engine.md) to check the **Origin** header on the request.  If it's a valid origin, your rule will set the **Access-Control-Allow-Origin** header with the origin provided in the request.  If the origin specified in the **Origin** header is not allowed, your rule should omit the **Access-Control-Allow-Origin** header, which will cause the browser to reject the request. 
 
-There are two ways to do this with the Premium rules engine. In both cases, the **Access-Control-Allow-Origin** header from the file's origin server is ignored and the CDN's rules engine completely manages the allowed CORS origins.
+Using the Verizon Premium rules engine, you need to [create a rule](./cdn-verizon-premium-rules-engine.md) to check the **Origin** header on the request.  If it's a valid origin, your rule sets the **Access-Control-Allow-Origin** header with the origin provided in the request. If the origin specified in the **Origin** header isn't allowed, your rule should omit the **Access-Control-Allow-Origin** header, which causes the browser to reject the request. 
+
+There are two ways to resolve this problem with the Premium rules engine. In both cases, the **Access-Control-Allow-Origin** header from the file's origin server is ignored and the CDN's rules engine completely manages the allowed CORS origins.
 
 #### One regular expression with all valid origins
-In this case, you'll create a regular expression that includes all of the origins you want to allow: 
+
+In this case, you create a regular expression that includes all of the origins you want to allow: 
 
 ```http
 https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.com)$
@@ -86,7 +89,7 @@ https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.co
 > 
 > 
 
-If the regular expression matches, your rule will replace the **Access-Control-Allow-Origin** header (if any) from the origin with the origin that sent the request.  You can also add additional CORS headers, such as **Access-Control-Allow-Methods**.
+If the regular expression matches, your rule replaces the **Access-Control-Allow-Origin** header (if any) from the origin with the origin that sent the request.  You can also add extra CORS headers, such as **Access-Control-Allow-Methods**.
 
 ![Rules example with regular expression](./media/cdn-cors/cdn-cors-regex.png)
 
@@ -96,6 +99,6 @@ Rather than regular expressions, you can instead create a separate rule for each
 ![Rules example without regular expression](./media/cdn-cors/cdn-cors-no-regex.png)
 
 > [!TIP]
-> In the example above, the use of the wildcard character * tells the rules engine to match both HTTP and HTTPS.
+> In the example, the use of the wildcard character * tells the rules engine to match both HTTP and HTTPS.
 > 
 >

articles/cdn/cdn-manage-expiration-of-blob-content.md

@@ -2,20 +2,17 @@
 title: Manage expiration of Azure Blob storage
 titleSuffix: Azure Content Delivery Network
 description: Learn about the options for controlling time-to-live for blobs in Azure CDN caching.
-services: cdn
-documentationcenter: 
-author: zhangmanling
-manager: erikre
-editor: ''
-
+services: cdn 
+author: duongau
+manager: kumudd
 ms.assetid: ad4801e9-d09a-49bf-b35c-efdc4e6034e8
 ms.service: azure-cdn
 ms.workload: media
 ms.tgt_pltfrm: na
 ms.devlang: csharp
 ms.topic: how-to
-ms.date: 02/1/2018
-ms.author: mazha 
+ms.date: 02/27/2023
+ms.author: duau
 ms.custom: devx-track-azurepowershell
 
 ---
@@ -24,9 +21,8 @@ ms.custom: devx-track-azurepowershell
 > * [Azure web content](cdn-manage-expiration-of-cloud-service-content.md)
 > * [Azure Blob storage](cdn-manage-expiration-of-blob-content.md)
 > 
-> 
 
-The [Blob storage service](../storage/common/storage-introduction.md#blob-storage) in Azure Storage is one of several Azure-based origins integrated with Azure Content Delivery Network (CDN). Any publicly accessible blob content can be cached in Azure CDN until its time-to-live (TTL) elapses. The TTL is determined by the `Cache-Control` header in the HTTP response from the origin server. This article describes several ways that you can set the `Cache-Control` header on a blob in Azure Storage.
+The [Blob storage service](../storage/common/storage-introduction.md#blob-storage) in Azure Storage is one of several Azure-based origins integrated with Azure Content Delivery Network (CDN). Any publicly accessible blob content can be cached in Azure CDN until its time-to-live (TTL) elapses. The TTL gets determined by the `Cache-Control` header in the HTTP response from the origin server. This article describes several ways that you can set the `Cache-Control` header on a blob in Azure Storage.
 
 You can also control cache settings from the Azure portal by setting CDN caching rules. If you create a caching rule and set its caching behavior to **Override** or **Bypass cache**, the origin-provided caching settings discussed in this article are ignored. For information about general caching concepts, see [How caching works](cdn-how-caching-works.md).
 
@@ -65,7 +61,7 @@ The preferred method for setting a blob's `Cache-Control` header is to use cachi
 
    ![CDN global caching rules example](./media/cdn-manage-expiration-of-blob-content/cdn-global-caching-rules-example.png)
 
-   This global caching rule sets a cache duration of one hour and affects all requests to the endpoint. It overrides any `Cache-Control` or `Expires` HTTP headers that are sent by the origin server specified by the endpoint.   
+   This global caching rule sets a cache duration of one hour and affects all requests to the endpoint. It overrides any `Cache-Control` or `Expires` HTTP headers that get sent by the origin server specified by the endpoint.   
 
 3. Select **Save**.