Linux之Http＜3＞--表单

之前的代码编写,都是对网站资源的请求,等等 ,那些都是对于静态资源的获取

但是还存在动态内容的获取,比如动态站点,支持用户进行登录,注册,支付,查找等功能功能

静态资源请求 VS 动态请求

1. 静态资源

• 请求目标：.html、.png、.css、.js这类文件
• 特点：文件内容提前写死、不会随用户变化；服务器只做一件事：读取本地文件，把文件原样返回给浏览器
• 例子：访问/index.html、/pet.png

2. 动态请求

• 请求目标：不是一个本地实体文件，是一个接口路径，比如/login、/register
• 特点：服务器不能直接读文件返回，要执行业务逻辑： 接收前端传过来的参数（账号密码）→ 操作数据库 → 根据结果动态生成返回内容（页面、跳转指令、JSON 数据）
• 数据传递：一般用POST请求，把参数放在请求体（body）里；GET 参数一般放在 URL 问号后面

http表单

Get和Post方法

如何理解浏览器给httpserver提交参数的过程

在前端网页中,表单

如果使用get方法,就是url传参

浏览器会把表单数据拼在URL 问号后面，放在请求行里，没有请求体 body

在我输入完用户名和密码的时候

1. URL 变成简单的POST /login HTTP/1.1
2. 账号密码放到HTTP 请求体（body）里面，不再暴露在地址栏
3. 请求头会带上Content-Type: application/x-www-form-urlencoded，body 内容是username=maomao&password=666666

路由服务功能

服务器解析请求报文，提取请求 URI，优先在wwwroot静态资源目录中查找文件：

1. 当目录下存在该文件时，识别为静态资源，读取文件内容构造响应返回浏览器；
2. 当目录下找不到对应文件时，不再走静态文件逻辑，转发至动态服务模块，执行注册好的业务回调。

再main中要注册这个服务

结论

get方法可以用来获取静态资源,同时也可以向目标服务器传递参数->uri传参

post方法可以向目标服务器传递参数->正文传参

如何看代http请求中的uri

1.认为是linux web根目录小存在的一个文件路径(静态资源访问),

2.将其看作一个字符串,用来请求http server所对应的服务(动态服务),字符串也往往以路径的形式出现,但是这个路径不能再web跟目录下面

两者都可以进行传参用哪个比较好呢

post传参更加私密,也可以传参数据量比较大的情况,但是两者都不安全

怎么证明不安全

Http Tool Kit可以对其进行抓包

流程：浏览器直连远端服务器，没有中间代理

1. 浏览器构造 HTTP 请求，直接通过网络发给服务器；
2. 服务器接收请求、处理、返回响应，数据直接传回浏览器；
3. 流量没有任何中间软件拦截，看不到原始报文。

流程：浏览器 → HTTP Toolkit（代理） → 远端服务器

1. Windows 上的浏览器要访问网页、提交登录表单，不会直接发给服务器；
2. 浏览器的网络流量先转发给本机运行的 HTTP Toolkit；
3. HTTP Toolkit 把请求报文原样（或者你修改之后）转发给远端服务器；
4. 服务器处理请求，返回响应报文，先回到 HTTP Toolkit；
5. HTTP Toolkit 把响应交给浏览器，浏览器渲染页面、跳转。

抓取到的内容是明文的,说明get和post的方法其实都不安全

这时需要加密流程

HTTP 明文不安全，但它依然有不可替代的存在价值，不会被彻底淘汰；HTTPS 是加密升级版，不是用来直接废掉 HTTP 的。

HTTP 的 “不安全” 指的是传输明文

• 比如这个 HTTP Toolkit、公共 WiFi 里的抓包程序可以直接看到全部内容：请求路径、表单用户名密码、Cookie、返回的网页内容；
• 还可以篡改报文，把返回的页面改掉；
• 所以涉及登录、支付、隐私数据的业务，绝对不能裸用 HTTP，必须 HTTPS

https

黑色箭头

链路：浏览器 → HTTP 明文 → TCP → 网络 → 服务器

• 抓包工具拿到 TCP 的数据，直接就是完整 HTTP 明文
• 能直接看到：请求行、请求头、POST 表单用户名密码、响应 HTML 内容
• 可以随意修改报文再转发给服务器，也就是中间人篡改。

蓝色箭头

网线里抓到的 TCP 载荷是TLS 加密后的密文，只有一堆乱码，看不到里面的 HTTP 内容。 外面的人只能看到：IP、端口，看不到 URL、表单、Cookie。

http剩余的方法