目录
HTTP协议的请求方法
-
GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
-
GET
- 最常见的一种请求方式，当客户端要从服务器中读取文档时，当点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页的，使用的都是GET方式。
- GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端，使用GET方法时，请求参数和对应的值附加在URL后面，例如：
/index.jsp?id=100&op=bind
- 各个数据之间用”&”符号隔开。
- 显然，这种方式不适合传送私密数据。一般最多只能识别1024个字符，所以如果需要传送大量数据的时候，也不适合使用GET方式。
-
POST
- POST方法可以允许客户端给服务器提供信息较多。
- POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中。
- 可以看到，POST方式请求行中不包含数据字符串，这些数据保存在”请求内容”部分，各数据之间也是使用”&”符号隔开。POST方式大多用于页面的表单中。
-
HEAD
- HEAD就像GET，只不过服务端接受到HEAD请求后只返回响应头，而不会发送响应内容。
- 当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容。
- 这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
- 例如：欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则意义更加明确。
-
PUT
- PUT和POST极为相似，都是向服务器发送数据;
- 但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。
- 例如：一个用于提交博文的URL，/addBlog。
- 如果用PUT，则提交的URL会是像这样的”/addBlog/abc123”，其中abc123就是这个博文的地址。
- 而如果用POST，则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。
- 显然，PUT和POST用途是不一样的。具体用哪个还取决于当前的业务场景。
-
DELETE
- 删除某一个资源。
- 基本上这个也很少见，不过还是有一些地方比如amazon的S3云服务里面就用的这个方法来删除资源。
-
OPTIONS
- 这个方法很有趣，但极少使用。
- 它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。
-
TRACE
- 回显服务器收到的请求，主要用于测试或诊断。
-
CONNECT
- HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
状态码解析
-
概述
- 当服务器响应时，其状态行的信息为HTTP的版本号，状态码，及解释状态码的简单说明。
-
HTTP的常见状态码种类：
- 1XX：
- 表示请求已被接受，需接后续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。
- 2XX：
- 表示请求已成功被服务器接收、理解并接受。
- 3XX：
- 表示需要客户端采取进一步的操作才能完成请求。通常用来重定向，重定向目标需在本次响应中指明。
- 4XX：
- 表示客户端可能发生了错误，妨碍了服务器的处理。
- 5XX：
- 表示服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器以当前的软硬件资源无法完成对请求的处理。
- 1XX：
-
1xx：表示临时响应
- 100：（继续）请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分
- 101：（切换协议）请求者已要求服务器切换协议，服务器已确认并准备切换
-
2xx：表示成功处理了请求的状态代码
- 200（成功）服务器已成功处理了请求，通常，这表示服务器提供了请求的页面
- 204（重置内容）服务器成功处理了请求，但没有返回任何内容
- 206（部分内容）服务器成功处理了部分GET请求
-
3xx（重定向）：表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向
- 301:（永久移动）请求的页面已永久移动到新位置。服务器返回此响应（对GET和HEAD请求的响应）时，会自动将请求者转到新位置
- 302（临时移动）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
- 303（查看其他位置）请求者应当对不同的位置使用单独的GET请求来检索响应时，服务器返回此代码
- 304（未修改）自从上次请求后，请求的页面未修改过。服务器返回此响应时，不会返回网页内容
-
4xx（请求错误）：这些状态代码表示请求可能出错，妨碍了服务器的处理
- 400：（错误请求）服务器不理解请求的语法
- 401（未授权）请求要求身份验证。对于需要登录的网页，服务器可能返回此响应
- 403（禁止）服务器拒绝请求
- 404（未找到）服务器找不到请求的网页
- 405（方法禁用）禁用请求中指定的方法
- 406（不接受）无法使用请求的内容特性响应请求的网页
- 408（请求超时）服务器等候请求时发生超时
- 414（请求的URI过长）请求的URI（通常为网址）过长，服务器无法处理
- 415（不支持的媒体类型）请求的格式不受请求页面的支持
- 416（请求范围不符合要求）如果页面无法提供请求的范围，则服务器会返回此状态码
-
5xx（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错
- 500（服务器内部错误）服务器遇到错误，无法完成请求
- 501（尚未实施）服务器不具备完成请求的功能，例如，服务器无法识别请求方法时可能会返回此代码
- 502（错误网关）服务器作为网关和代理，从上游服务器收到无效响应
- 503（服务器不可用）服务器目前无法使用（由于超载或者停机维护）。通常，这只是暂时状态
- 504（网关超时）服务器作为网关或者代理，但是没有及时从上游服务器收到请求
- 505（HTTP版本不受支持）服务器不支持请求中所用的HTTP协议版本
-
其他
-
428 Precondition Required (要求先决条件)
- 先决条件是客户端发送 HTTP 请求时，如果想要请求能成功必须满足一些预设的条件。
- 一个好的例子就是 If-None-Match 头，经常在 GET 请求中使用，如果指定了 If-None-Match ，那么客户端只在响应中的 ETag 改变后才会重新接收回应。
- 先决条件的另外一个例子就是 If-Match 头，这个一般用在 PUT 请求上用于指示只更新没被改变的资源，这在多个客户端使用 HTTP 服务时用来防止彼此间不会覆盖相同内容。
- 当服务器端使用 428 Precondition Required 状态码时，表示客户端必须发送上述的请求头才能执行请求，这个方法为服务器提供一种有效的方法来阻止 'lost update' 问题。
-
429 Too Many Requests (太多请求)
- 当你需要限制客户端请求某个服务数量时，该状态码就很有用，也就是请求速度限制。
- 在此之前，有一些类似的状态码，例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 （这不是HTTP定义的状态码）
- 如果你希望限制客户端对服务的请求数，可使用 429 状态码，同时包含一个 Retry-After 响应头用于告诉客户端多长时间后可以再次请求服务。
-
431 Request Header Fields Too Large (请求头字段太大)
- 某些情况下，客户端发送 HTTP 请求头会变得很大，那么服务器可发送 431 Request Header Fields Too Large 来指明该问题。
- 我不太清楚为什么没有 430 状态码，而是直接从 429 跳到 431，我尝试搜索但没有结果。唯一的猜测是 430 Forbidden 跟 403 Forbidden 太像了，为了避免混淆才这么做的，天知道！
-
511 Network Authentication Required (要求网络认证)
- 对我来说这个状态码很有趣，如果你在开发一个 HTTP 服务器，你不一定需要处理该状态码，但如果你在编写 HTTP 客户端，那这个状态码就非常重要。
- 如果你频繁使用笔记本和智能手机，你可能会注意到大量的公用 WIFI 服务要求你必须接受一些协议或者必须登录后才能使用。
- 这是通过拦截HTTP流量，当用户试图访问网络返回一个重定向和登录，这很讨厌，但是实际情况就是这样的。
- 使用这些“拦截”客户端，会有一些讨厌的副作用。在 RFC 中有提到这两个的例子：
- 如果你在登录WIFI前访问某个网站，网络设备将会拦截首个请求，这些设备往往也有自己的网站图标 ‘favicon.ico'。登录后您会发现，有一段时间内你访问的网站图标一直是WIFI登录网站的图标。
- 如果客户端使用HTTP请求来查找文档（可能是JSON），网络将会响应一个登录页，这样你的客户端就会解析错误并导致客户端运行异常，在现实中这种问题非常常见。
- 因此 511 状态码的提出就是为了解决这个问题。
- 如果你正在编写 HTTP 的客户端，你最好还是检查 511 状态码以确认是否需要认证后才能访问。
-