签名交换(SXG)

签名交换(SXG)是一种交付机制，它可以独立于资源的交付方式来验证资源的来源。本文提供了SXG的概述。

基于Chromium的浏览器支持SXG(从版本：Chrome 73、Edge 79和Opera 64开始)。

签名交换(SXG)允许站点对请求/响应对(HTTP交换)进行加密签名，从而使浏览器能够独立于内容的分发方式来验证内容的来源和完整性。因此，浏览器可以在地址栏中显示源站点的URL，而不是传递内容的服务器的URL。将内容归属与内容分发分开，可改进各种用例，如隐私保护预取、离线互联网体验和提供来自第三方缓存的内容。

SXG封装在一个二进制编码的文件中，该文件有两个主要组件：HTTP交换和签名。HTTP交换由请求URL、内容协商信息和HTTP响应组成。

格式版本：1B3Request：Method：Get URI：https://example.org/Header：Response：Status：200Header：Cache-Control：Max-Aage=604800摘要：mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY=Expires：Mon，Aug.24 2020 16：08：24 GMT Content-Type：Text/HTML；Charset=Utf-8 Content-Encoding：MI-sha256-03 Date：Mon，Aug 17 2020 16：08：24 GMT Variable：Accept-Encoding Signature：label；cert-sha256=*ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=*；Cert-URL="；Https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE"；；date=1597680503；expires=1598285303；integrity="；digest/mi-sha256-03"；；sig=*MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=*；validity-url="；https://example.org/webpkg/validity"；标头完整性：sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=交换具有有效签名。有效负载[1256字节]：<；！>；SXG示例正文{Background-color：#f0f0f2；March：0；PADDING：0；}您好。

签名中的Expires参数表示SXG的到期日期。ASXG的有效期最长为7天。如果SXG的过期日期在未来超过7天，浏览器将拒绝该SXG。在签名的HTTP Exchange规范中找到有关签名头的更多信息。

SXG是更广泛的WebPackaging规范提案家族的一部分。除了SXG，Web打包规范的另一个主要组件是Web捆绑包(捆绑的HTTP交换)。Web捆绑包是HTTP资源和解释捆绑包所需的元数据的集合。

SXG和Web捆绑包之间的关系是一个共同的混淆之处。SXGS和Web捆绑包是两种截然不同的技术，并不相互依赖-Web捆绑包既可以与签名的交换一起使用，也可以与未签名的交换一起使用。SXGS和Web捆绑包的共同目标是创建一种Web打包格式，允许整个站点共享以供离线消费。

SXG是基于Chromium的浏览器将实现的Web打包规范的第一部分。

最初，SXG的主要用例可能是作为页面主文档的交付机制。对于此用例，可以使用<；link>；或<；a>；标记以及LinkHeader引用SXG。

尽管理论上可以使用<；脚本>；或<；img>；标记引用SXG，但这不是使用SXG加载子资源的推荐方法。对SXG子资源加载的工具支持还不够成熟，因此本文档不涉及此用例-不过，您可以在签名Exchange子资源替代中阅读更多信息。

与其他资源一样，SXG可以通过在浏览器的地址栏中输入其URL来加载。

内容协商是一种机制，用于根据客户端的能力和偏好在相同的URL上提供相同资源的不同表示-例如，将资源的gzip版本提供给一些客户端，但将Brotli版本提供给其他客户端。内容协商使得根据浏览器的功能同时提供相同内容的SXG和非SXG表示成为可能。

Web浏览器使用AcceptRequest头来传达它们支持的MIME类型。如果浏览器支持SXGS，则MIME类型应用程序/签名交换将自动包括在此值列表中。

该字符串的application/sign-exchange；v=b3；q=0.9部分通知Web服务器Chrome支持SXGS-具体地说是b3版本。最后一部分q=0.9表示Q值。

Q值使用从0到1的小数位数表示浏览器对特定格式的相对偏好，1代表最高优先级。当没有为格式提供Q值时，1是隐含的值。

当Accept报头指示应用程序/签名交换的Q值大于或等于text/html的Q值时，服务器应该服务SXG。

以下正则表达式可用于匹配应用作SXG的请求的Accept标头：

请注意，子表达式(，|$)与省略了SXG的q值的头匹配；此省略意味着SXG的q值为1。尽管理论上Accept标头可以包含子字符串q=1，但实际上浏览器不会显式列出具有默认值1的格式的Q值。

可以通过在Chrome DevTools的“网络”面板的“类型”列中查找已签名的交换来标识已签名的交换。

从高层次上讲，实现SXG包括生成对应于给定URL的SXG，然后将该SXG提供给用户。要生成SXG，您需要一个可以签署SXG的证书。

证书将实体与公钥相关联。使用证书对SXG进行签名允许内容与实体相关联。

SXG的生产使用需要支持CanSignHttpExchange扩展的证书。根据规范，具有此扩展的证书的有效期不能超过90天，并且要求请求域配置了DNS CAArecord.。

此页列出了可以颁发此类证书的证书颁发机构。SXG的证书只能通过商业证书颁发机构获得。

Web Packager是一个开源的、基于Go的工具，它实际上是生成(打包)签名交换的工具。您可以使用它手动创建SXG，也可以将其用作自动创建和服务SXG的服务器。Web Packager目前处于Alpha版本。

生成SXG文件后，将其上传到您的服务器，并使用application/sign-exchange；v=b3MIME类型提供它。

Web Packagerserver(Webpkgserver)充当服务SXG的反向代理。给定URL后，webpkgserver将获取URL的内容，将其打包为SXG，并作为响应提供SXG。

在上面的示例中，运行在localhost：8080上的webpkgserver实例将把https://example.com的内容作为sxg返回。/priv/doc/是webpkgserver端点的默认名称。使用webpkgserver配置文件自定义此终结点的名称以及许多其他设置。

在生产中，webpkgserver不应使用公共端点。相反，前端Web服务器应该将SXG请求转发到webpkgserver。这些建议包含有关在前端边缘服务器后面运行webpkgserver的更多信息。

Nginx SXG模块生成并服务于SXG。已经使用Nginx的站点应该考虑使用此模块，而不是Web Packager Server。

Gen-SigneDexchange是WebPackage规范提供的一个工具，作为生成SXG的参考实现。由于功能集有限，gen-signeexchange对于尝试SXG很有用，但对于更大规模和生产用途则不切实际。