当我查看 Amazon.com 时,我看到他们的页面 URL,它在 URL 的末尾没有.htm
,.html
或.php
。
http://www.amazon.com/books-used-books-textbooks/b/ref=topnav_storetab_b?ie=UTF8&node=283155
为什么以及如何?那是什么样的延伸?
您的浏览器不关心文件的扩展名,只关心服务器报告的内容类型。(好吧,除非您使用 IE,因为在 Microsoft,他们认为他们比您更了解您所提供的服务)。如果您的服务器报告所提供的内容是 Content-Type:text / html,那么无论文件名如何,您的浏览器都应该将其视为 HTML。
通常,它是使用某种描述的 URL 重写方案来实现的。基本概念是,Web 应该转向使用适当的 URI 来寻址资源,而不是泄漏实现细节的经典旧 URL,这些 URL 容易受到未来变化的影响。
有关该主题的详尽讨论可以在 Tim Berners-Lee 的文章Cool URIs Don't Change中找到,该文章主张减少 URI 中不相关的麻烦,以帮助避免在实现确实发生变化时出现的问题,以及当资源确实移动到不同的 URL 时。本文本身包含有关规划 URI 方案的良好的一般建议,非常值得一读。
比大多数这些答案更具体:
Web 内容不使用文件扩展名来确定正在提供的文件类型 (除非您是 Internet Explorer)。相反,它们使用Content-type
HTTP 标头,该标头在图像、 HTML 页面、下载或其他内容的内容之前通过网络发送。例如:
Content-type: text/html
表示您正在查看的页面应解释为 HTML,并且
Content-type: image/png
表示该页是 PNG 图像。
如果文件直接从磁盘提供给determinewhatContent-type
to assign,则 Web 服务器通常使用文件扩展名,但是 Web 应用程序也可以生成具有任何Content-type
的页面以响应请求。无论文件名的结构或扩展名如何,只要页面的实际内容与声明的Content-type
匹配,数据就会按预期呈现。
对于使用 Apache的网站,他们可能正在使用 mod_rewrite,使他们能够重写 URL(并使它们更加用户和 SEO 友好)
您可以在这里阅读更多http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html和这里http://www.sitepoint.com/article/apache-mod_rewrite-examples/
编辑:还有 IIS 的重写模块。
本站系公益性非盈利分享网址,本文来自用户投稿,不代表码文网立场,如若转载,请注明出处
评论列表(12条)