Merge pull request #105106 from surajmb/patch-15

Updating the date and links

Author: PRMerger8

articles/application-gateway/configuration-overview.md

@@ -252,14 +252,14 @@ Azure Application Gateway uses gateway managed cookies for maintaining user sess
 
 This feature is useful when you want to keep a user session on the same server and when session state is saved locally on the server for a user session. If the application can't handle cookie-based affinity, you can't use this feature. To use it, make sure that the clients support cookies.
 
-Starting from **17th February 2020**, the [Chromium](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) brings a mandate where HTTP cookies without SameSite attribute to be treated as SameSite=Lax. In case of CORS (Cross-Origin Resource Sharing) requests, if the cookie has to be sent in a third-party context, it has to use “SameSite=None; Secure” attributes and it should be sent over HTTPS only. Otherwise, in a HTTP only scenario, the browser won’t send the cookies in the third-party context. The goal of this update from Chrome is to enhance security and to avoid Cross-Site Request Forgery (CSRF) attacks. 
+The [Chromium browser](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) brought a mandate where HTTP cookies without [SameSite](https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-03.html#rfc.section.5.3.7) attribute has to be treated as SameSite=Lax. In the case of CORS (Cross-Origin Resource Sharing) requests, if the cookie has to be sent in a third-party context, it has to use *SameSite=None; Secure* attributes and it should be sent over HTTPS only. Otherwise, in a HTTP only scenario, the browser doesn't send the cookies in the third-party context. The goal of this update from Chrome is to enhance security and to avoid Cross-Site Request Forgery (CSRF) attacks. 
 
-To support this change, Application Gateway (all the SKU types) will be injecting another identical cookie called **ApplicationGatewayAffinityCORS** in addition to the existing **ApplicationGatewayAffinity** cookie, which is similar, but this cookie will now have two more attributes **"SameSite=None; Secure"** added to it so that sticky session can be maintained even for cross-origin requests.
+To support this change, starting February 17th 2020, Application Gateway (all the SKU types) will inject another cookie called *ApplicationGatewayAffinityCORS* in addition to the existing *ApplicationGatewayAffinity* cookie. The *ApplicationGatewayAffinityCORS* cookie has two more attributes added to it (*"SameSite=None; Secure"*) so that sticky session are maintained even for cross-origin requests.
 
-Please note that the default affinity cookie name is **ApplicationGatewayAffinity** and this can be changed by the users. In case you are using a custom affinity cookie name, an additional cookie will be added with CORS as suffix, for example, **CustomCookieNameCORS**.
+Note that the default affinity cookie name is *ApplicationGatewayAffinity* and you can change it. In case you are using a custom affinity cookie name, an additional cookie is added with CORS as suffix. For example, *CustomCookieNameCORS*.
 
 > [!NOTE]
-> It is mandatory that if the attribute **SameSite=None** is set, the cookie also should contain the **Secure** flag and should be sent over **HTTPS**. So if session affinity is required over CORS, you must migrate your workload to HTTPS. 
+> If the attribute *SameSite=None* is set, it is mandatory that the cookie also contains the *Secure* flag, and must be sent over HTTPS.  If session affinity is required over CORS, you must migrate your workload to HTTPS. 
 Please refer to SSL offload and End-to-End SSL documentation for Application Gateway here – [Overview](ssl-overview.md), [How-to configure SSL offload](create-ssl-portal.md), [How-to configure End-to-End SSL](end-to-end-ssl-portal.md).
 
 ### Connection draining