Shield

Returns a Backend representing an encrypted connection to the POP.

For reference, this is almost always the backend that you want to use. Only use Shield::unencrypted_backend in situations in which you are 100% sure that all the data you will send and receive over the backend is already encrypted.

Load information about the given shield.

Returns an object representing the shield if it is active, or an error if the string is malformed or the shield doesn't exist.

Shield names are defined on this webpage, in the "shield code" column. For example, the string "pdx-or-us" will look up our Portland, OR, USA shield site, while "paris-fr" will look up our Paris site.

If you are using a major cloud provider for your primary origin site, consider looking at the "Recommended for" column, to find the Fastly POP most closely located to the given cloud provider.

Returns whether we are currently operating on the given shield.

Technically, this may also return true in very isolated incidents in which Fastly is routing traffic from the target shield POP to the POP that this code is running on, but in these situations the results should be approximately identical.

(For example, it may be the case that you are asking to shield to 'pdx-or-us'. But, for load balancing, performance, or other reasons, Fastly is temporarily shifting shielding traffic from Portland to Seattle. In that case, this function may return true for hosts running on 'bfi-wa-us', our Seattle site, because effectively the shield has moved to that location. This should give you a slightly faster experience than the alternative, in which this function would return false, you would try to forward your traffic to the Portland site, and then that traffic would be caught and redirected back to Seattle.)

Returns a Backend representing an unencrypted connection to the POP.

Generally speaking, we encourage users to use Shield::encrypted_backend instead of this function. Data sent over this backend -- the unencrypted version -- will be sent over the open internet, with no protections. In most cases, this is not what you want. However, in some cases -- such as when you want to ship large data blobs that you know are already encrypted --- using these backends can prevent a double-encryption performance penalty.

Creates a copy of this Shield with the first-byte timeout configured.

The configured first-byte timeout will apply to any backends derived from the returned Shield (Shield::encrypted_backend or Shield::unencrypted_backend). See BackendBuilder::set_first_byte_timeout.