search

ProvidenceGeeks / website-frontend

UI frontend repository for the Providence Geeks website
https://www.pvdgeeks.org
7 stars 9 forks source link

visiting a canonical link / slug (like for a post details page) shows a (CloudFront) error page #131

Closed thescientist13 closed 6 years ago

thescientist13 commented 6 years ago

Type of Change

Summary

  1. Visit a canonical link / slug URL like - https://stage.pvdgeeks.org/post/9

OR

  1. Load the home page
  2. Click the Posts tab
  3. Click any Blog Post card
  4. Refresh the page

Expected The details page should load

Actual A CloudFront error is seen instead

screen shot 2018-01-10 at 11 14 02 am
thescientist13 commented 6 years ago

My hunch is that there is some sort of configuration error in S3, which is preventing index.html to be loaded for a 404 request, which is a common server configuration step needed for SPAs (Single Page Applications) that use a router.

Whatever the solution, it needs to be applied to both stage and production environments.

thescientist13 commented 6 years ago

Ok, so by creating a custom error page response in CloudFront screen shot 2018-01-11 at 10 58 54 am

we can now handle error response codes, like is needed for client side routing requests.... 

$ curl -I https://stage.pvdgeeks.org/post/9
HTTP/2 200
content-type: text/html
content-length: 7719
date: Thu, 11 Jan 2018 15:35:32 GMT
last-modified: Mon, 08 Jan 2018 19:11:55 GMT
etag: "881ababf13398fd55fe58b1dc36f7925"
accept-ranges: bytes
server: AmazonS3
vary: Accept-Encoding
x-cache: Error from cloudfront
via: 1.1 d56db0d65906a3edce526dc6600d65c6.cloudfront.net (CloudFront)
x-amz-cf-id: czxxh5qisNRVkB_V-bjGv-tGwjIspRWtjPwschOUVGkW8Sm9wSaqIQ==

The only downside is that a call to a legit 404 (like an API endpoint that doesn't exist) will still return a 200 index.html response, so this puts more of the burden on the client to handle these cases.

$ curl -I https://stage.pvdgeeks.org/api/events/9
HTTP/2 200
content-type: text/html
content-length: 7719
date: Thu, 11 Jan 2018 15:35:32 GMT
last-modified: Mon, 08 Jan 2018 19:11:55 GMT
etag: "881ababf13398fd55fe58b1dc36f7925"
accept-ranges: bytes
server: AmazonS3
vary: Accept-Encoding
age: 698
x-cache: Error from cloudfront
via: 1.1 12988681512372d827da78863e01c49a.cloudfront.net (CloudFront)
x-amz-cf-id: CRRIf66MetP1iGeDD03SQRSSD3VjkxbucDqws_RmNPXO9dTwOx-75Q==

# compared to hitting the API directly
$ curl -I http://54.208.177.39:8080/api/events/9
HTTP/1.1 404
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 11 Jan 2018 15:50:20 GMT

It doesn't seem there is a way to do this in CloudFront / S3, where in an ideal world would allow us to specify a way to handle errors for a Distributions behavior vs another one. For example

  1. API requests like https://<domain>.com/api/<resource>/:id should allow a true 404 to return if there is legitimately no resource at that endpoint
  2. Client side static assets requests like https://<domain>.com/post/9 should return a fallback client side page, in our case index.html

I guess until we actually have use cases like in example 1 above, we can get away with just letting the client handle this for now. 🤷‍♂️