现在可以使用Lambda@Edge来重写路径

下面是一个lambda@Edge函数:

创建一个新的Lambda函数，但是使用一个已经存在的蓝图，而不是一个空白函数。 搜索“cloudfront”，并从搜索结果中选择cloudfront-response-generation。 创建函数后，将内容替换为以下内容。我还必须将节点运行时更改为10。X，因为cloudfront在撰写本文时不支持节点12。

'use strict';
exports.handler = (event, context, callback) => {
    
    // Extract the request from the CloudFront event that is sent to Lambda@Edge 
    var request = event.Records[0].cf.request;

    // Extract the URI from the request
    var olduri = request.uri;

    // Match any '/' that occurs at the end of a URI. Replace it with a default index
    var newuri = olduri.replace(/\/$/, '\/index.html');
    
    // Log the URI as received by CloudFront and the new URI to be used to fetch from origin
    console.log("Old URI: " + olduri);
    console.log("New URI: " + newuri);
    
    // Replace the received URI with the URI that includes the index page
    request.uri = newuri;

    return callback(null, request);
};

在您的云前行为中，您将编辑它们以在“Viewer Request”上添加对lambda函数的调用

完整教程:https://aws.amazon.com/blogs/compute/implementing-default-directory-indexes-in-amazon-s3-backed-amazon-cloudfront-origins-using-lambdaedge/

这是切题的，但这里有一个提示，对于那些使用Rackt的React Router库和(HTML5)浏览器历史，想要在S3上托管的人。

假设一个用户在s3托管的静态网站上访问/foo/bear。根据David之前的建议，重定向规则将把它们发送到/#/foo/bear。如果您的应用程序是使用浏览器历史记录构建的，那么这样做不会有太大的好处。然而，你的应用程序在这一点上加载，它现在可以操纵历史。

在我们的项目中包括Rackt历史(参见React Router项目中的使用自定义历史)，你可以添加一个侦听器，它可以感知哈希历史路径，并根据需要替换路径，如下例所示:

import ReactDOM from 'react-dom';

/* Application-specific details. */
const route = {};

import { Router, useRouterHistory } from 'react-router';
import { createHistory } from 'history';

const history = useRouterHistory(createHistory)();

history.listen(function (location) {
  const path = (/#(\/.*)$/.exec(location.hash) || [])[1];
  if (path) history.replace(path);
});

ReactDOM.render(
  <Router history={history} routes={route}/>,
  document.body.appendChild(document.createElement('div'))
);

回顾一下:

David的S3重定向规则将/foo/bear定向到/#/foo/bear。 您的应用程序将加载。 历史侦听器将检测#/foo/bear历史符号。 用正确的路径替换历史记录。

链接标签将按预期工作，所有其他浏览器历史功能也是如此。我所注意到的唯一缺点是在初始请求时发生的间隙重定向。

这是受到AngularJS的一个解决方案的启发，我怀疑它可以很容易地适应任何应用程序。

其他人提到的基于S3/Redirect的方法有一些问题。

多重重定向发生在应用程序的路径被解析时。例如:www.myapp.com/path/for/test被重定向为www.myapp.com/#/path/for/test 由于您的SPA框架的操作，当“#”出现和消失时，url栏中有一个闪烁。 seo会受到影响，因为——‘嘿!这谷歌迫使他的手重定向 Safari对你的应用程序的支持值得一试。

解决方案是:

Make sure you have the index route configured for your website. Mostly it is index.html Remove routing rules from S3 configurations Put a Cloudfront in front of your S3 bucket. Configure error page rules for your Cloudfront instance. In the error rules specify: Http error code: 404 (and 403 or other errors as per need) Error Caching Minimum TTL (seconds) : 0 Customize response: Yes Response Page Path : /index.html HTTP Response Code: 200 For SEO needs + making sure your index.html does not cache, do the following: Configure an EC2 instance and setup an nginx server. Assign a public ip to your EC2 instance. Create an ELB that has the EC2 instance you created as an instance You should be able to assign the ELB to your DNS. Now, configure your nginx server to do the following things: Proxy_pass all requests to your CDN (for index.html only, serve other assets directly from your cloudfront) and for search bots, redirect traffic as stipulated by services like Prerender.io

我可以提供更多关于nginx设置的细节，请留下一张便条。经历了惨痛的教训。

一旦云前端分发更新。使您的云前缓存失效一次，使其处于原始模式。 在浏览器中点击url，一切都应该是好的。

大多数建议的解决方案(尤其是最流行的答案)的问题是，对于不存在的后端资源，您永远不会看到404错误。如果希望继续得到404，请参考此解决方案

I added a root path to all my routes (that's new to this solution) e.g. all my route-paths start with the same front end root... in place of paths /foo/baz, /foo2/baz I now have /root/foo/baz , /root/foo2/baz paths. The choice of the front-end root is such that it does not conflict with any real folder or path at the back-end. Now I can use this root to create simple redirection rules anywhere, I like. All my redirection changes will be impacting only this path and everything else will be as earlier.

这是我在s3桶中添加的重定向规则

[
    {
        "Condition": {
            "HttpErrorCodeReturnedEquals": "404",
            "KeyPrefixEquals": "root/"
        },
        "Redirect": {
            "HostName": "mydomain.com",
            "ReplaceKeyPrefixWith": "#/"
        }
    }
]

甚至是跟随

[
        {
            "Condition": {
               
                "KeyPrefixEquals": "root/"
            },
            "Redirect": {
                "HostName": "mydomain.com",
                "ReplaceKeyPrefixWith": "#/"
            }
        }
    ]

在此之后，/root/foo/baz被重定向到/#/foo/baz，页面在主页加载，没有错误。

我在装载Vue应用程序后添加了以下代码。它将把我的应用程序带到所需的路线。您可以更换路由器。push部分根据Angular或你正在使用的任何东西。

if(location.href.includes("#"))
{
  let currentRoute = location.href.split("#")[1];

  router.push({ path: `/root${currentRoute}` })
}

即使您没有在s3级别使用重定向，在您可能喜欢的任何其他重定向中，为所有路由提供一个单一的基础也会很方便。它帮助后端识别这不是一个真正的后端资源的请求，前端应用程序将能够处理它。

我做到这一点的方法如下:

在域的S3控制台的“编辑重定向规则”部分中，添加以下规则:

<RoutingRules>
  <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <HostName>yourdomainname.com</HostName>
      <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

这将导致404错误的所有路径重定向到根域，并显示路径的散列版本。所以http://yourdomainname.com/posts将重定向到http://yourdomainname.com/#!如果/posts上没有文件。

然而，要使用HTML5的pushState，我们需要接受这个请求，并根据散列路径手动建立正确的pushState。所以把这个添加到index.html文件的顶部:

<script>
  history.pushState({}, "entry page", location.hash.substring(1));
</script>

这将获取散列并将其转换为HTML5 pushState。从这一点开始，你可以使用pushStates在你的应用程序中拥有非哈希键路径。

如果你在这里寻找与React路由器和AWS Amplify控制台一起工作的解决方案，你已经知道你不能直接使用CloudFront重定向规则，因为Amplify控制台不会为应用程序公开CloudFront Distribution。

然而，解决方案非常简单-你只需要在Amplify控制台中添加一个重定向/重写规则，就像这样:

查看以下链接获取更多信息(以及截图中的复制友好规则):

https://docs.aws.amazon.com/amplify/latest/userguide/redirects.html#redirects-for-single-page-web-apps-spa https://github.com/aws-amplify/amplify-console/issues/83