注意：这篇文章已被弃用。虽然它工作了一段时间，阿彭金改变了他们的立场，导致它破裂。我们决定创造出一种长期有效的、更广泛的服务或服务的东西，而不是用一种脆弱的解决方案来耍小把戏。称为Flexible SSL，了解有关以下博客帖子：如何在Tumblr，WordPress，Blogger，AppEngine，Posterous&More上启用SSL。。。

我们阅读我们收到的每封电子邮件，并一直收到来自用户的精彩功能建议。有一天，他们中的一个告诉我们，他与谷歌AppEngine有一个问题。事实证明，如果您想在AppEngine上使用SSL，您需要使用appspot.com网站子域，不是您自己的自定义域。这已经产生了1000多个来自AppEngine开发人员的修复请求。已经有一些建议的解决方案，但它们通常要求您放弃在云中运行的许多好处。谷歌AppEngine并不孤单。云中的SSL是但亚马逊的EC2和其他云服务也面临同样的问题。这里有一些关于核心问题的细节。SSL绑定到一个特定的域，通常是一个IP地址。在弹性云环境中管理SSL证书非常重要。因此，许多云提供商根本不支持SSL，或者像AppEngine一样，为他们的域创建一个通配符SSL证书，并强制每个想要SSL的人向其发送请求。不幸的是，如果你试图如果从您自己的域AppEngine，则不会验证SSL证书。我们最初认为可以通过忽略SSL作为代理来解决这个问题来自源的错误，但是AppEngine也基于主机头进行路由。如果主机头不是关闭的子域appspot.org网站然后流量被重新路由到Google主页。

在CloudFlare，我们围绕在云中管理SSL开发了大量技术。结果，我们意识到我们可以用AppEngine和其他云服务来解决这些问题。昨天，我们悄悄地打开了一个新功能，我们暂定为主机覆盖头。如果您的域启用了SSL，它将显示在CloudFlare设置页面中。该函数通过更改CloudFlare连接到源服务器时发送的主机头来工作。这意味着，如果您在AppEngine上托管，则可以输入<；yourkey>。appspot.com网站并启用主机覆盖标头。您的访问者可以使用HTTPS连接访问您的自定义域，但据AppEngine所知，他们将输入appspot.com网站子域。这不仅看起来更加专业和实用，而且还帮助开发人员保持HTTP和HTTPS连接之间的会话一致性。我们认为主机覆盖头功能还有许多其他的机会，包括支持扩展到SSL支持之外的功能，但是我们希望谨慎地进行并消除可能出现的任何错误。到目前为止我们已经看到两个了。第一个问题涉及在插入SetCookie头时当前是否正在设置域字段。如果你使用appspot.com网站域，则不会存储cookies，因为域不匹配。域，或者说域是你的自定义域，你的解决方案就是忽略它。我们看到的第二个bug是，在某些情况下，当你进行重定向时，你会发现自己陷入一个循环。我们已经内置了循环检测逻辑，但请确保您没有重定向来自appspot.com网站域返回到您的自定义域，否则您可能会看到一些问题。不可避免地，其他问题也会出现。如果你自己找到的话，请告诉我们。同时，希望我们已经为1000多名AppEngine开发人员创造了一个更好的世界，他们一直在寻找一种方法来托管服务并仍然使用SSL。