说明:不是第一次学习学习HTTP相关知识,因工作需要又翻看了一下,特做些笔记
一 基本概念
(1)URL和URI理解
1: '概念'
URI:Uniform Resource Identifier 统一资源'标识符'
URL:Uniform Resource Location 统一资源'定位符'
URN:Uniform Resource Name 统一资源名-->是'带有名字'的'因特网资源'
区别
URI是一个用于标识互联网'资源名称'的字符串 -->'可以理解为资源在网站的相对位置' -->'强调'web资源
'资源': html文档、图像、视频、程序等
该种标识允许用户对网络中(一般指万维网)的资源通过'特定的协议'进行'交互操作'
------- '分割线' -------
URI强调'资源的唯一标识',URL在此基础上加上协议,URL强调的是'资源的访问方式'
资源访问方式理解:通俗的讲就是通过什么协议('protoctl')'http、https、ftp、file、mailto、telnet 等'来访问资源
原因: 浏览器的功能'不仅仅局限于'访问 web 服务器,也可以用来访问 ftp 服务器,也可以用来浏览本地文件,也可以用来'发送邮件'
核心: 浏览器需要有一个东西来'判断使用哪种功能'来访问相应的数据
'维基百科':URL是URI的一种,不仅'标识了Web 资源',还指定了'操作或者获取'方式,同时指出了主要'访问机制和网络位置'
------- '分割线' -------
通俗地说,URL和URN是URI的'子集',URI属于URL'更高层次的抽象',一种字符串文本标准。
'辩证':URL和URN都是URI,但是URI不一定是URL或者URN
'维基百科': URN是URI的一种,用'特定命名空间(某一个特定资源特定位置-->锚点)'的'名字标识资源',使用URN可以在'不知道其网络位置'及'访问方式'的情况下'讨论资源'
绝对URI
一个例子说明问题
URI -->'严格意义上不算是URI'
http://wangzj.club/index.html#print
URL -->'告诉我们访问网络位置的方式'-->'不包括锚点'
http://wangzj.club/index.html
URN -->'不包括访问方式'
wangzj.club/index.html#print
1. 井号在URL中指定的是页面中的一个位置-->其实就是'页面内''特定位置'资源的的一个'锚点'
2. 井号后面的数据'不会发送到'HTTP请求中
原因:井号后面的参数是'针对浏览器'起作用的'而不是服务器端'
3. 任务位于井号后面的字符都是'位置标识符'
不管第一个井号后面跟的是什么参数,只要是在'井号后面的参数'一律看成是'位置标识符'
4. 改变井号后面的参数'不会触发页面的重新加载'但是会'留下一个历史记录'
仅改变井号后面的内容,只会使浏览器'滚动'到相应的位置,'并不会'重现加载页面
牢记
牢记:URI可以被分为URL、URN或两者的组合。如果你一直使用'URI这个术语',就'没毛病'
(2)URL地址最后面的“/”加和不加到底有什么区别
(1)http://wangzj.club/
'域名'(ip)'直接加上'/ ,这个 / 表示我们要访问的是'根目录',但是'没有指定根目录下的文件','默认'就是根目录下的 'index.html' -->具体看我们'怎么配置的'
(2)http://www.baidu.com/folder/
这个 URI 以一个 / 结尾,表示'folder 是一个目录',我们'要访问的是这个目录下的文件',但是又'没有说明'是这个目录下的'哪个文件',此时依然是采用该目录下 index.html 一类的文件
(3)http://www.baidu.com/folder
1) 即 folder 后面没有 /,此时会'先将' folder 当作一个'资源去访问'(比如一个名为 folder资源)
2) 如果'没有'名为 folder 的资源,那么浏览器会'自动在 folder 后面加上一个 /' ,此时地址变为 http://www.baidu.com/folder/ ,folder 是一个目录,然后就会去尝试访问 folder 目录下的 index.html 或者 default.html。
'注意':这种自动调整'只在浏览器中存在',如果你的项目是一个'手机 App' 或者你是一个 'Ajax 请求',则不会有这种调整,即没写 / 就当做具体资源来对待,如果该资源不存在,就会报 404 ,写了/ 就当目录来对待。
'结论':有 / 和没有 / ,访问结果有可能是天壤之别。
(3)浏览器显示术语的讲解
请求首部、请求行、请求头、请求体
(4)HTTP的资源操作动作
Restful风格: Http定义了客户端'C'与服务器'S'交互的不同方法
'最基本的方法'有4种: 分别是'GET,POST,PUT,DELETE'
理解:一个URL地址,它用于描述一个网络上的资源,而HTTP中的GET,POST,PUT,DELETE就对应着'对这个资源'的查,改,增,删4个'操作'
(5)浅谈HTTP中Get与Post的区别
通俗理解: GET一般用于'获取/查询'资源信息,而POST一般用于'更新'资源信息
伏笔: '更新'的理解?
HTTP对GET的规范要求
1.根据HTTP规范,GET用于'信息获取',而且应该是'安全的'和'幂等的'
1) 所谓安全的'意味着'该操作用于'获取信息而非修改信息',换句话说,GET 请求一般不应产生'副作用'。
'抽象理解': 它仅仅是获取资源信息,就像数据库查询一样,不会修改,增加数据,'不会影响资源的状态'
'注意':这里安全的含义仅仅是指是'非修改信息'
(2) 幂等的意味着'对同一URL的多个请求应该返回同样的结果'。
幂等(idempotent、idempotence)是一个数学或计算机学概念,常见于抽象代数中。
幂等有一下几种定义:
对于'单目运算',如果一个运算对于在范围内的所有的一个数多次进行该运算所得的结果和进行一次该运算所得的结果是一样的,那么我们就称该运算是幂等的。比如绝对值运算就是一个例子,在实数集中,有abs(a)=abs(abs(a))。
对于'双目运算',则要求当参与运算的两个值是等值的情况下,如果满足运算结果与参与运算的两个值相等,则称该运算幂等,如求两个数的最大值的函数,有在在实数集中幂等,即max(x,x) = x。
看完上述解释后,应该可以理解GET幂等的含义了。
但在实际应用中,以上'2条规定并没有这么严格'。比如,新闻站点的'头版不断更新'。虽然第二次请求会'返回不同的一批新闻',该操作仍然被认为是'安全的和幂等的',因为它总是'返回当前的新闻'。
实际幂等理解: 从根本上说,如果目标是'当用户打开一个链接时',他可以确信'从自身的角度'来看没有改变资源即可
HTTP对POST规范要求
2.根据HTTP规范,POST表示可能修改变服务器上的资源的请求。
例子:还是新闻以网站为例,读者对新闻'发表自己的评论'应该通过POST实现,因为在评论提交后'站点的资源已经不同了',或者说资源'被修改了'
没有遵守HTTP对GET、POST规范引发问题
但在实际的做的时候,很多人却'没有按照HTTP规范'去做,导致这个问题的原因有很多
比如说:
1.很多人'贪方便','更新资源时用了GET',因为用POST必须要到FORM(表单),这样'会麻烦'一点。
2.对资源的增,删,改,查操作,'其实都可以通过GET/POST完成','不需要用到'PUT和DELETE。
3.另外一个是,早期的Web MVC框架设计者们'并没有有意识地'将URL当作'抽象的资源'来看待和设计,所以导致一个比较严重的问题是'传统的Web MVC框架'基本上都'只支持GET和POST'两种HTTP方法,而'不支持PUT和DELETE方法'。
MVC: M是指数据模型('model'),V是指用户界面('visual'),C则是控制器('control')。使用MVC的目的是将M和V的实现代码分离,从而使同一个程序可以'使用不同的表现形式。
以上3点典型地描述了'老一套的风格'(没有严格遵守HTTP规范),随着架构的发展,现在出现REST(Representational State Transfer),一套'支持HTTP规范的新风格'
(6)表像上看GET和POST的区别
(1) '数据传送方式'-->位置
(2) '数据限制'
(3) '安全性'
GET和POST数据
(1) GET'请求的数据'会附在URL之后(就是把数据放置在'HTTP协议头'中),以'?'分割'URL'和'传输数据',参数之间'以&(且)相连'
如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。
1) 如果'数据'是英文字母/数字,'原样发送'
2) 如果是'空格',转换为+
3) 如果是'中文/其他字符',则直接把字符串用'BASE64加密',得出如:%E4%BD%A0%E5%A5%BD,其中%XX中的XX为该符号'以16进制'表示的ASCII。
后续测试: base解码看是否能'还原中文'
备注:该方法对于用户希望'加入书签的表单提交'很有用
(2) POST把提交的数据则放置在是'HTTP包的包体中' -->后续'浏览器展示'
数据限制
(1) 'GET方式'提交的数据'最多'只能是'1024字节',理论上POST没有限制,可传较大量的数据,IIS4中最大为80KB,'IIS5'中为100KB
以上这句是我从其他文章转过来的,其实这样说是'错误的,不准确的':
1).首先是"GET方式提交的数据最多只能是1024字节"
因为GET是'通过URL提交数据',那么GET可提交的数据量就'跟URL的长度'有直接关系了。而实际上,URL'不存在参数上限'的问题
HTTP'协议规范'没有对'URL长度'进行限制,这个限制是'特定的浏览器'及'服务器'对它的限制.
IE对URL长度的限制是2083字节(2K+35),对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于'操作系统的支持'。
注意: 这是'限制是整个URL长度',而'不仅仅'是你的'参数值数据长度'。
(2) 理论上讲,POST是没有大小限制的,HTTP'协议规范'也没有进行大小限制,说"POST数据量存在80K/100K的大小限制"是不准确的,POST数据是没有限制的
实质:'起限制作用'的是'服务器的处理程序'的处理能力。
对于ASP程序,Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个限制。
由这个延伸出去,对于IIS 6.0,微软'出于安全考虑',加大了限制。我们还需要注意:
1).IIS 6.0默认ASP POST数据量最大为200KB,每个表单域限制是100KB。
2).IIS 6.0默认上传文件的最大大小是4MB。
3).IIS 6.0默认最大请求头是16KB。
IIS 6.0之前没有这些限制,重点是这些'限制参数大小的类型'
所以上面的80K,100K'可能只是默认值'而已,但肯定是可以自己设置的。由于每个版本的IIS对这些参数的'默认值都不一样',具体请参考相关的IIS配置文档。
(3) POST的安全性要比GET的'安全性高'。
注意:这里所说的安全性和上面GET提到的"安全"不是同个概念。上面"安全"的含义仅仅是'不作数据修改',而这里安全的含义是"真正的Security的含义".
比如:通过GET提交数据,'用户名和密码'将'明文'出现在URL上-->'不安全原因'
1) 登录页面'有可能被浏览器缓存'-->cookier
2) 其他人'查看浏览器的历史纪录',那么别人就可以拿到'你的账号和密码了'-->'历史记录'
3) 除此之外,使用'GET提交数据'还可能会造成Cross-site request forgery攻击。
总结:Get是向服务器发索取数据的一种请求,而Post是向服务器提交数据的一种请求,在FORM(表单)中,Method默认为"GET",实质上,GET和POST只是发送机制不同,并不是一个取一个发!