HTTP协议小结
·····什么getParameter又失效了Σ(っ °Д °;)っ
@(Java Web)[http, 请求, 响应, \r\n, Content-Type, application/x-www-form-urlencoded, ]
HTTP是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。它于1990年提出,经过几年的使用与发展,得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,而且HTTP-NG(Next Generation of HTTP)的建议已经提出。HTTP协议的主要特点可概括如下:(反正这段是我抄的o((>ω< ))o)
- 1 :支持客户/服务器模式。
- 2 :简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
- 3 :灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type
加以标记
- 4 无连接
:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。1
- 5无状态
:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。
简单说几句
第一句:首先呢,这篇博客的主要框架内容来自于我学习的黑马视频中附送的资料,后来我发现这是来自CSDN的一篇博客,但是当我在网上找到相同资料的时候发现原来博客的链接竟然失效了(说什么违反CSDN的规则- -)。自己本着学习要及时记录的原则,我又从网络上搜罗了一些资料,和我在视频中学到的知识进行整理,从而有了这篇文章。我会尽量将我用到资料的原址在文章中链接出来供可能会看到人参考。。如果是别的作者的原话我会用引用框标出来!!!!!!!!!!!!!!!
对于硬性的死知识就随便了~
第二句:这篇文章我只想尽量总结一下http中的我目前会有的疑问,
1Browser---请求--->Server[收到]--响应-->Browser
2总的来说,请求有请求的参数,响应有响应的参数。这种一问一答的方式就是http给我最大的印象。
因此你可以把它看成两个部分,而每个部分又分成主要的3份
。
饭前点心:HTTP协议详解之URL篇
URL统一资源定位符 —— 百度百科
了解得不清楚的同学平时很容易和URI搞混。
在JDK5以后对java.net包对其作出了明确的区分,借用知乎中看到的话说“RI表示请求服务器的路径,定义这么一个资源。而URL同时说明要如何访问这个资源” 。具体情况 可以参看知乎上的这个问答。
HTTP URL (URL是一种特殊类型的URI,包含了用于查找某个资源的足够的信息)的格式如下:
http://host:port[abs_path]
http表示要通过HTTP协议来定位网络资源;host表示合法的Internet主机域名或者IP地址;port指定一个端口号,为空则使用缺省端口80;abs_path指定请求资源的URI;如果URL中没有给出abs_path,那么当它作为请求URI时,必须以“/”的形式给出,通常这个工作浏览器自动帮我们完成。
eg:
1、输入:www.guet.edu.cn
浏览器自动转换成:http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp
* HTTP协议详解之请求篇
HTTP 请求
http请求由三部分组成,分别是:请求行、消息报头、请求正文
-1但更确切的说,是四部分,尤其是请求头和请求体之间的空格不能省略。
-2有关回车符 ‘\r’ 换行符 ‘\n’ 涉及在http协议中乃至不同系统之间传输所起到的作用将在下面的重点与详细说明中一一细说。
请求行
1、请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本,格式如下:Method Request-URI HTTP-Version CRLF
其中
Method 表示请求方法;
Request-URI 是一个统一资源标识符;
HTTP-Version 表示请求的HTTP协议版本;
CRLF表示回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)2
常见的请求方式有:分别对应 查、改、增、删 具体如下:
GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
PUT 请求服务器存储一个资源,并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
具体的方法共有15种:
序号 | 方法 | 描述 |
---|---|---|
1 | GET | 请求指定的页面信息,并返回实体主体 |
2 | HEAD | 类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头 |
3 | POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求 体中。POST请求可能会导致新的资源的建立和/或已有资源的修改 |
4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
5 | DELETE | 请求服务器删除指定的页面。 |
6 | CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器 |
7 | OPTIONS | 允许客户端查看服务器的性能 |
8 | TRACE | 回显服务器收到的请求,主要用于测试或诊断 |
9 | PATCH | 实体中包含一个表,表中说明与该URI所表示的原内容的区别 |
10 | MOVE | 请求服务器将指定的页面移至另一个网络地址 |
11 | COPY | 请求服务器将指定的页面拷贝至另一个网络地址 |
12 | LINK | 请求服务器建立链接关系 |
13 | UNLINK | 断开链接关系 |
14 | WRAPPED | 允许客户端发送经过封装的请求 |
15 | Extension-mothed | 在不改动协议的前提下,可增加另外的方法 |
请求头
请求头标:允许客户端传递关于自身的信息和希望的响应形式。
以键值对得形式可以抓包看的。常见的我在下面会用红色
加注。
反正我感觉ContextType挺重要的。web开发什么问题很恶心?乱码
。
请求体
需要注意的是:POST、PUT以及PATCH这三个动词时会包含请求体,而GET、HEAD、DELETE、CONNECT、TRACE、OPTIONS这几个动词时不包含请求体。
请求体的种类
对于刚刚接触java web的接触初学者来说(看什么看,我也是¬_¬),暂时只需要了解:
GET 和POST方法,这也是最最常用的两种请求方式。
GET:此时没有请求体,请求的参数会在请求行中“便携”给服务器端。
POST:会有请求体。
好奇心害死猫㊙
疑问1:http协议请求行,请求头,请求体后面都有
\r\n
,这是必需的么,平时抓包怎么看不到,他到底有什么作用?还有就是请求头和请求体之间的空行可以省略么?
答:是必须的,这涉及到了不同操作系统之间信息传递。请求头和请求体之间的空行也不可以取消。在一些互联网编程书籍中,CRLF还被认为是HTTP请求的第四部分。同理在响应头里也是一样的。
平时抓包有看不到或许是调试工具屏蔽掉了,使用巴克斯范式就可以看到,具体参考这篇文章。
其实这里面有一点是需要明确一下的,数据在网线上进行传输,最终的形态都是二进制即高低电平的形式在物理层上面传输,我们所要讨论的问题在于其在应用层面做了什么操作。比如FTP,先做转换,完事之后传输。 说完FTP,回来看HTTP是如何传输的。这其实要分成两部分,第一部分是HTTP的头部是如何传输的;第二部分是HTTP的消息实体是如何传输的。就像前面所涉及到的FTP,说的是数据部分要做转换。对于HTTP的消息实体,其传输方式多种多样,可以从头域Content-Encoding中看出来。也就是说消息实体会先经过Content-Encoding编码转换成为中间格式,在到达目的端然后在解码出来,即转换为目的端的情况。这里其实和FTP会经历中间格式是一回事,也就是说对于消息实体换行的事情,中间格式给解决了。这些也就是浏览器的开发者需要考虑实现的。
\n 软回车:
在Windows 中表示换行且回到下一行的最开始位置。相当于Mac OS 里的 \r 的效果。
在Linux、unix 中只表示换行,但不会回到下一行的开始位置。
\r 软空格:
在Linux、unix 中表示返回到当行的最开始位置。
在Mac OS 中表示换行且返回到下一行的最开始位置,相当于Windows 里的 \n 的效果。
Unix系统里,每行结尾只有“<换行>”,即“\n”;
Windows系统里面,每行结尾是“<换行><回车>”,即“\n\r”;
Mac系统里,每行结尾是“<回车>”。一个直接后果是,Unix/Mac系统下的文件在Windows里打开的话,所有文字会变成一行;而Windows里的文件在Unix/Mac下打开的话,在每行的结尾可能会多出一个^M符号。具体参考小历史。3
疑问2:我在练习Ajax的时候使用的传输的格式Json,发现抓包的看到请求头Accept属性是:application/json, text/javascript;然后看到响应头的Content-Type属性是:text/html;charset=utf-8;后来我检查服务器端代码发现是我为了防止乱码的进行设置的。但我不明白为什么写成text/html也可以?
答:首先我们需要知道什么是MIME,他的全称为“Multipurpose Internet Mail Extensions”, 比较确切的中文名称为“多用途互联网邮件扩展”。 什么是MIME类型?-在把输出结果传送到浏览器上的时候,浏览器必须启动适当的应用程序来处理这个输出文档。在HTTP中,MIME类型被定义在Content-Type header中。每个MIME类型由两部分组成,前面是数据的大类别,例如声音audio、图象image等,后面定义具体的种类。刚开始有来规范他们,但随着互联网的高速发展慢慢就形成这样的局面:客户机和服务器共同承认这个MIME类型,即使它是不标准的类型也没有关系
,举个例子,尽管你设置响应格式是text/html;当你返回的Json数据中不包含html标签的时候,浏览器也解释不出你这到底是个啥,只知道这是普通文本,但是有意思的地方在于你使用的是Ajax,Ajax说了“不管你给的啥,反生请求前咱就说好了就用Json格式,你变卦是你的事,反正返回的文本我就按Json来解析”。正好你的Json数据符合,因此解析正确,这样的情况正好对应上边红色的话,只要客户和服务器器都承认,表不标准不重要,但这也不太好,这样不符合标准不说,还容易发生错误。尽量写成 application/json 为妙,还有人写成 text/json,其实压根没有这种说法。比如常见的媒体格式类型如下:
text/html
: HTML格式
text/plain
:纯文本格式
text/xml : XML格式
image/gif :gif图片格式
image/jpeg :jpg图片格式
image/png:png图片格式
以application
开头的媒体格式类型:
application/xhtml+xml :XHTML格式
application/xml : XML数据格式
application/atom+xml :Atom XML聚合格式
application/json
: JSON数据格式
application/pdf :pdf格式
application/msword : Word文档格式
application/octet-stream : 二进制流数据(如常见的文件下载)
application/x-www-form-urlencoded : 中默认的encType,form表单数据被编码为key/value格式发送到服务器(表单默认的提交数据的格式)
另外一种常见的媒体格式是上传文件之时使用的:
multipart/form-data : 需要在表单中进行文件上传时,就需要使用该格式
以上就是我们在日常的开发中,经常会用到的若干content-type的内容格式。疑问3:form表单提交的数据,为啥我服务器端的request.getParameter()方法取到的是空值?(๑ŐдŐ)b
答:
1.首先确保你的前台后台取值对象正确,代码拼写。
2.看看你的form表单的encType属性,是否写成了 multipart/form-data ,参考疑问2可以知道这是用于文件上传的选项,基于tomcat的源码,查询HttpServletRequest接口中关于public String getParameter()有明确说明getInputStream方法和getReader方法会对其产生影响(提示你使用这两种方法进行获取)
* <p>
* You should only use this method when you are sure the parameter has only
* one value. If the parameter might have more than one value, use
* {@link #getParameterValues}.
* <p>
* If you use this method with a multivalued parameter, the value returned
* is equal to the first value in the array returned by
* <code>getParameterValues</code>.
* <p>最后一段
* If the parameter data was sent in the request body, such as occurs with
* an HTTP POST request, then reading the body directly via
* {@link #getInputStream} or {@link #getReader} can interfere with the
* execution of this method.
至于为什么会产生影响,大体上是如果是上传文件的形式,那么传上来的数据上来数据不往getParameter()获取的目的地paramHashValues 对象进行存储,因此获取不到。如果提交的只是普通的键值对,encType属性设为空
即可,如果encType属性设为 application/x-www-form-urlencoded,那么需要将form表单的提交方式确定为POST。
查看tomcat org.apache.tomcat.util.http.Parameters
我们可以找到一个此对象:
private final Map<String,ArrayList<String>> paramHashValues =
new LinkedHashMap<String,ArrayList<String>>();
由上边的结构我们可以看出对于同名参数的value存放是在map中嵌套数组实现的。
- 疑问4:我在使用jQuery中ajax方法传输时context-type设置为application/json,为啥服务器的request.getParameter()方法取到的是空值?
答:参看疑问3,我们知道getParameter()方法实质上是从一个map中获取的相应的参数
的,这也就意味这你传过来的数据必须以键值对的形式提供给给我(谁来解析并包装这些数据呢?tomcat
)。那么问题就来了,服务器怎么知道
你传过来的数据到底是不是键值对的形式呢?
首先明确几点:(不想看的可以直接跳过去,但你必须知道post有x-www-form-urlencoded而get没有)
1.对于htttp,请求中,get方法是没有请求体的,他也没有Context-Type请求头属性4
举例:
//页面完毕后使用get提交方式去服务器端获取所有的category数据
$(function(){
$.get(
"${pageContext.request.contextPath}/product?method=categoryList",
"[{'cid':'1','cname':'手机数码'},{'cid':'2','cname':'电脑办公'}]",
function(data){
}
},
"json"
);
});
通过抓包请求头没有发现Context-Type:
2.对于htttp,请求中x-www-form-urlencoded的意义是会将表单内的数据转换为键值对
,比如,name=Jtom&age = 11 这也是POST提交方式的默认选项。
举例:
//页面完毕后使用post提交方式去服务器端获取所有的category数据
$(function(){
$.post(
"${pageContext.request.contextPath}/product?method=categoryList",
"[{'cid':'1','cname':'手机数码'},{'cid':'2','cname':'电脑办公'}]",
function(data){
},
"json"
);
});
通过抓包请求头发现Context-Type:application/x-www-form-urlencoded; charset=UTF-8:
3.同样,在jQuery中的Ajax方法同样遵循上述两种规则:
但要注意他的默认提交方式是GET:
因此,如果你想观察到ContextType的话,还是用过设置data:”POST” 吧,事实上这也是开发中最常用的。
说了这么多,’回到tomcat怎么知道你传过来的数据到底是不是键值对的形式呢
?’
这个话题,我们找到继续查询tomcat源码HttpServletRequest 的实现类org.apache.catalina.connector.RequestFacade
protected void parseParameters() {
.............
try {
........中间的注释是大部分被省略的内容的解释,或许也挺有用的
// getCharacterEncoding() may have been overridden to search for
// hidden form field containing request encoding
........
parameters.handleQueryParameters();//这里是处理url中的参数的方法如果追查下去会发现其中的参数经历了字符串分割最后进入parameters.processParameters()方法,我想这也是get方法照样可以被getParameter()获取到的原因。
//这里可以看到用流的形式处理在getParameter()之前,或许这就是在疑问3中提到的为什么流可以影响getParameter()方法
if (usingInputStream || usingReader) {
success = true;
return;
}
..........
获取ContentType并对其加工,方便下一步检测
String contentType = getContentType();
if (contentType == null) {
contentType = "";
}
int semicolon = contentType.indexOf(';');
if (semicolon >= 0) {
contentType = contentType.substring(0, semicolon).trim();
} else {
contentType = contentType.trim();
}
//重点来了,如果是文件上传类型,直接跳转到其他处理函数不在执行
if ("multipart/form-data".equals(contentType)) {
parseParts();
success = true;
return;
}
//如果不是键值对类型(非POST),直接不再执行(“tomcat吐槽:什么乱七八糟的,妖魔鬼怪快走开)
if (!("application/x-www-form-urlencoded".equals(contentType))) {
success = true;
return;
}
//经过过滤,只剩下了POST类型的了
int len = getContentLength();
if (len > 0) {
...........反正又经历了一堆乱七八糟看不懂的准备过程(貌似是加工请求体的)
try {
if (readPostBody(formData, len) != len) {//自己看名字
return;
}
} catch (IOException e) {
// Client disconnect
if (context.getLogger().isDebugEnabled()) {
context.getLogger().debug(
sm.getString("coyoteRequest.parseParameters"), e);
}
return;
}
parameters.processParameters(formData, 0, len);//终于开始处理POST请求参数,把它放到前文提到好多次map中
} else if ("chunked".equalsIgnoreCase(
coyoteRequest.getHeader("transfer-encoding"))) {
...........又是一堆扑捉异常的看不懂的高深代码(/ □ \)
} finally {
if (!success) {
parameters.setParseFailed(true);
}
}//try
}//parseParameters()
/**
* Read post body in an array.
*/
protected int readPostBody(byte body[], int len)
throws IOException {
int offset = 0;
do {
int inputLen = getStream().read(body, offset, len - offset);
if (inputLen <= 0) {
return offset;
}
offset += inputLen;
} while ((len - offset) > 0);
return len;
}
至此,Content-Type如果不是application/x-www-form-urlencoded的POST请求tomcat就不会解析你的数据放在map中。所以你通过request.getParameter()是根本获取不到的,那你会说这咋整?
1.把你提交的Content-Type 的application/json 改成 application/x-www-form-urlencoded,一般json数据从服务器返回时我们才会写成application/json。
2.在服务器端使用流的方式进行接收,具体处理,要看你是什么样的数据结构了。
对了,你还要注意,如果你是搞前端的,js原生Ajax必须手动设置Content-Type为application/x-www-form-urlencoded,不然变成text/plain
你也知道意味着啥<( ̄ˇ ̄)/
* HTTP协议详解之响应篇
响应行
格式如下:
HTTP-Version /Status-Code /Reason-Phrase CRLF(s就是前面说的换行回车)
其中,HTTP-Version表示服务器HTTP协议的版本;
Status-Code表示服务器发回的响应状态代码;
Reason-Phrase表示状态代码的文本描述。状态代码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值。
1xx:指示信息–表示请求已接收,继续处理。
2xx:成功–表示请求已被成功接收、理解、接受。
3xx:重定向–要完成请求必须进行更进一步的操作。
4xx:客户端错误–请求有语法错误或请求无法实现。
5xx:服务器端错误–服务器未能实现合法的请求。
其实我们真正常见的有这几种,其他的因为太多都不常用(懒得用?¬_¬)。反正暂时我没感觉很重要,表格我就不贴了。
•200
- 请求成功
•301
- 资源(网页等)被永久转移到其它URL
•404
- 请求的资源(网页等)不存在
•500
- 内部服务器错误
响应头
跟请求头差不多噻?反正就是键值对,包含各种信息。
但是得知道的是:
1通用头标:即可用于请求,也可用于响应,是作为一个整体而不是特定资源与事务相关联。
2.请求头标:允许客户端传递关于自身的信息和希望的响应形式。
3.响应头标:服务器和于传递自身信息的响应。
4.实体头标:定义被传送资源的信息。即可用于请求,也可用于响应.
具体查看??自己看表格吧。⬇
响应体
具体你请求到的资源,一段格式各异字符串,一个页面,一段代码,一个图片,音频…(* ̄0 ̄)ノv
*HTTP协议详解之消息报头篇
请求头列表:
请求头 | 解释 | 事例 |
---|---|---|
Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
Connection | 表示是否需要持久连接。(HTTP 1.1默认进行持久连接) | Connection: close |
Cookie | HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
Content-Length | 请求的内容长度 | Content-Length: 348 |
Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
Expect | 请求的特定的服务器行为 | Expect: 100-continue |
From | 发出请求的用户的Email | From: user@email.com |
Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
If-None-Match | 如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Range | 如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Range | 只请求实体的一部分,指定范围 | Range: bytes=500-999 |
Referer | 先前网页的地址,当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
TE | 客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
Upgrade | 向服务器指定某种传输协议以便服务器进行转换(如果支持) | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
Via | 通知中间网关或代理服务器地址,通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
响应头列表:
Col1 | Col2 | Col3 |
---|---|---|
Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
Age | 从原始服务器到代理缓存形成的估算时间(以秒计,非负) | Age: 12 |
Allow | 对某网络资源的有效的请求行为,不允许则返回405 | Allow: GET, HEAD |
Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
Content-Language | 响应体的语言 | Content-Language: en,zh |
Content-Length | 响应体的长度 | Content-Length: 348 |
Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.baidu.com/ |
Pragma | 包括实现特定的指令,它可应用到响应链上的任何接收方 | Pragma: no-cache |
Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
refresh | 应用于重定向或一个新的资源被创造,在5秒之后重定向(由网景提出,被大部分浏览器支持) | Refresh: 5; url=http://www.baidu.com/ |
Retry-After | 如果实体暂时不可取,通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
Server web | 服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
Set-Cookie | 设置 | Http Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
Trailer | 指出头域在分块传输编码的尾部存在 | Trailer: Max-Forwards |
Transfer-Encoding | 文件传输编码 | Transfer-Encoding:chunked |
Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
Via | 告知代理客户端响应是通过哪里发送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
反馈与建议
- 邮箱:<499792549@qq.com>
如果你看到这里,恭喜你发现彩蛋一枚,你没有发现我文中有个截图里的请求头
贼长?为了截上他,图都变形了=_=~。那么问题来了,他为什么我们通常见到User-Agent
那么长?????答案在…..
注脚
- 无连接、无状态。这些曾是http协议的风光一时的优点,随着现代互联网的网速提升,web服务器的并发量急剧升高,服务器被动,通信占用资源大的缺点也在慢慢暴露出来。这也是我学到Ajax后才偶然了解到的。尽管我还是个菜鸟,但我想着在未来博客里尽量总结一下这方面的知识。
浏
↩ - 无连接、无状态。这些曾是http协议的风光一时的优点,随着现代互联网的网速提升,web服务器的并发量急剧升高,服务器被动,通信占用资源大的缺点也在慢慢暴露出来。这也是我学到Ajax后才偶然了解到的。尽管我还是个菜鸟,但我想着在未来博客里尽量总结一下这方面的知识。
浏
↩ - “回车”(carriage return)和“换行”(line feed)这两个概念的来历和区别:
在计算机还没有出现之前,有一种叫做电传打字机(Teletype Model 33)的玩意,每秒钟可以打10个字符。但是它有一个问题,就是打完一行换行的时候,要用去0.2秒,正好可以打两个字符。要是在这0.2秒里面,又有新的字符传过来,那么这个字符将丢失。览
于是,研制人员想了个办法解决这个问题,就是在每行后面加两个表示结束的字符。一个叫做“回车”,告诉打字机把打印头定位在左边界;另一个叫做“换行”,告诉打字机把纸向下移一行。器
后来,计算机发明了,这两个概念也就被般到了计算机上。那时,存储器很贵,一些科学家认为在每行结尾加两个字符太浪费了,加一个就可以。于是,就出现了分歧。大
↩ - 这里需要说明的是既然GET方式的参数是跟在请求行的URL后面的,那么他的编码方式就是跟随URL一致的,事实上,在Http请求到达Servlet解析之前,GET过来的URL已经被Tomcat先做了一次URLDecode,Tomcat对GET方式默认的URL解码结果是iso-8859-1。Tomcat对GET方式默认的URL解码结果是iso-8859-1。
战
↩