常见状态码
100-199 : 表示成功接收请求, 要求客户端继续提交下一次请求才能完成整个处理过程
200-299: 表示成果接收请求并已完成整个处理过程. 常用200
300-399: 为完成请求, 客户需进一步细化需求: 例如: 请求的资源已经移动一个新地址, 常用302(重定向), 307和304(拿缓存)
400-499: 客户端的请求有错误, 包含语法错误或者不能正确执行. 常用404(请求的资源在web服务器中没有) 403(服务器拒绝访问, 权限不够)
500-599: 服务器端出现错误
200 正常 表示一切正常, 返回的是正常请求结果
201 Created
302/307 临时重定向 指出请求的文档已被临时移动到别处, 此文档的新的url在location响应头中给出
304 未修改 表示客户机缓存的版本是最新的, 客户机应该继续使用它
400 Bad Request
403 禁止 服务器理解客户端请求, 但拒绝处理它, 通常用于服务器上文件或目录的权限设置所致
404 找不到 服务器上不存在客户机所请求的资源
500 服务器内部错误 服务器端的cgi, asp, jsp等程序发生错误
| statusCode | Content | Description |
|---|---|---|
| 200 | OK | 表示一切正常, 返回的是正常请求结果 |
| 201 | Created | |
| 204 | No Content | 该状态码表示服务器接收到的请求已经处理完毕，但是服务器不需要返回响应体. |
| 304 | Not Modified | |
| 400 | Bad Request | |
| 401 | Unauthorized | |
| 403 | Forbidden | |
| 404 | Not Found | |
| 409 | Conflict | 请求不能完成由于和当前资源的状态冲突。此状态码只被允许出现在期望用户也许能解决此冲并且能重新提交此请求的情况下 |
| 500 | Internal Server Error |
HTTP请求头和响应头结构
请求报文
请求行（request-line）：（GET /homepage.html HTTP/1.1）
请求方法（GET/POST)
请求资源路径（/homepage.html)
协议类型和版本（HTTP/1.1）
请求头部（header）：若干消息头
content-teyp=text/html
Accept-Language: zh-cn,zh;q=0.5
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; 域名)
Host: www.baidu.com
Connection: Keep-Alive
空行(blank-line):
最后一个请求头之后是一个空行，分隔请求头
请求数据：消息体
这个部分不在GET方法中使用，在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。
响应报文
状态行（status-line）：HTTP/1.1 200 OK(CRLF)
协议和版本（HTTP/1.1）
状态码（200）
状态码的描述（OK(CRLF)）
消息包头：(header)
和请求报文header一样
空行(blank-line)：
和请求报文空行一样
响应包体：(body)
返回的数据
HTTP请求头字段
Accept：用于高速服务器，客户机支持的数据类型
Accept-Charset：用于告诉服务器，客户机采用的编码格式
Accept-Encoding：用于告诉服务器，客户机支持的数据压缩格式
Accept-Language：客户机的语言环境
Host：客户机通过这个头高速服务器，想访问的主机名
If-Modified-Since | 客户机通过这个头告诉服务器，资源的缓存时间
Referer：客户机通过这个头告诉服务器，它是从哪个资源来访问服务器的（防盗链）
User-Agent：客户机通过这个头告诉服务器，客户机的软件环境
Cookie：客户机通过这个头可以向服务器带数据
Connection：处理完这次请求后是否断开连接还是继续保持连接
Date | 当前时间值 | "Sat, 04 Mar 2017 05:59:42 GMT"
HTTP响应头字段
Location：这个头配合302状态码使用，用于告诉客户找谁。
Server：服务器通过这个头告诉浏览器服务器的类型。
Content-Encoding：服务器通过这个头告诉浏览器数据的压缩格式。
Content-Length：服务器通过这个头告诉浏览器回送数据的长度
Content-Type：服务器通过这个头告诉浏览器回送数据的类型
Last-Modified：告诉浏览器当前资源的最后缓存时间
Refresh：告诉浏览器隔多久刷新一次
Content-Disposition：告诉浏览器以下载方式打开数据
Transfer-Encoding：告诉浏览器数据的传送格式
ETag：缓存相关的头
三种禁止浏览器缓存的头字段：
Expires：告诉浏览器把回送的资源缓存多长时间 -1或0则是不缓存
Cache-Control：no-cache
Pragma：no-cache
HTTP/1.1与HTTP/1.0的区别
详细参考资料HTTP/1.1与HTTP/1.0的区别
GET与POST的区别
在RFC7231里面是这么说的
4.3.1. GET
The GET method requests transfer of a current selected representation
for the target resource. GET is the primary mechanism of information
retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request.
It is tempting to think of resource identifiers as remote file system
pathnames and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see
Section 9.1 for related security considerations). However, there are
no such limitations in practice. The HTTP interface for a resource
is just as likely to be implemented as a tree of content objects, a
programmatic view on various database records, or a gateway to other
information systems. Even when the URI mapping mechanism is tied to
a file system, an origin server might be configured to execute the
files with the request as input and send the output as the
representation rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource
identifiers corresponds to an implementation and how each
implementation manages to select and send a current representation of
the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request
([RFC7233]).
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [RFC7234]).
4.3.3. POST
8.1 GET
GET方法就是以实体方式得到由请求URI所指定资源的信息。如果请求URI只是一个数据产生过程，那么最终要在回应实体中返回的是由该处理过程的结果所指向的资源，而不是返回该处理过程的描述文字，除非那段文字恰好是处理的输出。
如果请求消息包含If-Modified-Since标题域，GET方法的语法就变成“条件GET”，即“（conditional GET）”。 条件GET方法可以对指定资源进行判断，如果它在If-Modified-Since标题域（见10.9节）中的指定日期后发生了更新，才启动传输，否则不传输。这种条件GET允许被缓存的实体在不必经过多次请求或不必要的数据传输就能进行刷新，从而有助于降低网络负载。
8.3 POST
POST方法用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列（Request-Line）中请求URI所指定资源的附加新子项。POST被设计成用统一的方法实现下列功能：
o 对现有资源的注释（Annotation of existing resources）；
o 向电子公告栏、新闻组，邮件列表或类似讨论组发送消息；
o 提交数据块，如将表格（form [3]）的结果提交给数据处理过程；
o 通过附加操作来扩展数据库。
POST方法的实际功能由服务器来决定，而且通常依赖于请求URI。在POST过程中，实体是URI的从属部分，就好象文件从属于包含它的目录、新闻组文件从属于发出该文件的新闻组、记录从属于其所在的数据库一样。
成功的POST不需要在原始服务器创建实体，并将其做为资源；也不需要为未来的访问提供条件。也就是说，POST方法不一定会指向URI指定的资源。在这种情况下，200（成功）或204（无内容）都是适当的回应状态，取决于实际回应实体中对结果的描述。
如果在原始服务器上创建了资源，回应应是201（已创建），并包含一个实体（对"text/html"类型最为适合），该实体中记录着对新资源请求的状态描述。
在所有的HTTP/1.0的POST请求中，必须指定合法的内容长度（Content-Length）。如果HTTP/1.0服务器在接收到请求消息内容时无法确定其长度，就会返回400（非法请求）代码。
应用程序不能缓存对POST请求的回应，因为做为应用程序来说，它们没有办法知道服务器在未来的请求中将如何回应。
总结一下就是
GET的语义是请求获取指定的资源。GET方法是安全、幂等、可缓存的（除非有 Cache-ControlHeader的约束）,GET方法的报文主体没有任何语义。
POST的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST不安全，不幂等，（大部分实现）不可缓存。为了针对其不可缓存性，有一系列的方法来进行优化，以后有机会再研究（FLAG已经立起）。
还是举一个通俗栗子吧，在微博这个场景里，GET的语义会被用在「看看我的Timeline上最新的20条微博」这样的场景，而POST的语义会被用在「发微博、评论、点赞」这样的场景中。
关于幂等，POST所对应的URI并非创建的资源本身，而是资源的接收者。比如：POST http://www.forum.com/articles 的语义是在http://www.forum.com/articles 下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。比如：PUT http://www.forum/articles/4231 的语义是创建或更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。
