Merge pull request #52911 from MicrosoftDocs/release-ignite-frontdoor

Ignite Merge Down

Author: Cory Fowler

articles/azure-subscription-service-limits.md

@@ -66,6 +66,7 @@ In the limits below, a new table has been added to reflect any differences in li
 * [DNS](#dns-limits)
 * [Event Hubs](#event-hubs-limits)
 * [Azure Firewall](#azure-firewall-limits)
+* [Front Door](#azure-front-door-service-limits)
 * [IoT Hub](#iot-hub-limits)
 * [IoT Hub Device Provisioning Service](#iot-hub-device-provisioning-service-limits)
 * [Key Vault](#key-vault-limits)
@@ -152,6 +153,9 @@ The following table details the features and limits of the Basic, Standard, and
 #### Azure Firewall limits
 [!INCLUDE [azure-firewall-limits](../includes/firewall-limits.md)]
 
+#### Azure Front Door Service limits
+[!INCLUDE [azure-front-door-service-limits](../includes/front-door-limits.md)]
+
 ### Storage limits
 <!--like # storage accts -->
 [!INCLUDE [azure-storage-limits](../includes/azure-storage-limits.md)]

articles/frontdoor/TOC.yml

@@ -0,0 +1,55 @@
+- name: Front Door Service Documentation
+  href: index.yml
+- name: Overview
+  items:
+  - name: What is Azure Front Door Service?
+    href: front-door-overview.md    
+- name: Quickstarts
+  items:
+  - name: Create a Front Door
+    href: quickstart-create-front-door.md
+- name: Tutorials
+  items:
+  - name: Add a custom domain to your Front Door
+    href: front-door-custom-domain.md
+- name: Samples
+  items:
+  - name: Resource Manager Templates
+    href: front-door-quickstart-template-samples.md
+- name: Concepts
+  items:
+  - name: Backends and backend pools
+    href: front-door-backend-pool.md
+  - name: DDoS protection and application layer security
+    href: front-door-ddos-security.md
+  - name: Load-balancing with Azure’s application delivery suite
+    href: front-door-lb-with-azure-app-delivery-suite.md
+  - name: Routing architecture
+    href: front-door-routing-architecture.md
+  - name: Traffic routing methods
+    href: front-door-routing-methods.md
+  - name: How Front Door matches routing for a request
+    href: front-door-route-matching.md
+  - name: Health probes
+    href: front-door-health-probes.md
+  - name: URL rewrite
+    href: front-door-url-rewrite.md
+  - name: Caching with Front Door
+    href: front-door-caching.md
+  - name: HTTP/2 support
+    href: front-door-http2.md
+  - name: HTTP headers protocol support
+    href: front-door-http-headers-protocol.md
+  - name: Monitoring
+    href: front-door-diagnostics.md
+- name: Resources
+  items:
+  - name: Azure Roadmap
+    href: https://azure.microsoft.com/roadmap/
+  - name: Pricing
+    href: https://azure.microsoft.com/pricing/details/frontdoor/
+  - name: Pricing calculator
+    href: https://azure.microsoft.com/pricing/calculator/
+  - name: Service updates
+    href: https://azure.microsoft.com/updates/?product=frontdoor
+

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

@@ -0,0 +1,74 @@
+---
+title: Azure Front Door Service - Backends and Backend Pools | Microsoft Docs
+description: This article helps you understand what are backend and backend pools for in Front Door configuration.
+services: front-door
+documentationcenter: ''
+author: sharad4u
+ms.service: frontdoor
+ms.devlang: na
+ms.topic: article
+ms.tgt_pltfrm: na
+ms.workload: infrastructure-services
+ms.date: 09/10/2018
+ms.author: sharadag
+---
+
+# Backends and backend pools in Azure Front Door Service
+This article explains the different concepts regarding how you can map your application deployment with Front Door. We will also explain you what the different terms in Front Door configuration around application backend mean.
+
+## Backend pool
+A backend pool in Front Door refers to the set of equivalent backends that can receive the same type of traffic for their application. In other words, it is a logical grouping of your application instances throughout the world that can receive the same traffic and can respond with the expected behavior. These backends are usually deployed across different regions or within the same region. Additionally, these backends can all be in Active-Active deployment mode or otherwise could be defined as an Active/Passive configuration.
+
+Backend pool also defines how the different backends should all be evaluated for their health via health probes and correspondingly how the load balancing between the backends should happen.
+
+### Health probes
+Front Door sends periodic HTTP/HTTPS probe requests to each of your configured backends to 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 for the health status for your application backends. The following settings are available for configuration for load balancing:
+
+1. **Path**: URL path where the probe requests will be sent to 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 protocol is set to HTTP, will send the health probe requests to http://contoso-westus.azurewebsites.net/probe/test.aspx. 
+2. **Protocol**: Defines whether the health probe requests from Front Door to your backends will be sent over HTTP or HTTPS protocol.
+3. **Interval (seconds)**: This field defines the frequency of health probes to your backends, that is, the intervals in which each of the Front Door environments will send a probe. Note - if you are looking for faster failovers, then set this field to a lower value. However, the lower the value more the health probe volume that your backends will receive. To get an idea of how much probe volume Front Door will generate on your backends, let's take an example. Let's say, the interval is set to 30 seconds and there are about 90 Front Door environments or POPs globally. So, each of your backends will approximately receive about 3-5 probe requests per second.
+
+Read [health probes](front-door-health-probes.md) for details.
+
+### Load balancing settings
+The load balancing settings for the backend pool define how we evaluate the health probes for deciding the backend to be healthy or unhealthy and also how we need to load balance the traffic between the different backends in the backend pool. The following settings are available for configuration for load balancing:
+
+1. **Sample size**: This property identifies how many samples of health probes we need to consider for backend health evaluation.
+2. **Successful sample size**: This property defines that of the 'sample size' as explained above, how many samples do we need to check for success to call the backend as healthy. 
+</br>For example, let's say for your Front Door you have set the health probe *interval* to 30 seconds, *sample size* is set to '5' and *successful sample size* is set to '3'. Then what this configuration means is that every time we evaluate the health probes for your backend, we will look at the last five samples, which would be spanning last 150 seconds (=5*30 s) and unless there are 3 or more of these probes successful we will declare the backend unhealthy. Let's say there were only two successful probes and, so we will mark the backend as unhealthy. The next time we run the evaluation if we find 3 successful in the last five probes, then we mark the backend as healthy again.
+3. **Latency sensitivity (additional latency)**: The latency sensitivity field defines whether you want Front Door to send the request to backends that are within the sensitivity range in terms of latency measurement or forwarding the request to the closest backend. Read [least latency based routing method](front-door-routing-methods.md#latency) for Front Door to learn more.
+
+## Backend
+A backend is equivalent to an application's deployment instance in a region. Front Door supports both Azure as well as non-Azure backends and so the region here isn't only restricted to Azure regions but can also be your on-premise datacenter or an application instance in some other cloud.
+
+Backends, in the context of Front Doors, refers to the host name or public IP of your application, which can serve client requests. So, backends should not be confused with your database tier or your storage tier etc. but rather should be viewed as the public endpoint of your application backend.
+
+When you add a backend in a backend pool of your Front Door, you will need to fill in the following details:
+
+1. **Backend host type**: The type of resource you want to add. Front Door supports auto-discovery of your application backends if from app service, cloud service, or storage. If you want a different resource in Azure or even a non-Azure backend, select 'Custom host'. Note - During configuration, the APIs do not validate whether the backend is accessible from Front Door environments, instead you need to ensure that your backend can be reached by Front Door. 
+2. **Subscription and Backend host name**: If you have not selected 'Custom host' for backend host type, then you need to scope down and select your backend by choosing the appropriate subscription and the corresponding backend host name from the user interface.
+3. **Backend host header**: The Host header value sent to the backend for each request. Read [backend host header](#hostheader) for details.
+4. **Priority**: You can assign priorities to your different backends when you want to use a primary service backend for all traffic, and provide backups in case the primary or the backup backends are unavailable. Read more about [priority](front-door-routing-methods.md#priority).
+5. **Weight**: You can assign weights to your different backends when you want to distribute traffic across a set of backends, either evenly or according to weight coefficients. Read more about [weights](front-door-routing-methods.md#weighted).
+
+
+### <a name = "hostheader"></a>Backend host header
+
+Requests forwarded by Front Door to a backend have 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 are configuring your backend using Azure portal, then the default value that gets populated for this field is the host name of the backend. For example, if your backend is `contoso-westus.azurewebsites.net`, then in the Azure portal the auto-populated value for backend host header will be `contoso-westus.azurewebsites.net`. 
+</br>However, if you are using Resource Manager templates or other mechanism and you are not setting this field explicitly then Front Door sends the incoming host name as the value for Host header. For example, if the request was made for `www.contoso.com`, and your backend is `contoso-westus.azurewebsites.net` with the backend host header field as empty, then Front Door will set the Host header as `www.contoso.com`.
+
+Most application backends (such as 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 have a different hostname like www.contoso.azurefd.net. If the backend you are setting up requires the Host header to match the host name of the backend, you should ensure that the 'Backend host header’ also has the host name of the backend.
+
+#### Configuring the backend host header for the backend
+The ‘Backend host header’ field can be configured for a backend in the backend pool section.
+
+1. Open your Front Door resource and click on the backend pool that has the backend to be configured.
+
+2. Add a backend if you have not added any, or edit an existing one. The 'Backend host header' field can be set to a custom value or left blank, which means that the hostname for the incoming request will be used as the Host header value.
+
+
+
+## Next steps
+
+- Learn how to [create a Front Door](quickstart-create-front-door.md).
+- Learn [how Front Door works](front-door-routing-architecture.md).

articles/frontdoor/front-door-caching.md

@@ -0,0 +1,115 @@
+---
+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
+services: frontdoor
+documentationcenter: ''
+author: sharad4u
+ms.service: frontdoor
+ms.devlang: na
+ms.topic: article
+ms.tgt_pltfrm: na
+ms.workload: infrastructure-services
+ms.date: 09/10/2018
+ms.author: sharadag
+---
+
+# Caching with Azure Front Door Service
+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.
+
+</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.
+
+</br>For more information on the byte-range request, read [RFC 7233](http://www.rfc-base.org/rfc-7233.html).
+Front Door caches any chunks as they're received and so the entire file doesn't need to be cached on the Front Door cache. Subsequent requests for the file or byte ranges are served from the cache. If not all the chunks are cached, pre-fetching is used to request chunks from the backend. This optimization relies on the ability of the backend to support byte-range requests; if the backend doesn't support byte-range requests, this optimization isn't effective.
+
+## File compression
+Front Door can dynamically compress content on the edge, resulting in a smaller and faster response to your clients. All files are eligible for compression. However, a file must be of a MIME type that eligible for compression list. Currently, Front Door does not allow this list to be changed. The current list is:</br>
+- "application/eot"
+- "application/font"
+- "application/font-sfnt"
+- "application/javascript"
+- "application/json"
+- "application/opentype"
+- "application/otf"
+- "application/pkcs7-mime"
+- "application/truetype"
+- "application/ttf",
+- "application/vnd.ms-fontobject"
+- "application/xhtml+xml"
+- "application/xml"
+- "application/xml+rss"
+- "application/x-font-opentype"
+- "application/x-font-truetype"
+- "application/x-font-ttf"
+- "application/x-httpd-cgi"
+- "application/x-mpegurl"
+- "application/x-opentype"
+- "application/x-otf"
+- "application/x-perl"
+- "application/x-ttf"
+- "application/x-javascript"
+- "font/eot"
+- "font/ttf"
+- "font/otf"
+- "font/opentype"
+- "image/svg+xml"
+- "text/css"
+- "text/csv"
+- "text/html"
+- "text/javascript"
+- "text/js", "text/plain"
+- "text/richtext"
+- "text/tab-separated-values"
+- "text/xml"
+- "text/x-script"
+- "text/x-component"
+- "text/x-java-source"
+
+Additionally, the file must also be between 1 KB and 8 MB in size, inclusive.
+
+These profiles support the following compression encodings:
+- [Gzip (GNU zip)](https://en.wikipedia.org/wiki/Gzip)
+- [Brotli](https://en.wikipedia.org/wiki/Brotli)
+
+If a request supports gzip and Brotli compression, Brotli compression takes precedence.</br>
+When a request for an asset specifies compression and the request results in a cache miss, Front Door performs compression of the asset directly on the POP server. Afterward, the compressed file is served from the cache. The resulting item is returned with a transfer-encoding: chunked.
+
+## Query string behavior
+With Front Door, you can control how files are cached for a web request that contains a query string. In a web request with a query string, the query string is that portion of the request that occurs after a question mark (?). A query string can contain one or more key-value pairs, in which the field name and its value are separated by an equals sign (=). Each key-value pair is separated by an ampersand (&). For example, http://www.contoso.com/content.mov?field1=value1&field2=value2. If there is more than one key-value pair in a query string of a request, their order does not matter.
+- **Ignore query strings**: Default mode. In this mode, Front Door passes the query strings from the requestor to the backend on the first request and caches the asset. All subsequent requests for the asset that are served from the Front Door environment ignore the query strings until the cached asset expires.
+
+- **Cache every unique URL**: In this mode, each request with a unique URL, including the query string, is treated as a unique asset with its own cache. For example, the response from the backend for a request for `www.example.ashx?q=test1` is cached at the Front Door environment and returned for subsequent caches with the same query string. A request for `www.example.ashx?q=test2` is cached as a separate asset with its own time-to-live setting.
+
+## Cache purge
+Front Door will cache assets until the asset's time-to-live (TTL) expires. After the asset's TTL expires, when a client requests the asset, the Front Door environment will retrieve a new updated copy of the asset to serve the client request and store refresh the cache.
+</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/\*.
+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. 
+
+## Cache expiration
+The following order of headers is used in order to determine how long an item will be stored in our cache:</br>
+1. Cache-Control: s-maxage=<seconds>
+2. Cache-Control: maxage=<seconds>
+3. Expires: <http-date>
+
+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.
+
+
+## Request headers
+
+The following request headers will not be forwarded to a backend when using caching.
+- Authorization
+- Content-Length
+- Transfer-Encoding
+
+## Next steps
+
+- Learn how to [create a Front Door](quickstart-create-front-door.md).
+- Learn [how Front Door works](front-door-routing-architecture.md).