Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zh-cn: Format /web/http using Prettier #14670

Merged
merged 1 commit into from
Jul 28, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion .prettierignore
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,5 @@ build/
/files/zh-cn/web/api/**/*.md
/files/zh-cn/web/css/**/*.md
/files/zh-cn/web/html/**/*.md
/files/zh-cn/web/http/**/*.md
/files/zh-cn/web/javascript/reference/**/*.md
/files/zh-cn/web/svg/**/*.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,9 +31,9 @@ GET /mypage.html
响应也极其简单的:只包含响应文档本身。

```html
<HTML>
这是一个非常简单的 HTML 页面
</HTML>
<html>
这是一个非常简单的 HTML 页面
</html>
```

跟后来的版本不同,HTTP/0.9 的响应内容并不包含 HTTP 头。这意味着只有 HTML 文件可以传送,无法传输其他类型的文件。也没有状态码或错误代码。一旦出现问题,一个特殊的包含问题描述信息的 HTML 文件将被发回,供人们查看。
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -50,18 +50,18 @@ urn:ietf:rfc:7230
- ![Protocol]([email protected])
- : `http://`告诉浏览器使用何种协议。对于大部分 Web 资源,通常使用 HTTP 协议或其安全版本,HTTPS 协议。另外,浏览器也知道如何处理其他协议。例如, `mailto:` 协议指示浏览器打开邮件客户端;`ftp:`协议指示浏览器处理文件传输。常见的方案有:

| 方案 | 描述 |
| ----------- | --------------------------------------------------------------------- |
| data | [Data URIs](/zh-CN/docs/Web/HTTP/data_URIs) |
| file | 指定主机上文件的名称 |
| ftp | [文件传输协议](/zh-CN/docs/Glossary/FTP) |
| 方案 | 描述 |
| ----------- | ------------------------------------------------------------------ |
| data | [Data URIs](/zh-CN/docs/Web/HTTP/data_URIs) |
| file | 指定主机上文件的名称 |
| ftp | [文件传输协议](/zh-CN/docs/Glossary/FTP) |
| http/https | [超文本传输 协议/安全的超文本传输协议](/zh-CN/docs/Glossary/HTTP) |
| mailto | 电子邮件地址 |
| ssh | 安全 shell |
| tel | 电话 |
| urn | 统一资源名称 |
| view-source | 资源的源代码 |
| ws/wss | (加密的)[WebSocket](/zh-CN/docs/WebSockets) 连接 |
| mailto | 电子邮件地址 |
| ssh | 安全 shell |
| tel | 电话 |
| urn | 统一资源名称 |
| view-source | 资源的源代码 |
| ws/wss | (加密的)[WebSocket](/zh-CN/docs/WebSockets) 连接 |

### 主机

Expand Down
6 changes: 3 additions & 3 deletions files/zh-cn/web/http/basics_of_http/mime_types/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -141,9 +141,9 @@ HTML 并没有明确定义被用于{{HTMLElement("audio")}}和{{HTMLElement("vid
| `audio/wave` `audio/wav` `audio/x-wav` `audio/x-pn-wav` | 音频流媒体文件。一般支持 PCM 音频编码 (WAVE codec "1") ,其他解码器有限支持(如果有的话)。 |
| `audio/webm` | WebM 音频文件格式。Vorbis 和 Opus 是其最常用的解码器。 |
| `video/webm` | 采用 WebM 视频文件格式的音视频文件。VP8 和 VP9 是其最常用的视频解码器。Vorbis 和 Opus 是其最常用的音频解码器。 |
| `audio/ogg` | 采用 OGG 多媒体文件格式的音频文件。Vorbis 是这个多媒体文件格式最常用的音频解码器。 |
| `video/ogg` | 采用 OGG 多媒体文件格式的音视频文件。常用的视频解码器是 Theora;音频解码器为 Vorbis。 |
| `application/ogg` | 采用 OGG 多媒体文件格式的音视频文件。常用的视频解码器是 Theora;音频解码器为 Vorbis。 |
| `audio/ogg` | 采用 OGG 多媒体文件格式的音频文件。Vorbis 是这个多媒体文件格式最常用的音频解码器。 |
| `video/ogg` | 采用 OGG 多媒体文件格式的音视频文件。常用的视频解码器是 Theora;音频解码器为 Vorbis。 |
| `application/ogg` | 采用 OGG 多媒体文件格式的音视频文件。常用的视频解码器是 Theora;音频解码器为 Vorbis。 |
| `application/json` | application/json (MIME_type) <https://en.wikipedia.org/wiki/Media_type#Common_examples> <https://www.iana.org/assignments/media-types/application/json> |

### multipart/form-data
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@ slug: Web/HTTP/Browser_detection_using_the_user_agent

| 浏览器 | 规则 | 示例 |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Mozilla (Gecko, Firefox) | 注释中的 [**Mobile 或 Tablet 标记**](/zh-CN/docs/Gecko_user_agent_string_reference) | Mozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0 |
| Mozilla (Gecko, Firefox) | 注释中的 [**Mobile 或 Tablet 标记**](/zh-CN/docs/Gecko_user_agent_string_reference) | Mozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0 |
| WebKit-based (Android, Safari) | 注释外的[**Mobile Safari 标记**](https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/OptimizingforSafarioniPhone/OptimizingforSafarioniPhone.html#//apple_ref/doc/uid/TP40006517-SW3) | Mozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30 |
| Blink-based (Chromium, Google Chrome, Opera 15+) | 注释外的[**Mobile Safari 标记**](https://developers.google.com/chrome/mobile/docs/user-agent) | Mozilla/5.0 (Linux; Android 4.4.2); Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Mobile Safari/537.36 OPR/20.0.1396.72047 |
| Presto-based (Opera 12-) | 注释中的[**Opera Mobi/xyz 标记**](http://my.opera.com/community/openweb/idopera/)(Opera 12-) | Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1111101157; U; es-ES) Presto/2.9.201 Version/11.50 |
Expand Down
2 changes: 1 addition & 1 deletion files/zh-cn/web/http/caching/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -462,7 +462,7 @@ Cache-Control: max-age=31536000

共享缓存主要位于源服务器之前,旨在减少到源服务器的流量。

因此,如果多个相同的请求同时到达共享缓存,中间缓存将代表自己将单个请求转发到源,然后源可以将结果重用于所有客户端。这称为***请求折叠***。
因此,如果多个相同的请求同时到达共享缓存,中间缓存将代表自己将单个请求转发到源,然后源可以将结果重用于所有客户端。这称为**_请求折叠_**。

当请求同时到达时会发生请求折叠,因此即使响应中给出了 `max-age=0` 或 `no-cache`,它也会被重用。

Expand Down
4 changes: 2 additions & 2 deletions files/zh-cn/web/http/compression/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ slug: Web/HTTP/Compression

每一种文件类型都会存有冗余,也就是*浪费的空间*。如果一个典型的文本文件存在 60% 的冗余的话,那么对于其他类型的文件,例如音频或视频文件来说,这个比率会更高。不同于文本文件,这些其他类型的媒体文件占据的空间也更大,所以很早就出现了回收这些浪费的空间的需求。工程师们设计了可以应用于特定用途的文件类型的经过优化的算法。用于文件的压缩算法可以大致分为两类:

- *无损压缩*。在压缩与解压缩的循环期间,不会对要恢复的数据进行修改。复原后的数据与原始数据是一致的(比特与比特之间一一对应)。对于图片文件来说,`gif` 或者 `png` 格式的文件就是采用了无损压缩算法。
- *有损压缩*。在压缩与解压缩的循环期间,会对原始数据进行修改,但是会(希望)以用户无法觉察的方式进行。网络上的视频文件通常采用有损压缩算法,`jpeg` 格式的图片也是有损压缩。
- _无损压缩_。在压缩与解压缩的循环期间,不会对要恢复的数据进行修改。复原后的数据与原始数据是一致的(比特与比特之间一一对应)。对于图片文件来说,`gif` 或者 `png` 格式的文件就是采用了无损压缩算法。
- _有损压缩_。在压缩与解压缩的循环期间,会对原始数据进行修改,但是会(希望)以用户无法觉察的方式进行。网络上的视频文件通常采用有损压缩算法,`jpeg` 格式的图片也是有损压缩。

一些特定的文件格式既可以采用无损压缩算法,又可以采用有损压缩算法,例如 `webp`,并且有损压缩算法可以对压缩比率进行配置,当然这会导致压缩品质的不同。为了使一个站点获得更好的性能,理想情况是在保持可以接受的品质水准的前提下,压缩比率尽可能得高。对于图片来说,通过压缩工具生成的图片对于 Web 应用来说,优化程度可能依然不够高。一般建议选用在保持所要求的品质的前提下压缩比率尽可能高的工具。这里有[各种各样的工具](https://www.creativebloq.com/design/image-compression-tools-1132865)专门用来干这个。

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ slug: Web/HTTP/Connection_management_in_HTTP_1.x

{{HTTPSidebar}}

连接管理是一个 HTTP 的关键话题:打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1.x 里有多种模型:*短连接*、*长连接*和 *HTTP 流水线*
连接管理是一个 HTTP 的关键话题:打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1.x 里有多种模型:_短连接_、*长连接*和 _HTTP 流水线_

HTTP 的传输协议主要依赖于 TCP 来提供从客户端到服务器端之间的连接。在早期,HTTP 使用一个简单的模型来处理这样的连接。这些连接的生命周期是短暂的:每发起一个请求时都会创建一个新的连接,并在收到应答时立即关闭。

Expand Down Expand Up @@ -51,7 +51,7 @@ HTTP/1.0 里默认并不使用长连接。把 {{HTTPHeader("Connection")}} 设
> - 正确的实现流水线是复杂的:传输中的资源大小、多少有效的 [RTT](https://zh.wikipedia.org/wiki/來回通訊延遲) 会被用到以及有效带宽都会直接影响到流水线提供的改善。不知道这些的话,重要的消息可能被延迟到不重要的消息后面。这个重要性的概念甚至会演变为影响到页面布局!因此 HTTP 流水线在大多数情况下带来的改善并不明显。
> - 流水线受制于[队头阻塞(HOL)](https://zh.wikipedia.org/wiki/队头阻塞)问题。
>
> 由于这些原因,流水线已被 HTTP/2 中更好的算法——*多路复用*(multiplexing)所取代。
> 由于这些原因,流水线已被 HTTP/2 中更好的算法——_多路复用_(multiplexing)所取代。

默认情况下,[HTTP](/zh-CN/docs/Web/HTTP) 请求是按顺序发出的。下一个请求只有在当前请求收到响应过后才会被发出。由于会受到网络延迟和带宽的限制,在下一个请求被发送到服务器之前,可能需要等待很长时间。

Expand Down
4 changes: 2 additions & 2 deletions files/zh-cn/web/http/content_negotiation/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ slug: Web/HTTP/Content_negotiation

{{HTTPSidebar}}

在 [HTTP](/zh-CN/docs/Glossary/HTTP) 协议中,***内容协商***是一种机制,用于为同一 URI 提供资源不同的{{Glossary("Representation header","表示")}}形式,以帮助用户代理指定最适合用户的表示形式(例如,哪种文档语言、哪种图片格式或者哪种内容编码)。
在 [HTTP](/zh-CN/docs/Glossary/HTTP) 协议中,**_内容协商_**是一种机制,用于为同一 URI 提供资源不同的{{Glossary("Representation header","表示")}}形式,以帮助用户代理指定最适合用户的表示形式(例如,哪种文档语言、哪种图片格式或者哪种内容编码)。

> **备注:** 你可以在[来自 WHATWG 的维基页面](https://wiki.whatwg.org/wiki/Why_not_conneg)发现 HTTP 内容协商的一些缺点。HTML5 提供其他的选择来进行内容协商,例如 [`<source>` 元素](/zh-CN/docs/Web/HTML/Element/source)。

Expand Down Expand Up @@ -97,7 +97,7 @@ HTTP/1.1 规范指定了一系列的标准标头用于启动服务端驱动型

服务端驱动型内容协商也有一些缺点:它不能很好的扩展。在协商机制中,每一个特性需要对应一个标头。如果想要使用屏幕大小、分辨率或者其他方面的特性,就需要创建一个新的 HTTP 标头。而且在每一次请求中都必须发送这些标头。在标头很少的时候,这并不是问题,但是随着数量的增多,消息的体积会导致性能的下降。带有精确信息的标头发送的越多,信息熵就会越大,也就准许了更多 HTTP 指纹识别行为,以及与此相关的隐私问题的发生。

从 HTTP 协议制定之初,该协议就准许另外一种协商机制:*代理驱动型内容协商*,或称为*响应式协商*。在这种协商机制中,当面临不明确的请求时,服务器会返回一个页面,其中包含了可供选择的资源的链接。资源呈现给用户,由用户做出选择。
从 HTTP 协议制定之初,该协议就准许另外一种协商机制:_代理驱动型内容协商_,或称为*响应式协商*。在这种协商机制中,当面临不明确的请求时,服务器会返回一个页面,其中包含了可供选择的资源的链接。资源呈现给用户,由用户做出选择。

![客户端请求一个 URL,其中标头表示对内容类型的偏好。服务器有多个由 URL 表示的资源并发回多个响应,因此客户端可以选择应用了首选压缩算法的主体。](httpnego3.png)

Expand Down
Loading