使用Cloudfront将S3子文件夹重定向到另一个域 [英] Redirect S3 subfolder to another domain with Cloudfront

问题描述

我在S3上托管了一个静态展示网站，并使用CloudFront；在OVH服务器上托管了一个网上商店（Prestashop）和一个博客（Wordpress）。

I have a static showcase website hosted on S3 and using CloudFront, and an online shop (Prestashop) and a blog (Wordpress), both hosted on OVH servers.

我想在静态网站的两个子文件夹中进行隐藏的重定向，以使我的3个网站位于同一主机上，使用以下模式：

I want to make a hidden redirection on two subfolders of my static website so it acts like my 3 websites are on the same host, using the following pattern :

• mysite.com/->正常行为


• mysite.com/blog/-> myblog.com /


• mysite .com / store /-> mystore.com /

当然，我需要以这种方式处理每个请求，最终像这样的东西：

Of course, I need every request to be handled that way, eventually having something like that :

mysite.com/store /fr/1-myproduct.html

mysite.com/store/fr/1-myproduct.html

返回什么

mystore.com /fr/1-myproduct.html

mystore.com/fr/1-myproduct.html

将会回来。

这似乎很棘手，因为我没有找到解决问题的真正方法，在这一点上，我怀疑甚至可能是可能做这样的事情。
我考虑过使用代理，但是那不像是使用大锤摆脱苍蝇吗？

This seems really tricky, since I've found no real solution to my problem, and at this point I doubt it may even be possible to do such a thing. I considered using a proxy but wouldn't that be like using a sledgehammer to get rid of a fly ?

我已经搜索了任何可能的重定向，只能找到子域/域重定向...

I have searched for any possible redirection and I was only able to find subdomain/domain redirections...

所以我的问题是我该怎么办？
但是现在我想知道有人可以这样做吗？

PS：这是我有史以来的第一篇文章，在发布之前我已经搜索了很长一段时间，但直到现在我总是最终找到解决方案。欢迎提出任何建议。

P.S : It's my first post ever, I'm used to search for a long time before posting and I always end up finding a solution, except for now. Any suggestion is welcome.

推荐答案

我将检查代理，因为这是我的最后希望

I'll check about proxies since it's my last hope

等待。

我有一个静态展示柜S3上托管并使用CloudFront的网站

I have a static showcase website hosted on S3 and using CloudFront

CloudFront是反向代理。

根据您对其他两个站点的灵活性，CloudFront可以将您带到您想去的地方，将多个独立站点组合成一个主机名。

Depending on how much flexibility you have with the other two sites, CloudFront can potentially take you where you want to go, combining multiple independent sites under one hostname.

这是通过为您的发行版创建其他原始服务器，然后创建其他缓存行为来完成的，其路径模式与其他路径匹配，例如 / blog 和 / blog / * 将请求发送到备用源。

This is done by creating additional origin servers for your distributions and then creating additional cache behaviors, with path patterns matching the additonal paths, such as /blog and /blog/* that send requests to the alternate origins.

但是有一个问题。 CloudFront无法删除匹配的模式，因此匹配模式 / blog / * 的mainsite.example.com/blog/hello-world将被转发到blog.example。 com / blog / hello-world-请勿访问blog.example.com/hello-world。¹这将需要更改其他站点，以便以这种方式集成它们。

There is, however, a catch. CloudFront can't remove the matched pattern, so mainsite.example.com/blog/hello-world, matching the pattern /blog/* will be forwarded to blog.example.com/blog/hello-world -- not to blog.example.com/hello-world.¹ This will require changes to the other sites in order to integrate them in this way.

除非......

如果您已经具有唯一的路径模式，那么没问题，但是如果多余站点的内容位于每个站点的根目录中，则会在此处看到问题。

If you already have unique path patterns, no problem, but if the extra sites' content is in the root of each individual site, you see the issue, here. Not insurmoubtable, but still an issue.

您唯一的选择是在CloudFront后面的反向代理重写这些路径并发送请求到备用服务器。由于HAProxy，Nginx和Varnish都提供了这样的功能，并且可以在出乎意料的小型硬件上处理大量代理请求，因此这也不是什么大不了的。

最近（2017年）发布的 Lambda @ Edge 服务允许您在必要时动态重写路径，以处理请求。

The recently (2017) released Lambda@Edge service allows you to rewrite paths on the fly, as requests are processed, if necessary.

但最重要的是，您找不到请求的原因除代理服务器外，真正的解决方案是没有其他选择-给定主机名的每个路径都必须在一个逻辑位置进行处理-一组一个或多个相同配置的端点。对于CloudFront，逻辑位置在全球范围内分布。

But the bottom line is that the reason you have not found a real solution other than a proxy is that there is no alternative -- every path at a given hostname must be handled in one logical place -- one group of one or more identically-configured endpoints. In the case of CloudFront, the logical place is physically distributed globally.

¹从本质上讲，CloudFront实际上可以在转发请求之前添加到路径中，因此可以通过将原始路径设置为<$，将对mainsite.example.com/bar/fizz的请求转发至foosite.example.com/foo/bar/fizz。 c $ c> / foo 配置原点时。但是，如果不同时使用Lambda @ Edge，则无法删除路径部分或修改路径。在上述情况下，在配置其他原始服务器时，会将原始路径留空。

¹ CloudFront, natively, can actually prepend onto the path before forwarding the request, so requests for mainsite.example.com/bar/fizz can be forwarded to foosite.example.com/foo/bar/fizz by setting the origin path to /foo when you configure the origin. But it can't remove path parts or otherwise modify the path without also using Lambda@Edge. In the scenario discussed above, you would leave the origin path blank when configuring the additional origin servers.

这篇关于使用Cloudfront将S3子文件夹重定向到另一个域的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！