You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -29,11 +29,11 @@ Each ACL in the list has a number to show its **priority**. All traffic arrivin
29
29
30
30
Each ACL has an **action**: `Allow`, `Deny` or `Redirect`, which it applies **conditionally** or **unconditionally**. A conditional ACL only applies its action to traffic it encounters which matches the configured condition. An unconditional ACL applies its action to all traffic it encounters. For more information on conditions, see [the next section of this document](/#what-conditions-can-be-set-for-acls).
31
31
32
-
Once an ACL applies its action - either because it is unconditional or because the traffic matched the condition - that action is carried out immediately. That is to say, the traffic is allowed to pass to the backend, or definitively denied access to the backend, or redirected. **That traffic is not filtered by any ACLs further down the list of priority**. It is therefore important to construct a list of ACLs carefully, placing conditional ACLs before unconditional ones in the list of priority and constructing conditions with attention.
32
+
Once an ACL applies its action - either because it is unconditional or because the traffic matched the condition - that action is carried out immediately. That is to say, the traffic is allowed to pass to the backend, or definitively denied access to the backend, or redirected. **That traffic is not filtered by any ACLs further down the list of priority**. It is therefore important to construct a list of ACLs carefully, placing conditional ACLs before unconditional ones in the list of priority, and constructing conditions with attention.
33
33
34
34
Note that constructing an ACL with a conditional `Allow` action does not mean that same ACL will therefore carry out a `Deny` action on traffic which does not meet its conditions. **The unmatched traffic will simply pass to the next ACL in the list**.
35
35
36
-
If traffic reaches the end of the list of ACLs without any actions being applied to it, it is allowed to pass to the backend. If you want to avoid this, create an unconditional `Deny`ACL and place it at the end of your list of conditional `Allow` ACLs.
36
+
If traffic reaches the end of the list of ACLs without any actions being applied to it, it is allowed to pass to the backend. If you want to avoid this, create an unconditional `Deny` ACL and place it at the end of your list of conditional `Allow` ACLs.
Copy file name to clipboardExpand all lines: network/load-balancer/reference-content/sni-route-deprecation.mdx
+13-46Lines changed: 13 additions & 46 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,31 +13,19 @@ categories:
13
13
- network
14
14
---
15
15
16
-
## What is being deprecated
16
+
This page documents the deprecation of SNI routes with HTTP backends on Scaleway Load Balancers
17
17
18
-
We are removing the ability to create SNI based [routes](/network/load-balancer/how-to/create-manage-routes/) to HTTP backends in Scaleway Load Balancer:
18
+
We removed the ability to create SNI based [routes](/network/load-balancer/how-to/create-manage-routes/) to HTTP backends in Scaleway Load Balancer. This feature was deprecated on March 1st 2023, and removed on June 1st 2023.
19
19
20
20
- SNI routes are still available and supported for TCP backends.
21
-
- For HTTP backends, SNI routes are replaced with the new **HTTP Host header**-based routes.
21
+
- SNI routes with HTTP backends are no longer be available.
22
+
- SNI routes to an HTTP backend were automatically converted to new **HTTP Host header**-based routes.
22
23
23
-
## Deprecation planning
24
-
25
-
SNI routes with HTTP backends are **deprecated** from March 1st 2023. This means:
26
-
27
-
- The feature will no longer be available via the Scaleway console: it will be impossible to create an SNI route to an HTTP backend.
28
-
- The feature will still be available via the Scaleway API, CLI and Terraform interfaces. This is to avoid breaking changes with configuration automation tools.
29
-
- The feature is still supported.
30
-
31
-
SNI routes with HTTP backends are **removed** on June 1st 2023. This means:
32
-
33
-
- The feature will no longer be available via the Scaleway console, nor from the API, CLI or Terraform interfaces.
34
-
- Any existing and remaining SNI routes to an HTTP backend will be automatically converted to HTTP Host header routes.
35
-
36
-
## Why are we deprecating this feature?
24
+
## Why did we deprecate this feature?
37
25
38
26
SNI routes were originally introduced to enable routing with TCP backends when connections were encrypted with TLS. This enabled the forwarding of traffic to different backend server pools based on the "host" the client wanted to connect to.
39
27
40
-
Since HTTPS relies on TLS, this feature also worked with HTTP backends, providing the SNI closely matched the HTTP Host header value. The problem came when clients started establishing long-living connections and connection reuse, which frequently happened with newer HTTP versions such as HTTP/2. SNI is only sent when initiating the TCP connection to the host (in our case, the Load Balancer). This is the moment when we identify the backend we need to forward the traffic to. As long as the TCP connection to the Load Balancer remains open, the SNI is not sent again and all subsequent requests will then follow the route that was established when the connection was initiated.
28
+
Since HTTPS relies on TLS, this feature also worked with HTTP backends, providing the SNI closely matched the HTTP Host header value. But with newer HTTP versions such as HTTP/2, clients started establishing long-living connections and connection reuse, which frequently happened with newer HTTP versions such as HTTP/2. SNI is only sent when initiating the TCP connection to the host (in our case, the Load Balancer). This is the moment when we identify the backend we need to forward the traffic to. As long as the TCP connection to the Load Balancer remains open, the SNI is not sent again and all subsequent requests will then follow the route that was established when the connection was initiated.
41
29
42
30
While this proves to be efficient since it avoids all the overhead related to TCP and TLS handshakes, it can be a problem when a client reuses the connection to send requests to a different host resolving to the same IP address. With the Load Balancer being a reverse proxy, this happens frequently. In such cases, the SNI (for the new host) is not sent again since the connection to the Load Balancer is already established, and the request gets forwarded to the original host based on the original SNI. This results in a request which arrives at a backend server that doesn't know how to process it.
43
31
@@ -55,30 +43,13 @@ See the console screenshots below as examples:
55
43
56
44
<Lightboxsrc="scaleway-http-route.webp"alt="" />
57
45
58
-
## What is the impact?
46
+
## What was the impact?
59
47
60
-
We do not expect this change to have an impact on your applications or services using Scaleway Load Balancer, since HTTP Host header routes will provide more accurate routing than SNI with HTTP backends.
61
-
62
-
## Migration
63
-
64
-
You can expect the following in terms of migration:
65
-
66
-
### Before June 1st 2023
67
-
- No change to your Load Balancers and how they work, if you do not interact with them or change their configuration
68
-
- If you are creating new routes from the Scaleway console, you will not be able to create SNI routes with HTTP backend
69
-
- If you are editing a pre-existing SNI route to an HTTP backend from the console, the console will automatically convert it to an HTTP Host header route. You will not be able to change it back to an SNI route any more.
70
-
- If you are creating or editing routes from the API, the CLI or the Terraform interface, you will still be able to create SNI routes to HTTP backends along with HTTP host header routes. There will not be any breaking change
71
-
72
-
### From June 1st 2023
73
-
- Scaleway will automatically convert all SNI routes to HTTP backends into HTTP Host header routes to these backends, with the same value for the HTTP Host header as the SNI. This will be applied to your Load Balancer the next time you interact with its configuration.
74
-
- You will not see any SNI routes on HTTP backends in the Scaleway console anymore. All such routes will be converted automatically on June 1st.
75
-
- You will only be able to create HTTP Host header routes (not SNI) to HTTP backends in the console.
76
-
- You will only be able to create HTTP Host header routes (not SNI) to HTTP backends via the API, the CLI or the Terraform interface.
77
-
- If your configuration automation system uses the API, the CLI or the Terraform provider to send configurations containing SNI routes to HTTP backends, it will receive an error from the Load Balancer and the configuration will not be applied.
48
+
There was no impact on your applications or services using Scaleway Load Balancer, since HTTP Host header routes provided more accurate routing than SNI with HTTP backends.
78
49
79
50
## Sample configurations
80
51
81
-
Find below some sample configurations for HTTP Host header routes to HTTP backends. These should be used as a replacement for any old old SNI routes:
52
+
Find below some sample configurations for HTTP Host header routes to HTTP backends. These can be used to guide you in creating HTTP Host header routes if you were previously used to SNI routes:
82
53
83
54
<Tabsid="sample-route-config">
84
55
<TabsTablabel="API">
@@ -144,7 +115,7 @@ Find below some sample configurations for HTTP Host header routes to HTTP backen
@@ -176,7 +147,7 @@ Find below some sample configurations for HTTP Host header routes to HTTP backen
176
147
}
177
148
```
178
149
179
-
...you should now declare your resource in the following way:
150
+
...you should declare your resource in the following way:
180
151
181
152
```bash
182
153
resource "scaleway_lb_route""rt01" {
@@ -186,8 +157,4 @@ Find below some sample configurations for HTTP Host header routes to HTTP backen
186
157
}
187
158
```
188
159
</TabsTab>
189
-
</Tabs>
190
-
191
-
<Messagetype="tip">
192
-
If you experience any problems, do not hesitate to [open a support ticket](/console/account/how-to/open-a-support-ticket/) or speak to us on the `#load-balancer` channel of our [Slack Community](/tutorials/scaleway-slack-community/).
0 commit comments