Merge pull request #48392 from cephalin/issue8136

#8136

Author: PRMerger8

articles/app-service/app-service-local-cache-overview.md

@@ -3,8 +3,8 @@ title: Azure App Service Local Cache overview | Microsoft Docs
 description: This article describes how to enable, resize, and query the status of the Azure App Service Local Cache feature
 services: app-service
 documentationcenter: app-service
-author: SyntaxC4
-manager: yochayk
+author: cephalin
+manager: jpconnock
 editor: ''
 tags: optional
 keywords: ''
@@ -16,10 +16,14 @@ ms.topic: article
 ms.tgt_pltfrm: na
 ms.workload: na
 ms.date: 03/04/2016
-ms.author: cfowler
+ms.author: cephalin
 
 ---
 # Azure App Service Local Cache overview
+
+> [!NOTE]
+> Local cache is not supported in containerized App Service apps, such as on [App Service on Linux](containers/app-service-linux-intro.md).
+
 Azure web app content is stored on Azure Storage and is surfaced up in a durable manner as a content share. This design is intended to work with a variety of apps and has the following attributes:  
 
 * The content is shared across multiple virtual machine (VM) instances of the web app.
@@ -37,11 +41,11 @@ The Azure App Service Local Cache feature provides a web role view of your conte
 
 ## How Local Cache changes the behavior of App Service
 * The local cache is a copy of the /site and /siteextensions folders of the web app. It is created on the local VM instance on web app startup. The size of the local cache per web app is limited to 300 MB by default, but you can increase it up to 2 GB.
-* The local cache is read-write. However, any modifications is discarded when the web app moves virtual machines or gets restarted. Do not use Local Cache for apps that store mission-critical data in the content store.
+* The local cache is read-write. However, any modification is discarded when the web app moves virtual machines or gets restarted. Do not use Local Cache for apps that store mission-critical data in the content store.
 * Web apps can continue to write log files and diagnostic data as they do currently. Log files and data, however, are stored locally on the VM. Then they are copied over periodically to the shared content store. The copy to the shared content store is a best-case effort--write backs could be lost due to a sudden crash of a VM instance.
 * There is a change in the folder structure of the LogFiles and Data folders for web apps that use Local Cache. There are now subfolders in the storage LogFiles and Data folders that follow the naming pattern of "unique identifier" + time stamp. Each of the subfolders corresponds to a VM instance where the web app is running or has run.  
-* Publishing changes to the web app through any of the publishing mechanisms will publish to the shared content store. This is by design because we want the published content to be durable. To refresh the local cache of the web app, it needs to be restarted. Does this seem like an excessive step? To make the lifecycle seamless, see the information later in this article.
-* D:\Home points to the local cache. D:\local continue to point to the temporary VM-specific storage.
+* Publishing changes to the web app through any of the publishing mechanisms will publish to the durable shared content store. To refresh the local cache of the web app, it needs to be restarted. To make the lifecycle seamless, see the information later in this article.
+* D:\Home points to the local cache. D:\local continues to point to the temporary VM-specific storage.
 * The default content view of the SCM site continues to be that of the shared content store.
 
 ## Enable Local Cache in App Service

articles/app-service/app-service-web-tutorial-auth-aad.md

@@ -13,7 +13,7 @@ ms.workload: web
 ms.tgt_pltfrm: na
 ms.devlang: dotnet
 ms.topic: tutorial
-ms.date: 04/03/2018
+ms.date: 08/07/2018
 ms.author: cephalin
 ---
 
@@ -237,7 +237,7 @@ From the management page of the AD application, copy the **Application ID** to a
 
 Follow the same steps for the front-end app, but skip the last step. You don't need the **Application ID** for the front-end app. Keep the **Azure Active Directory Settings** page open.
 
-If you like, navigate to `http://<front_end_app_name>.azurewebsites.net`. It should now direct you to a sign-in page. After you sign in, you still can't access the data from the back-end app, because you still need to do three things:
+If you like, navigate to `http://<front_end_app_name>.azurewebsites.net`. It should now direct you to a secured sign-in page. After you sign in, you still can't access the data from the back-end app, because you still need to do three things:
 
 - Grant the front end access to the back end
 - Configure App Service to return a usable token
@@ -318,7 +318,7 @@ git commit -m "add authorization header for server code"
 git push frontend master
 ```
 
-Sign in to `http://<front_end_app_name>.azurewebsites.net` again. At the user data usage agreement page, click **Accept**.
+Sign in to `https://<front_end_app_name>.azurewebsites.net` again. At the user data usage agreement page, click **Accept**.
 
 You should now be able to create, read, update, and delete data from the back-end app as before. The only difference now is that both apps are now secured by App Service authentication and authorization, including the service-to-service calls.
 
@@ -348,7 +348,7 @@ This step is not related to authentication and authorization. However, you need
 
 In the local repository, open _wwwroot/index.html_.
 
-In Line 51, set the `apiEndpoint` variable to the URL of your back-end app (`http://<back_end_app_name>.azurewebsites.net`). Replace _\<back\_end\_app\_name>_ with your app name in App Service.
+In Line 51, set the `apiEndpoint` variable to the URL of your back-end app (`https://<back_end_app_name>.azurewebsites.net`). Replace _\<back\_end\_app\_name>_ with your app name in App Service.
 
 In the local repository, open _wwwroot/app/scripts/todoListSvc.js_ and see that `apiEndpoint` is prepended to all the API calls. Your Angular.js app is now calling the back-end APIs. 
 
@@ -402,7 +402,7 @@ git commit -m "add authorization header for Angular"
 git push frontend master
 ```
 
-Navigate to `http://<front_end_app_name>.azurewebsites.net` again. You should now be able to create, read, update, and delete data from the back-end app, directly in the Angular.js app.
+Navigate to `https://<front_end_app_name>.azurewebsites.net` again. You should now be able to create, read, update, and delete data from the back-end app, directly in the Angular.js app.
 
 Congratulations! Your client code is now accessing the back-end data on behalf of the authenticated user.