BackendBuilder

Set the CA certificate to use when checking the validity of the backend. Setting this will enable SSL for the connection as a side effect.

If ca_certificate is not provided (default), the backends's certificate is validated using a set of public root CAs.

Define the hostname that the server certificate should declare, and turn on validation during backend connections. You should enable this if you are using SSL/TLS, and setting this will enable SSL for the connection as a side effect.

If check_certificate is not provided (default), the server certificate's hostname may have any value.

Determine whether or not connections to the same backend should be pooled across different sessions.

Fastly considers two backends "the same" if they're registered with the same name and the exact same settings. In those cases, when pooling is enabled, if Session 1 opens a connection to this backend it will be left open, and can be re-used by Session 2. This can help improve backend latency, by removing the need for the initial network / TLS handshake(s).

By default, pooling is enabled for dynamic backends.

Use SSL/TLS to connect to the backend.

When using SSL/TLS, Fastly checks the validity of the backend's certificate, and fails the connection if the certificate is invalid. This check is not optional: an invalid certificate will cause the backend connection to fail (but read on).

By default, the validity check does not require that the certificate hostname matches the hostname of your request. You can use check_certificate to request a check of the certificate hostname.

By default, certificate validity uses a set of public certificate authorities. You can specify an alternative CA using ca_certificate.

Attempt to register this backend with runtime, returning the backend for use like any other backends.

In the case that this function returns BackendCreationError::NameInUse, users can use Backend::from_str as per normal to create a reference to that version. (That being said, you should be careful to only use this capability in situations in which you are 100% sure that this name will always lead to the same place.)

Set a timeout that applies between the time of sending a request and the time the HTTP headers are fully received. Defaults to 15,000ms (15s).

The name is, admittedly, confusing; it notionally refers to "first byte of the HTTP body", though of course not all responses have bodies.

Experimental: Add a healthcheck created from HealthcheckBuilder to the current dynamic backend.

Note that this feature is experimental, and may be removed or changed without a SemVer breaking change. This feature is not available to all customers / on all services. If you are interested in trying this feature, please contact your Fastly representative.

Configure how many connections to allow in the connection pool for this backend.

0 is treated as unlimited. The default is 200.

Note that this limit is best determined experimentally, since the total number of connections to the backend will depend on POP sizes, HTTP keepalive limits, and the traffic patterns for individual POPs.

Configure an upper bound for how long a pooled HTTP keepalive connection is allowed to have been open before we stop trying to reuse it.

Duration::ZERO is treated as unlimited. The default is Duration::ZERO.

Configure how many times an HTTP keepalive connection can be reused in a connection pool.

0 is treated as unlimited. The default is 0.

Create a new dynamic backend builder.

The arguments are the name of the new backend to use, along with a string describing the backend host. The latter can be of the form:

• "<ip address>"
• "<hostname>"
• "<ip address>:<port>"
• "<hostname>:<port>"

The name can be whatever you would like, as long as it does not match the name of any of the static service backends nor match any other dynamic backends built during this session. (Names can overlap between different sessions of the same service -- they will be treated as completely separate entities and will not be pooled -- but you cannot, for example, declare a dynamic backend named "dynamic-backend" twice in the same session.)

The builder will start with default values for all other possible fields for the backend, which can be overridden using the other methods provided. Call finish() to complete the construction of the dynamic backend.

Dynamic backends must be enabled for this Compute service. You can determine whether or not dynamic backends have been allowed for the current service by using this builder, and then checking for the BackendCreationError::Disallowed error result. This error only arises when attempting to use dynamic backends with a service that has not had dynamic backends enabled, or dynamic backends have been administratively prohibited for the node in response to an ongoing incident.

Set a host header override when contacting this backend.

This will force the value of the "Host" header to the given string when sending out the origin request. If this is not set and no header already exists, the "Host" header will default to this builder's target.

For more information, see the Fastly documentation on override hosts here: https://docs.fastly.com/en/guides/specifying-an-override-host

Configure whether to prefer trying IPv6 connections first before IPv4 when a hostname has both A and AAAA records.

This defaults to true.

Provide the given client certificate to the server as part of the SSL handshake. Setting this will enable SSL for the connection as a side effect. Both the certificate and the key to use should be in standard PEM format; providing the information in another format will lead to an error. We suggest that (at least the) key should be held in something like the Fastly secret store for security, with the handle passed to this function without unpacking it via Secret::plaintext; the certificate can be held in a less secure medium.

(If it is absolutely necessary to get the key from another source, we suggest the use of Secret::from_bytes).