X-Amz-Expires是否是必需的标头/参数？官方文档不一致，并在some examples中使用，而不在others中。
如果不需要，签名请求的默认过期值是多少？它是否等于X-Amz-Expires参数的最大可能值，即604800 (seven days)？
文档（参见上面的链接）仅在查询字符串中传递签名参数的上下文中讨论X-Amz-Expires参数。如果需要X-Amz-Expires参数，是否只需要在查询字符串中传递签名参数（而不是使用Authorization标头传递它们）？
更新
Introduction to AWS Security Processes论文，第17页说
请求必须在15分钟内到达AWS 请求中的时间戳。否则，AWS拒绝该请求。
现在我们在这里谈论什么时间戳？我的猜测是X-Amz-Date。如果我是对的，那么另一个问题就出现了：
X-Amz-Date和X-Amz-Expires参数如何相互关联？对我而言，如果X-Amz-Date不存在，请求到期算法会从X-Amz-Expire时间戳回落到15分钟。答案 0 :(得分：9)
X-Amz-Expires是必需的标头/参数吗？
X-Amz-Expires仅用于查询字符串身份验证，而不是Authorization:标头。
查询字符串身份验证没有默认值。这是必需参数，如果查询字符串中存在X-Amz-Algorithm=AWS4-HMAC-SHA256但X-Amz-Expires=...不存在，则服务将拒绝请求。
<Error>
<Code>AuthorizationQueryParametersError</Code>
...
现在我们在这里谈论什么时间戳？
当与X-Amz-Date:标头一起使用时，这指的是Authorization:。由于X-Amz-Date:是签名算法输入的一部分，因此日期或时间的更改也会更改签名。在1秒之前或之后签名的其他相同请求具有完全不同的签名。 AWS基本上允许您的服务器时钟错误最多15分钟，而不会破坏您对请求进行身份验证的能力。它不是后备或默认。这是一个固定的窗口。
AWS将X-Amz-Date: Authorization:个基于标头的请求与其系统时间进行比较，当然系统时间与UTC同步，如果此值大于此值，请求将被拒绝请求到达时，从UTC返回15分钟。在时间检查之前，没有其他与身份验证相关的验证。
验证查询字符串验证过期涉及不同的逻辑：
X-Amz-Expires不得为大于604800或小于0的值;否则，请求会立即被拒绝而无需进一步处理，包括类似于上述消息的消息。X-Amz-Date将来不得超过15分钟。错误为Request is not yet valid。X-Amz-Date过去的秒数不得超过X-Amz-Expires秒，且不适用15分钟的容差。错误为Request has expired。如果出现上述任何一种情况，则不会对签名进行进一步验证，因此这些消息不会根据签名的有效性而改变。首先检查这一点。
此外，X-Amz-Date:的最左边8个字符必须与Credential标题的Authorization:组件的日期部分相匹配。对于凭证的差异，日期本身是零容忍的（因此，在签名时，不要两次读取系统时间，否则您可能会在UTC午夜左右产生偶尔的无效签名）。
最后，请求在处理过程中不会过期。如果您使用签名方法发送请求，该方法在到达时被视为有效但很快就会过期，则始终允许其运行完成 - 例如，大型S3下载或EBS快照创建请求将无法启动，然后无法继续，因为在请求已经在AWS端启动时，到期计时器被触发。如果在请求时授权该操作，则它将继续并正常成功。