Merge pull request #107753 from sharad4u/master

Front Door branding changes to remove service from name and other minor updates

Author: ttorble

articles/firewall/overview.md

@@ -109,7 +109,7 @@ Network filtering rules for non-TCP/UDP protocols (for example ICMP) don't work
 |Azure Firewall SNAT/DNAT doesn't work for private IP destinations|Azure Firewall SNAT/DNAT support is limited to Internet egress/ingress. SNAT/DNAT doesn't currently work for private IP destinations. For example, spoke to spoke.|This is a current limitation.|
 |Can't remove first public IP configuration|Each Azure Firewall public IP address is assigned to an *IP configuration*.  The first IP configuration is assigned during the firewall deployment, and typically also contains a reference to the firewall subnet (unless configured explicitly differently via a template deployment). You can't delete this IP configuration because it would de-allocate the firewall. You can still change or remove the public IP address associated with this IP configuration if the firewall has at least one other public IP address available to use.|This is by design.|
 |Availability zones can only be configured during deployment.|Availability zones can only be configured during deployment. You can't configure Availability Zones after a firewall has been deployed.|This is by design.|
-|SNAT on inbound connections|In addition to DNAT, connections via the firewall public IP address (inbound) are SNATed to one of the firewall private IPs. This requirement today (also for Active/Active NVAs) to ensure symmetric routing.|To preserve the original source for HTTP/S, consider using [XFF](https://en.wikipedia.org/wiki/X-Forwarded-For) headers. For example, use a service such as [Azure Front Door](../frontdoor/front-door-http-headers-protocol.md#front-door-service-to-backend) or [Azure Application Gateway](../application-gateway/rewrite-http-headers.md) in front of the firewall. You can also add WAF as part of Azure Front Door and chain to the firewall.
+|SNAT on inbound connections|In addition to DNAT, connections via the firewall public IP address (inbound) are SNATed to one of the firewall private IPs. This requirement today (also for Active/Active NVAs) to ensure symmetric routing.|To preserve the original source for HTTP/S, consider using [XFF](https://en.wikipedia.org/wiki/X-Forwarded-For) headers. For example, use a service such as [Azure Front Door](../frontdoor/front-door-http-headers-protocol.md#front-door-to-backend) or [Azure Application Gateway](../application-gateway/rewrite-http-headers.md) in front of the firewall. You can also add WAF as part of Azure Front Door and chain to the firewall.
 |SQL FQDN filtering support only in proxy mode (port 1433)|For Azure SQL Database, Azure SQL Data Warehouse, and Azure SQL Managed Instance:<br><br>During the preview, SQL FQDN filtering is supported in proxy-mode only (port 1433).<br><br>For Azure SQL IaaS:<br><br>If you're using non-standard ports, you can specify those ports in the application rules.|For SQL in redirect mode, which is the default if connecting from within Azure, you can instead filter access using the SQL service tag as part of Azure Firewall network rules.
 |Outbound traffic on TCP port 25 isn't allowed| Outbound SMTP connections that use TCP port 25 are blocked. Port 25 is primarily used for unauthenticated email delivery. This is the default platform behavior for virtual machines. For more information, see more [Troubleshoot outbound SMTP connectivity issues in Azure](../virtual-network/troubleshoot-outbound-smtp-connectivity.md). However, unlike virtual machines, it isn't currently possible to enable this functionality on Azure Firewall.|Follow the recommended method to send email as documented in the SMTP troubleshooting article. Or, exclude the virtual machine that needs outbound SMTP access from your default route to the firewall, and instead configure outbound access directly to the Internet.
 |Active FTP isn't supported|Active FTP is disabled on Azure Firewall to protect against FTP bounce attacks using the FTP PORT command.|You can use Passive FTP instead. You must still explicitly open TCP ports 20 and 21 on the firewall.

articles/frontdoor/TOC.yml

@@ -1,8 +1,8 @@
-- name: Front Door Service Documentation
+- name: Front Door Documentation
   href: index.yml
 - name: Overview
   items:
-  - name: What is Azure Front Door Service?
+  - name: What is Azure Front Door?
     href: front-door-overview.md    
 - name: Quickstarts
   expanded: true

articles/frontdoor/front-door-application-security.md

@@ -1,6 +1,6 @@
 ---
-title: Azure Front Door Service - Application layer security | Microsoft Docs
-description: This article helps you understand how Azure Front Door Service enables to protect and secure your application backends
+title: Azure Front Door - Application layer security | Microsoft Docs
+description: This article helps you understand how Azure Front Door enables to protect and secure your application backends
 services: frontdoor
 documentationcenter: ''
 author: sharad4u
@@ -14,7 +14,7 @@ ms.author: sharadag
 ---
 
 # Application layer security with Front Door
-Azure Front Door Service provides web application protection capability to safeguard your web applications from network attacks and common web vulnerabilities exploits like SQL Injection or Cross Site Scripting (XSS). Enabled for http(s) front-ends, Front Door's application layer security is globally distributed and always on, stopping malicious attacks at Azure's network edge, far away from your backends. With added security and performance optimization, Front Door delivers fast and secure web experiences to your end users.
+Azure Front Door provides web application protection capability to safeguard your web applications from network attacks and common web vulnerabilities exploits like SQL Injection or Cross Site Scripting (XSS). Enabled for http(s) front-ends, Front Door's application layer security is globally distributed and always on, stopping malicious attacks at Azure's network edge, far away from your backends. With added security and performance optimization, Front Door delivers fast and secure web experiences to your end users.
 
 ## Application protection
 Front Door's application protection is configured on each edge environment around the globe, in line with applications, and automatically blocks non-http(s) traffic from reaching your web applications. Our multi-tenant distributed architecture enables global protection at scale without sacrificing performance. For http(s) workloads, Front Door's web application protection service provides a rich rules engine for custom rules, pre-configured ruleset against common attacks, and detailed logging for all requests that matches a rule. Flexible actions including allow, block, or log only are supported.

articles/frontdoor/front-door-backend-pool.md

@@ -1,5 +1,5 @@
 ---
-title: Backends and backend pools in Azure Front Door Service | Microsoft Docs
+title: Backends and backend pools in Azure Front Door| Microsoft Docs
 description: This article describes what backends and backend pools are in Front Door configuration.
 services: front-door
 documentationcenter: ''
@@ -13,15 +13,15 @@ ms.date: 09/10/2018
 ms.author: sharadag
 ---
 
-# Backends and backend pools in Azure Front Door Service
-This article describes concepts about how to map your app deployment with Azure Front Door Service. It also explains the different terms in Front Door configuration around app backends.
+# Backends and backend pools in Azure Front Door
+This article describes concepts about how to map your app deployment with Azure Front Door. It also explains the different terms in Front Door configuration around app backends.
 
 ## Backends
-A backend is equal to an app's deployment instance in a region. Front Door Service supports both Azure and non-Azure backends, so the region isn't only restricted to Azure regions. Also, it can be your on-premises datacenter or an app instance in another cloud.
+A backend is equal to an app's deployment instance in a region. Front Door supports both Azure and non-Azure backends, so the region isn't only restricted to Azure regions. Also, it can be your on-premises datacenter or an app instance in another cloud.
 
-Front Door Service backends refer to the host name or public IP of your app, which can serve client requests. Backends shouldn't be confused with your database tier, storage tier, and so on. Backends should be viewed as the public endpoint of your app backend. When you add a backend in a Front Door backend pool, you must also add the following:
+Front Door backends refer to the host name or public IP of your app, which can serve client requests. Backends shouldn't be confused with your database tier, storage tier, and so on. Backends should be viewed as the public endpoint of your app backend. When you add a backend in a Front Door backend pool, you must also add the following:
 
-- **Backend host type**. The type of resource you want to add. Front Door Service supports autodiscovery of your app backends from app service, cloud service, or storage. If you want a different resource in Azure or even a non-Azure backend, select **Custom host**.
+- **Backend host type**. The type of resource you want to add. Front Door supports autodiscovery of your app backends from app service, cloud service, or storage. If you want a different resource in Azure or even a non-Azure backend, select **Custom host**.
 
     >[!IMPORTANT]
     >During configuration, APIs don't validate if the backend is inaccessible from Front Door environments. Make sure that Front Door can reach your backend.
@@ -38,9 +38,9 @@ Front Door Service backends refer to the host name or public IP of your app, whi
 
 Requests forwarded by Front Door to a backend include a host header field that the backend uses to retrieve the targeted resource. The value for this field typically comes from the backend URI and has the host and port.
 
-For example, a request made for www\.contoso.com will have the host header www\.contoso.com. If you use Azure portal to configure your backend, the default value for this field is the host name of the backend. If your backend is contoso-westus.azurewebsites.net, in the Azure portal, the autopopulated value for the backend host header will be contoso-westus.azurewebsites.net. However, if you use Azure Resource Manager templates or another method without explicitly setting this field, Front Door Service will send the incoming host name as the value for the host header. If the request was made for www\.contoso.com, and your backend is contoso-westus.azurewebsites.net that has an empty header field, Front Door Service will set the host header as www\.contoso.com.
+For example, a request made for www.contoso.com will have the host header www.contoso.com. If you use Azure portal to configure your backend, the default value for this field is the host name of the backend. If your backend is contoso-westus.azurewebsites.net, in the Azure portal, the autopopulated value for the backend host header will be contoso-westus.azurewebsites.net. However, if you use Azure Resource Manager templates or another method without explicitly setting this field, Front Door will send the incoming host name as the value for the host header. If the request was made for www\.contoso.com, and your backend is contoso-westus.azurewebsites.net that has an empty header field, Front Door will set the host header as www\.contoso.com.
 
-Most app backends (Azure Web Apps, Blob storage, and Cloud Services) require the host header to match the domain of the backend. However, the frontend host that routes to your backend will use a different hostname such as www\.contoso.azurefd.net.
+Most app backends (Azure Web Apps, Blob storage, and Cloud Services) require the host header to match the domain of the backend. However, the frontend host that routes to your backend will use a different hostname such as www.contoso.net.
 
 If your backend requires the host header to match the backend host name, make sure that the backend host header includes the host name backend.
 
@@ -55,16 +55,16 @@ To configure the **backend host header** field for a backend in the backend pool
 3. Set the backend host header field to a custom value or leave it blank. The hostname for the incoming request will be used as the host header value.
 
 ## Backend pools
-A backend pool in Front Door Service refers to the set of backends that receive similar traffic for their app. In other words, it's a logical grouping of your app instances across the world that receive the same traffic and respond with expected behavior. These backends are deployed across different regions or within the same region. All backends can be in Active/Active deployment mode or what is defined as Active/Passive configuration.
+A backend pool in Front Door refers to the set of backends that receive similar traffic for their app. In other words, it's a logical grouping of your app instances across the world that receive the same traffic and respond with expected behavior. These backends are deployed across different regions or within the same region. All backends can be in Active/Active deployment mode or what is defined as Active/Passive configuration.
 
 A backend pool defines how the different backends should be evaluated via health probes. It also defines how load balancing occurs between them.
 
 ### Health probes
-Front Door Service sends periodic HTTP/HTTPS probe requests to each of your configured backends. Probe requests determine the proximity and health of each backend to load balance your end-user requests. Health probe settings for a backend pool define how we poll the health status of app backends. The following settings are available for load-balancing configuration:
+Front Door sends periodic HTTP/HTTPS probe requests to each of your configured backends. Probe requests determine the proximity and health of each backend to load balance your end-user requests. Health probe settings for a backend pool define how we poll the health status of app backends. The following settings are available for load-balancing configuration:
 
-- **Path**. The URL used for probe requests for all the backends in the backend pool. For example, if one of your backends is contoso-westus.azurewebsites.net and the path is set to /probe/test.aspx, then Front Door Service environments, assuming the protocol is set to HTTP, will send health probe requests to http\://contoso-westus.azurewebsites.net/probe/test.aspx.
+- **Path**. The URL used for probe requests for all the backends in the backend pool. For example, if one of your backends is contoso-westus.azurewebsites.net and the path is set to /probe/test.aspx, then Front Door environments, assuming the protocol is set to HTTP, will send health probe requests to http\://contoso-westus.azurewebsites.net/probe/test.aspx.
 
-- **Protocol**. Defines whether to send the health probe requests from Front Door Service to your backends with HTTP or HTTPS protocol.
+- **Protocol**. Defines whether to send the health probe requests from Front Door to your backends with HTTP or HTTPS protocol.
 
 - **Interval (seconds)**. Defines the frequency of health probes to your backends, or the intervals in which each of the Front Door environments sends a probe.
 

articles/frontdoor/front-door-caching.md

@@ -1,6 +1,6 @@
 ---
-title: Azure Front Door Service - caching | Microsoft Docs
-description: This article helps you understand how Azure Front Door Service monitors the health of your backends
+title: Azure Front Door - caching | Microsoft Docs
+description: This article helps you understand how Azure Front Door monitors the health of your backends
 services: frontdoor
 documentationcenter: ''
 author: sharad4u
@@ -13,11 +13,11 @@ ms.date: 09/10/2018
 ms.author: sharadag
 ---
 
-# Caching with Azure Front Door Service
+# Caching with Azure Front Door
 The following document specifies behavior for Front Door with routing rules that have enabled caching.
 
 ## Delivery of large files
-Azure Front Door Service delivers large files without a cap on file size. Front Door uses a technique called object chunking. When a large file is requested, Front Door retrieves smaller pieces of the file from the backend. After receiving a full or byte-range file request, a Front Door environment requests the file from the backend in chunks of 8 MB.
+Azure Front Door delivers large files without a cap on file size. Front Door uses a technique called object chunking. When a large file is requested, Front Door retrieves smaller pieces of the file from the backend. After receiving a full or byte-range file request, a Front Door environment requests the file from the backend in chunks of 8 MB.
 
 </br>After the chunk arrives at the Front Door environment, it is cached and immediately served to the user. Front Door then pre-fetches the next chunk in parallel. This pre-fetch ensures that the content stays one chunk ahead of the user, which reduces latency. This process continues until the entire file is downloaded (if requested), all byte ranges are available (if requested), or the client terminates the connection.
 
@@ -87,8 +87,8 @@ Front Door will cache assets until the asset's time-to-live (TTL) expires. After
 </br>The best practice to make sure your users always obtain the latest copy of your assets is to version your assets for each update and publish them as new URLs. Front Door will immediately retrieve the new assets for the next client requests. Sometimes you may wish to purge cached content from all edge nodes and force them all to retrieve new updated assets. This might be due to updates to your web application, or to quickly update assets that contain incorrect information.
 
 </br>Select what assets you wish to purge from the edge nodes. If you wish to clear all assets, click the Purge all checkbox. Otherwise, type the path of each asset you wish to purge in the Path textbox. Below formats are supported in the path.
-1. **Single URL purge**: Purge individual asset by specifying the full URL, with the file extension, for example, /pictures/strasbourg.png;
-2. **Wildcard purge**: Asterisk (\*) may be used as a wildcard. Purge all folders, subfolders and files under an endpoint with /\* in the path or purge all subfolders and files under a specific folder by specifying the folder followed by /\*, for example, /pictures/\*.
+1. **Single path purge**: Purge individual asset(s) by specifying the full path of the asset (without the protocol and domain), with the file extension, for example, /pictures/strasbourg.png;
+2. **Wildcard purge**: Asterisk (\*) may be used as a wildcard. Purge all folders, subfolders, and files under an endpoint with /\* in the path or purge all subfolders and files under a specific folder by specifying the folder followed by /\*, for example, /pictures/\*.
 3. **Root domain purge**: Purge the root of the endpoint with "/" in the path.
 
 Cache purges on the Front Door are case-insensitive. Additionally, they are query string agnostic, meaning purging a URL will purge all query-string variations of it. 
@@ -101,11 +101,9 @@ The following order of headers is used in order to determine how long an item wi
 
 Cache-Control response headers that indicate that the response won’t be cached such as Cache-Control: private, Cache-Control: no-cache, and Cache-Control: no-store are honored. However, if there are multiple requests in-flight at a POP for the same URL, they may share the response. If no Cache-Control is present the default behavior is that AFD will cache the resource for X amount of time where X is randomly picked between 1 to 3 days.
 
-
 ## Request headers
 
 The following request headers will not be forwarded to a backend when using caching.
-- Authorization
 - Content-Length
 - Transfer-Encoding