【问题标题】:RFC7231 - Content-Location must be verified by other meansRFC7231 - Content-Location 必须通过其他方式验证
【发布时间】:2019-11-12 20:26:58
【问题描述】:

我正在阅读此 RFC,并发现我在 google-webs 上看不到任何信息。 Section 3.1.4.1. Identifying a Representation有段位:

如果响应具有 Content-Location 标头字段,并且其字段值是对不同于有效请求 URI 的 URI 的引用,则发送者断言有效负载是由 Content-Location 标识的资源的表示字段值。但是,除非可以通过其他方式(未由本 规范)。

通过什么其他方式可以验证这种表示?

【问题讨论】:

    标签: http security http-headers web-development-server rfc


    【解决方案1】:

    规范在这一点上说得更多further down

    如果Content-Location 包含在2xx(成功)响应消息中,并且其字段值引用的URI 与有效请求URI 不同,则源服务器声称该URI 是不同的标识符对应于封闭表示的资源。只有当两个标识符共享同一资源所有者时,才能信任此类声明,而这无法通过 HTTP 以编程方式确定。

    因此,如果请求的资源和 Content-Location 资源具有相同的所有者,则您可以信任该声明。你是怎么确定的?

    可以想象编程方式,例如检查相应 URL 提供的证书。但在实践中,我怀疑这归结为客户使用简单的规则来决定信任谁。例如,如果Content-Location URI 与资源具有相同的域,则您可能会决定该声明是可信的。

    或者,您可以选择隐式信任某些列入白名单的域提出的任何 Content-Location 声明。例如,Instagram 应用可能会信任其中一台 Instagram 服务器提出的任何声明。

    【讨论】:

      猜你喜欢
      • 2015-05-10
      • 1970-01-01
      • 2020-09-14
      • 2012-05-04
      • 1970-01-01
      • 2011-06-17
      • 2011-10-17
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多