这是一篇可能解决困扰了 .NET 程序猿多年的文章！

首先，使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序，直接选用了 MVC 模板。

直接发布项目，默认的设置如下图：

对于小型项目，按默认设置发布基本可满足正常运行，首次运行打开第一个页面基本在 5~6 秒（视服务器配置），其它页面的首次打开也基本在 1~2 秒完成，非首次瞬间打开。

一旦项目功能变得复杂，文件增多，会导致发布后首次运行打开第一个页面 30 秒以上，其它页面的首次打开 10 秒左右，非首次瞬间打开。

这是因为项目在发布时没有进行预编译，而是在用户访问网页时动态编译，一旦应用程序池回收，或项目文件改动，都会重新编译，再次经历缓慢的“第一次”，这是不能忍的。

于是咱们来研究一下“预编译”。

在发布页面勾选“在发布期间预编译”，这时发布会在“输出”窗口显示正在执行编译命令（编译时间会比较长）：

该选项对发布后的文件结构和内容影响不大，因此对首次执行效率的提升也不大，重要的在后面。

在“高级预编译设置”窗口中：

我们针对预编译选项和合并选项分别做测试。

不勾选“允许更新预编译站点”，会致 bin 目录中生成许多 .compiled 文件，而所有 .cshtml 文件的内容都是：

这是预编译工具生成的标记文件，不应删除!

如果是 Web From 网站，.aspx/.ashx 等文件内容同上。

尝试打开网站页面，你会发现，除了项目启动后的第一个页面仍然需要 1~2 秒（无 EF），其余每个页面的首次都是瞬间打开的（EF 的首次慢不在本文讨论范围）。这让我对预编译有一种相见恨晚的感觉！

这里偷偷地告诉你，把 Views 目录删掉也不影响网页正常打开哦~为什么不让删，咱也不敢问，咱也不敢删。

目的达到了，有一些后遗症需要解决，比如 bin 目录内杂乱无章。

选“不合并。为每个页面和控件创建单独的程序集”，结果是 bin 多出许多 App_Web_*.dll 文件。

选“将所有输出合并到单个程序集”，填写程序集名称。这时会发现“输出”窗口执行了命令：

如果程序集名称跟已有名称冲突，会发生错误：

合并程序集时出错: ILMerge.Merge: The target assembly '******' lists itself as an external reference.

查看 bin 目录，.compiled 文件还在，但 App_Web_*.dll 合并成了一个程序集。FTP 的“不合并”也是把所有 App_Web_*.dll 上传一遍，所以不存在相对于“合并”的增量发布优势。

是不是勾了“视为库组件删除(AppCode.compiled 文件)”.compiled 文件就会不见？意外之外，情理之中，bin 没有什么变化。

继续选择“将各个文件夹输出合并到其自己的程序集”，呃，bin 中文件数不降反增。

最后选择“将所有页和控件输出合并到单个程序集”，同样程序集名称不能冲突。结局令人失望，bin 中仍然一大堆 .compiled 和 App_Web_*.dll。

整理成表格：

bin 目录下，页面的程序集文件（App_Web_*.dll）增多的原因是编译后的文件名不固定，发布到会导致残留许多无用的程序集文件。

相比较，如果第 3 种能实现 FTP 稳定的增量上传的话是比较完美的（还有一个缺点是：如果页面有删除，目标 bin 内对应该页面的 .compiled 和 .dll 不会删除，这跟“允许更新预编译站点”是一个情况），那么第 4 种 或第 5 种也是不错的选择（同样有缺点：执行合并比较慢）。

测试一个有 300 个页面的项目，compiler 用时约 2 分钟，merge 用时约 5 分钟，发布用时约 4 分钟。

这里有个槽点，执行预编译和合并是佛系的，CPU 和磁盘使用率永远保持在最低水平。

所以如果是要经常修改的项目，那么建议选择“不合并”的第 3 种发布方式：

“视为库组件（删除 AppCode.compiled 文件）”：移除主代码程序集（App_Code 文件夹中的代码）的 .compiled 文件。 如果应用程序包含对主代码程序集的显式类型引用，则不要使用此选项。

补充：

• 不允许更新预编译站点发布后，因为前端页面没有内容，因此无法单独修改发布（单独发布一个页面后，在访问时不会生效！），只能全站发布，耗时较长；bin 目录有变动将导致使用 InProc 方式存储的 Session 丢失。

• 预编译的另一个优点是可以检查 .aspx / .cshtml 页面 C# 部分的错误（特别是命名空间和路径引用）。

• 改为预编译发布后，可以将服务器上残留的 .master / .ascx / .asax 删除，但不能删除 .aspx / .ashx /.config 等。
  

• VS 发布到 FTP 经常会遗漏一些页面文件，不合并时会遗漏独立文件，合并后也会遗漏合并后的 .dll 的文件，合并的好处就是方便检查是否完全上传发布。

• 慎选“在发布前删除所有现有文件”！一旦勾选发布，世界就清静了，所有网友上传的图片附件以及网站运行产生的其它文件，消失得无影无踪。不管发布到文件系统还是发布到 FTP 都一样。当然，如果是先发布到文件系统，再通过 FileZilla 等 FTP 软件上传到服务器的，建议勾选此项。

• .NET Core 应用程序部署：https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index

• 由于上传文件时 bin 目录文件较多，理论上 bin 目录内的文件有任何改动都会重启应用池，而且 VS 是单线程上传的，导致期间网站访问缓慢，服务器 CPU 升高，我的做法是：发布到文件系统，再使用专用 FTP 工具上传，上传用时约半分钟（如果大小不同或源文件较新则覆盖文件）。还嫌慢？那就打包上传，解压覆盖。

• 关于本文研究对象的官方解释：高级预编译设置对话框

• 出现“未能加载文件或程序集“***”或它的某一个依赖项。试图加载格式不正确的程序。”的问题时，先用改用 Debug 方式发布会报详细错误，一般是 .aspx 等客户端页面有 C# 语法问题，注意提示报错的是 /obj/ 目录下的克隆文件，应更改原文件。排除错误后关闭所有页面，再使用 Release 方式发布。

当我们用 ASP.NET Web API 作服务端接口时，如果客户端以 GET 方式请求的 URL 中，由于拼接错误导致“？”和“&”并列出现，会发生 400 Bad Request，那么需要在 IIS 中使用 URL 重写模块来纠正。

请求 URL 如：

http://www.abc.com/api/obj?&foo=bar

需要重写为：

http://www.abc.com/api/obj?foo=bar

打开 IIS 管理器中对应网站的 URL 重写，

添加空白规则。

匹配的 URL 不包含域名，如上述 URL 则匹配的范围是：

api/obj

不包含我们要查找的字符串 ?&，所以此处模式只能匹配所有：

.*

又因为重定向路径中需要包含这部分，所以用括号包裹，即：

(.*)

继续添加条件匹配：

条件输入：{QUERY_STRING}，表示匹配查询字符串，

匹配的部分是“?”后面的字符串：

&foo=bar

那么可以填写模式：

^\&.*

因为 & 后面的部分仍然需要使用，所以用括号包裹：

^\&(.*)

“操作”中选择类型“重定向”，URL 填写：

{R:1}?{C:1}

其中 {R:1} 指代 api/obj，{C:1} 指代 foo=bar

取消“附加查询字符串”前面的勾

重定向类型在测试时可以选择 302 或 307，没问题后选择 301。

完成。

最终我们可以在网站的配置文件 web.config 中看到：

<rewrite>
    <rules>
        <rule name="uni-app-h5-replace-q" stopProcessing="true">
            <match url="(.*)" />
            <conditions>
                <add input="{QUERY_STRING}" pattern="^\&amp;(.*)" />
            </conditions>
            <action type="Redirect" url="{R:1}?{C:1}" appendQueryString="false" redirectType="Temporary" />
        </rule>
    </rules>
</rewrite>

我们要把这段代码复制到开发环境源代码的 web.config 中，以免发布网站时将我们设置好的配置覆盖掉。

在学习和使用 ASP.NET Web API 之前，最好先对 RESTful 有所了解。它是一种软件架构风格、设计风格，而不是标准。

推荐视频教程：https://www.imooc.com/learn/811

讲师：会飞的鱼Xia

需时：2小时25分

REST API 测试工具：

在 Chrome 网上应用店中搜索：Restlet Client

或网站 https://client.restlet.com

>>> 资源路径

SCHEME :// HOST [ ":" PORT ] [ PATH [ "?" QUERY ]]

其中 PATH 中的资源名称应该使用复数名词，举例：

GET https://xoyozo.net/api/Articles/{id}

POST https://xoyozo.net/api/Articles

>>> HTTP verb（对应 CURD 操作）：

>>> 过滤信息：

如分页、搜索等

>>> 常用状态码：

>> 错误处理：

C# 例：throw new HttpResponseException(HttpStatusCode.NotFound);

PHP 例：throw new Exception('文章不存在', 404);

>>> 返回结果：

JSON/XML

不要返回密码等机密字段

>>> 其它：

身份验证窗口（浏览器弹窗，类似 alert，非页面表单），明文传输，安全性不高，不建议使用。实现：

在 Headers 中添加 Authorization:Basic “用户名:密码”的 Base64 编码

〓 系统

〓 文件

〓 tar

〓 磁盘

〓 网络

〓 防火墙

〓 用户/权限

〓 vi 编辑器

〓 计划任务

〓 网站

〓 goaccess

〓 lnmp

〓 nginx

〓 vsftpd

〓 MySQL

〓 scp 远程文件/目录传输命令 (yum install openssh-clients) 用法

scp 会把文件权限（读取/写入/执行）带过来，但所有者为当前执行 scp 命令的用户。

scp 低版本有许多漏洞，用完最好 yum remove openssh-clients

scp 采用直接覆盖的机制，如需判断文件无差异则跳过，应改用 rsync 命令。查看 rsync 详细使用方式及与 scp 对比

〓 rsync 远程文件/目录传输命令 (yum install rsync) 用法查看 rsync 详细使用方式及与 scp 对比

rsync 会把文件权限（读取/写入/执行）带过来，所有者也会带过来。

相比于 scp 最大的优势就是可以增量同步

〓 ftp 客户端 (yum install ftp)

〓 iftop

流量监控工具 教程 

〓 GoAccess

实时网站日志分析工具 官网 

〓 Cacti

网络流量监测图形分析工具 官网  百科 

常见问题笔记

加硬盘

• 插入新硬盘

• 若有 RAID，则先设置，使操作系统能认到硬盘

• 使用 fdisk 命令对新设备进行分区

• 使用 mkfs 命令对新分区进行格式化

• 使用 mount 命令进行挂载

• 设置开机自动挂载（vi /etc/fstab）

更改 MySQL 数据库目录位置

• 停止 MySQL 服务

• 将原数据目录转移或复制到新位置（若是复制，则修改所有者使原来一致）

• 找到 my.cnf 配置文件（一般在 /etc/），修改 datadir 值为新路径

• 启动 MySQL 服务

502 Bad Gateway 问题排查

• 查看 PHP 日志，路径：/usr/local/php/var/log

• 一般为“server reached pm.max_children setting (10), consider raising it”连接数问题，在“/usr/local/php/etc”下的所有配置文件中查找并修改相关设置即可（如改成 1000）。

计划任务（实例：定时备份数据库并通过 FTP 同步至其它服务器）

• 创建可执行文件：vi dotask.sh

• dotask.sh 的内容示例：
  

  DATE_TIME=`date +%Y_%m_%d_%H%M%S`;
  FILE_NAME=数据库名_backup_$DATE_TIME.sql;
  cd /home/mysqlbackup/;
  mysqldump -u数据库用户名 -p数据库密码 数据库名>$FILE_NAME;
  tar -zcf $FILE_NAME.tar.gz $FILE_NAME;
  rm $FILE_NAME;
  
  ftp -v -n FTP地址 << END
  user FTP用户名 FTP密码
  bin
  put 本地目录文件 目标路径文件
  bye
  END
  

  
  文件名乱码问题可以在行末加“;”来解决

• 赋予执行权限：chmod 777 dotask.sh （ls 命令时呈绿色）

• 编辑计划任务：crontab -e

• crontab 书写规则：
  

  # 分 时 日 月 周 文件路径
  0 3 * * * /home/dotask.sh
  30 4 * * * /home/dotask2.sh
  

  
  更多帮助 

• 重启 crond：/etc/init.d/crond restart

netstat

• netstat -an | grep xxx.xxx.xxx.xxx 可查看此 IP 的 TCP 请求及端口

本文不定时更新中……

具备 RESTful 相关知识会更有利于学习 ASP.NET Web API：RESTful API 学习笔记

ASP.NET Web API 官网：https://www.asp.net/web-api

服务 URI Pattern

HttpResponseMessage

可提供大量控制的响应消息。 例如，以下控制器操作设置的缓存控制标头。

public class ValuesController : ApiController
{
    public HttpResponseMessage Get()
    {
        HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.OK, "value");
        response.Content = new StringContent("hello", Encoding.Unicode);
        response.Headers.CacheControl = new CacheControlHeaderValue()
        {
            MaxAge = TimeSpan.FromMinutes(20)
        };
        return response;
    } 
}

IHttpActionResult

public IHttpActionResult Get (int id)
{
    Product product = _repository.Get (id);
    if (product == null)
    {
        return NotFound(); // Returns a NotFoundResult
    }
    return Ok(product);  // Returns an OkNegotiatedContentResult
}

其他的返回类型

响应状态代码为 200 （正常）。此方法的缺点是，不能直接返回错误代码，如 404。 但是，您可以触发 HttpResponseException 的错误代码。

完善 Help 页

一般都是通过元数据注释（Metadata Annotations）来实现的描述的。

显示接口和属性的描述：

打开 HelpPage 区域的 App_Start 目录下的 HelpPageConfig.cs 文件，在 Register 方法的首行取消注释行：

config.SetDocumentationProvider(new XmlDocumentationProvider(HttpContext.Current.Server.MapPath("~/App_Data/XmlDocument.xml")));

在项目右键属性“生成”页，勾选“XML 文档文件”，并填写与上述一致的路径（App_Data/XmlDocument.xml）。

给接口加上 ResponseType 显示响应描述和示例：[ResponseType(typeof(TEntity))]

在实体模型的属性上加入 RequiredAttribute 特性可提供请求或响应中的实体的属性描述，如：[Required]

推荐使用：Swashbuckle

关于格式

在 WebApiConfig.Register() 中加入以下代码以禁止以 XML 格式输出（请按需设置）：

GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();

Json 序列化去掉 k__BackingField

GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new Newtonsoft.Json.Serialization.DefaultContractResolver { IgnoreSerializableAttribute = true };

如果属性值为 null 则不序列化该属性

config.Formatters.JsonFormatter.SerializerSettings = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };

代码一：

#if DEBUG
    // Debug 模式
#else
    // Release 模式
#endif

作用：判断 调试模式 / 发布模式

条件：须在项目属性的生成页中勾选“定义 DEBUG 常量”

适用：记录 EF 生成的 SQL 语句、控制定时器只在生产环境执行等

注意：调试和发布时应选择正确的模式

代码二：

if(Request.IsLocal) { }

作用：判断 本地 / 远程

条件：在会话中

适用：显示错误详情、记录 EF 生成的 SQL 语句

注意：不能用于定时器、Application_Start、异步操作等非会话中

代码三：

if (System.Net.IPAddress.IsLoopback(HttpContext.Connection.RemoteIpAddress)) { }

说明：ASP.NET Core 中的写法，用于检测 IP 地址是否为本地回环地址（IPv4 为 127.0.0.1，IPv6 为 ::1）

若在视图中使用，HttpContext 改为 ViewContext.HttpContext 或 Context

作用/条件/适用/注意：参“代码二”

代码四：

if(HttpRuntime.AppDomainAppPath == "X:\xxx\") { }

作用：判断当前网站根目录路径

条件：开发环境和生产环境的根目录路径不同

适用：判断根目录路径作相应的处理，适用于以上各种情况

注意：路径有变须要修改相应程序代码

UEditor 的 ASP 版本在虚拟空间上传文件失败，提示“上传错误”或“上传失败，请重试”等，是因为其文件上传组件在创建目录时，没有网站目录外的访问权限。

例如上传文件的磁盘保存路径为：

D:\web\sitename\wwwroot\upload\20180523\123.jpg

百度编辑器的上传组件会依次判断以下目录是否存在，不存在则创建：

D:\

D:\web\

D:\web\sitename\

D:\web\sitename\wwwroot\

D:\web\sitename\wwwroot\upload\

D:\web\sitename\wwwroot\upload\20180523\

虚拟空间自动配置的网站根目录可能是：

D:\web\sitename\wwwroot\

所以，判断存在或创建以下目录没有问题：

D:\web\sitename\wwwroot\upload\

D:\web\sitename\wwwroot\upload\20180523\

但判断存在以下目录时会因为权限不足而失败：

D:\

D:\web\

D:\web\sitename\

解决方法是找到文件 asp/Uploader.Class.asp

找到 CheckOrCreatePath 这个 Function，替换为：

Private Function CheckOrCreatePath( ByVal path )    
   Set fs = Server.CreateObject("Scripting.FileSystemObject")    
   Dim parts    
   Dim root : root = Server.mappath("/") & "\"    
   parts = Split( Replace(path, root, ""), "\" )    
   path = root    
   For Each part in parts    
       path = path + part + "\"    
       If fs.FolderExists( path ) = False Then    
           fs.CreateFolder( path )    
       End If    
   Next    
End Function

另外，如果服务端无法通过 Request.Form 来接收该值，把 <form /> 放到 <table /> 外面试试。

或者绑定 contentChange 事件来赋值（不推荐）：

ue.addListener("contentChange", function() {
    document.getElementsByName('xxxxxx')[0].value = ue.getContent();
});

此方法的缺点是，不是所有操作都能触发 contentChange 事件，比如剪切、上传图片等。

改进方法（推荐）：在 form 提交之前赋值。

风险名称：系统共享配置检测

风险等级：中危

检测项说明：

检测注册表项HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\LSA\\RestrictAnonymous的值，该值控制是否允许远程操作注册表

检测项目:

远程操作注册表

建议值:

1

路径:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous

建议:

建议禁止远程访问操作注册表，建议关闭

在网站开发过程中遇到上传图片等文件的功能，需要在服务器上设置该目录可写入，并且必须防止被上传 .php 等可执行的脚本文件。

根据文件所有者的不同，我们分两种情况讨论：

一、程序上传的用户与执行 PHP 的用户不同（例如程序代码通过 SSH 上传（root 用户），而 PHP 以 www 身份运行）

由于 Linux 上的文件默认权限是 644，目录默认权限是 755，所以在这种情况下，PHP 不能修改 root 上传的程序文件，也不能将客户端上传的图片文件保存到服务器上。

例如我们将客户端上传的文件指定到 /upload/ 目录，那么，

第 1 步，赋予它写入权限：

chmod 777 upload

递归所有子目录请加 -R 参数，但会将文件也更改为 777，赋予了执行权限，这是不建议的。文件若需写入权限请设为 666。

第 2 步，设置该目录下不允许执行 PHP：

我们无法保证客户端上传完全符合我们要求的文件，那么必须禁止任何文件的执行权限。（此处指 PHP 的执行权限，注意与 sh 执行权限的区别，后者由 chmod 命令修改）

nginx 的 .conf 文件配置示例：

location ~ /upload/.*\.(php|php5)?$
{
    deny all;
}

Apache 的 .htaccess 文件配置示例：

RewriteRule upload/(.*).(php)$ – [F]

特别注意：上面的代码必须加在 PHP 引用配置的上方才有效（如 nginx 的 PHP 引用配置 include enable-php-**.conf;）

默认 Linux 系统是大小写敏感的，所以规则中的正则表达式无须忽略大小写（但必须与实际的目录或文件名大小写一致），因为 MIME 类型中设置的是小写的 .php，那么类似大写的 .PHP 文件是不被 php-fpm 解释的，结果是被当作普通文本返回到客户端。

提问：有些目录需要设置为可写入，但里面还有正常的 php 文件，禁止执行会有问题吗？（例如 Discuz! 的 config 目录，ThinkPHP 的 Runtime 目录）

解答：以 Discuz! 为例，config 下面虽然有 config_*.php 等配置文件，但这些文件并非直接供客户端浏览，而是被其它 .php 文件引用（include 方式、IO 方式等），当 config 目录禁止执行 PHP 后并不会对它们造成影响。

我们在开发程序的过程中应避免在允许写入的目录下放置直接供客户端浏览的 .php 文件。

二、程序上传的用户与执行 PHP 的用户相同（例如程序代码通过 FTP 上传，且和 PHP 一样，都使用 www 用户）

常见于虚拟空间。这种情况下，通过 PHP 上传的文件可以保存到该网站下面的任何目录下（甚至是网站目录之外，即传说中的跨站），原因大家都懂，默认 755 中第一个是“7”，即所有者拥有写入权限。

因此，除了做到上述设置，我们必须严格控制客户端上传文件的保存路径，做到以下几点：

必须更改客户端上传的文件名，而非直接使用原文件名；

不得从客户端文件名获取扩展名，或者只控制允许的后缀名。

最可靠的文件类型判别方式是分析文件签名，参考：文件签名表，以防篡改后缀名欺骗。

举个早期的栗子：上传文件名为 abc.asp;.jpg，未改文件名保存到服务器，浏览器直接访问该文件，IIS 6 当作 abc.asp 来解析。

一、概述

    重定向常常和请求转发放在一起讨论（前者是两次不相关的请求，后者是一次请求服务器端转发），然而本文并不讨论两者的区别，而是HTTP 1.0规范和HTTP 1.1规范中关于重定向的区别，以及实际使用中的情况。

    重定向实际使用是一个响应码（301或302或303或307）和一个响应头location，当浏览器收到响应的时候check响应码是3xx，则会取出响应头中location对应的url（重定向中url的编码问题，请参看点击打开链接），然后将该url替换浏览器地址栏并发起另一次HTTP事务。

    关于301、302、303、307的区别，找不到好的文章，因此打算直撸HTTP 1.0规范和HTTP 1.1规范，结合一些实际的案例和tomcat实现，来说清楚这几个状态码的差异。

1. 百度https重定向

    如下图所示，原请求访问的是http://www.baidu.com，然后返回302和location=https://www.baidu.com，从http转到https。不过关于响应行中302状态码的描述存在争议，在下文中会详细讨论。

2. tomcat重定向源码

二、详细

    http 1.0规范中有2个重定向——301和302，在http 1.1规范中存在4个重定向——301、302、303和307，其中302是值得讨论讨论的。

1. http 1.0

301

    301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向，对于资源请求，原来的url和响应头中location的url而言，资源应该对应location中的url。对于post请求的重定向，还是需要用户确认之后才能重定向，并且应该以post方法发出重定向请求。

    关于post请求重定向用户确认的问题，实际上浏览器都没有实现；而且post请求的重定向应该发起post请求，这里浏览器也并不一定遵守，所以说HTTP规范的实现并未严格按照HTTP规范的语义。

    在301中资源对应的路径修改为location的url，在SEO中并未出现问题，但是在302中就出现了302劫持问题，请往下看。

302

    在http 1.0规范中，302表示临时重定向，location中的地址不应该被认为是资源路径，在后续的请求中应该继续使用原地址。

    规范：原请求是post，则不能自动进行重定向；原请求是get，可以自动重定向；

    实现：浏览器和服务器的实现并没有严格遵守HTTP中302的规范，服务器不加遵守的返回302，浏览器即便原请求是post也会自动重定向，导致规范和实现出现了二义性，由此衍生了一些问题，譬如302劫持，因此在HTTP 1.1中将302的规范细化成了303和307，希望以此来消除二义性。

    补充：302劫持——A站通过重定向到B站的资源xxoo，A站实际上什么都没做但是有一个比较友好的域名，web资源xxoo存在B站并由B站提供，但是B站的域名不那么友好，因此对搜索引擎而言，可能会保存A站的地址对应xxoo资源而不是B站，这就意味着B站出了资源版权、带宽、服务器的钱，但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站，A站什么都没做却被索搜引擎广而告之用户，B站做了一切却不被用户知道，价值被A站窃取了。

2. http 1.1

301

    和http 1.0规范中保持一致，注意资源对应的路径应该是location中返回的url，而不再是原请求地址。

302

    在HTTP 1.1中，实际上302是不再推荐使用的，只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向，为了消除HTTP 1.0中302的二义性，在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。

303

    在HTTP 1.0的时候，302的规范是原请求是post不可以自动重定向，但是服务器和浏览器的实现是运行重定向。

    把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）。

307

    在http 1.1规范中，307为临时重定向，注意划红线的部分，如果重定向307的原请求不是get或者head方法，那么浏览器一定不能自动的进行重定向，即便location有url，也应该忽略。

    也就是307继承了302在HTTP 1.0中的规范（303继承了302在HTTP 1.0中的实现）。

3. 小结

    在HTTP 1.0规范中，302的规范并没有被服务器和浏览器遵守，即规范和实现出现了二义性，因此在HTTP 1.1中，将302的规范和实现拆分成了303和307。

三、结论

    虽然在不同版本的http规范中对重定向赋予了不同的语义，但是因为使用历史和服务器实现等原因，在实际中并不一定安全按照http规范实现，因此我个人感觉上述讨论只是一个了解，在实际写代码中302还是继续用吧···

参考：

1. 《http 1.0规范》
2. 《http 1.1规范》

3. 博客：点击打开链接

附注：

    本文如有错漏，烦请不吝指正，谢谢！