http (Hypertext Transfer Protocol) ist ein zustandsloses Protokoll auf Anwendungsebene, das auf dem Anforderungs- und Antwortmodus basiert und häufig auf der TCP-Verbindungsmethode basiert. In diesem Artikel geht es um das Wissen über das http-Protokoll, das Front-End-Entwickler kennen müssen. Freunde, die Front-End erstellen möchten oder derzeit am Front-End arbeiten, müssen es wissen.
1. Konzept
http (Hypertext Transfer Protocol) ist ein Anfrage-und-Antwort-Modell Basierend auf zustandslosen Protokollen der Anwendungsschicht, häufig basierend auf der TCP-Verbindungsmethode. Die HTTP 1.1-Version bietet einen kontinuierlichen Verbindungsmechanismus. Die überwiegende Mehrheit der Webentwicklung basiert auf HTTP-Webanwendungen, die auf dem Protokoll basieren.
2. Entwicklung
Version 0.9 (unterstützt nur Get) - 1.0 - 1.1 - 2.0 (in Entwicklung)
Version 0.9 kann nur als Testversion betrachtet werden und wird nicht eingeführt. Sprechen Sie hauptsächlich über den Unterschied zwischen 1,0 und 1,1.
2.1 Permanente Verbindung und nicht-persistente Verbindung
Version 1.0 unterstützt nicht-persistente Verbindungen, was bedeutet, dass das TCP-Protokoll übergeben wird (http ist ein auf der Anwendungsschicht basierendes Protokoll). auf TCP) Drei-Wege-Handshake Nachdem die Verbindung hergestellt wurde, kann der Server nur ein Objekt an den Browser senden, und dann wird die Verbindung getrennt. Wenn die Webseite andere Inline-Objekte wie Bilder, JS-Dateien, CSS-Dateien usw. enthält. usw. müssen mehrere Verbindungen hergestellt werden, einschließlich des Mehraufwands für den mehrmaligen Aufbau/Trennen. Version 1.1 unterstützt kontinuierliche Verbindungen, sodass Version 1.1 theoretisch ressourcenschonender und schneller ist als 1.0, was jedoch nicht akzeptabel ist Es.
2.2 Host-Domäne
Das Host-Header-Feld gibt den Internet-Host und die Portnummer der angeforderten Ressource an und muss den Standort des ursprünglichen Servers oder Gateways der angeforderten URL angeben. HTTP/1.1-Anfragen müssen das Host-Header-Feld enthalten, andernfalls gibt das System den Statuscode 400 zurück. Dieses Feld scheint entbehrlich zu sein, vielleicht um die Geschwindigkeit zu erhöhen. Schließlich kann die direkte Angabe von HOST den entsprechenden Host schneller finden. Wenn der Host nicht vorhanden ist, kann er auch schneller erkannt werden.
2.3 Bandbreitenoptimierung
Version 1.1 unterstützt die teilweise Ressourcenanforderung, und Sie können nur einen Teil der Ressource anfordern. Gleichzeitig unterstützt Version 1.1 den 100-Statuscode. Wenn die Anforderungsentität groß ist, können Sie zunächst das Header-Feld mit dem 100-Statuscode senden, um zu bestätigen, ob der Server auf die Anforderung antworten kann wird erneut gesendet, sodass zu einem bestimmten Zeitpunkt in einigen nicht reagierenden Situationen Bandbreite gespart werden kann.
Spezifischer Prozess: Client – sendet einen Anforderungsheader mit einem 100-Statuscode – der Server bestätigt, ob er antworten kann. Wenn nicht, gibt er den entsprechenden Statuscode zurück (z. B. 401, nicht authentifiziert). dann Statuscode „Return 100“ – der Client bestätigt anhand des Rückgabestatuscodes, ob er mit dem Senden der Anfrage fortfahren soll.
2.4 Anforderungsmethoden und Statuscodes
HTTP1.1 hat die Anforderungsmethoden OPTIONS, PUT, DELETE, TRACE, CONNECT hinzugefügt
Nur 16 sind in der HTTP/1.0-Statusantwort definiert Codes sind für Fehler oder Warnungen nicht spezifisch genug. HTTP/1.1 führte ein Warnungs-Header-Feld ein, um eine Beschreibung von Fehler- oder Warninformationen hinzuzufügen.
24 neue Statusantwortcodes wurden in HTTP/1.1 hinzugefügt. Beispielsweise zeigt 409 (Konflikt) an, dass die angeforderte Ressource mit dem aktuellen Status der Ressource in Konflikt steht; Server wird dauerhaft gelöscht.
3.HTTP-Kommunikationsprozess
(1) Fragen Sie DNS gemäß der URL ab, suchen Sie den Webserver und stellen Sie eine TCP-Verbindung her it (http-Unterschichtvereinbarung).
(2) Anschließend sendet der Webbrowser eine Anfrage an den Server.
Anforderungen umfassen im Allgemeinen: |. Anforderungstext-Beispiel:
GET /hello.jpg HTTP/1.1
Akzeptieren:image/gif.image/jpeg
Accept-Language:zh-cn
Verbindung:Keep-Alive
Host:127.0.0.1
User-Agent:Mozila/4.0(kompatibel;MSIE5.01;Windows NT5.0)
Accept-Encoding:gzip,deflate
(3) Antwort des Webservers. Das Antwortpaket enthält im Allgemeinen: |Beschreibung des Statuscodes der Protokollversion|Antwortheader|Antworttext
HTTP/1.1 200 OK
Server: Apache Tomcat/5.0 . 12
Datum:Mo,6. Okt. 2017 13:23:42 GMT
Inhaltslänge:188
4. http-Header-Feld
Dieser Teil des Inhalts ist zu detailliert und wird direkt in der Tabelle aufgeführt.
Anforderungsheader:
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 请求的特定的服务器行为 | Expect: 100-continue |
| From | 发出请求的用户的Email | From: user@email.com |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
| Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
| TE | 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服务器指定某种传输协议以便服务器进行转换（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中间网关或代理服务器地址，通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
Antwortheader:
| Header | Erläuterung | Example | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Accept-Ranges | Gibt an, ob der Server die angegebene Bereichsanforderung unterstützt und welchen Typ Fragmentierte Anfrage | Accept-Ranges: Bytes | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alter | Geschätzte Zeit in Sekunden vom Ursprungsserver bis zur Proxy-Cache-Bildung. Anzahl, nicht -negativ) | Alter: 12 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Zulassen | Ein gültiges Anforderungsverhalten für eine bestimmte Netzwerkressource, wenn dies nicht zulässig ist Rückgabe 405 | Erlauben: GET, HEAD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Cache-Control | Teilen Sie allen Caching-Mechanismen mit, ob sie zwischengespeichert werden können und welchen Typ sie haben | Cache-Control: no-cache | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Encoding | Der zurückgegebene Codierungstyp für die Inhaltskomprimierung, der vom Webserver unterstützt wird. | Content-Encoding: gzip | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Language | Die Sprache des Antworttextes | Content -Sprache: en,zh | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Length | Die Länge des Antworttextes | Content-Length: 348 td> tr> | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Location | Anfordern einer alternativen alternativen Adresse für die Ressource | Content-Location: /index.htm | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-MD5 | Gibt den MD5-Prüfwert der Ressource zurück | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== | Die Byte-Position dieses Teils im gesamten Rückgabetext | Content-Range: Bytes 21010-47021/47022 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Type | Gibt den MIME-Typ des Inhalts zurück | Content-Type: text/html charset=utf-8 | tr>|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Datum | Die Uhrzeit, zu der die ursprüngliche Servernachricht gesendet wurde | Datum: Di, 15. November 2010 08:12:31 GMT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ETag | Der aktuelle Wert des Entity-Tags der Anfragevariablen | ETag: „737060cd8c284d8af7ad3082f209582d“ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Läuft ab | Ablaufdatum und -uhrzeit der Antwort | Läuft ab: Do, 01. Dez. 2010 16:00:00 GMT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Letzte Änderung | Die letzte Änderungszeit der angeforderten Ressource | Letzte Änderung: Di, 15. November 2010 12:45:26 GMT | Standort | Wird verwendet, um den Empfänger zum Standort der nicht angeforderten URL umzuleiten, um die Anfrage abzuschließen oder eine neue Ressource zu identifizieren | Standort: http://www .zcmhi.com/archives/94.html | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Pragma | Enthält umsetzungsspezifische Anweisungen, die auf jeden Empfänger in der Antwortkette angewendet werden können td> | Pragma: no-cache | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Proxy-Authenticate | Es gibt das Authentifizierungsschema und die Parameter auf dieser URL an, die auf die angewendet werden können Proxy | Proxy-Authenticate: Basic | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| refresh | Auf Umleitung anwenden oder eine neue Ressource erstellt wird, Umleitung nach 5 Sekunden ( vorgeschlagen von Netscape, unterstützt von den meisten Browsern) |
Refresh: 5; url=http: //www.zcmhi.com/archives /94.html |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Retry-After | Wenn die Entität vorübergehend nicht verfügbar ist, benachrichtigen Sie den Client um es nach der angegebenen Zeit erneut zu versuchen | Retry-After: 120 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Server | Name der Webserver-Software | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Set-Cookie | Http-Cookie setzen | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Trailer | Gibt an, dass das Header-Feld vorhanden ist Ende der Chunked-Transfer-Kodierung | Trailer: Max-Forwards | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Transfer-Encoding | File Transfer Encoding | Transfer-Encoding:chunked||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Vary | Teilt dem Downstream-Proxy mit, ob eine zwischengespeicherte Antwort oder Anfrage vom Ursprungsserver verwendet werden soll | Vary: *||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Via | Informiert den Proxy, wohin die Client-Antwort gesendet wird | Via: 1.0 fred, 1.1 nirgendwo .com (Apache/1.1) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Warnung | Warnung vor möglichen Problemen mit Entitäten | Warnung: 199 Sonstige Warnung | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| WWW-Authenticate | Gibt das Autorisierungsschema an, das die vom Client anfordernde Entität verwenden soll | WWW-Authenticate: Basic | tr>
5. HTTP-Anfragemethode
GET-Anfrage zum Abrufen der durch Request-URI identifizierten Ressource
POST in der durch Request identifizierten Ressource -URI Neue Daten nach der Ressource anhängen
HEAD Anforderung zum Abrufen des Antwortnachrichtenheaders der durch Request-URI identifizierten Ressource
PUT Anforderung an den Server, eine Ressource zu speichern und Request-URI als Identifikator zu verwenden
DELETE Fordern Sie den Server zum Löschen auf. Request – Die durch den URI identifizierte Ressource.
TRACE Fordert den Server auf, die empfangenen Anforderungsinformationen zurückzusenden, die hauptsächlich für Tests oder Diagnosen verwendet werden.
CONNECT Für zukünftige Verwendung reserviert.
OPTIONS. Anfrage zur Abfrage der Leistung des Servers oder Abfrageoptionen und Anforderungen im Zusammenhang mit der Ressource
6 Statuscode
Antwort Die erste Zeile in Die Nachricht wird als Statuszeile bezeichnet und besteht aus der Versionsnummer des HTTP-Protokolls und dem Statuscode. Die Statusnachricht besteht aus drei Teilen.
Der Statuscode wird verwendet, um dem HTTP-Client mitzuteilen, ob der HTTP-Server die erwartete Antwort generiert hat.
HTTP/1.1 definiert 5 Arten von Statuscodes. Der Statuscode besteht aus drei Ziffern. Eine Zahl definiert die Kategorie der Antwort
1XX-Eingabeaufforderungsnachricht – zeigt an, dass die Anfrage erfolgreich empfangen wurde und weiterhin verarbeitet wird, was darauf hinweist, dass weiterhin Daten empfangen werden müssen, um die Anfrage abzuschließen.
2XX Erfolgreich – Zeigt an, dass die Anfrage erfolgreich empfangen, verstanden und akzeptiert wurde
3XX Weiterleitung – Zur Vervollständigung der Anfrage muss eine weitere Verarbeitung durchgeführt werden
4XX Clientfehler – Anfrage Es liegt ein Syntaxfehler vor oder die Anfrage kann nicht implementiert werden
5XX Serverseitiger Fehler – Der Server konnte eine rechtliche Anfrage nicht implementieren
Statuscodeliste
Tabelle 1 ( Kurze Einführungstabelle, Einführung Es wird empfohlen, zuerst diese Tabelle zu lesen. Wenn Sie sie nicht verstehen, lesen Sie die Tabelle unten 2)
| Statuscode | Statuscode Englischer Name | Chinesische Beschreibung |
|---|---|---|
| Statuscodes beginnend mit 1 | ||
| 100 | Weiter | weiter. Der Client sollte seine Anfrage |
| 101 | Switching Protocols | Switching Protocols fortsetzen. Der Server wechselt die Protokolle basierend auf der Anfrage des Clients. Sie können nur zu einem fortgeschritteneren Protokoll wechseln, zum Beispiel zu einer neuen Version des HTTP-Protokolls |
| Statuscode beginnend mit 2 | ||
| 200 | OK | Die Anfrage war erfolgreich. Wird im Allgemeinen für GET- und POST-Anfragen verwendet. |
| 201 | Erstellt | wurde erstellt. Erfolgreich angefordert und eine neue Ressource erstellt |
| 202 | Akzeptiert | Akzeptiert. Die Anfrage wurde angenommen, aber nicht bearbeitet |
| 203 | Nicht verbindliche Informationen | Nicht autorisierte Informationen. Die Anfrage war erfolgreich. Die zurückgegebenen Metainformationen befinden sich jedoch nicht auf dem Originalserver, sondern in einer Kopie |
| 204 | Kein Inhalt | Kein Inhalt. Der Server hat die Verarbeitung erfolgreich durchgeführt, es wurde jedoch kein Inhalt zurückgegeben. Stellt sicher, dass der Browser weiterhin das aktuelle Dokument anzeigt, ohne die Webseite zu aktualisieren |
| 205 | Inhalt zurücksetzen | Inhalt zurücksetzen. Die Serververarbeitung ist erfolgreich und das Benutzerterminal (z. B. Browser) sollte die Dokumentansicht zurücksetzen. Mit diesem Rückgabecode kann das Formularfeld des Browsers |
| 206 | Teilinhalt | gelöscht werden. Der Server hat einige GET-Anfragen erfolgreich verarbeitet |
| Statuscode beginnend mit 3 | ||
| 300 | Multiple Choices | Mehrere Auswahlmöglichkeiten. Die angeforderte Ressource kann mehrere Standorte umfassen, und dementsprechend kann eine Liste von Ressourcenmerkmalen und -adressen zurückgegeben werden, damit das Benutzerterminal (z. B. Browser) |
| 301 | Dauerhaft verschobenDauerhaft verschoben. Die angeforderte Ressource wurde dauerhaft auf den neuen URI verschoben, die Rückgabeinformationen enthalten den neuen URI und der Browser wird automatisch auf den neuen URI umgeleitet. Alle neuen Anfragen in der Zukunft sollten den neuen URI anstelle von | |
| Gefunden | Vorübergehend verschoben verwenden. Ähnlich wie 301. Die Ressource wird jedoch nur vorübergehend verschoben. Der Client sollte weiterhin den ursprünglichen URI | |
| Andere anzeigen | verwenden, um andere Adressen anzuzeigen. Ähnlich wie 301. Verwenden Sie GET- und POST-Anfragen, um | |
| Nicht geändert | Unverändert anzuzeigen. Die angeforderte Ressource wurde nicht geändert. Wenn der Server diesen Statuscode zurückgibt, wird keine Ressource zurückgegeben. Clients speichern normalerweise Ressourcen, auf die zugegriffen wird, im Cache, indem sie einen Header bereitstellen, der angibt, dass der Client nur Ressourcen zurückgeben möchte, die nach einem bestimmten Datum geändert wurden | |
| Proxy verwenden | Verwenden Sie einen Proxy. Auf die angeforderte Ressource muss über einen Proxy zugegriffen werden | |
| Nicht verwendet | Ein veralteter HTTP-Statuscode | |
| Temporäre Weiterleitung | Temporäre Weiterleitung. Ähnlich wie 302. Verwenden Sie die GET-Anfrageumleitung | |
| Bad Request | Customer The Syntaxfehler in der Endanfrage, der Server kann | |
| Nicht autorisiert | Die Anfrage erfordert eine Benutzerauthentifizierung | |
| Zahlung erforderlich | Reserviert für zukünftige Verwendung | |
| Verboten | Server verstanden Die Anfrage des Clients wird angefordert, die Ausführung der Anfrage wird jedoch verweigert | |
| Nicht gefunden | Der Server kann die Ressource (Webseite) nicht finden ) basierend auf der Anfrage des Kunden. Mit diesem Code können Website-Designer eine personalisierte Seite für „Die von Ihnen angeforderte Ressource kann nicht gefunden werden“ | |
| Methode nicht zulässig | einrichten Kunde Die Methode in der Client-Anfrage ist verboten | |
| Nicht akzeptabel | Der Server kann die Anfrage aufgrund der Inhaltsmerkmale des Clients nicht abschließen Anfrage | |
| Proxy-Authentifizierung erforderlich | Die Anfrage erfordert eine Proxy-Authentifizierung, ähnlich wie 401, aber der Anforderer sollte den Proxy zur Autorisierung verwenden | |
| Anfrage-Timeout | Der Server hat zu lange auf die vom Client gesendete Anfrage gewartet und es kam zu einer Zeitüberschreitung | |
| Konflikt | Der Server gibt diesen Code möglicherweise zurück, wenn die PUT-Anfrage des Clients abgeschlossen wird. Es ist ein Konflikt aufgetreten, als der Server die Anfrage verarbeitet hat | |
| Gegangen | Die vom Client angeforderte Ressource existiert nicht mehr. 410 unterscheidet sich von 404. Wenn die Ressource dauerhaft gelöscht wurde, kann der 410-Code verwendet werden. Der Website-Designer kann den neuen Speicherort der Ressource über den 301-Code | |
| Der Server kann die Anforderungsinformationen nicht ohne vom Client gesendete Inhaltslänge verarbeiten | 412 | |
| Client-Anforderungsinformationsvoraussetzungsfehler | 413 | |
| Angefordert, weil die Entität zu groß ist und der Server dies nicht kann Behandeln Sie es, also wird es abgelehnt. Um weitere Anfragen vom Client zu verhindern, kann der Server die Verbindung schließen.Wenn der Server es vorübergehend nicht verarbeiten kann, enthält er eine Retry-After-Antwortnachricht | ||
| 414 | Request-URI Too Large | Requested URI Too lang (URI ist normalerweise eine URL), kann der Server |
| 415 | Nicht unterstützter Medientyp | Der Server kann das angehängte Medienformat nicht verarbeiten die Anfrage |
| 416 | Angeforderter Bereich nicht erfüllbar | Der vom Kunden angeforderte Bereich ist ungültig |
| 417 | Expectation fehlgeschlagen | Der Server kann die Expect-Anforderungsheaderinformationen nicht erfüllen |
| Statuscode beginnt mit 5 | ||
| 500 | Interner Serverfehler | Serverinterner Fehler, die Anfrage konnte nicht abgeschlossen werden |
| 501 | Nicht implementiert | Der Server unterstützt es nicht. Die angeforderte Funktion konnte die Anfrage nicht abschließen. |
| 502 | Bad Gateway | Ein Server handelt als Gateway oder Proxy einen ungültigen Wert vom Remote-Server erhalten hat |
| 503 | Dienst nicht verfügbar | Aufgrund von Überlastung oder Systemwartung Der Server ist vorübergehend nicht in der Lage, die Anfrage des Clients zu verarbeiten. Die Länge der Verzögerung kann in den Retry-After-Header-Informationen des Servers enthalten sein |
| 504 | Gateway-Timeout | Server, der als Gateway fungiert oder Proxy, die Anfrage wurde nicht rechtzeitig vom Remote-Server erhalten |
| 505 | HTTP-Version nicht unterstützt | Der Server unterstützt die angeforderte Version nicht HTTP-Protokollversion und kann nicht abgeschlossen werden |
Tabelle 2 Detaillierte Einführungstabelle
| Statuscode | Bedeutung |
|---|---|
| 100 | Der Kunde sollte fortfahren Senden Sie eine Anfrage. Diese vorläufige Antwort wird verwendet, um den Client darüber zu informieren, dass ein Teil seiner Anfrage vom Server empfangen und noch nicht abgelehnt wurde. Der Client SOLLTE den Rest der Anfrage weiter senden oder diese Antwort ignorieren, wenn die Anfrage bereits abgeschlossen wurde. Der Server muss nach Abschluss der Anfrage eine endgültige Antwort an den Client senden. |
| 101 | Der Server hat die Anfrage des Clients verstanden und benachrichtigt den Client über den Upgrade-Nachrichtenheader, ein anderes Protokoll zum Abschließen der Anfrage zu verwenden. Nach dem Senden der letzten Leerzeile dieser Antwort wechselt der Server zu den im Upgrade-Header definierten Protokollen. Ähnliche Maßnahmen sollten nur dann ergriffen werden, wenn die Umstellung auf ein neues Protokoll vorteilhafter wäre. Beispielsweise bietet der Wechsel zu einer neuen HTTP-Version Vorteile gegenüber einer älteren Version oder der Wechsel zu einem Echtzeit- und synchronen Protokoll für die Bereitstellung von Ressourcen, die solche Funktionen nutzen. |
| 102 | Ein durch WebDAV (RFC 2518) erweiterter Statuscode, der angibt, dass die Verarbeitung fortgesetzt wird. |
| 200 | Die Anfrage war erfolgreich und der von der Anfrage erwartete Antwortheader oder Datenkörper wird mit dieser Antwort zurückgegeben. |
| 201 | Die Anfrage wurde implementiert und eine neue Ressource wurde basierend auf den Anforderungen der Anfrage erstellt und ihr URI wurde mit den Location-Header-Informationen zurückgegeben. Wenn die erforderlichen Ressourcen nicht rechtzeitig erstellt werden können, sollte „202 Akzeptiert“ zurückgegeben werden. |
| 202 | Der Server hat die Anfrage angenommen, aber noch nicht verarbeitet. Ebenso wie der Antrag abgelehnt werden kann, kann es sein, dass der Antrag letztendlich ausgeführt wird oder auch nicht. Bei asynchronen Vorgängen gibt es keinen bequemeren Weg, als diesen Statuscode zu senden. Der Zweck der Rückgabe einer 202-Statuscode-Antwort besteht darin, dem Server zu ermöglichen, Anforderungen von anderen Prozessen (z. B. einem Batch-basierten Vorgang, der nur einmal am Tag ausgeführt wird) anzunehmen, ohne dass der Client bis zum Batch-Vorgang mit dem Server verbunden bleiben muss ist abgeschlossen. Eine Antwort, die die Anforderungsverarbeitung akzeptiert und einen 202-Statuscode zurückgibt, sollte in der zurückgegebenen Entität einige Informationen enthalten, die den aktuellen Status der Verarbeitung angeben, sowie einen Zeiger auf einen Verarbeitungsstatusmonitor oder eine Statusvorhersage, damit der Benutzer abschätzen kann, ob der Vorgang ausgeführt wird ist abgeschlossen. |
| 203 | Der Server hat die Anfrage erfolgreich verarbeitet, aber die zurückgegebenen Entitätsheader-Metainformationen sind kein bestimmter Satz, der auf dem ursprünglichen Server gültig ist, sondern von stammen lokal oder von Dritten kopiert. Die aktuellen Informationen können eine Teilmenge oder eine Obermenge der Originalversion sein. Wenn beispielsweise Metadaten für eine Ressource enthalten sind, kann dies dazu führen, dass der Ursprungsserver die übergeordneten Informationen zu den Metadaten kennt. Die Verwendung dieses Statuscodes ist nicht erforderlich und nur dann sinnvoll, wenn die Antwort ohne diesen Statuscode 200 OK zurückgegeben hätte. |
| 204 | Der Server hat die Anfrage erfolgreich verarbeitet, muss aber keinen Entitätsinhalt zurückgeben und möchte aktualisierte Metainformationen zurückgeben. Die Antwort kann neue oder aktualisierte Metainformationen in Form von Entitätsheadern zurückgeben. Diese Header sollten, sofern vorhanden, den angeforderten Variablen entsprechen. Wenn der Client ein Browser ist, SOLLTE der Browser des Benutzers die Seite, für die die Anforderung gestellt wurde, ohne Änderungen an der Dokumentansicht beibehalten, selbst wenn neue oder aktualisierte Metainformationen gemäß der Spezifikation „Dokumente in Ansicht“ auf die Browseraktivität des Benutzers angewendet werden sollen. Da eine 204-Antwort keinen Nachrichtentext enthalten darf, endet sie immer mit der ersten Leerzeile nach dem Nachrichtenkopf. |
| 205 | Der Server hat die Anfrage erfolgreich verarbeitet und nichts zurückgegeben. Im Gegensatz zu einer 204-Antwort erfordert eine Antwort, die diesen Statuscode zurückgibt, jedoch, dass der Anforderer die Dokumentansicht zurücksetzt. Diese Antwort wird hauptsächlich verwendet, um das Formular unmittelbar nach der Annahme einer Benutzereingabe zurückzusetzen, damit der Benutzer problemlos eine andere Eingabe starten kann. Wie die 204-Antwort darf diese Antwort keinen Nachrichtentext enthalten und endet mit der ersten Leerzeile nach dem Nachrichtenkopf. |
| 206 | Der Server hat einen Teil der GET-Anfrage erfolgreich verarbeitet. HTTP-Download-Tools wie FlashGet oder Thunder verwenden diese Art von Reaktion, um unterbrochene Downloads fortzusetzen oder ein großes Dokument in mehrere Download-Segmente aufzuteilen, um es gleichzeitig herunterzuladen. Die Anfrage muss einen Range-Header enthalten, um den Inhaltsbereich anzugeben, den der Client erhalten möchte, und kann einen If-Range als Anfragebedingung enthalten. Die Antwort muss die folgenden Header-Felder enthalten: Content-Range wird verwendet, um den Bereich des in dieser Antwort zurückgegebenen Inhalts anzugeben, wenn es sich um einen mehrteiligen Download mit Content-Type Multipart/Byteranges handelt, jeweils mehrteilig Jeder Absatz sollte ein Content-Range-Feld enthalten, um den Inhaltsbereich dieses Absatzes anzugeben. Wenn eine Content-Length in der Antwort enthalten ist, muss ihr Wert mit der tatsächlichen Anzahl von Bytes im zurückgegebenen Inhaltsbereich übereinstimmen. Datums-ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200-Antwort hätte zurückgeben sollen. Läuft ab, Cache-Kontrolle und/oder variiert, wenn sich sein Wert möglicherweise von dem Wert unterscheidet, der anderen vorherigen Antworten auf dieselbe Variable entspricht.Wenn diese Antwortanforderung die starke Cache-Überprüfung von If-Range verwendet, sollte diese Antwort keine anderen Entitätsheader enthalten, wenn diese Antwortanforderung verwendet wird Wenn die Cache-Validierung schwach ist, darf diese Antwort keine anderen Entitätsheader enthalten. Dadurch werden Inkonsistenzen zwischen zwischengespeicherten Entitätsinhalten und aktualisierten Entitätsheaderinformationen vermieden. Andernfalls sollte diese Antwort alle Entitätsheaderfelder enthalten, die in einer 200-Antwort zurückgegeben werden sollen. Wenn die ETag- oder Last-Modified-Header nicht genau übereinstimmen, sollte der Client-Cache den von der 206-Antwort zurückgegebenen Inhalt nicht mit zuvor zwischengespeicherten Inhalten kombinieren. Jeder Cache, der die Header „Range“ und „Content-Range“ nicht unterstützt, darf den von der 206-Antwort zurückgegebenen Inhalt nicht zwischenspeichern. |
| 207 | Ein durch WebDAV (RFC 2518) erweiterter Statuscode, der angibt, dass der nachfolgende Nachrichtentext eine XML-Nachricht sein wird und je nach Anzahl variieren kann vorherige Unteranfragen, die eine Reihe unabhängiger Antwortcodes enthalten. |
| 300 | Die angeforderte Ressource verfügt über eine Reihe optionaler Antworten, jede mit ihrer eigenen spezifischen Adresse und Informationen zur Browsertreiberaushandlung. Der Benutzer oder Browser kann eine bevorzugte Adresse für die Weiterleitung auswählen. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort eine Entität mit einer Liste von Ressourcenattributen und Adressen enthalten, aus der der Benutzer oder Browser die am besten geeignete Weiterleitungsadresse auswählen kann. Das Format dieser Entität wird durch das durch Content-Type definierte Format bestimmt. Der Browser trifft möglicherweise automatisch die am besten geeignete Wahl, basierend auf dem Format der Antwort und den Fähigkeiten des Browsers. Natürlich gibt die RFC 2616-Spezifikation nicht an, wie eine solche automatische Auswahl durchgeführt werden soll. Wenn der Server selbst bereits über eine bevorzugte Feedback-Option verfügt, dann in Der Standort sollte den URI dieser Rückmeldung angeben; der Browser kann diesen Standortwert als Adresse für die automatische Umleitung verwenden. Darüber hinaus ist diese Antwort zwischenspeicherbar, sofern nicht anders angegeben. |
| 301 | Die angeforderte Ressource wurde dauerhaft an einen neuen Speicherort verschoben und alle zukünftigen Verweise auf diese Ressource sollten einen von mehreren URIs verwenden, die mit dieser Antwort zurückgegeben werden. Wenn möglich, sollten Clients mit Linkbearbeitungsfunktionen die angeforderte Adresse automatisch in die vom Server zurückgegebene Adresse ändern. Sofern nicht anders angegeben, ist diese Antwort auch zwischenspeicherbar. Der neue persistente URI sollte im Feld „Location“ der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwortentität einen Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. Wenn es sich nicht um eine GET- oder HEAD-Anfrage handelt, verhindert der Browser die automatische Umleitung, sofern dies nicht vom Benutzer bestätigt wird, da sich die Bedingungen der Anfrage entsprechend ändern können. Hinweis: Bei einigen Browsern, die das HTTP/1.0-Protokoll verwenden, wird die nachfolgende Umleitungsanforderung zu einer GET-Methode, wenn die von ihnen gesendete POST-Anfrage eine 301-Antwort erhält. |
| 302 | Die angeforderte Ressource reagiert jetzt vorübergehend auf Anfragen von einem anderen URI. Da solche Weiterleitungen temporär sind, sollte der Client künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischengespeichert werden, wenn sie in „Cache-Control“ oder „Expires“ angegeben wird. Der neue temporäre URI sollte im Feld „Standort“ der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwortentität einen Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. Wenn es sich nicht um eine GET- oder HEAD-Anfrage handelt, verhindert der Browser die automatische Umleitung, sofern dies nicht vom Benutzer bestätigt wird, da sich die Bedingungen der Anfrage entsprechend ändern können. Hinweis: Obwohl RFC Die Spezifikationen 1945 und RFC 2068 erlauben es dem Client nicht, die Anforderungsmethode bei der Umleitung zu ändern, aber viele bestehende Browser betrachten die 302-Antwort als 303-Antwort und verwenden die GET-Methode, um auf den im Standort angegebenen URI zuzugreifen, unabhängig vom Original Anfragemethode. Die Statuscodes 303 und 307 wurden hinzugefügt, um zu verdeutlichen, welche Antwort der Server vom Client erwartet. |
| 303 | Die Antwort, die der aktuellen Anfrage entspricht, kann unter einem anderen URI gefunden werden, und der Client sollte GET verwenden, um auf diese Ressource zuzugreifen. Diese Methode dient in erster Linie dazu, die Umleitung der skriptaktivierten POST-Anforderungsausgabe an eine neue Ressource zu ermöglichen. Dieser neue URI ist kein Ersatzverweis auf die ursprüngliche Ressource. Gleichzeitig ist es verboten, 303-Antworten zwischenzuspeichern. Natürlich könnte die zweite Anfrage (Umleitung) zwischengespeichert werden. Der neue URI sollte im Feld „Location“ der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwortentität einen Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. HINWEIS: Viele Browser vor HTTP/1.1 verstehen den 303-Status nicht richtig. Wenn Sie die Interaktion mit diesen Browsern in Betracht ziehen müssen, sollte der Statuscode 302 ausreichen, da die meisten Browser 302-Antworten genau so verarbeiten, wie die obige Spezifikation vom Client verlangt, 303-Antworten zu verarbeiten. |
| 304 | Wenn der Client eine bedingte GET-Anfrage sendet und die Anfrage zulässig ist, und der Inhalt des Dokuments (entweder seit dem letzten Zugriff oder basierend auf der Anfrage Wenn sich die Bedingung nicht geändert hat, sollte der Server diesen Statuscode zurückgeben. Eine 304-Antwort darf keinen Nachrichtentext enthalten und endet daher immer mit der ersten Leerzeile nach dem Nachrichtenkopf.Die Antwort MUSS die folgenden Header-Informationen enthalten: Datum, es sei denn, der Server verfügt nicht über eine Uhr. Wenn Server ohne Uhren diese Regeln befolgen, können Proxyserver und Clients das Datumsfeld selbst zu den empfangenen Antwortheadern hinzufügen (wie in RFC 2068 angegeben), und der Caching-Mechanismus funktioniert normal. ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200-Antwort hätte zurückgeben sollen. Läuft ab, Cache-Kontrolle und/oder variiert, wenn sich sein Wert möglicherweise von dem Wert unterscheidet, der anderen vorherigen Antworten auf dieselbe Variable entspricht. Wenn diese Antwortanforderung eine starke Cache-Überprüfung verwendet, sollte diese Antwort keine anderen Entitätsheader enthalten (z. B. verwendet eine bedingte GET-Anfrage eine schwache Cache-Überprüfung). Dies vermeidet Inkonsistenzen zwischen den zwischengespeicherten Entitätsinhalt und aktualisierte Entitätsheaderinformationen. Wenn eine 304-Antwort darauf hinweist, dass eine Entität derzeit nicht zwischengespeichert ist, muss das Caching-System die Antwort ignorieren und die Anfrage ohne Einschränkung wiederholen. Wenn eine 304-Antwort empfangen wird, die eine Aktualisierung eines Cache-Eintrags erfordert, muss das Cache-System den gesamten Eintrag aktualisieren, um die Werte aller Felder widerzuspiegeln, die in der Antwort aktualisiert wurden. |
| 305 | Auf die angeforderte Ressource muss über den angegebenen Proxy zugegriffen werden. Die URI-Informationen des angegebenen Proxys werden im Feld Standort angegeben. Der Empfänger muss wiederholt eine separate Anfrage senden, um über diesen Proxy auf die entsprechende Ressource zuzugreifen. Nur der Ursprungsserver kann eine 305-Antwort erstellen. Hinweis: RFC 2068 legt nicht fest, dass eine 305-Antwort dazu gedacht ist, eine einzelne Anfrage umzuleiten, und dass sie nur vom Ursprungsserver erstellt werden kann. Die Nichtbeachtung dieser Einschränkungen kann schwerwiegende Folgen für die Sicherheit haben. |
| 306 | In der neuesten Version der Spezifikation wird der Statuscode 306 nicht mehr verwendet. |
| 307 | Die angeforderte Ressource reagiert jetzt vorübergehend auf Anfragen von einem anderen URI. Da solche Weiterleitungen temporär sind, sollte der Client künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischengespeichert werden, wenn sie in „Cache-Control“ oder „Expires“ angegeben wird. Der neue temporäre URI sollte im Feld „Standort“ der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwortentität einen Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. Da einige Browser die 307-Antwort nicht erkennen, müssen die oben genannten notwendigen Informationen hinzugefügt werden, damit Benutzer den neuen URI verstehen und Zugriffsanfragen an ihn stellen können. Wenn dies kein GET oder HEAD ist Bei einer Anfrage verbietet der Browser die automatische Weiterleitung, es sei denn, der Benutzer bestätigt dies, da sich die Bedingungen der Anfrage entsprechend ändern können. |
| 400 | 1. Die Semantik ist falsch und die aktuelle Anfrage kann vom Server nicht verstanden werden. Der Client sollte diese Anfrage nicht erneut senden, es sei denn, sie wurde geändert. 2. Die Anforderungsparameter sind falsch. |
| 401 | Die aktuelle Anfrage erfordert eine Benutzerverifizierung. Die Antwort MUSS einen für die angeforderte Ressource geeigneten WWW-Authenticate-Header enthalten, der nach Benutzerinformationen fragt. Der Client kann wiederholt eine Anfrage senden, die den entsprechenden Autorisierungsheader enthält. Wenn die aktuelle Anfrage bereits Autorisierungszertifikate enthielt, weist die 401-Antwort darauf hin, dass die Serverüberprüfung diese Zertifikate abgelehnt hat. Wenn die 401-Antwort dieselbe Authentifizierungsabfrage wie die vorherige Antwort enthält und der Browser mindestens einmal einen Authentifizierungsversuch unternommen hat, sollte der Browser dem Benutzer die in der Antwort enthaltenen Entitätsinformationen anzeigen, da diese Entitätsinformationen möglicherweise relevante Diagnoseinformationen enthalten. Siehe RFC 2617. |
| 402 | Dieser Statuscode ist für mögliche zukünftige Anforderungen reserviert. |
| 403 | Der Server hat die Anfrage verstanden, sich jedoch geweigert, sie auszuführen. Im Gegensatz zu einer 401-Antwort bietet die Authentifizierung keine Hilfe und die Anfrage sollte nicht erneut gesendet werden. Wenn es sich nicht um eine HEAD-Anfrage handelt und der Server erklären möchte, warum die Anfrage nicht ausgeführt werden kann, sollte der Grund für die Ablehnung in der Entität beschrieben werden. Natürlich kann der Server auch eine 404-Antwort zurückgeben, wenn er nicht möchte, dass der Client irgendwelche Informationen erhält. |
| 404 | Die Anfrage ist fehlgeschlagen. Die angeforderte Ressource wurde nicht auf dem Server gefunden. Es gibt keine Informationen darüber, ob der Zustand vorübergehend oder dauerhaft ist. Wenn der Server die Situation kennt, sollte er den Statuscode 410 verwenden, um ihn darüber zu informieren, dass die alte Ressource aufgrund einiger Probleme mit dem internen Konfigurationsmechanismus dauerhaft nicht verfügbar ist und keine Sprungadresse vorhanden ist. Der Statuscode 404 wird häufig verwendet, wenn der Server nicht preisgeben möchte, warum die Anfrage abgelehnt wurde oder keine andere geeignete Antwort verfügbar ist. |
| 405 | Die in der Anforderungszeile angegebene Anforderungsmethode kann nicht zum Anfordern der entsprechenden Ressource verwendet werden. Die Antwort muss eine Allow-Header-Information zurückgeben, um die Liste der Anforderungsmethoden anzugeben, die die aktuelle Ressource akzeptieren kann. Da die PUT- und DELETE-Methoden Ressourcen auf den Server schreiben, unterstützen die meisten Webserver die oben genannten Anforderungsmethoden in der Standardkonfiguration nicht oder erlauben sie nicht, und für solche Anforderungen wird ein 405-Fehler zurückgegeben. |
| 406 | Die Inhaltsmerkmale der angeforderten Ressource können die Bedingungen im Anforderungsheader nicht erfüllen, sodass die Antwortentität nicht generiert werden kann. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort eine Entität zurückgeben, die eine Liste von Entitätsattributen und -adressen enthält, aus denen der Benutzer oder Browser die am besten geeigneten auswählen kann. Das Format der Entität wird durch den im Content-Type-Header definierten Medientyp bestimmt. Der Browser kann basierend auf dem Format und seinen Funktionen seine eigene beste Wahl treffen. Die Spezifikation definiert jedoch keine Kriterien für die Durchführung einer solchen automatischen Auswahl. |
| 407 | Ähnlich der 401-Antwort, außer dass sich der Client beim Proxyserver authentifizieren muss. Der Proxyserver muss für Identitätsabfragen ein Proxy-Authenticate zurückgeben. Der Client kann zur Überprüfung einen Proxy-Authorization-Header zurückgeben. Siehe RFC 2617. |
| 408 | Zeitüberschreitung anfordern. Der Client hat das Senden einer Anfrage nicht innerhalb der Zeit abgeschlossen, die der Server warten wollte. Der Kunde kann diesen Antrag jederzeit erneut stellen, ohne dass Änderungen erforderlich sind. |
| 409 | Die Anfrage kann aufgrund eines Konflikts mit dem aktuellen Status der angeforderten Ressource nicht abgeschlossen werden. Dieser Code sollte nur verwendet werden, wenn davon ausgegangen wird, dass der Benutzer den Konflikt lösen und eine neue Anfrage erneut einreichen kann. Die Antwort sollte genügend Informationen enthalten, damit der Benutzer die Ursache des Konflikts ermitteln kann. Bei der Verarbeitung von PUT-Anfragen kommt es in der Regel zu Konflikten. Wenn beispielsweise in einer Umgebung mit Versionsprüfung die Versionsinformationen, die an eine von einem PUT übermittelte Änderungsanforderung für eine bestimmte Ressource angehängt sind, mit einer vorherigen Anforderung (von einem Drittanbieter) in Konflikt stehen, sollte der Server zu diesem Zeitpunkt einen 409-Fehler zurückgeben. Informieren Sie den Benutzer darüber, dass die Anfrage nicht abgeschlossen werden kann. Zu diesem Zeitpunkt enthält die Antwortentität wahrscheinlich einen Differenzvergleich zwischen den beiden widersprüchlichen Versionen, sodass der Benutzer die neue Version nach dem Zusammenführen erneut einreichen kann. |
| 410 | Die angeforderte Ressource ist nicht mehr auf dem Server verfügbar und hat keine bekannte Weiterleitungsadresse. Eine solche Situation sollte als dauerhaft angesehen werden. Wenn möglich, sollten Clients mit Linkbearbeitungsfunktionen alle Verweise auf diese Adresse mit Zustimmung des Benutzers entfernen. Wenn der Server nicht weiß oder nicht feststellen kann, ob der Zustand dauerhaft ist, sollte der Statuscode 404 verwendet werden. Sofern nicht anders angegeben, ist diese Antwort zwischenspeicherbar. Der Zweck der 410-Antwort besteht hauptsächlich darin, Website-Administratoren bei der Wartung der Website zu helfen, Benutzer darüber zu informieren, dass die Ressource nicht mehr verfügbar ist, und der Serverbesitzer hofft, dass auch alle Remote-Verbindungen gelöscht werden, die auf diese Ressource verweisen. Diese Art von Vorfall kommt häufig bei zeitlich begrenzten Mehrwertdiensten vor. In ähnlicher Weise wird die 410-Antwort auch verwendet, um den Client darüber zu informieren, dass Ressourcen, die ursprünglich einer Person gehörten, auf dem aktuellen Serverstandort nicht mehr verfügbar sind. Müssen Sie natürlich alle dauerhaft nicht verfügbaren Ressourcen als „410“ markieren? „Vorbei“ und ob diese Markierung wie lange beibehalten werden muss, liegt ganz im Ermessen des Serverbesitzers. |
| 411 | Der Server weigerte sich, die Anfrage anzunehmen, ohne dass der Content-Length-Header definiert war. Nach dem Hinzufügen eines gültigen Content-Length-Headers, der die Länge des Anforderungsnachrichtentexts angibt, kann der Client die Anforderung erneut senden. |
| 412 | Der Server konnte eine oder mehrere der in den Headerfeldern der Anfrage angegebenen Voraussetzungen nicht erfüllen. Mit diesem Statuscode kann der Client beim Abrufen der Ressource Vorbedingungen in den Anforderungsmetainformationen (Anfrage-Header-Felddaten) festlegen und so verhindern, dass die Anforderungsmethode anders als erwartet auf die Ressource angewendet wird. |
| 413 | Der Server weigert sich, die aktuelle Anfrage zu verarbeiten, da die Größe der durch die Anfrage übermittelten Entitätsdaten den Bereich überschreitet, den der Server verarbeiten möchte oder kann . In diesem Fall kann der Server die Verbindung schließen, um zu verhindern, dass der Client diese Anfrage weiterhin sendet. Wenn die Situation vorübergehend ist, sollte der Server einen Retry-After-Antwortheader zurückgeben, um den Client darüber zu informieren, wie viel Zeit später er es erneut versuchen kann. |
| 414 | Der angeforderte URI ist länger, als der Server interpretieren kann, sodass der Server die Bearbeitung der Anfrage verweigert. Dies ist relativ selten und häufige Situationen sind: Die Formularübermittlung, die die POST-Methode hätte verwenden sollen, wird zur GET-Methode, was dazu führt, dass die Abfragezeichenfolge (Query String) zu lang ist. Der Umleitungs-URI ist beispielsweise ein „schwarzes Loch“. Bei jeder Umleitung wird der alte URI als Teil des neuen URI verwendet, was nach mehreren Umleitungen zu einem überlangen URI führt. Der Client versucht, die Sicherheitslücken einiger Server auszunutzen, um den Server anzugreifen. Dieser Servertyp verwendet einen Puffer fester Länge, um den angeforderten URI zu lesen oder zu betreiben. Wenn die Parameter nach GET einen bestimmten Wert überschreiten, kann es zu einem Pufferüberlauf kommen, der zur Ausführung beliebigen Codes führt [1]. Server ohne solche Schwachstellen sollten den Statuscode 414 zurückgeben. |
| 415 | Für die aktuell angeforderte Methode und angeforderte Ressource liegt die in der Anforderung übermittelte Entität nicht in einem vom Server unterstützten Format vor, sodass die Anforderung abgelehnt wird. |
| 416 | Wenn die Anfrage den Range-Anfrageheader enthält und ein im Bereich angegebener Datenbereich nicht mit dem verfügbaren Bereich der aktuellen Ressource übereinstimmt und die Anfrage enthält Wenn der If-Range-Anfrageheader nicht definiert ist, sollte der Server einen 416-Statuscode zurückgeben.Wenn Range einen Bytebereich verwendet, bedeutet diese Situation, dass die erste Byteposition aller in der Anforderung angegebenen Datenbereiche die Länge der aktuellen Ressource überschreitet. Der Server sollte außerdem einen Content-Range-Entitätsheader enthalten, um die Länge der aktuellen Ressource anzugeben und gleichzeitig den Statuscode 416 zurückzugeben. Es ist dieser Antwort auch untersagt, multipart/byteranges als Inhaltstyp zu verwenden. |
| 417 | Der im Anforderungsheader Expect angegebene erwartete Inhalt kann vom Server nicht erfüllt werden, oder der Server ist ein Proxyserver und es liegen offensichtliche Beweise dafür vor Wird in der aktuellen Route nicht verwendet. Der Inhalt von Expect kann nicht erfüllt werden. |
| 421 | Die Anzahl der Verbindungen zum Server von der IP-Adresse des aktuellen Clients überschreitet den maximal zulässigen Bereich des Servers. Normalerweise bezieht sich die IP-Adresse hier auf die Client-Adresse, die vom Server aus gesehen wird (z. B. die Gateway- oder Proxy-Server-Adresse des Benutzers). In diesem Fall kann die Anzahl der Verbindungen mehr als einen Endbenutzer umfassen. |
| 422 | Die Anzahl der Verbindungen zum Server von der IP-Adresse des aktuellen Clients überschreitet den maximal zulässigen Bereich des Servers. Normalerweise bezieht sich die IP-Adresse hier auf die Client-Adresse, die vom Server aus gesehen wird (z. B. die Gateway- oder Proxy-Server-Adresse des Benutzers). In diesem Fall kann die Anzahl der Verbindungen mehr als einen Endbenutzer umfassen. |
| 422 | Das Anfrageformat ist korrekt, es kann jedoch aufgrund semantischer Fehler nicht geantwortet werden. (RFC 4918 WebDAV) 423 Gesperrt Die aktuelle Ressource ist gesperrt. (RFC 4918 WebDAV) |
| 424 | Die aktuelle Anfrage ist aufgrund eines Fehlers fehlgeschlagen, der in einer früheren Anfrage aufgetreten ist, z. B. PROPPATCH. (RFC 4918 WebDAV) |
| 425 | ist im WebDav Advanced Collections-Entwurf definiert, erscheint aber nicht im WebDAV Sequence Collection Protocol (RFC 3658). |
| 426 | Clients sollten auf TLS/1.0 umsteigen. (RFC 2817) |
| 449 | Erweitert von Microsoft, gibt an, dass Anfragen nach Durchführung der entsprechenden Aktion erneut versucht werden sollten. |
| 500 | Der Server ist auf einen unerwarteten Zustand gestoßen, der die Verarbeitung der Anfrage verhindert hat. Im Allgemeinen tritt dieses Problem auf, wenn im Programmcode des Servers ein Fehler vorliegt. |
| 501 | Der Server unterstützt eine für die aktuelle Anfrage erforderliche Funktion nicht. Wenn der Server die angeforderte Methode nicht erkennt und seine Anforderung für keine Ressource unterstützen kann. |
| 502 | Ein Server, der als Gateway oder Proxy fungiert, hat beim Versuch, eine Anfrage auszuführen, eine ungültige Antwort vom Upstream-Server erhalten. |
| 503 | Aufgrund vorübergehender Serverwartung oder Überlastung kann der Server die Anfrage derzeit nicht verarbeiten. Dieser Zustand ist vorübergehend und wird nach einiger Zeit wiederhergestellt. Wenn mit einer Verzögerung zu rechnen ist, kann die Antwort einen Retry-After-Header enthalten, um die Verzögerung anzuzeigen. Wenn diese Retry-After-Nachricht nicht gegeben wird, SOLLTE der Client sie genauso behandeln wie eine 500-Antwort. Hinweis: Das Vorhandensein des Statuscodes 503 bedeutet nicht, dass der Server ihn verwenden muss, wenn er überlastet ist. Einige Server möchten einfach Verbindungen von Clients verweigern. |
| 504 | Wenn ein Server, der als Gateway oder Proxy fungiert, versucht, eine Anfrage auszuführen, kann er die Anfrage nicht rechtzeitig vom Upstream-Server (dem identifizierten Server) erhalten B. HTTP, FTP, LDAP) oder ein sekundärer Server (z. B. DNS) eine Antwort erhält. Hinweis: Einige Proxyserver geben einen 400- oder 500-Fehler zurück, wenn bei einer DNS-Abfrage eine Zeitüberschreitung auftritt |
| 505 | Der Server unterstützt HTTP nicht oder verweigert die Unterstützung in der Anfrage verwendete Version. Dies bedeutet, dass der Server nicht in der Lage oder nicht bereit ist, dieselbe Version wie der Client zu verwenden. Die Antwort sollte eine Entität enthalten, die beschreibt, warum die Version nicht unterstützt wird und welche Protokolle der Server unterstützt. |
| 506 | wird durch das Transparent Content Negotiation Protocol (RFC 2295) erweitert und stellt einen internen Serverkonfigurationsfehler dar: Die angeforderte Verhandlungsargumentressource ist so konfiguriert, dass sie sich in „Verwendet“ befindet sich in der transparenten Inhaltsverhandlung selbst und stellt daher keinen angemessenen Fokus in einem Verhandlungsprozess dar. |
| 507 | Der Server kann den zum Abschließen der Anfrage erforderlichen Inhalt nicht speichern. Dieser Zustand gilt als vorübergehend. WebDAV (RFC 4918) |
| 509 | Der Server hat sein Bandbreitenlimit erreicht. Dies ist kein offizieller Statuscode, wird aber dennoch häufig verwendet. |
| 510 | Die zur Ressourcenbeschaffung erforderlichen Strategien werden nicht erfüllt. (RFC 2774) |
Schließlich stammen die meisten Informationen aus dem Internet. Vielen Dank an alle älteren Kollegen, die dazu beigetragen haben!
[Empfohlener Kurs: http-Video-Tutorial]
Das obige ist der detaillierte Inhalt vonKenntnisse über das http-Protokoll, die Front-End-Entwickler kennen müssen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
