为什么URI编码(“#”)锚造成404,以及如何在JS处理呢?(Why URI-encoded (&

2019-07-30 12:23发布

prettyPhoto使用#标签,但如果他们获得的编码(至23%),大多数浏览器将弹出一个404错误。 这之前已经讨论 :

你得到一个404错误,因为#回调部分不是URL的一部分。 这是所使用的浏览器中的书签,它永远不会在请求发送到服务器。 如果编码的哈希,它成为文件名的一部分来代替。

  1. 为什么一个哈希成为文件的一部分,只是因为它的URI编码? 是不是一个错误?

  2. 我这么问是因为prettyPhoto使用#标签,并从同一个问题困扰。 我认为加上一个“?” 前哈希是最优雅的解决方案,我只是在一个小的损失如何做到这一点的现有代码:

      起作用getHashtag(){  URL = location.href;  包括hashtag = url.indexOf( '#画廊')==  -  1)decodeURI(url.substring(url.indexOf( '#画廊')+ 1,url.length)):!?假的;  回到主题标签;  }  功能setHashtag(){  如果(typeof运算theRel == '未定义')返回;  的location.hash = theRel + '/' + rel_index + '/';  }  起作用clearHashtag(){  如果 - 的location.hash = “”(location.href.indexOf( '#库')== 1!);  } 
  3. 任何其他的建议? 我马上去调整我的404页,但这似乎更像是处理一个问题,而不是阻止它。

谢谢!

编辑:既然显然没有什么错prettyphoto处理这些哈希,我结束了添加这些规则,我的Apache服务器的方式:

RewriteRule ^(.*).shtml(%23|#)$ /$1.shtml [R=301,NE,L]
RewriteRule ^(.*).shtml([^g]+)gallery(.+)$ /$1.shtml#gallery$3 [R=301,NE,L]

他们成功地处理,其中23%的问题引起的案件。

Answer 1:

  1. 为什么一个哈希成为文件的一部分,只是因为它的URI编码? 是不是一个错误?

如果您将浏览器指向http://example.com/index.html#title ,在浏览器解释这对文件中的请求index.html从服务器example.com 。 一旦请求完成,浏览器会寻找与“标题”(即名称的文档中的定位元素<a name="title">My title</a> )。

如果改为指向http://example.com/index.html%23title ,浏览器发出的文件的请求index.html%23titleexample.com ,这可能并不存在于服务器上,给你一个404.见有什么区别?

而且这不是一个错误。 这是一个互联网标准的一部分, 最后更新于1998年。参见RFC 2396 。 引用:

字符“#”被排除,因为它是用来从在URI引用(第4部分)的片段标识符限定一个URI。

至于2和3,有没有足够的上下文中的示例代码来告诉你想要做什么。 你是如何调用你的代码? 什么是你想与不工作prettyphoto办? 你们是不是要重定向到从用户点击或其他JavaScript事件特定的照片或图片库吗? 你们是不是要开画廊,当有人访问特定页面?

我检查与Twitter / OAuth的链接的问题,但我看不出这关系到你所提供的代码。 我开始在prettyphoto戳为好,但我没有看到你的代码是如何涉及两种。

相反,改变你的404页,也许你需要的是一个需要未找到的请求有一个在代码处理程序或服务器的重写规则%23在他们和用户解码URL重定向。 这可能有一些缺点,但如果你正在做的,你无法控制其他来源的传入请求这将是相当优雅。 什么是您的服务器环境? (语言,服务器技术,谁拥有的机器等)

我很高兴有一个解决方案或你周围的工作来更新我的答案。



Answer 2:

要回答#1)

因为它不再是一个令牌,该令牌的浏览器/服务器的/ etc知道如何分析出这将成为URL的一部分。

我的意思是,“?” 起着URL的显著作用 - 服务器知道分离从什么什么是前后的。 该浏览器并不需要关心什么是或不是在URI动态 - 这一切都显著(虽然JavaScript中的位置对象分隔值)。

该浏览器将不会发送“#......”到服务器,包括hashtag对浏览器的特殊内涵。

不过,如果你逃避的JavaScript哈希,浏览器会毫不犹豫地逃脱串发送给服务器作为一个文字值。

为什么不呢? 如果您的搜索查询合法要求的哈希字符(你做一个POST请求到Facebook涂鸦墙,并要提交PHONENUMBER),那么你会搞砸。 或者你正在做一个基于GET-搜索上411.com或任何一定数量,他们还没有真正经过深思熟虑他们的应用程序。

问题是,该服务器是不会明白的转义值将被从URL分别关押,如果它的实际路径发生。

它必须接受转义字符,否则空间(20%)和其他每一天的人物,这是在文件名/路径/查询其他有效/值会产生问题。

所以,如果你正在寻找:

//mysite.gov.on.ca/path/to/file.extension%23action%3Dfullscreen

真的,你们必定404。

有几件事情,你可以做,我敢肯定。 第一是在Apache中,或任何你从,你可以写它匹配任何URL到第一个“%23”正则表达式的服务,假设没有“?” 预先。

少灵魂人丁实现可能涉及搞清楚是否有逃跑的“#”是插件友好的方式。

谷歌,为实例,采用了“散列砰”战略(“#!”)在它要求的网址提交那个样子,就知道是否要进行编码。

其他选项可能是检查使用“#”字符url.indexOf("#"); 和分裂URL的哈希值,并提交有效的部分。

这真的一切都归结到你要完成的 - 我可以在它为什么是一个问题点,但如何最好地使它成为一个非问题依赖于你想要做什么,怎么你想要做到这一点,什么是允许你在工作的环境。



文章来源: Why URI-encoded ('#') anchors cause 404, and how to deal with it in JS?