Servir le fichier d'index au lieu de l'invite de téléchargement

Ce type de comportement est généralement contrôlé / causé par vos données d'en-tête HTTP (s), en particulier, le Content-Type que votre client reçoit.

Inspectez l'en-tête < / a> et essayez de peaufiner ce qui est renvoyé par votre serveur. Cela devrait conduire à votre solution.

Les points de terminaison de site Web et les points de terminaison REST ont nombreuses différences , y compris celle-ci.

Le La raison pour laquelle vous voyez ces fichiers de 0 octet pour les clés d'objet se terminant par / est que vous créez des objets de dossier dans le compartiment à l'aide de la console S3 ou d'un autre utilitaire qui crée en fait les objets de 0 octet. Ils ne sont pas nécessaires, une fois que les dossiers ont des objets "dans" eux - mais ils sont le seul moyen d'afficher un dossier vide dans la console S3, qui affiche un objet nommé foo / comme un dossier nommé foo , même s'il n'y a pas d'autres objets avec un préfixe de clé foo / . Cela fait partie de l'émulation visuelle d'une hiérarchie de dossiers dans la console, même si les objets dans S3 ne sont jamais vraiment "dans" des dossiers.

Si, pour une raison quelconque, vous devez utiliser le point de terminaison REST - comme vous ne voulez pas rendre le bucket public - alors vous avez besoin de deux déclencheurs Lambda @ Edge dans CloudFront, pour émuler cette fonctionnalité assez étroitement.

Un déclencheur Origin Request peut inspecter et modifier les demandes après la vérification du cache CloudFront, avant que la demande ne soit envoyée à l'origine. Nous utilisons ceci pour rechercher un chemin se terminant par / et ajouter index.html si nous trouvons cela.

Une Réponse d'origine em> trigger peut inspecter et éventuellement modifier les réponses, avant qu'elles ne soient écrites dans le cache CloudFront. Le déclencheur Origin Response peut également inspecter la demande d'origine qui a précédé la demande qui a généré la réponse. Nous utilisons ceci pour vérifier si la réponse est une erreur. Si tel est le cas et que la demande d'origine ne semble pas concerner un document d'index ou un fichier (en particulier, après la dernière barre oblique du chemin, un "fichier" comporte au moins un caractère, suivi de un point, suivi d'au moins un caractère supplémentaire - et si c'est le cas, c'est probablement un "fichier"). Si ce n'est ni l'une ni l'autre de ces choses, nous redirigeons vers le chemin d'origine plus un / final que nous ajoutons.

Les déclencheurs Origin Request et Origin Response se déclenchent uniquement en cas d'échec du cache. Lorsqu'il y a un hit de cache, aucun des déclencheurs ne se déclenche, car ils se trouvent du côté d'origine de CloudFront - l'arrière du cache. Les requêtes qui peuvent être servies à partir du cache sont servies à partir du cache, donc les déclencheurs ne sont pas appelés.

Ce qui suit est une fonction Lambda @ Edge écrite dans Node.js 8.10. Cette fonction Lambda modifie son comportement afin qu'elle se comporte comme une demande d'origine ou une réponse d'origine, en fonction du contexte. Après avoir publié une version dans Lambda, associez l'ARN de cette version aux paramètres CloudFront Cache Behavior en tant que à la fois une demande d'origine et un déclencheur de réponse d'origine.

'use strict';

// combination origin-request, origin-response trigger to emulate the S3
// website hosting index document functionality, while using the REST
// endpoint for the bucket

// https://stackoverflow.com/a/54263794/1695906

const INDEX_DOCUMENT = 'index.html'; // do not prepend a slash to this value

const HTTP_REDIRECT_CODE = '302'; // or use 301 or another code if desired
const HTTP_REDIRECT_MESSAGE = 'Found'; 

exports.handler = (event, context, callback) => {
    const cf = event.Records[0].cf;

    if(cf.config.eventType === 'origin-request')
    {
        // if path ends with '/' then append INDEX_DOCUMENT before sending to S3
        if(cf.request.uri.endsWith('/'))
        {
            cf.request.uri = cf.request.uri + INDEX_DOCUMENT;
        }
        // return control to CloudFront, to send request to S3, whether or not
        // we modified it; if we did, the modified URI will be requested.
        return callback(null, cf.request);
    }
    else if(cf.config.eventType === 'origin-response')
    {
        // is the response 403 or 404?  If not, we will return it unchanged.
        if(cf.response.status.match(/^40[34]$/))
        {
            // it's an error.

            // we're handling a response, but Lambda@Edge can still see the attributes of the request that generated this response; so, we
            // check whether this is a page that should be redirected with a trailing slash appended.  If it doesn't look like an index
            // document request, already, and it doesn't end in a slash, and doesn't look like a filename with an extension... we'll try that.

            // This is essentially what the S3 web site endpoint does if you hit a nonexistent key, so that the browser requests
            // the index with the correct relative path, except that S3 checks whether it will actually work.  We are using heuristics,
            // rather than checking the bucket, but checking is an alternative.

            if(!cf.request.uri.endsWith('/' + INDEX_DOCUMENT) && // not a failed request for an index document
               !cf.request.uri.endsWith('/') && // unlikely, unless this code is modified to pass other things through on the request side
               !cf.request.uri.match(/[^\/]+\.[^\/]+$/)) // doesn't look like a filename  with an extension
            {
                // add the original error to the response headers, for reference/troubleshooting
                cf.response.headers['x-redirect-reason'] = [{ key: 'X-Redirect-Reason', value: cf.response.status + ' ' + cf.response.statusDescription }];
                // set the redirect code
                cf.response.status = HTTP_REDIRECT_CODE;
                cf.response.statusDescription = HTTP_REDIRECT_MESSAGE;
                // set the Location header with the modified URI
                // just append the '/', not the "index.html" -- the next request will trigger
                // this function again, and it will be added without appearing in the
                // browser's address bar.
                cf.response.headers['location'] = [{ key: 'Location', value: cf.request.uri + '/' }];
                // not strictly necessary, since browsers don't display it, but remove the response body with the S3 error XML in it
                cf.response.body = '';
            }
        }

        // return control to CloudFront, with either the original response, or
        // the modified response, if we modified it.

        return callback(null, cf.response);

    }
    else // this is not intended as a viewer-side trigger.  Throw an exception, visible only in the Lambda CloudWatch logs and a 502 to the browser.
    {
        return callback(`Lambda function is incorrectly configured; triggered on '${cf.config.eventType}' but expected 'origin-request' or 'origin-response'`);
    }

};

p >

Les réponses données sont fausses. Cloudfront a sa propre configuration pour que www.yourdomain.com/ serve un document. Il s'appelle «objet racine par défaut» et sa configuration se trouve sous l'onglet «général» de votre distribution cloudfront. Voici les étapes complètes pour obtenir un domaine personnalisé compatible SSL / https + cloudfront + s3.

1. Créez un tout nouveau compartiment S3 avec des autorisations par défaut (fermées) ou supprimez tous les accès publics du compartiment cible.
2. Désactivez l'hébergement de site Web statique. Vous n'en avez pas besoin.
3. Si vous ne l'avez pas déjà fait, récupérez votre certificat SSL dans Amazon afin de pouvoir le joindre à la distribution cloudfront qui pointera vers votre compartiment S3.
4. Créez une distribution cloudfront pointant vers le compartiment S3 cible, à l'aide du certificat.
5. Pour la configuration de l'origine, utilisez le formulaire www.votredomaine.com.s3.amazonaws.com pour l'origine, PAS l'URL d'hébergement du site Web statique (qui devrait de toute façon être désactivée).
6. Laissez la configuration cloudfront modifier automatiquement l'accès au compartiment S3 ("restreindre l'accès au compartiment"). Vous souhaitez que l'accès au compartiment soit limité à cette distribution cloudfront UNIQUEMENT (via une identité spécifique). Personne ne devrait toucher directement votre compartiment S3, d'autant plus qu'il peut servir via http (pas de "s").
7. Sous l'onglet "général" de cloudfront (ou pendant l'installation), définissez votre objet racine par défaut sur "index.html" ou autre. Sinon, les demandes adressées à https://www.yourdomain.com/ afficheront l'autorisation refusée.