#[non_exhaustive]pub struct CustomErrorResponse {
pub error_code: i32,
pub response_page_path: Option<String>,
pub response_code: Option<String>,
pub error_caching_min_ttl: Option<i64>,
}
Expand description
A complex type that controls:
-
Whether CloudFront replaces HTTP status codes in the 4xx and 5xx range with custom error messages before returning the response to the viewer.
-
How long CloudFront caches HTTP status codes in the 4xx and 5xx range.
For more information about custom error pages, see Customizing Error Responses in the Amazon CloudFront Developer Guide.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. }
syntax; cannot be matched against without a wildcard ..
; and struct update syntax will not work.error_code: i32
The HTTP status code for which you want to specify a custom error page and/or a caching duration.
response_page_path: Option<String>
The path to the custom error page that you want CloudFront to return to a viewer when your origin returns the HTTP status code specified by ErrorCode
, for example, /4xx-errors/403-forbidden.html
. If you want to store your objects and your custom error pages in different locations, your distribution must include a cache behavior for which the following is true:
-
The value of
PathPattern
matches the path to your custom error messages. For example, suppose you saved custom error pages for 4xx errors in an Amazon S3 bucket in a directory named/4xx-errors
. Your distribution must include a cache behavior for which the path pattern routes requests for your custom error pages to that location, for example,/4xx-errors/*
. -
The value of
TargetOriginId
specifies the value of theID
element for the origin that contains your custom error pages.
If you specify a value for ResponsePagePath
, you must also specify a value for ResponseCode
.
We recommend that you store custom error pages in an Amazon S3 bucket. If you store custom error pages on an HTTP server and the server starts to return 5xx errors, CloudFront can't get the files that you want to return to viewers because the origin server is unavailable.
response_code: Option<String>
The HTTP status code that you want CloudFront to return to the viewer along with the custom error page. There are a variety of reasons that you might want CloudFront to return a status code different from the status code that your origin returned to CloudFront, for example:
-
Some Internet devices (some firewalls and corporate proxies, for example) intercept HTTP 4xx and 5xx and prevent the response from being returned to the viewer. If you substitute
200
, the response typically won't be intercepted. -
If you don't care about distinguishing among different client errors or server errors, you can specify
400
or500
as theResponseCode
for all 4xx or 5xx errors. -
You might want to return a
200
status code (OK) and static website so your customers don't know that your website is down.
If you specify a value for ResponseCode
, you must also specify a value for ResponsePagePath
.
error_caching_min_ttl: Option<i64>
The minimum amount of time, in seconds, that you want CloudFront to cache the HTTP status code specified in ErrorCode
. When this time period has elapsed, CloudFront queries your origin to see whether the problem that caused the error has been resolved and the requested object is now available.
For more information, see Customizing Error Responses in the Amazon CloudFront Developer Guide.
Implementations§
Source§impl CustomErrorResponse
impl CustomErrorResponse
Sourcepub fn error_code(&self) -> i32
pub fn error_code(&self) -> i32
The HTTP status code for which you want to specify a custom error page and/or a caching duration.
Sourcepub fn response_page_path(&self) -> Option<&str>
pub fn response_page_path(&self) -> Option<&str>
The path to the custom error page that you want CloudFront to return to a viewer when your origin returns the HTTP status code specified by ErrorCode
, for example, /4xx-errors/403-forbidden.html
. If you want to store your objects and your custom error pages in different locations, your distribution must include a cache behavior for which the following is true:
-
The value of
PathPattern
matches the path to your custom error messages. For example, suppose you saved custom error pages for 4xx errors in an Amazon S3 bucket in a directory named/4xx-errors
. Your distribution must include a cache behavior for which the path pattern routes requests for your custom error pages to that location, for example,/4xx-errors/*
. -
The value of
TargetOriginId
specifies the value of theID
element for the origin that contains your custom error pages.
If you specify a value for ResponsePagePath
, you must also specify a value for ResponseCode
.
We recommend that you store custom error pages in an Amazon S3 bucket. If you store custom error pages on an HTTP server and the server starts to return 5xx errors, CloudFront can't get the files that you want to return to viewers because the origin server is unavailable.
Sourcepub fn response_code(&self) -> Option<&str>
pub fn response_code(&self) -> Option<&str>
The HTTP status code that you want CloudFront to return to the viewer along with the custom error page. There are a variety of reasons that you might want CloudFront to return a status code different from the status code that your origin returned to CloudFront, for example:
-
Some Internet devices (some firewalls and corporate proxies, for example) intercept HTTP 4xx and 5xx and prevent the response from being returned to the viewer. If you substitute
200
, the response typically won't be intercepted. -
If you don't care about distinguishing among different client errors or server errors, you can specify
400
or500
as theResponseCode
for all 4xx or 5xx errors. -
You might want to return a
200
status code (OK) and static website so your customers don't know that your website is down.
If you specify a value for ResponseCode
, you must also specify a value for ResponsePagePath
.
Sourcepub fn error_caching_min_ttl(&self) -> Option<i64>
pub fn error_caching_min_ttl(&self) -> Option<i64>
The minimum amount of time, in seconds, that you want CloudFront to cache the HTTP status code specified in ErrorCode
. When this time period has elapsed, CloudFront queries your origin to see whether the problem that caused the error has been resolved and the requested object is now available.
For more information, see Customizing Error Responses in the Amazon CloudFront Developer Guide.
Source§impl CustomErrorResponse
impl CustomErrorResponse
Sourcepub fn builder() -> CustomErrorResponseBuilder
pub fn builder() -> CustomErrorResponseBuilder
Creates a new builder-style object to manufacture CustomErrorResponse
.
Trait Implementations§
Source§impl Clone for CustomErrorResponse
impl Clone for CustomErrorResponse
Source§fn clone(&self) -> CustomErrorResponse
fn clone(&self) -> CustomErrorResponse
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreSource§impl Debug for CustomErrorResponse
impl Debug for CustomErrorResponse
Source§impl PartialEq for CustomErrorResponse
impl PartialEq for CustomErrorResponse
impl StructuralPartialEq for CustomErrorResponse
Auto Trait Implementations§
impl Freeze for CustomErrorResponse
impl RefUnwindSafe for CustomErrorResponse
impl Send for CustomErrorResponse
impl Sync for CustomErrorResponse
impl Unpin for CustomErrorResponse
impl UnwindSafe for CustomErrorResponse
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left
is true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left(&self)
returns true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the foreground set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red()
and
green()
, which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg()
:
use yansi::{Paint, Color};
painted.fg(Color::White);
Set foreground color to white using white()
.
use yansi::Paint;
painted.white();
Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the background set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red()
and
on_green()
, which have the same functionality but
are pithier.
§Example
Set background color to red using fg()
:
use yansi::{Paint, Color};
painted.bg(Color::Red);
Set background color to red using on_red()
.
use yansi::Paint;
painted.on_red();
Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute
value
.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold()
and
underline()
, which have the same functionality
but are pithier.
§Example
Make text bold using attr()
:
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);
Make text bold using using bold()
.
use yansi::Paint;
painted.bold();
Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi
Quirk
value
.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask()
and
wrap()
, which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk()
:
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);
Enable wrapping using wrap()
.
use yansi::Paint;
painted.wrap();
Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition
value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted
only when both stdout
and stderr
are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);