首页 文章

URL片段和302重定向

提问于
浏览 次
125

众所周知，URL片段（ # 之后的部分）不会发送到服务器 .

我确实想知道当涉及服务器重定向（通过HTTP状态302和 Location: 标头）时片段如何工作 .

我的问题实际上是双重的：

  • 如果原始URL有一个片段（ /original.php#foo ），并且重定向到 /new.php ，那么原始URL的片段部分是否会丢失？或者它有时会应用到新的URL？
    在这种情况下，新URL是否会 /new.php#foo ？

  • 无论原始URL如何，如果服务器重定向到带有片段的新URL（ /new.php#foo ），片段是否会获得"honored"？或者服务器真的没有任何业务干扰片段 - 因此浏览器会忽略它，只需转到 /new.php ??

redirect fragment-identifier http-redirect

3 回答

  • 38

    Update 2014-Jun-27 ：

    RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content，已作为建议标准发布 . 来自Changelog：

    Location头字段的语法已更改为允许所有URI引用，包括相对引用和片段，以及关于何时使用片段不合适的一些说明 . （第7.1.2节）

    Section 7.1.2. Location的重点：

    如果3xx（重定向）响应中提供的Location值没有片段组件，则用户代理必须处理重定向，就好像该值继承了用于生成请求目标的URI引用的片段组件（即重定向）继承原始引用的片段（如果有的话） . 例如，为URI引用“http://www.example.org/~tim”生成的GET请求可能会生成包含 Headers 字段的303（请参阅其他）响应：Location：/People.html#tim
    这表明用户代理重定向到“http://www.example.org/People.html#tim”同样，为URI引用生成的GET请求“http://www.example.org/index.html# larry“可能会产生包含 Headers 字段的301（永久移动）响应：位置：http：//www.example.net/index.html
    这表明用户代理重定向到“http://www.example.net/index.html#larry”，保留原始片段标识符 .

    这应该清楚地回答你的问题 .

    Update END

    这是current HTTP specification的开放（未指定）问题 . 它在IETF httpbis working group的2个问题中得到解决：

    ＃6允许 Location 标头中的片段 . ＃43说：

    我刚用各种浏览器测试过这个 . Firefox和Safari使用位置 Headers 中的片段 . Opera使用来自源URI的片段，当存在时，否则来自重定向位置IE（8）的片段忽略位置URI中的片段，因此将使用来自源URI的片段，当存在时Proposal：“注意：行为当原始URI和重定向需要组合的片段标识符未定义时;当前用户代理确实在哪个片段优先级上有所不同 . “ [...]似乎IE8确实使用了Location中的片段idenfitier（我看到的行为可能仅限于localhost） . 因此，我们似乎对Safari / IE / Firefox / Chrome（刚刚测试过）具有一致的行为，因为无论原始URI是什么，都会使用Location头中的片段 . 因此，我改变了我的建议，将其记录为预期的行为 .

    这导致了大多数浏览器兼容和未来证明（因为这个问题最终会标准化）回答你的问题：

    来自原始URL的 A: 片段将被丢弃 .

    来自 Location Headers 的 B: 片段受到尊重 .

    回复于
  • 9

    如果发生HTTP / 3xx重定向，Safari 5和IE9及更低版本将丢弃原始URI的片段 . 如果响应上的Location标头指定了一个片段，则使用它 .

    IE10，Chrome 11，Firefox 4和Opera将在执行3xx重定向后“重新附加”原始URI的片段 .

    测试页：http://www.webdbg.com/test/redir/fragment/ .

    请参阅http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx进一步讨论此问题

    回复于
  • 123

    只是为了让您知道，在这里您可以找到合适的规格 . 通过w3c定义所有应该如何表现：http://www.w3.org/TR/cuap#uri - 第4.1条 - 见下文：

    当资源（URI1）移动时，HTTP重定向可以指示其新位置（URI2） . 如果URI1具有片段标识符#frag，那么用户代理应该尝试访问的新目标将是URI2＃frag . 如果URI2已经有片段标识符，则不得附加#frag，新目标为URI2 . 错误：大多数当前用户代理确实实现了HTTP重定向但不将片段标识符附加到新URI，这通常会使用户感到困惑，因为他们最终会使用错误的资源 . 参考：HTTP重定向在HTTP / 1.1规范[RFC2616]的第10.3节中描述 . “重定向URL中的片段标识符的处理”[RURL]中详细描述了所需的行为 . 术语“持久统一资源定位符（PURL）”指定通过HTTP重定向指向另一个URL的URL（URI的特殊情况） . 有关更多信息，请参阅“持久统一资源定位器”[PURL] . 示例：假设用户在http://www.w3.org/TR/WD-ruby/#changes上请求资源，服务器将用户代理重定向到http://www.w3.org/TR/ruby/ . 在获取后一个URI之前，浏览器应该将片段标识符#changes附加到它：http：//www.w3.org/TR/ruby/#changes .

    回复于

相关问题