fix uodate 21r2 link

docs/Notes/updates.md

@@ -5,7 +5,7 @@ title: Release Notes
 
 ## 4D 21 R2
 
-Read [**What’s new in 4D 21 R2**](https://blog.4d.com/en-whats-new-in-4d-21-r2/), the blog post that lists all new features and enhancements in 4D 21 R2.
+Read [**What’s new in 4D 21 R2**](https://blog.4d.com/whats-new-in-4d-21-r2/), the blog post that lists all new features and enhancements in 4D 21 R2.
 
 #### Highlights
 

docs/WebServer/http-request-handler.md

@@ -28,10 +28,12 @@ Custom HTTP Request handlers are supported in the following context:
 
 Since HTTP Request handler functions are called from standard web requests (they do not contain `/rest/xxx` pattern like REST requests), they are not subject to the [**Force login**](../REST/authUsers.md#force-login-mode) rules. It means that they can be executed without prior authentication, i.e. without a call to [`setPrivileges()`](../API/SessionClass.md#setprivileges) on the session, in which case they will be executed in a *guest* session. 
 
-However, these functions need to have appropriate **permissions**, like all requests executed from web processes. When the handler function is called, the **privileges** of its web session must allow the code to run properly. Any other resources accessed within the code (data, other functions...) also need to be allowed by permissions. In [*restricted mode by default*](../ORDA/privileges.md#restriction-modes), you must configure the privileges:
+However, these functions need to have appropriate **permissions**, like all requests executed from web processes. When the handler function is called, the **privileges** of its web session must allow the code to run properly. Any other resources accessed within the code (data, other functions...) also need to be allowed by permissions. 
 
-- If a HTTP Request handler can open a new, unauthenticated session (which is the case for example when your application provides **deep linking** feature), you need to make sure that the *guest* privilege is allowed to execute the handler function and access all subsequent resources. 
-- If a HTTP Request handler function can be executed within an already authenticated session, you need to make sure the user session is allowed to execute the handler function and access all subsequent resources. Note that this can also happen with deep linking if you copy/paste the link into a browser where you are already authenticated for the application and the session is still active (provided that the 4D session cookie is *Lax*).
+In [*restricted mode by default*](../ORDA/privileges.md#restriction-modes), if a HTTP Request handler can open a new, unauthenticated session (which is the case for example when your application provides **deep linking** feature), you need to make sure that the *guest* privilege is allowed to execute the handler function and access all subsequent resources. 
+
+
+If a HTTP Request handler function can be executed within an already authenticated session, you need to make sure the user session is allowed to execute the handler function and access all subsequent resources. Note that this can also happen with deep linking if you copy/paste the link into a browser where you are already authenticated for the application and the session is still active.
 
 
 ## How to set handlers 

versioned_docs/version-21-R2/Notes/updates.md

@@ -5,7 +5,7 @@ title: Release Notes
 
 ## 4D 21 R2
 
-Read [**What’s new in 4D 21 R2**](https://blog.4d.com/en-whats-new-in-4d-21-r2/), the blog post that lists all new features and enhancements in 4D 21 R2.
+Read [**What’s new in 4D 21 R2**](https://blog.4d.com/whats-new-in-4d-21-r2/), the blog post that lists all new features and enhancements in 4D 21 R2.
 
 #### Highlights
 

versioned_docs/version-21-R2/WebServer/http-request-handler.md

@@ -28,10 +28,12 @@ Custom HTTP Request handlers are supported in the following context:
 
 Since HTTP Request handler functions are called from standard web requests (they do not contain `/rest/xxx` pattern like REST requests), they are not subject to the [**Force login**](../REST/authUsers.md#force-login-mode) rules. It means that they can be executed without prior authentication, i.e. without a call to [`setPrivileges()`](../API/SessionClass.md#setprivileges) on the session, in which case they will be executed in a *guest* session. 
 
-However, these functions need to have appropriate **permissions**, like all requests executed from web processes. When the handler function is called, the **privileges** of its web session must allow the code to run properly. Any other resources accessed within the code (data, other functions...) also need to be allowed by permissions. In [*restricted mode by default*](../ORDA/privileges.md#restriction-modes), you must configure the privileges:
+However, these functions need to have appropriate **permissions**, like all requests executed from web processes. When the handler function is called, the **privileges** of its web session must allow the code to run properly. Any other resources accessed within the code (data, other functions...) also need to be allowed by permissions. 
 
-- If a HTTP Request handler can open a new, unauthenticated session (which is the case for example when your application provides **deep linking** feature), you need to make sure that the *guest* privilege is allowed to execute the handler function and access all subsequent resources. 
-- If a HTTP Request handler function can be executed within an already authenticated session, you need to make sure the user session is allowed to execute the handler function and access all subsequent resources. Note that this can also happen with deep linking if you copy/paste the link into a browser where you are already authenticated for the application and the session is still active (provided that the 4D session cookie is *Lax*).
+In [*restricted mode by default*](../ORDA/privileges.md#restriction-modes), if a HTTP Request handler can open a new, unauthenticated session (which is the case for example when your application provides **deep linking** feature), you need to make sure that the *guest* privilege is allowed to execute the handler function and access all subsequent resources. 
+
+
+If a HTTP Request handler function can be executed within an already authenticated session, you need to make sure the user session is allowed to execute the handler function and access all subsequent resources. Note that this can also happen with deep linking if you copy/paste the link into a browser where you are already authenticated for the application and the session is still active.
 
 
 ## How to set handlers 

versioned_docs/version-21/WebServer/http-request-handler.md

@@ -28,10 +28,12 @@ Custom HTTP Request handlers are supported in the following context:
 
 Since HTTP Request handler functions are called from standard web requests (they do not contain `/rest/xxx` pattern like REST requests), they are not subject to the [**Force login**](../REST/authUsers.md#force-login-mode) rules. It means that they can be executed without prior authentication, i.e. without a call to [`setPrivileges()`](../API/SessionClass.md#setprivileges) on the session, in which case they will be executed in a *guest* session. 
 
-However, these functions need to have appropriate **permissions**, like all requests executed from web processes. When the handler function is called, the **privileges** of its web session must allow the code to run properly. Any other resources accessed within the code (data, other functions...) also need to be allowed by permissions. In [*restricted mode by default*](../ORDA/privileges.md#restriction-modes), you must configure the privileges:
+However, these functions need to have appropriate **permissions**, like all requests executed from web processes. When the handler function is called, the **privileges** of its web session must allow the code to run properly. Any other resources accessed within the code (data, other functions...) also need to be allowed by permissions. 
 
-- If a HTTP Request handler can open a new, unauthenticated session (which is the case for example when your application provides **deep linking** feature), you need to make sure that the *guest* privilege is allowed to execute the handler function and access all subsequent resources. 
-- If a HTTP Request handler function can be executed within an already authenticated session, you need to make sure the user session is allowed to execute the handler function and access all subsequent resources. Note that this can also happen with deep linking if you copy/paste the link into a browser where you are already authenticated for the application and the session is still active (provided that the 4D session cookie is *Lax*).
+In [*restricted mode by default*](../ORDA/privileges.md#restriction-modes), if a HTTP Request handler can open a new, unauthenticated session (which is the case for example when your application provides **deep linking** feature), you need to make sure that the *guest* privilege is allowed to execute the handler function and access all subsequent resources. 
+
+
+If a HTTP Request handler function can be executed within an already authenticated session, you need to make sure the user session is allowed to execute the handler function and access all subsequent resources. Note that this can also happen with deep linking if you copy/paste the link into a browser where you are already authenticated for the application and the session is still active.
 
 
 ## How to set handlers