cloudfront无法请求行为对象 [英] cloudfront fail to request objects in behavior
问题描述
我已经为默认行为（没有缓存）设置了cloudfront，elb和ec2 Web服务器，一切正常。只有1个原点（elb），并且原点路径为空。
现在，我想从Web服务器（野生）（如js / css）使用cloudfront缓存静态内容，它们都放在/ my-context / assets文件夹中
I have setup cloudfront, elb and my ec2 web server for default behavior (no caching), everything is working fine. There is only 1 origin (the elb) and the origin path is empty. Now I want to cache static stuff with cloudfront from the web server (wildfly) like js/css, they're all served in /my-context/assets folder
因此，我使用相同的来源添加了路径模式为'/ my-context / assets / *'和默认缓存设置的新行为。
这不起作用，我的请求登录页面返回页面html本身，但是所有的css / js都失败了。请求/my-context/assets/a/b/some.css返回502， CloudFront无法连接到源。
So i add a new behavior with path pattern '/my-context/assets/*' and default cache settings using the same origin. This is not working, my request login page return the page html itself, but all css/js are failed. Request to /my-context/assets/a/b/some.css return 502 with "CloudFront wasn't able to connect to the origin."
我也尝试过为新行为设置路径为 / my-context / assets的新起点（具有相同的弯头），它也会失败。
I also tried to setup a new origin (with the same elb) with path "/my-context/assets" for the new behavior, it also fail.
我可以对如何使这项工作？还是这实际上不可行？
Can I have instruction on how to make this work? or is this actually not do-able?
谢谢！
推荐答案
解决方案是配置缓存行为，以将传入的请求中的 Host：头转发（白名单）到源。
The solution is to configure the cache behavior to forward (whitelist) the Host: header to the origin, from the incoming request.
这并不意味着在每种情况下它都是正确的配置，而是很多时候都是可取的，甚至是必需的。
This is not to imply that it's the "correct" configuration in every case, but many times it is desirable, or even required.
当CloudFront与原始服务器建立后端https连接时，该服务器提供的证书不仅必须有效（未过期，也不能自签名，由受信任的CA颁发，并具有一个完整的中间链），但是必须有效， CloudFront将发送该请求。
When CloudFront makes a back-end https connection to your origin server, the certificate offered by the server has to not only be valid (not expired, not self-signed, issued by a trusted CA, and with an intact intermediate chain) but also has to be valid for the request CloudFront will be sending.
要让CloudFront与您的来源进行通信时使用HTTPS，证书中的域名之一必须与以下两个值之一或两个都匹配：
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:
&bull ;您为分配中的适用来源指定的原始域名的值。
• The value that you specified for Origin Domain Name for the applicable origin in your distribution.
•如果您将CloudFront配置为将Host标头转发到您的来源，则为Host标头的值。
• If you configured CloudFront to forward the Host header to your origin, the value of the Host header.
您来源的SSL / TLS证书在Common中包含一个域名名称字段，主题备用名称字段中可能还有更多字段。 （CloudFront在证书域名中支持通配符。）如果您的证书不包含与原始域名或主机标头中的域名匹配的任何域名，则CloudFront会向查看器返回HTTP状态代码502（错误网关） 。
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将所有请求标头转发到源来完成，因为这会自动禁用响应的缓存。
In your case, you originally were running requests through CloudFront with caching disabled, which is typically done by configuring CloudFront to forward all request headers to the origin, as this automatically disables caching of responses.
稍后，当您尝试配置第二个缓存行为，以便可以缓存与某些路径模式匹配的对象时，您自然不会将所有标头转发到源头，但是在这种情况下，转发主机：标头（CloudFront将该报头称为白名单以进行转发）是必需的，因为CloudFront似乎需要该信息为了验证原始服务器出示的证书，请执行以下操作。
Later, when you attempted configure a second cache behavior so that objects matching certain path patterns could be cached, you naturally did not forward all headers to the origin -- but in this case, forwarding the Host: header (which CloudFront refers to as "whitelisting" the header for forwarding) was necessary, because CloudFront appeared to have needed that information in order to validate the certificate that the origin server was presenting.
如果您不转发 Host：标头中，证书必须与原始域名相匹配，如上所述，在您的情况下，显然不是这样。如果 Host：标头未列入转发白名单，则CloudFront仍会在后端请求中发送主机标头，但此标头设置为与Origin域相同的值名称，即证书必须与该值匹配的原因。
If you don't forward the Host: header, the the certificate must match the Origin Domain Name, as noted above, and in your case, this us apparently not the case. If the Host: header is not whitelisted for forwarding, then CloudFront still sends a host header in the back-end request, but this header is set to the same value as Origin Domain Name, hence the reason the certificate must match that value.
如果不需要一种或另一种匹配方式（以及CloudFront在HTTPS连接上施加的所有其他条件）源），这将阻止CloudFront合理确定后端服务器正在由目标服务器处理，并且源服务器确实是它声称的服务器，这是TLS /提供的两项保护之一SSL（另一种保护，当然是流量的实际加密）。
If matching one way or the other were not required (along with all the other conditions CloudFront imposes on HTTPS connections to the origin), this would prevent CloudFront from determining with reasonable certainty that the back end connection was being handled by the intended server, and that the origin server is genuinely the server it claims to be, which is one of two protections provided by TLS/SSL (the other protection, of course, is the actual encryption of traffic).
这篇关于cloudfront无法请求行为对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
