Hi, everyone, and welcome back.
Now, in today's video, we are going to discuss about the custom error pages in cloud front.
Now, generally having a customer error page is one of the important things, not just specific to the
cloud front based environment, but any website that you have.
It is important that you set the customer pages, so let's go ahead and look into it.
So first, let's look into the overall challenge.
Now, in a cloud based architecture, you have an origin and you have a client.
So the status code and the error page that Cloud friend receives from the origin is also returned to
the viewer.
And again, this might not create a best of the experiences.
For example, in this specific screenshot you will see that user has requested for a file called test
txt and in the response this is an x HTML based response with the access denied, and it is showing
various things like request ID, host ID, etc..
Now generally in websites you do not really want this kind of response to be returned to the user.
You need a more generic response that should be served.
So this is where the custom error pages comes into picture.
Now, within cloud print you can configure it to send a custom error response to the viewer that is
different from that of the origin response.
So this can be better understood with this diagram where you have the user, you have a cloud print
and you have a three bucket where there is some kind of a website that is hosted.
So the user sends a request to the cloud, print cloud and sends the request to the origin origin sends
a response back to the cloud firm stating http 403 access denied.
Now at this stage cloud front, when it receives, you can configure a different set of response to
be sent to the user.
So if you see the response is different, including the status code.
So here the HTTP status code is for zero three access denied.
However, the status code that is being sent by cloud firm is for zero four, which is not found.
All right.
So let's do one thing.
Let's go ahead and look into this practically.
Now, if you generally look into the larger websites, you will have some kind of a custom error page,
for example, in the documentation.
If we just request for an object that does not exist instead of plane 404 naught font, you see you
have a very nice response which is also helpful and gives much more better information.
Now, in a cloud distribution which does not have the custom error page that is configured, if you
request for a non existent object or let's try it out.
So you see you got the typical XML response stating access denied and so on.
So this is something as we were discussing, you do not want to send back to your users.
So instead of that you configure a custom error page at the cloud print level and the response can be
improved.
Now I have one more cloud firm distribution with custom error page that is configured, so let's replace
the URL with the newer distribution and I'll just add a random text here.
Let's press enter and this time you see the response is a little different.
Which states sorry, the page is not available.
You can have a much more cleaner page here.
However, just for simplicity, I just added a text document here with the details and in websites you
will have something like this or you'll have some kind of an image which makes things look much more
better.
Now, let me also quickly show you on how you can configure this.
So just for simplicity, I have a cloud distribution and this in turn is associated with the origin
of S3 Bucket.
So the website is hosted in S3.
Now if you look into the distribution and the error page, I have one error page that is configured
here.
So what this states, it states that if the cloud friend receives a403 access denied, which is this
specific page that we had earlier seen, instead of sending that, just send the response that is part
of the custom error page HTML file.
And where this file is stored, it is stored in the same as three bucket.
So you have a custom error page HTML.
So this file will be returned instead of 403.
In case if everything is working, then our index HTML file will be returned.
Now, one more interesting thing that you will see is that the HTTP status code is also changed.
So here the error code is 403.
However, the HTTP response code here is for zero four.
So instead of sending access denied message to the user, cloud front will send a page not found.
And this can be configurable as well.
Now let's also quickly look into it.
So let's do one thing.
Let's go back to the distribution.
One of the distribution has the custom error page configured.
Second one does not have the custom error page configured.
First, let's look into the cloud distribution, which does not have the error page configured now from
the Scylla.
If I'll quickly do a curl to the.
Distribution and we know that the object does not exist.
Let's look into the header.
The header here is for zero three forbidden.
Now let's look into the cloud distribution, which has the error page configured.
I'll make a curl request again.
You are sending it to the object that does not really exist.
Now ideally three will send this 4034 return message back to the cloud friend.
However, this time you see the HTTP status code is also changed to 404.
So this is something that you can easily configure at the cloud level as well.
Now generally when you configure the error pages.
You have to define the HTTP error code.
For example, if the origin sends this 404 not found message back to the cloud front, then you can
customize the error message here.
And within here you can specify what is the file that should be returned.
In this case, the file is custom error page HTML, so you can just specify it over here.
And there is also an option to send a different HTTP status code.
So instead of 404 not found by the origin, you can say something like 400 bad requests or any other
status code depending upon the requirement grid.
So this is a very high level overview about sending the custom error response back to the viewer.
And with this will conclude today's video.