cloudfront 无法请求行为中的对象
cloudfront fail to request objects in behavior
我已经为默认行为（无缓存）设置了 cloudfront、elb 和我的 ec2 web 服务器，一切正常。只有 1 个原点（elb），原点路径为空。
现在我想从 Web 服务器 (wildfly) 缓存带有云端的静态内容，例如 js/css，它们都在 /my-context/assets 文件夹
中提供
所以我添加了一个新行为，路径模式为“/my-context/assets/*”，默认缓存设置使用相同的来源。
这不起作用，我的请求登录页面 return 页面 html 本身，但所有 css/js 都失败了。使用 "CloudFront wasn't able to connect to the origin."
请求 /my-context/assets/a/b/some.css return 502
我还尝试为新行为设置一个路径为“/my-context/assets”的新源（使用相同的 elb），它也失败了。
我可以得到有关如何进行这项工作的说明吗？或者这实际上是行不通的？
谢谢！
解决方案是配置缓存行为以将 Host: header 从传入请求转发（白名单）到源。
这并不意味着它在所有情况下都是 "correct" 配置，但很多时候它是可取的，甚至是必需的。
当 CloudFront 与您的源服务器建立 back-end https 连接时，服务器提供的证书不仅必须有效（未过期，不是 self-signed，由受信任的 CA 颁发，并且具有完整的中间链）而且必须有效对于 CloudFront 将发送的请求。
For CloudFront to use HTTPS when communicating with your origin, one of the domain names in the certificate must match one or both of the following values:
• The value that you specified for Origin Domain Name for the applicable origin in your distribution.
• If you configured CloudFront to forward the Host header to your origin, the value of the Host header.
The SSL/TLS certificate on your origin includes a domain name in the Common Name field and possibly several more in the Subject Alternative Names field. (CloudFront supports wildcard characters in certificate domain names.) If your certificate doesn't contain any domain names that match either Origin Domain Name or the domain name in the Host header, CloudFront returns an HTTP status code 502 (Bad Gateway) to the viewer.
在您的情况下，您最初是通过禁用缓存的 CloudFront 发出 运行 请求，这通常是通过将 CloudFront 配置为将所有请求 header 转发到源来完成的，因为这会自动禁用缓存回复数。
稍后，当您尝试配置第二个缓存行为以便 objects 匹配某些路径模式可以被缓存时，您自然不会将所有 header 转发到源 - 但在此在这种情况下，转发 Host: header（CloudFront 将其称为 "whitelisting" header 转发）是必要的，因为 CloudFront 似乎需要该信息来验证原始服务器提供的证书。
如果您不转发 Host: header，证书必须与源域名匹配，如上所述，在您的情况下，我们显然不是这种情况。如果 Host: header 没有被列入转发白名单，那么 CloudFront 仍然会在 back-end 请求中发送一个主机 header，但是这个 header 设置为相同值作为源域名，因此证书必须匹配该值的原因。
如果不需要以一种或另一种方式进行匹配（以及 CloudFront 对到源的 HTTPS 连接施加的所有其他条件），这将阻止 CloudFront 合理确定后端连接正在由预期的服务器，并且原始服务器确实是它声称的服务器，这是 TLS/SSL 提供的两种保护之一（另一种保护，当然是对流量的实际加密）。
我已经为默认行为（无缓存）设置了 cloudfront、elb 和我的 ec2 web 服务器，一切正常。只有 1 个原点（elb），原点路径为空。 现在我想从 Web 服务器 (wildfly) 缓存带有云端的静态内容，例如 js/css，它们都在 /my-context/assets 文件夹
中提供所以我添加了一个新行为，路径模式为“/my-context/assets/*”，默认缓存设置使用相同的来源。 这不起作用，我的请求登录页面 return 页面 html 本身，但所有 css/js 都失败了。使用 "CloudFront wasn't able to connect to the origin."
请求 /my-context/assets/a/b/some.css return 502我还尝试为新行为设置一个路径为“/my-context/assets”的新源（使用相同的 elb），它也失败了。
我可以得到有关如何进行这项工作的说明吗？或者这实际上是行不通的？
谢谢！
解决方案是配置缓存行为以将 Host: header 从传入请求转发（白名单）到源。
这并不意味着它在所有情况下都是 "correct" 配置，但很多时候它是可取的，甚至是必需的。
当 CloudFront 与您的源服务器建立 back-end https 连接时，服务器提供的证书不仅必须有效（未过期，不是 self-signed，由受信任的 CA 颁发，并且具有完整的中间链）而且必须有效对于 CloudFront 将发送的请求。
For CloudFront to use HTTPS when communicating with your origin, one of the domain names in the certificate must match one or both of the following values:
• The value that you specified for Origin Domain Name for the applicable origin in your distribution.
• If you configured CloudFront to forward the Host header to your origin, the value of the Host header.
The SSL/TLS certificate on your origin includes a domain name in the Common Name field and possibly several more in the Subject Alternative Names field. (CloudFront supports wildcard characters in certificate domain names.) If your certificate doesn't contain any domain names that match either Origin Domain Name or the domain name in the Host header, CloudFront returns an HTTP status code 502 (Bad Gateway) to the viewer.
在您的情况下，您最初是通过禁用缓存的 CloudFront 发出 运行 请求，这通常是通过将 CloudFront 配置为将所有请求 header 转发到源来完成的，因为这会自动禁用缓存回复数。
稍后，当您尝试配置第二个缓存行为以便 objects 匹配某些路径模式可以被缓存时，您自然不会将所有 header 转发到源 - 但在此在这种情况下，转发 Host: header（CloudFront 将其称为 "whitelisting" header 转发）是必要的，因为 CloudFront 似乎需要该信息来验证原始服务器提供的证书。
如果您不转发 Host: header，证书必须与源域名匹配，如上所述，在您的情况下，我们显然不是这种情况。如果 Host: header 没有被列入转发白名单，那么 CloudFront 仍然会在 back-end 请求中发送一个主机 header，但是这个 header 设置为相同值作为源域名，因此证书必须匹配该值的原因。
如果不需要以一种或另一种方式进行匹配（以及 CloudFront 对到源的 HTTPS 连接施加的所有其他条件），这将阻止 CloudFront 合理确定后端连接正在由预期的服务器，并且原始服务器确实是它声称的服务器，这是 TLS/SSL 提供的两种保护之一（另一种保护，当然是对流量的实际加密）。