PROSAGA码农传奇-CDN-CloudFlare或AWS CDN链接

<div class =“post-text”itemprop =“text”>
  
    使用CloudFront的简单解决方案需要稍微改变路径设计：
  
  
    桶：
  
   <pre>
 <code>
 /1.1.9/v1/foo

</code>
 </pre>
  
    浏览器：
  
   <pre>
 <code>
 /v1/foo

</code>
 </pre>
  
    CloudFront Origin Path（在Origin选项卡上）
  
   <pre>
 <code>
 /1.1.9

</code>
 </pre>
  
    无论您配置什么原因路径都添加到
    
      开始
    
     在将请求发送到Origin服务器之前请求的浏览器。
  
  
    请注意，更改此值意味着您还需要执行缓存失效，因为响应是根据请求的内容缓存的，而不是基于所获取的内容。
  
  
    这里有一个潜在的竞争条件，在您更改配置和无效之间 - 配置更改和无效请求之间的操作顺序没有相关性 - 配置更改
    
      其次是
    
     ，失效可能在完成后完成，？因此可能需要使无效，更新配置，无效，验证分发已进展稳定状态，然后再次失效。您不需要单独使对象无效
     <code>
 /*
 </code>
     要么
     <code>
 /v1*
 </code>
    。如果只有直接请求的资源受重写影响最好，而不是它的依赖性。还要记住，浏览器缓存是一个很大的成本节省，如果您使用相同的请求URI来表示不同的对象，则无法充分利用它。
  
  
    CloudFront中更复杂的路径重写需要Lambda @ Edge Origin Request触发器（或者您可以使用Viewer Request，但这些更频繁地运行，因此成本更高，并增加整体延迟）。
  
  <HR />
  
    ？失效请求 - 虽然没有记录，并且严格来说是轶事 - 似乎涉及一些时间旅行。失效是带时间戳的，看起来它们使在时间戳之前缓存的任何内容无效，而不是在它们传播到边缘位置之前。在架构上，如果设计CloudFront使得失效不主动清除内容，但仅作为缓存的指令，将任何缓存的对象视为过时，如果它在失效请求之前的时间戳上预先设定，则允许实际清除在后台进行。对于任何其他解释，失效似乎完成得太快。这意味着在分配返回稳定后创建无效请求
     <code>
 Deployed
 </code>
     state会确保旧的所有内容都被清除，并且最初提交更改时的另一个失效请求将捕获可能在传播更改之前从缓存中提供的大多数straggler。根据观察到的完成时间，变化和失效似乎确实通过独立的管道传播到边缘。
  
</DIV>