如果为存储桶启用网站托管,还有另一种添加 301 重定向的方法。
根据它,重定向规则以 XML 格式在存储桶级别进行描述,并且可以通过 AWS S3 控制台(静态网站托管部分)在存储桶的属性中指定。
目前可以在here找到有关其语法的完整文档。
当您有大量 URL 移动时,这种方法很方便,因为它更容易在一个地方管理所有重定向。例如可以定义重定向规则
<RoutingRule>
<Condition>
<KeyPrefixEquals>index.php</KeyPrefixEquals>
</Condition>
<Redirect>
<ReplaceKeyWith>index.html</ReplaceKeyWith>
</Redirect>
</RoutingRule>
<RoutingRule>
<Condition>
<KeyPrefixEquals>blog.php?id=21</KeyPrefixEquals>
</Condition>
<Redirect>
<ReplaceKeyWith>mysql-utf-8-database-creation-snippet.html</ReplaceKeyWith>
</Redirect>
</RoutingRule>
这看起来与创建假对象并为它们指定 x-amz-website-redirect-location 元数据相同。
坏消息是一个存储桶的 XML 中这样的规则可能不超过 50 条。
是的,管理 XML 并不方便。但对我来说,这种方式目前更容易。同样,因为在一个地方管理所有文件更容易。
这种 XML 方法在您重命名包含大量页面的目录时非常有用。在这种情况下,有必要
为目录创建单个重定向规则,而不是为其中的每个页面创建单独的规则。比如
<RoutingRule>
<Condition>
<KeyPrefixEquals>blog/</KeyPrefixEquals>
</Condition>
<Redirect>
<ReplaceKeyPrefixWith>it-blog/</ReplaceKeyPrefixWith>
</Redirect>
</RoutingRule>
根据这条规则example.com/blog/whatever会被重定向到example.com/it-blog/whatever。
这种方法的另一个有用特性是它只替换前缀。与目录一样,它是可能的
重定向页面,但保存查询参数。如果这些查询有一些 JS 处理,它可能是合适的
参数。使用 x-amz-website-redirect-location 元数据,您可能会丢失它们。
正如我提到的,编写和阅读 XML 可能不方便。为了克服这个问题,我在 GWT 中写了a simple online tool
将具有以前和新 URL 的纯文本转换为 XML 格式。它使用
KeyPrefixEquals 谓词并执行ReplaceKeyPrefixWith 重定向。
最后根据documentation,
如果网站托管被禁用,则重定向支持不适用于此存储桶。