Dieser Artikel teilt Ihnen hauptsächlich die detaillierte Erklärung von HTTP-Anforderungsheadern und -Anforderungstexten mit. Das Studium von HTTP umfasst hauptsächlich die vier Teile HTTP-Grundlagen, HTTP-Anforderungsheader und -Anforderungstexte, HTTP-Antwortheader und -Statuscodes sowie HTTP-Cache Für HTTP-bezogene Erweiterungen müssen wir auch das Verständnis und die Praxis von HTTPS, HTTP/2-Grundlagen und WebSocket-Grundlagen verstehen. Die Wissenspunkte in diesem Teil sind auch in der Rezension des Autors über meinen Weg zur Einstellungsvorbereitung in der Schule zusammengefasst: vom Web-Frontend bis zur serverseitigen Anwendungsarchitektur.
HTTP-Anfrage
HTTP-Anfragenachricht ist in drei Teile unterteilt: Anfragezeile, Anfrageheader und Anfragetext. Das Format ist wie folgt: 
Ein typisches Feld für den Header einer Anforderungsnachricht lautet wie folgt:
POST/GET http://download.microtool.de:80/somedata.exe Host: download.microtool.de Accept:*/* Pragma: no-cache Cache-Control: no-cache Referer: http://download.microtool.de/ User-Agent:Mozilla/4.04[en](Win95;I;Nav) Range:bytes=554554-
Die Anforderungszeile (Anforderungszeile) ist in drei Teile unterteilt: Anforderungsmethode, Anforderungsadresse und Protokoll und Version, endend mit CRLF(rn).
HTTP/1.1 definiert 8 Anforderungsmethoden: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE. Die beiden häufigsten sind GET und POST, wenn es sich um eine RESTful-Schnittstelle handelt. SETZEN.
Beachten Sie, dass nur die drei Verben POST, PUT und PATCH den Anfragetext enthalten, während die Verben GET, HEAD, DELETE, CONNECT, TRACE und OPTIONS den Anfragetext enthalten . Enthält keinen Anfragetext.
| Header | Erklärung | Beispiel |
|---|---|---|
| Akzeptieren | Geben Sie die Inhaltstypen an, die der Client empfangen kann | Akzeptieren: text/plain, text/html,application/json |
| Accept-Charset | Der Zeichenkodierungssatz, den der Browser akzeptieren kann. | Accept-Charset: iso-8859-5 |
| Accept-Encoding | Geben Sie den Codierungstyp für die Inhaltskomprimierung an, der vom Webserver zurückgegeben wird, den der Browser verwendet unterstützen kann. | Accept-Encoding: compress, gzip |
| Accept-Language | Accept-Language: en,zh | |
| Sie können ein oder mehrere Unterbereichsfelder der Webseitenentität anfordern | Accept-Ranges: Bytes | |
| Autorisierungszertifikat für HTTP-Autorisierung | Autorisierung: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== | |
| Geben Sie den verwendeten Caching-Mechanismus an durch Anfragen und Antworten | Cache-Control: no-cache | |
| Gibt an, ob eine dauerhafte Verbindung erforderlich ist. (HTTP 1.1 verwendet standardmäßig dauerhafte Verbindungen) | Verbindung: schließen | |
| Wenn eine HTTP-Anfrage gesendet wird, werden die Informationen unter der angeforderten gespeichert Der Domainname lautet: Alle Cookie-Werte werden zusammen an den Webserver gesendet. | Cookie: $Version=1; Skin=new; | |
| Inhaltslänge | Gewünschte Inhaltslänge | Inhaltslänge : 348 |
| Content-Type | Die angeforderten MIME-Informationen, die der Entität entsprechen | Content-Type: application/x-www-form- urlencoded |
| Datum | Datum und Uhrzeit, zu der die Anfrage gesendet wurde | Datum: Di, 15. November 2010 08:12:31 GMT |
| Erwartet | Angefordertes spezifisches Serververhalten | Erwartet: 100-weiter |
| Von | E-Mail des Benutzers, der die Anfrage gestellt hat | Von: user@email.com |
| Host | Geben Sie den Domänennamen und die Portnummer des angeforderten Servers an | Host: www.zcmhi.com |
| If-Match | Nur gültig, wenn der Anfrageinhalt mit der Entität übereinstimmt | If -Match: „737060cd8c284d8af7ad3082f209582d“ |
| If-Modified-Since | Wenn das angeforderte Teil nach der angegebenen Zeit geändert wird, ist die Anforderung erfolgreich, wenn es nicht geändert wird , ein 304-Code wird zurückgegeben | If-Modified-Since: Sa, 29. Okt. 2010 19:43:31 GMT |
| If-None-Match | Wenn sich der Inhalt nicht geändert hat, geben Sie den 304-Code zurück. Der Parameter ist das Etag, das zuvor vom Server gesendet wurde, und wird mit dem Etag verglichen, auf das der Server geantwortet hat, um festzustellen, ob es sich geändert hat | If-None- Übereinstimmung: „737060cd8c284d8af7ad3082f209582d“ |
| If-Range | Wenn sich die Entität nicht geändert hat, sendet der Server den fehlenden Teil vom Client, andernfalls wird die gesamte Entität gesendet.Die Parameter sind auch Etag | If-Range: "737060cd8c284d8af7ad3082f209582d" |
| If-Unmodified-Since | nur wenn die Entität danach nicht geändert wurde Zum angegebenen Zeitpunkt ist die Anfrage erfolgreich | If-Unmodified-Since: Sa, 29. Okt. 2010 19:43:31 GMT |
| Max-Forwards | Beschränken Sie die von Proxys und Gateways gesendeten Informationen über die Zeit | Maximale Weiterleitungen: 10: kein Cache |
| Proxy-Autorisierung | Autorisierungszertifikat für die Verbindung zum Proxy | Proxy-Autorisierung: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Bereich | Fordern Sie nur einen Teil der Entität an, geben Sie den Bereich an | Bereich: Bytes=500-999 |
| Referer | Die Adresse der vorherigen Webseite, gefolgt von der aktuell angeforderten Webseite, also der Quelle | Referer: http://www.zcmhi.com/archives... |
| TE | Die Übertragungskodierung, zu der der Kunde bereit ist akzeptieren und benachrichtigt den Server, die Tail- und Header-Informationen zu akzeptieren | TE: Trailers,deflate;q=0.5 |
| Upgrade | Geben Sie eine bestimmte an Transportprotokoll zum Server zur Konvertierung (falls unterstützt) | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | Der Inhalt von User-Agent enthält die Benutzerinformationen, die die Anfrage gestellt haben | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | Zwischen-Gateway- oder Proxy-Server-Adresse, Kommunikationsprotokoll benachrichtigen | Über: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warnung | Warninformationen zur Nachrichtenentität | Warnung: 199 Sonstige Warnung |
Request Body:请求体Types根据应用场景的不同，HTTP请求的请求体有三种不同的形式。 任意类型移动开发者常见的，请求体是任意类型，服务器不会解析请求体，请求体的处理需要自己解析，如 POST JSON时候就是这类。 application/jsonapplication/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。 JSON 格式支持比键值对复杂得多的结构化数据，这一点也很有用。记得我几年前做一个项目时，需要提交的数据层次非常深，我就是把数据 JSON 序列化之后来提交的。不过当时我是把 JSON 字符串作为 val，仍然放在键值对里，以 x-www-form-urlencoded 方式提交。 Google 的 AngularJS 中的 Ajax 功能，默认就是提交 JSON 字符串。例如下面这段代码： JSvar data = {'title':'test', 'sub' : [1,2,3]};$http.post(url, data).success(function(result) {
...
});Nach dem Login kopieren 最终发送的请求是： BASHPOST http://www.example.com HTTP/1.1 Content-Type: application/json;charset=utf-8{"title":"test","sub":[1,2,3]}Nach dem Login kopieren 这种方案，可以方便的提交复杂的结构化数据，特别适合 RESTful 的接口。各大抓包工具如 Chrome 自带的开发者工具、Firebug、Fiddler，都会以树形结构展示 JSON 数据，非常友好。但也有些服务端语言还没有支持这种方式，例如 php 就无法通过 $_POST 对象从上面的请求中获得内容。这时候，需要自己动手处理下：在请求头中 Content-Type 为 application/json 时，从 当然 AngularJS 也可以配置为使用 x-www-form-urlencoded 方式提交数据。如有需要，可以参考这篇文章。 text/xml我的博客之前提到过 XML-RPC（XML Remote Procedure Call）。它是一种使用 HTTP 作为传输协议，XML 作为编码方式的远程调用规范。典型的 XML-RPC 请求是这样的： HTMLPOST http://www.example.com HTTP/1.1
Content-Type: text/xml<?xml version="1.0"?><methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>41</i4></value>
</param>
</params></methodCall>Nach dem Login kopieren XML-RPC 协议简单、功能够用，各种语言的实现都有。它的使用也很广泛，如 WordPress 的 XML-RPC Api，搜索引擎的 ping 服务等等。JavaScript 中，也有现成的库支持以这种方式进行数据交互，能很好的支持已有的 XML-RPC 服务。不过，我个人觉得 XML 结构还是过于臃肿，一般场景用 JSON 会更灵活方便。 Abfragezeichenfolge:application/x-www-form-urlencodedDies ist die gebräuchlichste Methode zur Übermittlung von Daten per POST. Das native |
