What CloudFront/S3 doing with HTML/CSS/JS files?

Question

I uploaded to S3 below files:

• EntryPoint__fd6b122d5ca60cd57ec5.js
• index.html
• Main.css

But server returns below content:

Especially the gray one is strange: it does not seems like file. It's name (filename?) is ID from URN:

https://XXXX.com/product/53483ca1-9fd1-4970-841d-e9fbeadd4660

But when I checked the content of EntryPoint__fd6b122d5ca60cd57ec5.js, Main.css, I saw the same HTML code as in picture above (by other words, content of 53483ca1-9fd1-4970-841d-e9fbeadd4660, Main.css and EntryPoint__fd6b122d5ca60cd57ec5.js is even).

I have error:

Uncaught SyntaxError: Unexpected token '<'    
EntryPoint__fd6b122d5ca60cd57ec5.js:1 

To solve this error, first I need to understand what CloudFront/S3 did with my files. What is gray one? Where it's name has been set?

Anyway, it did something wrong: EntryPoint__fd6b122d5ca60cd57ec5.js has HTML content, and certainly JavaScript can not parse it.

Update or request: deploying to S3 task

const applicationDeployment = ({
  targetFilesGlobSelections,
  targetIsFunctionalTesting = false
}) =>

   Gulp.src(targetFilesGlobSelections)

       .pipe(GulpPlugins.plumber({
         errorHandler: (error) => {
           console.error("Task: 'DeployApplication', error occurred:");
           console.error(error);
           NodeNotifier.notify({
             title: "Task: 'DeployApplication', error occurred:",
             message: error.message
           });
         }
       }))

       .pipe(GulpPlugins.s3(
          targetIsFunctionalTesting ? AMAZON_S3_DEPLOYMENT_CONFIG__FUNCTIONAL_STAGING : AMAZON_S3_DEPLOYMENT_CONFIG__PRODUCTION
       ));

Gulp.task("Deployment to production", () => applicationDeployment({
  targetFilesGlobSelections: `${public}/**/**`
}));

Answer 1

1. The viewer requests the website at www.example.com.
2. If the requested object is cached, CloudFront returns the object from its cache to the viewer.
3. If the object is not in CloudFront’s cache, CloudFront requests the object from the origin (an S3 bucket).
4. S3 returns the object to CloudFront, which triggers the Lambda@Edge origin response event.
5. The object, including the security headers added by the Lambda@Edge function, is added to CloudFront’s cache.
6. (Not shown) The objects is returned to the viewer. Subsequent requests for the object that come to the same CloudFront edge location are served from the CloudFront cache.

As mentioned in 5th point, let elaborate the Lambda@Edge more! There are many uses for Lambda@Edge processing. For example:

• A Lambda function can inspect cookies and rewrite URLs so that users see different versions of a site for A/B testing.
• CloudFront can return different objects to viewers based on the device they're using by checking the User-Agent header, which includes information about the devices. For example, CloudFront can return different images based on the screen size of their device. Similarly, the function could consider the value of the Referer header and cause CloudFront to return the images to bots that have the lowest available resolution.
• Or you could check cookies for other criteria. For example, on a retail website that sells clothing, if you use cookies to indicate which color a user chose for a jacket, a Lambda function can change the request so that CloudFront returns the image of a jacket in the selected color.
• A Lambda function can generate HTTP responses when CloudFront viewer request or origin request events occur.
• A function can inspect headers or authorization tokens, and insert a header to control access to your content before CloudFront forwards the request to your origin.
• A Lambda function can also make network calls to external resources to confirm user credentials, or fetch additional content to customize a response.

I hope it can help you to understand what happened to your files. By the in inspect grey files mean HTML, orange/yellow mean javascript or .js file and blue mean css file.

Following is the example of my files!