Updates from PR review

Author: johndowns

articles/frontdoor/front-door-caching.md

@@ -93,11 +93,11 @@ When a request for an asset specifies compression and the request results in a c
 
 If the origin uses Chunked Transfer Encoding (CTE) to send compressed data to the Azure Front Door PoP, then response sizes greater than 8 MB aren't supported.
 
-::: zone-end
-
 > [!NOTE]
 > Range requests may be compressed into different sizes. Azure Front Door requires the content-length values to be the same for any GET HTTP request. If clients send byte range requests with the `Accept-Encoding` header that leads to the Origin responding with different content lengths, then Azure Front Door will return a 503 error. You can either disable compression on the origin, or create a Rules Engine rule to remove the `Accept-Encoding` header from the request for byte range requests.
 
+::: zone-end
+
 ## Query string behavior
 
 With Azure Front Door, you can control how files are cached for a web request that contains a query string.
@@ -190,8 +190,8 @@ If the origin response is cacheable, then the `Set-Cookie` header is removed bef
 
 In addition, Front Door attaches the `X-Cache` header to all responses. The `X-Cache` response header includes one of the following values:
 
-- `TCP_HIT` or `TCP_REMOTE_HIT`: The first byte of the request is a cache hit, and content is served from the Front Door cache.
-- `TCP_MISS`: The first byte of the request is a cache miss, and the content is served from the origin.
+- `TCP_HIT` or `TCP_REMOTE_HIT`: The first 8MB chunk of the response is a cache hit, and the content is served from the Front Door cache.
+- `TCP_MISS`: The first 8MB chunk of the response is a cache miss, and the content is fetched from the origin.
 - `PRIVATE_NOSTORE`: Request can't be cached because the *Cache-Control* response header is set to either *private* or *no-store*.
 - `CONFIG_NOCACHE`: Request is configured to not cache in the Front Door profile.
 

articles/frontdoor/standard-premium/how-to-compression.md

@@ -19,7 +19,7 @@ There are two ways to enable file compression:
 - Enabling compression directly on the Azure Front Door POP servers (*compression on the fly*). In this case, Azure Front Door compresses the files and sends them to the end users.
 
 > [!NOTE]
-> Range requests may be compressed into different sizes. Azure Front Door requires the content-length values to be the same for any GET HTTP request. If clients send byte range requests with the `accept-encoding` header that leads to the Origin responding with different content lengths, then Azure Front Door will return a 503 error. You can either disable compression on Origin/Azure Front Door or create a Rules Set rule to remove `accept-encoding` from the request for byte range requests.
+> Range requests may be compressed into different sizes. Azure Front Door requires the `Content-Length` response header values to be the same for any GET HTTP request. If clients send byte range requests with the `Accept-Encoding` header that leads to the origin responding with different content lengths, then Azure Front Door returns a 503 error. You can either disable compression on the origin/Azure Front Door, or create a Rules Engine rule to remove the `Accept-Encoding` header from byte range requests.
 
 > [!IMPORTANT]
 > Azure Front Door configuration changes takes up to 10 mins to propagate throughout the network. If you're setting up compression for the first time for your CDN endpoint, consider waiting 1-2 hours before you troubleshoot to ensure the compression settings have propagated to all the POPs.

articles/frontdoor/standard-premium/how-to-logs.md

@@ -77,7 +77,7 @@ Azure Front Door currently provides individual API requests with each entry havi
 | Endpoint | The domain name of AFD endpoint, for example, contoso.z01.azurefd.net |
 | HttpStatusCode | The HTTP status code returned from Azure Front Door. If a request to the origin times out, the value for HttpStatusCode is set to **0**.|
 | Pop | The edge pop, which responded to the user request.  |
-| Cache Status | Provides the status code of how the request gets handled by the CDN service when it comes to caching. Possible values are:<ul><li>`HIT` and `REMOTE_HIT`: The HTTP request was served from the Front Door cache.</li><li>`MISS`: The HTTP request was served from the origin.</li><li> `PARTIAL_HIT`: Some of the bytes from a request were served from the Front Door cache, and some of the bytes were served from origin. This status occurs in [object chunking](../front-door-caching.md#delivery-of-large-files) scenarios.</li><li>`CACHE_NOCONFIG`: Request was forwarded without caching settings, including bypass scenario.</li><li>`PRIVATE_NOSTORE`: No cache configured in caching settings by customers.</li><li>`N/A`: The request was denied by a signed URL and rules engine.</li></ul> |
+| Cache Status | Provides the status code of how the request gets handled by the CDN service when it comes to caching. Possible values are:<ul><li>`HIT` and `REMOTE_HIT`: The HTTP request was served from the Front Door cache.</li><li>`MISS`: The HTTP request was served from the origin.</li><li> `PARTIAL_HIT`: Some of the bytes from a request were served from the Front Door cache, and some of the bytes were served from origin. This status occurs in [object chunking](../front-door-caching.md#delivery-of-large-files) scenarios.</li><li>`CACHE_NOCONFIG`: Request was forwarded without caching settings, including bypass scenario.</li><li>`PRIVATE_NOSTORE`: No cache configured in caching settings by customers.</li><li>`N/A`: The request was denied by a signed URL or the rules engine.</li></ul> |
 | MatchedRulesSetName | The names of the rules that were processed. |
 | RouteName | The name of the route that the request matched. |
 | ClientPort | The IP port of the client that made the request. |