IIS的重定向在网站设计中的使用

银海软件•2016-02-17•经验之谈•

IIS的重定向在网站设计中使用原因有很多，比如跟踪对内容或广告的点击，域名拼写错误，URL别名或短地址，或者域名变更。甚至还有一个叫做Post/Redirect/Get（PRG）的设计模式，用于避免重复提交表单。这种模式本质上就是在提交表单时调用POST操作，重定向浏览器，最好采用HTTP303响应。这些都是网站制作中把用户从一个站点重定向到另一个站点的合理原因。但是，任何事物都有两面性，与其他好工具一样，使用不当或过度使用都会导致不尽如人意的结果，我们在很多网站建设公司的案例中都发现了这样的问题。首先，让我们根据HTTP标准来讨论一下网站建设中的重定向。

根据RFC2616超文本传输协议，有几种重定向代码，其中包括网站设计人员都熟悉的301永久转移和302临时重定向。凡是与重定向有关的代码都是以3开头的，3xx是一类状态码，需要用户进一步的动作来完成需求。下面的表格中我们列出所有重定向的3xx代码。

状态码	名称	作用说明
300	Multiple Choices 多重选择	请求的资源对应多个表述方式，用户可以选择自己想要的表述方式。
301	Move Permanently 永久迁移	所请求的资源已经被指派到新的永久URI，将来任何对该资源的引用都应该使用所返回的URI。
302	Found 已找到	所请求的资源临时存在于另一个URI，但是客户端应该在将来的请求中继续使用该请求URI。
303	See Other	可以在另一个URI中找到该请求的响应，应该用GET方法到该URI获取。这种方法主要适用于PRG设计模式，使POST的输出重定向到用户代理。
304	Not Modified 未修改	如果客户端执行了一个有条件的GET请求，且访问是允许的，但是文档没有变化，服务器应该用该状态码进行响应。
305	Use Proxy 使用代理	请求的资源必须通过Location头提供的代理访问。
306	未使用	该状态码在规范中还没有使用
307	Temporary Redirect 临时跳转	请求的资源临时存在于另一个URI中。

虽然网站设计时我们有很多方法进行重定向，但是不同的重定向方法在网站建设中会产生不同的利弊。把用户从一个页面重定向到另一个，最简单的方法是创建一个HTML页面，请求用户点击页面上的链接，从而前进到他们真正要访问的资源。这种方法最大的问题在于要求用户再次点击链接才能进入页面。稍微好点的方法则是利用元标签刷新，自动把新的页面发送到浏览器，代码如下： <meta http-equiv=”Refresh” content=”0;url=http://www.newnet.cc"/>，虽然这种方法解决了用户交互的问题，但是我们仍然需要请求Web服务器，使其获取请求并响应，把一个页面发送回用户的浏览器。

另一个更加成熟的方法是使用服务器端代码。几乎所有的程序设计语言都支持重定向。服务端重定向好处在于无需请求浏览器解析HTML，而是直接通过响应头中的HTTP状态码进行重定向。利用HTTP，通过在响应头中定义各种数据传输的特征，可以响应头中具有请求或响应的运行参数。

通过在响应头中加入HTTP状态码，我们已经提高了重定向效率，但是这样仍然需要服务器解析页面代码。为了不用代码进行重定向，我们可以利用web server中嵌入的模块进行重定向。在IIS服务器上有个模块叫做“HTTP重定向”，如下图，

IIS重定向模块

通过IIS内置模块进行重定向可以绕开服务器端的页面渲染管道，在页面还未被服务器渲染之前就返回跳转状态码了，节约了一定的服务器资源。类似IIS的重定向模块在其它web server上也有，如Apache的mod_alias和mod_rewrite模块。

讨论过了不同的方法实现网站建设中的重定向利弊，希望对广大网站制作和网站设计人员对如何优化重定向有所了解。最后要说的是，应该选用正确的工具。最理想的情况是尽量少用重定向，重定向总是延迟返回给客户他们想要的资源，还会占用计算资源，许多方法会把重定向搞得一团糟，既破坏了用户浏览，又降低了搜索引擎的排名，这些都是网站建设人员要尽量避免使用重定向的原因。

高端网站建设

文章关键词: 网站建设