blocks|key|3060737|text|更新2014-6月27日|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3060738|RFC+7231,+Hypertext+Transfer+Protocol+(HTTP/1.1):+Semantics+and+Content，已作为建议标准发布。从Changelog|3060739|3060740|位置标头字段的语法已更改，以允许所有URI引用，包括相对引用和片段，同时还澄清了何时不适合使用片段。(第7.1.2节)|blockquote|3060741|3060742|3060743|来自Section+7.1.2.+Location的要点|3060744|3060745|如果3xx+(重定向)响应中提供的位置值没有片段组件，则用户代理必须处理重定向，就好像该值继承了用于生成请求目标的URI引用的片段组件(即，重定向继承了原始引用的片段(如果有的话))。例如，为URI引用"http://www.example.org/~tim“生成的GET请求可能会导致包含头字段的303+(请参阅其他)响应：|3060746|3060747|位置:+/People.html#tim|3060748|它建议用户代理重定向到"http://www.example.org/People.html#tim“。|3060749|同样，为URI引用"http://www.example.org/index.html#larry“生成的GET请求可能导致包含头字段的301+(永久移动)响应：|3060750|位置：http://www.example.net/index.html|3060751|其建议用户代理重定向到"http://www.example.net/index.html#larry"“，保留原始片段标识符。|3060752|3060753|这应该可以清楚地回答您的问题。|3060754|更新结束|3060755|这是current+HTTP+specification的一个开放(未指定)问题。在IETF+httpbis+working+group的两期中对此进行了讨论|3060756|3060757|#6:+|unordered-list-item|3060758|#43:+|3060759|3060760|#6允许在Location报头中包含片段。#43说：|CODE|3060761|我刚刚在不同的浏览器上测试了这一点。|3060762|3060763|Firefox和Safari使用位置中的片段当存在时使用来自源URI的片段，否则来自重定向位置|3060764|IE+(8)的片段忽略位置URI中的片段，因此当存在|3060765|时将使用来自源URI的片段|3060766|3060767|+Proposal：“注意:来自原始URI的片段标识符和重定向需要组合的行为是未定义的；当前的用户代理确实在哪个片段优先的问题上存在差异。”...看起来IE8确实使用了与Location相同的片段(我看到的行为可能仅限于本地主机)。因此，我们似乎对Safari/IE/Firefox/Chrome+(刚刚测试的)具有一致的行为，因为无论原始URI是什么，都会使用Location头中的片段。因此，我更改了我的建议，将其记录为预期行为。|3060768|3060769|3060770|这将导致最兼容的浏览器和未来的证据(因为这个问题最终将得到标准化)对您的问题的答案：|3060771|A:来自原始URL的片段被丢弃。|3060772|B:接受来自Location标头的片段。|3060773|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc7231|1|https://www.rfc-editor.org/rfc/rfc7231#appendix-B|2|https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2|3|http://www.example.org/~tim|4|http://www.example.org/People.html#tim|5|http://www.example.org/index.html#larry|6|http://www.example.net/index.html|7|http://www.example.net/index.html#larry|8|https://www.rfc-editor.org/rfc/rfc2616|9|http://www.ietf.org/dyn/wg/charter/httpbis-charter.html|10|http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6|11|http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43^0|0|C|0|0|1Z|0|2B|9|1|0|0|0|0|0|2|N|2|0|0|2U|R|3|0|0|0|C|12|4|0|A|13|5|0|3|X|6|0|C|14|7|0|0|0|0|4|0|2|Q|8|16|Q|9|0|0|0|4|A|0|0|5|B|0|0|5|8|0|0|0|0|0|0|0|2D|8|0|0|0|0|0|A|0|0|H|6|8|0^^$0|@$1|2|3|4|5|6|7|2Y|8|@$9|2Z|A|30|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|31|8|@]|D|@$9|32|A|33|1|34]|$9|35|A|36|1|37]]|E|$]]|$1|H|3|-4|5|6|7|38|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|39|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|3A|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|3B|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|3C|8|@]|D|@$9|3D|A|3E|1|3F]]|E|$]]|$1|P|3|-4|5|6|7|3G|8|@]|D|@]|E|$]]|$1|Q|3|R|5|K|7|3H|8|@]|D|@$9|3I|A|3J|1|3K]]|E|$]]|$1|S|3|-4|5|6|7|3L|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|3M|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|3N|8|@]|D|@$9|3O|A|3P|1|3Q]]|E|$]]|$1|X|3|Y|5|6|7|3R|8|@]|D|@$9|3S|A|3T|1|3U]]|E|$]]|$1|Z|3|10|5|6|7|3V|8|@]|D|@$9|3W|A|3X|1|3Y]]|E|$]]|$1|11|3|12|5|6|7|3Z|8|@]|D|@$9|40|A|41|1|42]]|E|$]]|$1|13|3|-4|5|6|7|43|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|44|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|45|8|@$9|46|A|47|B|C]]|D|@]|E|$]]|$1|18|3|19|5|6|7|48|8|@]|D|@$9|49|A|4A|1|4B]|$9|4C|A|4D|1|4E]]|E|$]]|$1|1A|3|-4|5|6|7|4F|8|@]|D|@]|E|$]]|$1|1B|3|1C|5|1D|7|4G|8|@]|D|@$9|4H|A|4I|1|4J]]|E|$]]|$1|1E|3|1F|5|1D|7|4K|8|@]|D|@$9|4L|A|4M|1|4N]]|E|$]]|$1|1G|3|-4|5|6|7|4O|8|@]|D|@]|E|$]]|$1|1H|3|1I|5|6|7|4P|8|@$9|4Q|A|4R|B|1J]]|D|@]|E|$]]|$1|1K|3|1L|5|6|7|4S|8|@]|D|@]|E|$]]|$1|1M|3|-4|5|6|7|4T|8|@]|D|@]|E|$]]|$1|1N|3|1O|5|1D|7|4U|8|@]|D|@]|E|$]]|$1|1P|3|1Q|5|1D|7|4V|8|@]|D|@]|E|$]]|$1|1R|3|1S|5|6|7|4W|8|@]|D|@]|E|$]]|$1|1T|3|-4|5|6|7|4X|8|@]|D|@]|E|$]]|$1|1U|3|1V|5|K|7|4Y|8|@$9|4Z|A|50|B|1J]]|D|@]|E|$]]|$1|1W|3|-4|5|6|7|51|8|@]|D|@]|E|$]]|$1|1X|3|-4|5|6|7|52|8|@]|D|@]|E|$]]|$1|1Y|3|1Z|5|6|7|53|8|@]|D|@]|E|$]]|$1|20|3|21|5|6|7|54|8|@$9|55|A|56|B|C]]|D|@]|E|$]]|$1|22|3|23|5|6|7|57|8|@$9|58|A|59|B|C]|$9|5A|A|5B|B|1J]]|D|@]|E|$]]|$1|24|3|-4|5|6|7|5C|8|@]|D|@]|E|$]]]|25|$26|$5|27|28|29|E|$2A|2B]]|2C|$5|27|28|29|E|$2A|2D]]|2E|$5|27|28|29|E|$2A|2F]]|2G|$5|27|28|29|E|$2A|2H]]|2I|$5|27|28|29|E|$2A|2J]]|2K|$5|27|28|29|E|$2A|2L]]|2M|$5|27|28|29|E|$2A|2N]]|2O|$5|27|28|29|E|$2A|2P]]|2Q|$5|27|28|29|E|$2A|2R]]|2S|$5|27|28|29|E|$2A|2T]]|2U|$5|27|28|29|E|$2A|2V]]|2W|$5|27|28|29|E|$2A|2X]]]]

Update 2014-Jun-27:
<a href="https://www.rfc-editor.org/rfc/rfc7231" rel="nofollow noreferrer">RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>, has been published as a PROPOSED STANDARD. From the <a href="https://www.rfc-editor.org/rfc/rfc7231#appendix-B" rel="nofollow noreferrer">Changelog</a>:
<blockquote>
The syntax of the Location header field has been changed to allow all
URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be
appropriate. (Section 7.1.2)
</blockquote>
The important points from <a href="https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2" rel="nofollow noreferrer">Section 7.1.2. Location</a>:
<blockquote>
If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the URI
reference used to generate the request target (i.e., the redirection
inherits the original reference's fragment, if any).
</blockquote>
<blockquote>
For example, a
GET request generated for the URI reference
&quot;http://www.example.org/~tim&quot; might result in a 303 (See Other)
response containing the header field:
<pre><code>Location: /People.html#tim
</code></pre>
which suggests that the user agent redirect to
&quot;http://www.example.org/People.html#tim&quot;
Likewise, a GET request generated for the URI reference
&quot;http://www.example.org/index.html#larry&quot; might result in a 301 (Moved
Permanently) response containing the header field:
<pre><code>Location: http://www.example.net/index.html
</code></pre>
which suggests that the user agent redirect to
&quot;http://www.example.net/index.html#larry&quot;, preserving the original
fragment identifier.
</blockquote>
This should clearly answer your questions.
Update END
this is an open (not specified) issue with the <a href="https://www.rfc-editor.org/rfc/rfc2616" rel="nofollow noreferrer">current HTTP specification</a>. it is addressed in 2 issues of the <a href="http://www.ietf.org/dyn/wg/charter/httpbis-charter.html" rel="nofollow noreferrer">IETF httpbis working group</a>:
<ul>
<li><a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6" rel="nofollow noreferrer">#6: Fragments allowed in Location</a></li>
<li><a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43" rel="nofollow noreferrer">#43: Fragment combination / precedence during redirects</a></li>
</ul>
#6 allows fragments in the <code>Location</code> header. #43 says this:
<blockquote>
I just tested this with various browsers.
</blockquote>
<blockquote>
<ul>
<li>Firefox and Safari use the fragment in the location header.</li>
<li>Opera uses the fragment from the source URI, when present, otherwise the fragment from the redirect location</li>
<li>IE (8) ignores the fragment in the location URI, thus will use the fragment from the source URI, when present</li>
</ul>
</blockquote>
<blockquote>
Proposal:
</blockquote>
<blockquote>
&quot;Note: the behavior when fragment identifiers from the original URI and the redirect need to be combined is undefined; current User Agents indeed differ on what fragment takes precedence.&quot;
</blockquote>
<blockquote>
[...]
</blockquote>
<blockquote>
It appears that IE8 does use the fragment idenfitier from <code>Location</code> (the behavior I saw might be limited to localhost).
</blockquote>
<blockquote>
Thus we seem to have consistent behavior for Safari/IE/Firefox/Chrome (just tested), in that the fragment from the Location header gets used, no matter what the original URI was.
</blockquote>
<blockquote>
I therefore change my proposal to document that as expected behavior.
</blockquote>
this leads to the most browser compatible and future proof (because this issue will eventually get standardized) answer to your question:
A: fragments from original URLs get discarded.
B: fragments from the <code>Location</code> header are honored.

blocks|key|315894|text|如果发生HTTP/3xx重定向，Safari5和IE9及更低版本会丢弃原始URI的片段。如果响应上的Location标头指定了一个片段，则使用该片段。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|315895|IE10%2B、Chrome+11%2B、火狐4%2B和Opera都将在3xx重定向之后“重新附加”原始URI的片段。|315896|测试页面：http://www.webdbg.com/test/redir/fragment/。|offset|length|315897|有关此问题的进一步讨论，请访问http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx|315898|entityMap|0|LINK|mutability|MUTABLE|url|http://www.webdbg.com/test/redir/fragment/|1|http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx^0|0|0|5|16|0|0|F|2Z|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$F|W|G|X|1|Y]]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$F|10|G|11|1|12]]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

Safari 5 and IE9 and below drop the original URI's fragment if a HTTP/3xx redirect occurs. If the Location header on the response specifies a fragment, it is used.

IE10+, Chrome 11+, Firefox 4+, and Opera will all "reattach" the original URI's fragment after following a 3xx redirection.

Test page: <a href="http://www.webdbg.com/test/redir/fragment/" rel="noreferrer">http://www.webdbg.com/test/redir/fragment/</a>.

See further discussion of this issue at <a href="http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx" rel="noreferrer">http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx</a>

blocks|key|3274057|text|只想让你知道，你可以在这里找到合适的规格。由w3c定义所有人的行为方式：http://www.w3.org/TR/cuap#uri+-第4.1条-见下文：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3274058|当资源(URI1)已移动时，|3274059|重定向可以指示其新位置(URI2)。|blockquote|3274060|3274061|如果URI1有一个片段标识符#frag，那么用户代理应该尝试到达的新目标应该是URI2#frag。如果URI2已经有了片段标识符，则不能附加#frag，并且新目标为URI2。|3274062|错误:大多数当前的用户代理确实实现了HTTP重定向，但没有将片段标识符附加到新的URI，这通常会使用户感到困惑，因为它们最终得到了错误的资源。|3274063|参考文献：|3274064|HTTP重定向在HTTP1.1规范RFC2616的第10.3节中进行了描述。所需的行为在“处理重定向RURL中的片段标识符”RURL中详细描述。术语“永久统一资源定位符(PURL)”表示通过HTTP重定向指向另一个URL的URL(URI的特例)。有关更多信息，请参阅“持久统一资源定位器”PURL。示例：|3274065|假设用户在http://www.w3.org/TR/WD-ruby/#changes请求资源，服务器将用户代理重定向到http://www.w3.org/TR/ruby/。在获取后一个URI之前，浏览器应该将片段标识符#changes附加到它后面：http://www.w3.org/TR/ruby/#changes.|3274066|entityMap|0|LINK|mutability|MUTABLE|url|http://www.w3.org/TR/cuap#uri|1|http://www.w3.org/TR/WD-ruby/#changes|2|http://www.w3.org/TR/ruby/|3|http://www.w3.org/TR/ruby/#changes^0|10|T|0|0|0|0|0|0|0|0|0|5|11|1|1N|Q|2|3G|Y|3|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|D|3|E|5|6|7|1B|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1C|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1E|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1G|8|@]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1H|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|1I|8|@]|9|@$A|1J|B|1K|1|1L]|$A|1M|B|1N|1|1O]|$A|1P|B|1Q|1|1R]]|C|$]]|$1|T|3|-4|5|6|7|1S|8|@]|9|@]|C|$]]]|U|$V|$5|W|X|Y|C|$Z|10]]|11|$5|W|X|Y|C|$Z|12]]|13|$5|W|X|Y|C|$Z|14]]|15|$5|W|X|Y|C|$Z|16]]]]

Just to let you know, here you can find proper spec. by w3c defining how all should behave: <a href="http://www.w3.org/TR/cuap#uri" rel="noreferrer">http://www.w3.org/TR/cuap#uri</a> - clause 4.1 - see below:

<blockquote>
 When a resource (URI1) has moved, an HTTP redirect can indicate its
 new location (URI2).
 
 If URI1 has a fragment identifier #frag, then the new target that the
 user agent should be trying to reach would be URI2#frag. If URI2
 already has a fragment identifier, then #frag must not be appended and
 the new target is URI2.
 
 Wrong: Most current user agents do implement HTTP redirects but do not
 append the fragment identifier to the new URI, which generally
 confuses the user because they end up with the wrong resource.
 
 References:
 
 HTTP redirects are described in section 10.3 of the HTTP/1.1
 specification [RFC2616]. The required behavior is described in detail
 in "Handling of fragment identifiers in redirected URLs" [RURL]. The
 term "Persistent Uniform Resource Locator (PURL)" designates a URL (a
 special case of a URI) that points to another one through an HTTP
 redirect. For more information, refer to "Persistent Uniform Resource
 Locators" [PURL]. Example:
 
 Suppose that a user requests the resource at
 <a href="http://www.w3.org/TR/WD-ruby/#changes" rel="noreferrer">http://www.w3.org/TR/WD-ruby/#changes</a> and the server redirects the
 user agent to <a href="http://www.w3.org/TR/ruby/" rel="noreferrer">http://www.w3.org/TR/ruby/</a>. Before fetching that latter
 URI, the browser should append the fragment identifier #changes to it:
 <a href="http://www.w3.org/TR/ruby/#changes" rel="noreferrer">http://www.w3.org/TR/ruby/#changes</a>.
</blockquote>

blocks|key|313851|text|发布我所面对的类似的issue+with+the+solution。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|313852|希望它能帮助那些对302重定向有类似preserving+hash+in+IE要求的人。|style|CODE|313853|添加答案的基本部分，而不是仅添加链接|313854|我们在应用程序中使用SiteMinder身份验证。|313855|我发现在成功认证之后，SiteMinder通过使用登录表单隐藏变量SiteMinder+302+redirection到用户请求的应用程序页面(它存储用户请求的URL+/myapp/+-+without+hash+fragment，因为它不会被发送到服务器)，名称类似于redirect。下面的示例表单|BOLD|313856|​|313857|📷|atomic|313858|313859|由于redirect隐藏变量value只包含没有散列片段的/myapp/，并且它是一个302重定向，因此即使在进入我们的应用程序之前，IE也会自动删除散列片段，无论我们在应用程序代码中尝试什么解决方案都不起作用。|313860|IE仅重定向到/myapp/，并在我们的应用程序https://ourapp.com/myapp/#/home的默认主页上登陆。|313861|已经浪费了几乎一天的时间来弄清楚这种行为。|313862|解决方案是：|313863|更改了登录表单+hidden+variable+(redirect)散列值，通过附加window.location.hash和现有值来保存散列片段。类似于下面的代码|313864|$(function+()+{
++var+$redirect+=+$('input[name="redirect"]');
++$redirect.val($redirect.val()+%2B+window.location.hash);
});|code-block|syntax|javascript|313865|在此更改之后，redirect隐藏变量将用户请求的URL值存储为/myapp/#/pending/requests，并且SiteMinder将其重定向到IE中的/myapp/#/pending/requests。|313866|上面的解决方案在所有三种浏览器+Chrome,+Firefox+and+IE**.**中都工作得很好|313867|感谢@AlexFord为这个问题提供了detailed+explanation+and+providing+solution。|313868|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/62917034/url-hash-fragment-removed-by-ie-after-302-redirect|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/4f40587f941a248dc62178a99dd7f812.png|imageAlt|2|https://chevtek.io/how-to-persist-url-hash-fragments-across-a-login-redirect^0|A|N|0|0|I|L|0|0|A|A|0|B|A|X|A|18|F|2C|7|2M|L|3R|8|P|I|18|2Z|0|0|1|0|0|1|0|1|1|0|0|1|0|0|2Y|2|8|T|7|0|0|1S|7|7|O|V|0|0|L|0|0|6|0|0|11|P|8|16|K|0|0|7|8|W|P|1O|A|28|P|0|0|F|G|O|G|M|0|J|17|2|0^^$0|@$1|2|3|4|5|6|7|1V|8|@]|9|@$A|1W|B|1X|1|1Y]]|C|$]]|$1|D|3|E|5|6|7|1Z|8|@$A|20|B|21|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|22|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|23|8|@$A|24|B|25|F|G]]|9|@]|C|$]]|$1|L|3|M|5|6|7|26|8|@$A|27|B|28|F|G]|$A|29|B|2A|F|G]|$A|2B|B|2C|F|G]|$A|2D|B|2E|F|G]|$A|2F|B|2G|F|G]|$A|2H|B|2I|F|G]|$A|2J|B|2K|F|N]|$A|2L|B|2M|F|N]]|9|@]|C|$]]|$1|O|3|P|5|6|7|2N|8|@$A|2O|B|2P|F|N]]|9|@]|C|$]]|$1|Q|3|R|5|S|7|2Q|8|@$A|2R|B|2S|F|N]]|9|@$A|2T|B|2U|1|2V]]|C|$]]|$1|T|3|P|5|6|7|2W|8|@$A|2X|B|2Y|F|N]]|9|@]|C|$]]|$1|U|3|V|5|6|7|2Z|8|@$A|30|B|31|F|N]|$A|32|B|33|F|G]|$A|34|B|35|F|G]]|9|@]|C|$]]|$1|W|3|X|5|6|7|36|8|@$A|37|B|38|F|N]|$A|39|B|3A|F|G]|$A|3B|B|3C|F|G]]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|3D|8|@$A|3E|B|3F|F|N]]|9|@]|C|$]]|$1|10|3|11|5|6|7|3G|8|@$A|3H|B|3I|F|N]]|9|@]|C|$]]|$1|12|3|13|5|6|7|3J|8|@$A|3K|B|3L|F|N]|$A|3M|B|3N|F|G]|$A|3O|B|3P|F|G]]|9|@]|C|$]]|$1|14|3|15|5|16|7|3Q|8|@]|9|@]|C|$17|18]]|$1|19|3|1A|5|6|7|3R|8|@$A|3S|B|3T|F|G]|$A|3U|B|3V|F|G]|$A|3W|B|3X|F|G]|$A|3Y|B|3Z|F|G]]|9|@]|C|$]]|$1|1B|3|1C|5|6|7|40|8|@$A|41|B|42|F|N]|$A|43|B|44|F|N]|$A|45|B|46|F|G]]|9|@]|C|$]]|$1|1D|3|1E|5|6|7|47|8|@]|9|@$A|48|B|49|1|4A]]|C|$]]|$1|1F|3|-4|5|6|7|4B|8|@]|9|@]|C|$]]]|1G|$1H|$5|1I|1J|1K|C|$1L|1M]]|1N|$5|1O|1J|1P|C|$1Q|1R|1S|-4]]|1T|$5|1I|1J|1K|C|$1L|1U]]]]

Posting similar <a href="https://stackoverflow.com/questions/62917034/url-hash-fragment-removed-by-ie-after-302-redirect">issue with the solution</a> faced by me.
Hope it helps to someone with the similar requirement of <code>preserving hash in IE</code> for 302 redirects.
<h3>Adding essential parts of the answer instead of links alone</h3>
We use <code>SiteMinder</code> authentication in our application.
I figured out that after successful authentication, <code>SiteMinder</code> is doing <code>302 redirection</code> to user requested application page by using login form hidden variable <code>value</code> (where it stores user requested URL <code>/myapp/</code> - <code>without hash fragment</code> since it won't be sent to the server) with name similar to <code>redirect</code>. Sample form below
<a href="https://i.stack.imgur.com/J6XLs.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/J6XLs.png" alt="Sample login form" /></a>
Since <code>redirect</code> hidden variable value contains only <code>/myapp/</code> without hash fragment and it's a 302 redirect, the hash fragment is automatically removed by IE even before coming to our application and whatever the solutions we are trying in our application code are not working out.
IE is redirecting to <code>/myapp/</code> only and it is landing on default home page of our app <code>https://ourapp.com/myapp/#/home</code>.
Have wasted almost a day to figure out this behavior.
<h3>The solution is:</h3>
Have changed the login form hidden variable (<code>redirect</code>) value to hold the hash fragment by
appending <code>window.location.hash</code> along with existing value. Similar to below code
<pre class="lang-js prettyprint-override"><code>$(function () {
 var $redirect = $('input[name=&quot;redirect&quot;]');
 $redirect.val($redirect.val() + window.location.hash);
});
</code></pre>
After this change, the <code>redirect</code> hidden variable is storing user requested URL value as <code>/myapp/#/pending/requests</code> and <code>SiteMinder</code> is redirecting it to <code>/myapp/#/pending/requests</code> in IE.
The above solution is working fine in all the three browsers <code>Chrome, Firefox and IE</code>.
Thanks to @AlexFord for the <a href="https://chevtek.io/how-to-persist-url-hash-fragments-across-a-login-redirect" rel="nofollow noreferrer">detailed explanation and providing solution</a> to this issue.

It's well known that the URL fragment (the part after the <code>#</code>) is not sent to the server. 

I do wonder though how fragments work when a server redirect (via HTTP status 302 and <code>Location:</code> header) is involved.

My question is really two-fold:

<ol>
<li>If the original URL had a fragment (<code>/original.php#foo</code>), and a redirect is made to <code>/new.php</code>, does the fragment part of the original URL simply get lost? Or does it sometimes get applied to the new URL? Will the new URL ever be <code>/new.php#foo</code> in this case?</li>
<li>Regardless of the original URL, if the server redirects to a new URL with a fragment (<code>/new.php#foo</code>), will the fragment get "honored"? Or does the server really have no business interfering with the fragment at all -- and will the browser therefore ignore it by simply going to <code>/new.php</code>??</li>
</ol>

URL Fragment and 302 redirects

众所周知，URL片段(#之后的部分)不会发送到服务器。我想知道当涉及到服务器重定向(通过HTTP status 302和Location:头)时，片段是如何工作的。我的问题实际上有两个方面：如果原始URL有一个片段(/original.php#foo)，并且重定向到/new.php，那么原始URL的片段部分会丢失吗？或...

问URL片段和302重定向
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问URL片段和302重定向EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问URL片段和302重定向
EN