再谈url的井号
先前写了一篇文章，简要的介绍了工作中遇到的有关井号的问题。可参照url中的井号
但今天又发现了新的问题。
假设一个url是这样的/view/1.html#fragment，井号后面的内容是不传给server端的，而server端给出的 301 location是：/view/1.htm，那么浏览器最终跳转到的url应该是/view/1.htm#fragment，还是/view/1.htm呢？在浏览器上试了下，发现在chrome18中是跳转到/view/1.htm#fragment，也就是加上了井号（#）后面的内容，而在IE8中，是直接跳到了/view/1.htm，丢掉了井号（#）后面的内容。
遂就翻阅rfc，看看在http中有没有关于重定向时framgment的规定，发现了这样一份草稿，看来rfc中并没有关于井号的规定,下面截取两段：http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt
开始阐述了http1.1中并没有明确规定关于井号标识符的使用：
But HTTP 1.1 doesn't talk explicitly about fragment identifiers, which has resulted in the sad fact that at the time of writing, there are clients that drop the fragment identifier upon a redirect. Anecdotal evidence suggests that in fact only about one third of Web browsers re-applies the fragment identifier to the redirected URL. This draft therefore explains how to apply the fragment identifier in case of a redirection.
后又阐述了本草稿的规定：
If the server returns a response code of 300 ("multiple choice"), 301
("moved permanently"), 302 ("moved temporarily") or 303 ("see
other"), and if the server also returns one or more URIs where the
resource can be found, then the client SHOULD treat the new URIs as
if the fragment identifier of the original URI was added at the end.
The exception is when a returned URI already has a fragment
identifier. In that case the original fragment identifier MUST NOT be
not added to it.
If the client retrieves the resource using the new URI and the
resource turns out to be of a type that doesn't allow fragments to be
identified, then the client SHOULD silently ignore the fragment ID
and not issue an error message.
如果是300，301，302，303跳转，则在新uri的基础上，client需要添加上原uri的identifier。但也提出了一个例外，就是如果location里已经加上了identifier了后，那原有的identifier需要忽略，不能添加。并且规定了，即使location后的uri不支持井号的定位，那client需要默默忽略井号，并且不能报错。
从这里基本就可以明了了，http 1.1中并没有明确规定跳转后井号的行为，但是drafts是有写，而chrome等浏览器提前实现了该drafts。不得不说，chrome确实是一直走在前列的浏览器。
本文来自于我的博客 http://www.log4myself.info/archives/174
