Luff 4年前

修改理由:

错别字

详细描述:

错别字

相关信息:


此投稿已在 4年前 合并。

内容修改:

红色背景 为原始内容

绿色背景 为新增或者修改的内容

OldNewDifferences
1  
21HTTP 消息接口
32=======================
43
 
76
87HTTP 消息是 Web 技术发展的基础。浏览器或 HTTP 客户端如 `curl` 生成发送 HTTP 请求消息到 Web 服务器,Web 服务器响应 HTTP 请求。服务端的代码接受 HTTP 请求消息后返回 HTTP 响应消息。
98
10 通常 HTTP 消息对于终端用户来说是不可见的,但是作为 Web 开发者,我们需要知道 HTTP 机制,如何发起、构建、取用还有操纵 HTTP 消息,知道这些原理,以助我们好的完成开发任务,无论这个任务是发起一个 HTTP 请求,或者处理传入的请求。
11 
 9通常 HTTP 消息对于终端用户来说是不可见的,但是作为 Web 开发者,我们需要知道 HTTP 机制,如何发起、构建、取用还有操纵 HTTP 消息,知道这些原理,以助我们好的完成开发任务,无论这个任务是发起一个 HTTP 请求,或者处理传入的请求。
 10
1211
1312每一个 HTTP 请求都有专属的格式:
1413
 
3635
3736本文件中的 `必须`,`不得`,`需要`,`应`,`不应`,`应该`,`不应该`,`推荐`,`可能` 和 `可选` 等能愿动词按照 [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt) 中的描述进行解释。
3837
39 
 38
4039### 参考文献
4140
4241-  [RFC 2119](http://tools.ietf.org/html/rfc2119)
 
5554
5655从这里开始,当描述这些接口时,命名空间 `Psr\Http\Message` 将会被省略。
5756
58 
 57
5958
6059### 1.2 HTTP 请求头信息
6160
 
8079虽然头信息可以用大小写不敏感的方式取出,但是接口实现类 **必须** 保持自己的大小写规范,特别是用 `getHeaders()` 方法输出的内容。
8180
8281因为一些非标准的 HTTP 应用程序,可能会依赖于大小写敏感的头信息,所有在此我们把主宰 HTTP 大小写的权利开放出来,以适用不同的场景。
83 
 82
8483
8584#### 对应多条数组的头信息
8685
 
9998```
10099
101100注意:并不是所有的头信息都可以适用逗号分割(例如 `Set-Cookie`),当处理这种头信息时候, `MessageInterace` 的继承类 **应该** 使用 `getHeader($name)` 方法来获取这种多值的情况。
102 
 101
103102#### 主机信息
104103
105104在请求中,`Host` 头信息通常和 URI 的 host 信息,还有建立起 TCP 连接使用的 Host 信息一致。然而,HTTP 标准规范允许主机 `host` 信息与其他两个不一样。
 
124123-  2 当前请求 `URI` 中的 `Host` 信息。
125124-  3 通过 `withUri()` 传参进入的 URI 中的 `host` 信息。
126125
127 
 126
128127
129128### 1.3 数据流
130129
 
134133`StreamInterface` 暴露出来几个接口,这些接口允许你读取、写入,还有高效的遍历内容。
135134
136135数据流使用这个三个接口来阐明对他们的操作能力:`isReadable()`、`isWritable()` 和 `isSeekable()`。这些方法可以让数据流的操作者得知数据流能否能提供他们想要的功能。
137 
 136
138137
139138每一个数据流的实例,都会有多种功能:可以只读、可以只写、可以读和写,可以随机读取,可以按顺序读取等。
140139
 
143142与请求和响应的接口不同的是,`StreamInterface` 并不强调不可修改性。因为在 PHP 的实现内,基本上没有办法保证不可修改性,因为指针的指向,内容的变更等状态,都是不可控的。作为读取者,可以
144143调用只读的方法来返回数据流,以最大程度上保证数据流的不可修改性。使用者要时刻明确的知道数据流的可修改性,建议把数据流附加到消息实例中,来强迫不可修改的特性。
145144
146 
 145
147146### 1.4 请求目标和 URI
148147
149148根据 RFC7230,请求消息包含「请求目标」做为请求行的第二个段落。请求目标可以是以下形式之一:
 
170169   ->withMethod('OPTIONS')
171170   ->withRequestTarget('*')
172171   ->withUri(new Uri('https://example.org/'));
173 ```
 172```
174173这个示例最终可能会导致 HTTP 请求类似下例:
175174
176175```source-httpspec
 
184183选择未实现上面四种请求目标形式的客户端,`必须` 依然使用 `getRequestTarget()`。这些客户端 `必须` 拒绝它们不支持的请求目标,并且 `不得` 依赖于 `getUri()` 的值。
185184
186185`RequestInterface` 提供了检索请求目标或用提供的请求目标创建一个新实例的方法。默认情况下,如果实例中没有专门组合请求目标, `getRequestTarget()` 将会返回组合 URI 的原始形式(如果没有组成 URI 则返回「/」)。`withRequestTarget($requestTarget)` 使用指定的请求目标创建一个新实例,从而允许开发人员创建表示其他三个请求目标形式(绝对形式、认证形式和星号形式)。使用时,组合的 URI 实例仍然可以使用,特别是在客户端中,它可以用于创建与服务器的连接。
187 
 186
188187### 1.5 服务端请求
189188
190189`RequestInterface` 提供了 HTTP 请求消息的通常表示形式。但是,由于服务器端环境的性质,服务器端请求需要额外的处理。服务器端处理需要考虑通用网关接口( CGI ),更具体地说,需要考虑 PHP 通过其服务器 API ( SAPI )对 CGI 的抽象和扩展。PHP 通过超级全局变量提供了关于输入编组的简化,例如:
 
197196
198197`ServerRequestInterface` 继承于 `RequestInterface`,提供围绕这些超全局变量的抽象访问。这种做法有助于减少开发人员对超全局的耦合,鼓励对代码的测试,并提升了测试人员对相应代码的测试能力。
199198
200 服务器请求提供了一个附加的属性,「attributes」,以便于开发人员可以根据应用程序的特定规则(例如路径匹配、scheme 匹配、主机匹配等)自检、分解和匹配请求。这样,服务器请求还可以在多段请求逻辑中进行消息传递。
 199服务器请求提供了一个附加的属性,「attributes」,以便于开发人员可以根据应用程序的特定规则(例如路径匹配、scheme 匹配、主机匹配等)自检、分解和匹配请求。这样,服务器请求还可以在多段请求逻辑中进行消息传递。
201200### 1.6 文件上传
202201
203202`ServerRequestInterface` 指定了一种在规范化结构中检索上传文件树的方法,每个叶子都是一个 `UploadedFileInterface` 的实例。
 
239238)
240239```
241240
242 这样造成的结果是开发人员必须知道这种语言实现细节,并为之编写特定的代码。
 241这样造成的结果是开发人员必须知道这种语言实现细节,并为之编写特定的代码。
243242另外,如果发生以下情况, `$_FILES` 会是空数组:
244243
245244- HTTP 方法不是 `POST`。
 
263262```html
264263<input type="file" name="avatar" />
265264```
266 
 265
267266在这种情况下,`$_FILES` 的结构如下:
268267
269268```php
 
384383   ),
385384)
386385```
387 
 386
388387开发人员可以用以下形式访问嵌套数组的索引 `1`:
389388
390389```php
 
429428$stream = new Psr7StreamWrapper($file1->getStream());
430429stream_copy_to_stream($stream, $s3wrapper);
431430```
432 
 431
433432
4344332\. 扩展包
435434-----------
 
611610}
612611```
613612
614 
 613
615614
616615### 3.2 `Psr\Http\Message\RequestInterface`
617616
 
728727}
729728```
730729
731 
 730
732731
733732#### 3.2.1 `Psr\Http\Message\ServerRequestInterface`
734733
 
946945}
947946```
948947
949 
 948
950949
951950### 3.3 `Psr\Http\Message\ResponseInterface`
952951
 
10091008}
10101009```
10111010
1012 
 1011
10131012
10141013### 3.4 `Psr\Http\Message\StreamInterface`
10151014
 
11631162}
11641163```
11651164
1166 
 1165
11671166
11681167### 3.5 `Psr\Http\Message\UriInterface`
11691168
 
14431442}
14441443```
14451444
1446 
 1445
14471446
14481447### 3.6 `Psr\Http\Message\UploadedFileInterface`
14491448