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