使用 mod_rewrite 删除 www 和 SWFAddress。为什么 Safari 在主题标签后会丢失内容,而 Chrome 和 FF 不会?
我对使用 mod_rewrite 和主题标签 (#) 时的浏览器行为感到好奇。 Firefox 和 Chrome 可以重写带有“www”的 URL,并删除“www”,同时保留原始 URL,带有主题标签和片段,没有问题。太棒了!但 Safari 和 IE7/8(不确定 9)在重写过程中删除了“www”并丢失了主题标签和片段。我想知道是否有针对 Safari 和 IE 使用 mod_rewrite 的修复程序?不过,我怀疑没有,因为我问的是碎片。 (我没有 mod_rewrite 的经验,我只是阅读了它并刚刚开始使用 HTML5 Boilerplate .htaccess 文件。我读过有关哈希片段如何不发送到服务器以及如果我想存储或使用该片段我必须使用 Javascript 在客户端执行一些操作。)
我可以使用 Twitter 来展示我正在谈论的内容的示例。如果您使用 Chrome 或 FF 并转到 http://www.twitter.com/#!biz 你会得到 http://twitter.com/#!biz 的重写,没问题,完美。但在 Safari 和 IE7/8 中使用相同的 URL(带有“www”)会将 URL 重写回主 Twitter URL,没有“www”,但没有哈希和片段,也没有深度链接。 那么对于具有 #!/biz(带有第二个 / )的 Twitter URL 来说,结果是相同的。
如果 Twitter 没有(或不能)对此 Safari/IE 和 Safari/IE 执行任何操作, “www”行为,那么也许我也不应该担心?这是浏览器的问题吗,因为没有解决方案在 .htaccess 文件中使用 mod_rewrite 来存储主题标签片段,对吧?
具体来说,在我的工作中,我使用 SWFAddress,它使用主题标签在 Flash 内容中进行深层链接,这几乎与 Twitter URL 完全相同,只是没有“!”。我认为 Twitter 正在使用“Making AJAX Crawlable”方法。就像 Twitter 一样,我的 URL 在 FF 和 Chrome 中重写得很好,但在 Safari 和 IE 7/8 中则很糟糕。主题标签是否带有“!”似乎没有什么区别或者不是,它仍然是片段的一部分,不是吗?
当我正在寻找一种使 Flash 站点上的内容可爬行的解决方案时,我开始尝试使用 SWFAddress 版本的方法使 AJAX 可爬行,但浏览器以相同的方式处理 mod_rewrite。删除“www”在 FF/Chrome 中工作正常,在 Safari 和 IE 中则破坏该片段。我有一个 SWFAddress Making AJAX Crawlable 方法版本的工作示例(必须删除链接。stackoverflow 的新用户每个帖子只能获得 2 个 URL)。最后我没有使用这种方法来使我的 Flash 内容可搜索,但它看起来很有前途。我认为制作 HTML 快照比使用 PHP 页面需要更多工作,但这是一个完全不同的主题/问题。
如果(对于我的第一个 stackoverflow 问题)有一个非常简短的答案,比如“是的,别担心!”,那就很有趣了! :)
谢谢!
I'm curious about the browser behavior when using mod_rewrite and a hashtag (#). Firefox and Chrome can rewrite a URL that has a 'www' and remove the 'www' while keeping the original URL, with the hashtag and fragment, no problem. That's awesome! But Safari and IE7/8 (not sure about 9) remove the 'www' and lose the hashtag and fragment during the rewrite. I'm wondering if there's a fix using mod_rewrite for the Safari and IE? Although, I suspect there isn't because I'm asking about fragments. (I have no experience with mod_rewrite, I've only been reading about it and just started using the HTML5 Boilerplate .htaccess file. I've read about how hash fragments aren't ever sent to the server and if I wanted to store or use that fragment I'd have to do something client-side with Javascript.)
I can use Twitter to show an example of what I'm talking about. If you use Chrome or FF and go to http://www.twitter.com/#!biz you'll get the rewrite of http://twitter.com/#!biz no problem, perfect. But using that same URL (with the 'www') in Safari and IE7/8 will rewrite the URL back to the main Twitter URL, without the 'www' but no hash and fragment, no deeplink. It's the same result for the Twitter URL that has #!/biz ( with the second / )
If Twitter doesn't (or can't) do anything about this Safari/IE & 'www' behavior, then maybe I shouldn't sweat it either? Is this a browser thing because there's no solution using mod_rewrite within a .htaccess file to store a hashtag fragment, right?
Specifically in my work, I'm using SWFAddress, which uses the hashtag to deep link in Flash content, which is almost exactly like a Twitter URL, except there's no '!'. I think Twitter is using the Making AJAX Crawlable approach. And just like Twitter, my URLs will rewrite fine in FF and Chrome, but bonk in Safari and IE 7/8. It doesn't seem to make a difference if the hashtag has the '!' or not, it's still part of the fragment, no?
I started to play around with a SWFAddress version approach of Making AJAX Crawlable back when I was looking for a solution to make the content on a Flash site crawlable, but the browsers handle the mod_rewrite the same way. The removal of the 'www' works fine in FF/Chrome, bonk the fragment in Safari and IE. I have a working example for my SWFAddress Making AJAX Crawlable approach version (had to remove the link. new users to stackoverflow only get 2 URLs per post). In the end I didn't use that approach for making my Flash content searchable, but it looks promising. I think making the HTML snapshot was more work than using PHP pages, but that's a totally different subject/question.
It'd be funny if (for my first stackoverflow question) there was a really short answer like, Yeah, don't sweat it! :)
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
哈希值之后的部分永远不会随请求一起发送到服务器,因此它会被浏览器而不是 Apache 丢失。您对此无能为力,除非向浏览器供应商提交错误报告。
The part after the hash is never sent to the server with the request, so it's being lost by the browser, not Apache. Nothing you can do about that, except maybe open a bug report with the browser vendors.