HTTP - Kurzanleitung

Das Hypertext Transfer Protocol (HTTP) ist ein Protokoll auf Anwendungsebene für verteilte, kollaborative Hypermedia-Informationssysteme. Dies ist die Grundlage für die Datenkommunikation für das World Wide Web (dh das Internet) seit 1990. HTTP ist ein generisches und zustandsloses Protokoll, das auch für andere Zwecke verwendet werden kann, indem seine Anforderungsmethoden, Fehlercodes und Header erweitert werden.

Grundsätzlich ist HTTP ein TCP / IP-basiertes Kommunikationsprotokoll, mit dem Daten (HTML-Dateien, Bilddateien, Abfrageergebnisse usw.) im World Wide Web bereitgestellt werden. Der Standardport ist TCP 80, es können jedoch auch andere Ports verwendet werden. Es bietet eine standardisierte Möglichkeit für Computer, miteinander zu kommunizieren. Die HTTP-Spezifikation gibt an, wie Client-Anforderungsdaten erstellt und an den Serve gesendet werden und wie Server auf diese Anforderungen reagieren.

Grundfunktionen

Es gibt drei grundlegende Funktionen, die HTTP zu einem einfachen, aber leistungsstarken Protokoll machen:

• HTTP is connectionless:Der HTTP-Client dh. Der Browser initiiert eine HTTP-Anfrage. Nachdem eine Anfrage gestellt wurde, trennt sich der Client vom Server und wartet auf eine Antwort. Der Server verarbeitet die Anforderung und stellt die Verbindung zum Client wieder her, um eine Antwort zurückzusenden.

• HTTP is media independent:Dies bedeutet, dass jeder Datentyp über HTTP gesendet werden kann, solange sowohl der Client als auch der Server wissen, wie mit dem Dateninhalt umzugehen ist. Dies ist sowohl für den Client als auch für den Server erforderlich, um den Inhaltstyp unter Verwendung des entsprechenden MIME-Typs anzugeben.

• HTTP is stateless:Wie oben erwähnt, ist HTTP verbindungslos und dies ist eine direkte Folge davon, dass HTTP ein zustandsloses Protokoll ist. Der Server und der Client kennen sich nur während einer aktuellen Anforderung. Danach vergessen sich beide. Aufgrund dieser Art des Protokolls können weder der Client noch der Browser Informationen zwischen verschiedenen Anforderungen auf den Webseiten speichern.

HTTP / 1.0 verwendet für jeden Anforderungs- / Antwortaustausch eine neue Verbindung, wobei eine HTTP / 1.1-Verbindung für einen oder mehrere Anforderungs- / Antwortaustausche verwendet werden kann.

Grundlegende Architektur

Das folgende Diagramm zeigt eine sehr grundlegende Architektur einer Webanwendung und zeigt, wo sich HTTP befindet:

Das HTTP-Protokoll ist ein Anforderungs- / Antwortprotokoll, das auf einer Client / Server-basierten Architektur basiert, bei der Webbrowser, Roboter und Suchmaschinen usw. wie HTTP-Clients und Webserver als Server fungieren.

Klient

Der HTTP-Client sendet eine Anforderung in Form einer Anforderungsmethode, eines URI und einer Protokollversion an den Server, gefolgt von einer MIME-ähnlichen Nachricht, die Anforderungsmodifikatoren, Clientinformationen und möglichen Textinhalt über eine TCP / IP-Verbindung enthält.

Server

Der HTTP-Server antwortet mit einer Statuszeile, einschließlich der Protokollversion der Nachricht und eines Erfolgs- oder Fehlercodes, gefolgt von einer MIME-ähnlichen Nachricht, die Serverinformationen, Entitätsmetainformationen und möglichen Entitätskörperinhalt enthält.

In diesem Kapitel werden einige der wichtigen HTTP-Protokollparameter und ihre Syntax so aufgelistet, wie sie in der Kommunikation verwendet werden. Beispiel: Format für Datum, Format der URL usw. Dies hilft Ihnen beim Erstellen Ihrer Anforderungs- und Antwortnachrichten beim Schreiben von HTTP-Client- oder -Serverprogrammen. Sie werden die vollständige Verwendung dieser Parameter in den folgenden Kapiteln sehen, während Sie die Nachrichtenstruktur für HTTP-Anforderungen und -Antworten erläutern.

HTTP-Version

HTTP verwendet a <major>.<minor>Nummerierungsschema zur Angabe von Versionen des Protokolls. Die Version einer HTTP-Nachricht wird in der ersten Zeile durch ein Feld für die HTTP-Version angezeigt. Hier ist die allgemeine Syntax zur Angabe der HTTP-Versionsnummer:

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Beispiel

HTTP/1.0

or

HTTP/1.1

Uniform Resource Identifiers (URI)

Uniform Resource Identifiers (URI) ist eine einfach formatierte Zeichenfolge ohne Berücksichtigung der Groß- und Kleinschreibung, die Namen, Speicherort usw. enthält, um eine Ressource zu identifizieren, z. B. eine Website, einen Webdienst usw. Eine allgemeine Syntax des für HTTP verwendeten URI lautet wie folgt:

URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Hier, wenn die port ist leer oder nicht angegeben, wird Port 80 für HTTP und leer angenommen abs_path ist gleichbedeutend mit einem abs_pathvon "/". Die anderen Zeichen als die in derreserved und unsafe Sätze entsprechen ihrer ""% "HEX HEX" -Codierung.

Beispiel

Die folgenden zwei URIs sind äquivalent:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

Datums- / Zeitformate

Alle HTTP-Datums- / Zeitstempel MÜSSEN ausnahmslos in Greenwich Mean Time (GMT) dargestellt werden. HTTP-Anwendungen dürfen eine der folgenden drei Darstellungen von Datums- / Zeitstempeln verwenden:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Zeichensätze

Sie verwenden den Zeichensatz, um die vom Client bevorzugten Zeichensätze anzugeben. Mehrere Zeichensätze können durch Kommas getrennt aufgelistet werden. Wenn kein Wert angegeben wird, ist der Standardwert US-ASCII.

Beispiel

Es folgen gültige Zeichensätze:

US-ASCII

or

ISO-8859-1

or 

ISO-8859-7

Inhaltscodierungen

Ein Inhaltscodierungswert gibt an, dass ein Codierungsalgorithmus verwendet wurde, um den Inhalt zu codieren, bevor er über das Netzwerk übertragen wird. Inhaltscodierungen werden hauptsächlich verwendet, um zu ermöglichen, dass ein Dokument komprimiert oder auf andere Weise sinnvoll transformiert wird, ohne die Identität zu verlieren.

Bei allen inhaltscodierenden Werten wird die Groß- und Kleinschreibung nicht berücksichtigt. HTTP / 1.1 verwendet Inhaltscodierungswerte in den Headerfeldern Accept-Encoding und Content-Encoding, die in den folgenden Kapiteln angezeigt werden.

Beispiel

Es folgen gültige Codierungsschemata:

Accept-encoding: gzip

or

Accept-encoding: compress

or 

Accept-encoding: deflate

Medientypen

HTTP verwendet Internetmedientypen in der Content-Type und AcceptHeader-Felder, um eine offene und erweiterbare Datentypisierung und Typaushandlung zu ermöglichen. Alle Medientypwerte werden bei der Internet Assigned Number Authority (IANA) registriert. Im Folgenden finden Sie eine allgemeine Syntax zur Angabe des Medientyps:

media-type     = type "/" subtype *( ";" parameter )

Bei den Attributnamen für Typ, Subtyp und Parameter wird die Groß- und Kleinschreibung nicht berücksichtigt.

Beispiel

Accept: image/gif

Sprach-Tags

HTTP verwendet Sprach-Tags innerhalb der Accept-Language und Content-LanguageFelder. Ein Sprach-Tag besteht aus einem oder mehreren Teilen: Ein primäres Sprach-Tag und eine möglicherweise leere Reihe von Untertags:

language-tag  = primary-tag *( "-" subtag )

Leerzeichen innerhalb des Tags sind nicht zulässig, und bei allen Tags wird die Groß- und Kleinschreibung nicht berücksichtigt.

Beispiel

Beispiel-Tags sind:

en, en-US, en-cockney, i-cherokee, x-pig-latin

Wenn ein aus zwei Buchstaben bestehendes Primär-Tag eine Abkürzung für die ISO-639-Sprache ist und ein aus zwei Buchstaben bestehendes anfängliches Sub-Tag ein ISO-3166-Ländercode ist.

HTTP basiert auf dem Client-Server-Architekturmodell und einem zustandslosen Anforderungs- / Antwortprotokoll, bei dem Nachrichten über eine zuverlässige TCP / IP-Verbindung ausgetauscht werden.

Ein HTTP- "Client" ist ein Programm (Webbrowser oder ein anderer Client), das eine Verbindung zu einem Server herstellt, um eine oder mehrere HTTP-Anforderungsnachrichten zu senden. Ein HTTP- "Server" ist ein Programm (im Allgemeinen ein Webserver wie Apache Web Server oder Internet Information Services IIS usw.), das Verbindungen akzeptiert, um HTTP-Anforderungen durch Senden von HTTP-Antwortnachrichten zu bedienen.

HTTP verwendet den URI (Uniform Resource Identifier), um eine bestimmte Ressource zu identifizieren und eine Verbindung herzustellen. Sobald die Verbindung hergestellt ist,HTTP messageswerden in einem Format übergeben, das dem von Internet Mail [RFC5322] und den Multipurpose Internet Mail Extensions (MIME) [RFC2045] verwendeten Format ähnelt. Diese Nachrichten bestehen ausrequests vom Client zum Server und responses vom Server zum Client mit folgendem Format:

HTTP-message   = <Request> | <Response> ; HTTP/1.1 messages

HTTP-Anforderung und HTTP-Antwort verwenden ein generisches Nachrichtenformat von RFC 822 zum Übertragen der erforderlichen Daten. Dieses generische Nachrichtenformat besteht aus den folgenden vier Elementen.

     

      
A Start-line
 
Zero or more header fields followed by CRLF
 
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 
Optionally a message-body
     

Im folgenden Abschnitt werden alle in der HTTP-Nachricht verwendeten Entitäten erläutert.

Start-Line der Nachricht

Eine Startzeile hat folgende generische Syntax:

start-line = Request-Line | Status-Line

Wir werden Request-Line und Status-Line diskutieren, während wir HTTP Request- bzw. HTTP Response-Nachrichten diskutieren. Sehen wir uns zunächst die Beispiele für die Startlinie bei Anforderung und Antwort an:

GET /hello.htm HTTP/1.1     (This is Request-Line sent by the client)

HTTP/1.1 200 OK             (This is Status-Line sent by the server)

Header-Felder

HTTP-Deader-Felder enthalten die erforderlichen Informationen zur Anforderung oder Antwort oder zum im Nachrichtentext gesendeten Objekt. Es gibt folgende vier Arten von HTTP-Nachrichtenkopfzeilen:

• General-header: Diese Headerfelder sind allgemein für Anforderungs- und Antwortnachrichten anwendbar.

• Request-header: Diese Headerfelder sind nur für Anforderungsnachrichten anwendbar.

• Response-header: Diese Headerfelder sind nur für Antwortnachrichten anwendbar.

• Entity-header: Diese Header-Felder definieren Metainformationen über den Entity-Body oder, falls kein Body vorhanden ist

Alle oben genannten Header haben dasselbe generische Format und jedes Headerfeld besteht aus einem Namen, gefolgt von einem Doppelpunkt (:) und den Feldwert wie folgt:

message-header = field-name ":" [ field-value ]

Es folgen Beispiele für verschiedene Header-Felder:

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Nachrichtentext

Der Nachrichtentextteil ist für eine HTTP-Nachricht optional. Wenn er jedoch verfügbar ist, wird er verwendet, um den der Anforderung oder Antwort zugeordneten Entitätstext zu übertragen. Wenn der Entitätskörper zugeordnet ist, ist dies normalerweise der FallContent-Type und Content-Length Kopfzeilen geben die Art des zugeordneten Körpers an.

Ein Nachrichtentext ist derjenige, der tatsächliche HTTP-Anforderungsdaten (einschließlich Formulardaten und hochgeladen usw.) und HTTP-Antwortdaten vom Server (einschließlich Dateien, Bilder usw.) enthält. Es folgt ein einfacher Inhalt eines Nachrichtentexts:

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Ein HTTP-Client sendet eine HTTP-Anforderung in Form einer Anforderungsnachricht an einen Server, die das folgende Format enthält:

     

      
A Request-line
 
Zero or more header (General|Request|Entity) fields followed by CRLF
 
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 
Optionally a message-body
     

Im folgenden Abschnitt werden alle in der HTTP-Nachricht verwendeten Entitäten erläutert.

Nachrichtenanforderungszeile

Die Anforderungszeile beginnt mit einem Methoden-Token, gefolgt von der Anforderungs-URI und der Protokollversion, und endet mit CRLF. Die Elemente sind durch Leerzeichen SP getrennt.

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

Lassen Sie uns jeden der in Request-Line genannten Teile besprechen.

Anforderungsmethode

Die Anfrage Method gibt die Methode an, die für die durch die angegebene Ressource identifizierte Ressource ausgeführt werden soll Request-URI. Die Methode unterscheidet zwischen Groß- und Kleinschreibung und sollte immer in Großbuchstaben angegeben werden. Im Folgenden werden Methoden in HTTP / 1.1 unterstützt

SN	Methode und Beschreibung
1	GET Die GET-Methode wird verwendet, um Informationen von dem angegebenen Server unter Verwendung eines bestimmten URI abzurufen. Anforderungen, die GET verwenden, sollten nur Daten abrufen und keine anderen Auswirkungen auf die Daten haben.
2	HEAD Wie GET, jedoch nur die Statuszeile und den Header-Bereich übertragen.
3	POST Eine POST-Anforderung wird verwendet, um Daten an den Server zu senden, z. B. Kundeninformationen, Datei-Upload usw. mithilfe von HTML-Formularen.
4	PUT Ersetzen Sie alle aktuellen Darstellungen der Zielressource durch den hochgeladenen Inhalt.
5	DELETE Entfernen Sie alle aktuellen Darstellungen der von URI angegebenen Zielressource.
6	CONNECT Richten Sie einen Tunnel zum Server ein, der durch einen bestimmten URI identifiziert wird.
7	OPTIONS Beschreiben der Kommunikationsoptionen für die Zielressource.
8	TRACE Führen Sie einen Nachrichten-Loopback-Test auf dem Pfad zur Zielressource durch.

Request-URI

Der Anforderungs-URI ist eine einheitliche Ressourcenkennung und gibt die Ressource an, auf die die Anforderung angewendet werden soll. Im Folgenden sind die am häufigsten verwendeten Formulare zum Angeben eines URI aufgeführt:

Request-URI = "*" | absoluteURI | abs_path | authority

SN	Methode und Beschreibung
1	Das Sternchen *wird verwendet, wenn die HTTP-Anforderung nicht für eine bestimmte Ressource, sondern für den Server selbst gilt, und ist nur zulässig, wenn die verwendete Methode nicht unbedingt für eine Ressource gilt. Zum Beispiel: OPTIONS * HTTP/1.1
2	Das absoluteURIwird verwendet, wenn eine HTTP-Anforderung an einen Proxy gesendet wird. Der Proxy wird aufgefordert, die Anforderung weiterzuleiten oder aus einem gültigen Cache zu bedienen und die Antwort zurückzugeben. Zum Beispiel: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
3	Die häufigste Form der Anforderungs-URI ist die, mit der eine Ressource auf einem Ursprungsserver oder Gateway identifiziert wird. Beispielsweise würde ein Client, der die oben genannte Ressource direkt vom Ursprungsserver abrufen möchte, eine TCP-Verbindung zu Port 80 des Hosts "www.w3.org" herstellen und die folgenden Zeilen senden: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org Beachten Sie, dass der absolute Pfad nicht leer sein darf. Wenn in der ursprünglichen URI keine vorhanden ist, MUSS diese als "/" (Serverstamm) angegeben werden.

Header-Felder anfordern

Wir werden General-Header und Entity-Header in einem separaten Kapitel untersuchen, wenn wir HTTP-Header-Felder lernen. Lassen Sie uns zunächst überprüfen, was Anforderungsheaderfelder sind.

In den Anforderungsheaderfeldern kann der Client zusätzliche Informationen zur Anforderung und zum Client selbst an den Server übergeben. Diese Felder dienen als Anforderungsmodifikatoren, und es stehen folgende wichtige Anforderungsheaderfelder zur Verfügung, die je nach Anforderung verwendet werden können.

• Accept-Charset

• Accept-Encoding

• Accept-Language

• Authorization

• Expect

• From

• Host

• If-Match

• If-Modified-Since

• If-None-Match

• If-Range

• If-Unmodified-Since

• Max-Forwards

• Proxy-Authorization

• Range

• Referer

• TE

• User-Agent

Sie können Ihre benutzerdefinierten Felder einführen, falls Sie Ihren eigenen benutzerdefinierten Client und Webserver schreiben möchten.

Beispiele für Anforderungsnachrichten

Lassen Sie uns nun alles zusammenfügen, um eine HTTP-Anforderung zum Abrufen zu bilden hello.htm Seite vom Webserver, der auf tutorialspoint.com ausgeführt wird

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Hier senden wir keine Anforderungsdaten an den Server, da wir eine Plan-HTML-Seite vom Server abrufen. Die Verbindung ist ein allgemeiner Header, der hier verwendet wird, und der Rest der Header sind Anforderungsheader. Im Folgenden finden Sie ein weiteres Beispiel, in dem wir Formulardaten mithilfe des Anforderungsnachrichtentexts an den Server senden:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

Hier wird die angegebene URL /cgi-bin/process.cgi verwendet, um die übergebenen Daten zu verarbeiten, und dementsprechend wird eine Antwort erneut abgestimmt. Hiercontent-type teilt dem Server mit, dass übergebene Daten einfache Webformulardaten sind und lengthwird die tatsächliche Länge der Daten sein, die in den Nachrichtentext eingegeben werden. Das folgende Beispiel zeigt, wie Sie Plan-XML an Ihren Webserver übergeben können:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

Nach dem Empfang und der Interpretation einer Anforderungsnachricht antwortet ein Server mit einer HTTP-Antwortnachricht:

     

      
A Status-line
 
Zero or more header (General|Response|Entity) fields followed by CRLF
 
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 
Optionally a message-body
     

Im folgenden Abschnitt werden alle in der HTTP-Nachricht verwendeten Entitäten erläutert.

Nachrichtenstatuszeile

Die Statuszeile besteht aus der Protokollversion, gefolgt von einem numerischen Statuscode und der zugehörigen Textphrase. Die Elemente sind durch Leerzeichen SP getrennt.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Lassen Sie uns jeden der in der Statuszeile erwähnten Teile diskutieren.

HTTP-Version

Ein Server, der HTTP Version 1.1 unterstützt, gibt folgende Versionsinformationen zurück:

HTTP-Version = HTTP/1.1

Statuscode

Das Statuscode-Element ist eine dreistellige Ganzzahl, wobei die erste Ziffer des Statuscodes die Antwortklasse definiert und die letzten beiden Ziffern keine Kategorisierungsrolle haben. Es gibt 5 Werte für die erste Ziffer:

SN	Code und Beschreibung
1	1xx: Informational Dies bedeutet, dass eine Anfrage eingegangen ist und der Prozess fortgesetzt wird.
2	2xx: Success Dies bedeutet, dass die Aktion erfolgreich empfangen, verstanden und akzeptiert wurde.
3	3xx: Redirection Dies bedeutet, dass weitere Maßnahmen ergriffen werden müssen, um die Anforderung abzuschließen.
4	4xx: Client Error Dies bedeutet, dass die Anforderung eine schlechte Syntax enthält oder nicht erfüllt werden kann
5	5xx: Server Error Der Server konnte eine scheinbar gültige Anforderung nicht erfüllen

HTTP-Statuscodes sind erweiterbar und HTTP-Anwendungen sind nicht erforderlich, um die Bedeutung aller registrierten Statuscodes zu verstehen. Eine Liste aller Statuscodes wurde in einem separaten Kapitel als Referenz angegeben.

Antwortheaderfelder

Wir werden General-Header und Entity-Header in einem separaten Kapitel untersuchen, wenn wir HTTP-Header-Felder lernen. Lassen Sie uns zunächst überprüfen, was Antwortheaderfelder sind.

Über die Antwortheaderfelder kann der Server zusätzliche Informationen über die Antwort übergeben, die nicht in die Statuszeile eingefügt werden können. Diese Headerfelder enthalten Informationen zum Server und zum weiteren Zugriff auf die durch den Request-URI angegebene Ressource.

• Accept-Ranges

• Age

• ETag

• Location

• Proxy-Authenticate

• Retry-After

• Server

• Vary

• WWW-Authenticate

Sie können Ihre benutzerdefinierten Felder einführen, falls Sie Ihren eigenen benutzerdefinierten Webclient und Server schreiben möchten.

Beispiele für Antwortnachrichten

Lassen Sie uns nun alles zusammenfügen, um eine HTTP-Antwort für eine Anforderung zum Abrufen zu bilden hello.htm Seite vom Webserver, der auf tutorialspoint.com ausgeführt wird

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Im Folgenden finden Sie ein Beispiel für eine HTTP-Antwortnachricht, die einen Fehlerzustand anzeigt, wenn der Webserver die angeforderte Seite nicht finden konnte:

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Im Folgenden finden Sie ein Beispiel für eine HTTP-Antwortnachricht, die einen Fehlerzustand anzeigt, wenn der Webserver in einer bestimmten HTTP-Anforderung eine falsche HTTP-Version festgestellt hat:

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Der Satz allgemeiner Methoden für HTTP / 1.1 ist unten definiert und kann je nach Anforderung erweitert werden. Diese Methodennamen unterscheiden zwischen Groß- und Kleinschreibung und müssen in Großbuchstaben verwendet werden.

SN	Methode und Beschreibung
1	GET Die GET-Methode wird verwendet, um Informationen von dem angegebenen Server unter Verwendung eines bestimmten URI abzurufen. Anforderungen, die GET verwenden, sollten nur Daten abrufen und keine anderen Auswirkungen auf die Daten haben.
2	HEAD Wie GET, jedoch nur die Statuszeile und den Header-Bereich übertragen.
3	POST Eine POST-Anforderung wird verwendet, um Daten an den Server zu senden, z. B. Kundeninformationen, Datei-Upload usw. mithilfe von HTML-Formularen.
4	PUT Ersetzen Sie alle aktuellen Darstellungen der Zielressource durch den hochgeladenen Inhalt.
5	DELETE Entfernen Sie alle aktuellen Darstellungen der von URI angegebenen Zielressource.
6	CONNECT Richten Sie einen Tunnel zum Server ein, der durch einen bestimmten URI identifiziert wird.
7	OPTIONS Beschreiben der Kommunikationsoptionen für die Zielressource.
8	TRACE Führen Sie einen Nachrichten-Loopback-Test auf dem Pfad zur Zielressource durch.

GET-Methode

Eine GET-Anforderung ruft Daten von einem Webserver ab, indem Parameter im URL-Teil der Anforderung angegeben werden. Dies ist die Hauptmethode zum Abrufen von Dokumenten. Es folgt ein einfaches Beispiel, das die GET-Methode verwendet, um hello.htm abzurufen:

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Es folgt eine Serverantwort auf die obige GET-Anfrage:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HEAD-Methode

Die HEAD-Methode funktioniert funktional wie GET, außer dass der Server mit einer Antwortzeile und Headern antwortet, jedoch ohne Entity-Body. Es folgt ein einfaches Beispiel, das die HEAD-Methode verwendet, um Header-Informationen zu hello.htm abzurufen:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Es folgt eine Serverantwort auf die obige GET-Anfrage:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

Sie können feststellen, dass der Server hier keine Daten nach dem Header sendet.

POST-Methode

Die POST-Methode wird verwendet, wenn Sie einige Daten an den Server senden möchten, z. B. Dateiaktualisierung, Formulardaten usw. Im Folgenden finden Sie ein einfaches Beispiel, in dem mithilfe der POST-Methode Formulardaten an den Server gesendet werden, die von a verarbeitet werden process.cgi und schließlich wird eine Antwort zurückgegeben:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

Das serverseitige Skript process.cgi verarbeitet die übergebenen Daten und sendet die folgende Antwort:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

PUT-Methode

Die PUT-Methode wird verwendet, um den Server aufzufordern, den enthaltenen Entitätskörper an einem durch die angegebene URL angegebenen Speicherort zu speichern. Im folgenden Beispiel wird der Server aufgefordert, den angegebenen Entitätskörper in zu speichernhello.htm an der Wurzel des Servers:

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Der Server speichert den angegebenen Entity-Body in hello.htm Datei und sendet folgende Antwort an den Client zurück:

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

DELETE-Methode

Die DELETE-Methode wird verwendet, um den Server aufzufordern, Dateien an einem durch die angegebene URL angegebenen Speicherort zu löschen. Im folgenden Beispiel wird der Server aufgefordert, die angegebene Datei zu löschenhello.htm an der Wurzel des Servers:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive

Der Server löscht die genannte Datei hello.htm und sendet folgende Antwort an den Client zurück:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

CONNECT-Methode

Die CONNECT-Methode wird vom Client verwendet, um eine Netzwerkverbindung zu einem Webserver über HTTP herzustellen. Im folgenden Beispiel wird eine Verbindung mit einem Webserver angefordert, der auf dem Host tutorialspoint.com ausgeführt wird:

CONNECT www.tutorialspoint.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Die Verbindung zum Server wird hergestellt und die folgende Antwort wird an den Client zurückgesendet:

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

OPTIONEN Methode

Die OPTIONS-Methode wird vom Client verwendet, um herauszufinden, welche HTTP-Methoden und anderen Optionen von einem Webserver unterstützt werden. Der Client kann eine URL für die OPTIONS-Methode oder ein Sternchen (*) angeben, das auf den gesamten Server verweist. Im folgenden Beispiel wird eine Liste der Methoden angefordert, die von einem auf tutorialspoint.com ausgeführten Webserver unterstützt werden:

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Der Server sendet Informationen basierend auf der aktuellen Konfiguration des Servers, zum Beispiel:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

TRACE-Methode

Die TRACE-Methode wird verwendet, um den Inhalt einer HTTP-Anforderung an den Anforderer zurückzusenden, der zum Zeitpunkt der Entwicklung zum Debuggen verwendet werden kann. Das folgende Beispiel zeigt die Verwendung der TRACE-Methode:

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Der Server sendet als Antwort auf die obige Anfrage die folgende Nachricht:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Das Statuscode-Element in einer Serverantwort ist eine dreistellige Ganzzahl, wobei die erste Ziffer des Statuscodes die Antwortklasse definiert und die letzten beiden Ziffern keine Kategorisierungsrolle haben. Es gibt 5 Werte für die erste Ziffer:

SN	Code und Beschreibung
1	1xx: Informational Dies bedeutet, dass eine Anfrage eingegangen ist und der Prozess fortgesetzt wird.
2	2xx: Success Dies bedeutet, dass die Aktion erfolgreich empfangen, verstanden und akzeptiert wurde.
3	3xx: Redirection Dies bedeutet, dass weitere Maßnahmen ergriffen werden müssen, um die Anforderung abzuschließen.
4	4xx: Client Error Dies bedeutet, dass die Anforderung eine schlechte Syntax enthält oder nicht erfüllt werden kann
5	5xx: Server Error Der Server konnte eine scheinbar gültige Anforderung nicht erfüllen

HTTP-Statuscodes sind erweiterbar und HTTP-Anwendungen sind nicht erforderlich, um die Bedeutung aller registrierten Statuscodes zu verstehen. Es folgt eine Liste aller Statuscodes.

1xx: Informationen

Botschaft:	Beschreibung:
100 Weiter	Nur ein Teil der Anfrage wurde vom Server empfangen. Solange sie nicht abgelehnt wurde, sollte der Client mit der Anfrage fortfahren
101 Vermittlungsprotokolle	Der Server wechselt das Protokoll

2xx: Erfolgreich

Botschaft:	Beschreibung:
200 OK	Die Anfrage ist OK
201 Erstellt	Die Anforderung ist abgeschlossen und eine neue Ressource wird erstellt
202 Akzeptiert	Die Anforderung wird zur Verarbeitung angenommen, die Verarbeitung ist jedoch nicht abgeschlossen
203 Nicht maßgebliche Informationen	Die Informationen im Entitätsheader stammen von einer lokalen Kopie oder einer Kopie eines Drittanbieters, nicht vom ursprünglichen Server.
204 Kein Inhalt	In der Antwort werden ein Statuscode und ein Header angegeben, in der Antwort ist jedoch kein Entity-Body enthalten.
205 Inhalt zurücksetzen	Der Browser sollte das für diese Transaktion verwendete Formular für zusätzliche Eingaben löschen.
206 Teilinhalt	Der Server gibt Teildaten der angeforderten Größe zurück. Wird in Antwort auf eine Anfrage eine Angabe Bereich Header. Der Server muss den in der Antwort enthaltenen Bereich mit dem Content-Range- Header angeben .

3xx: Umleitung

Botschaft:	Beschreibung:
300 Mehrfachauswahl	Eine Linkliste. Der Benutzer kann einen Link auswählen und zu diesem Ort gehen. Maximal fünf Adressen
301 Dauerhaft verschoben	Die angeforderte Seite wurde in eine neue URL verschoben
302 gefunden	Die angeforderte Seite wurde vorübergehend in eine neue URL verschoben
303 Siehe Andere	Die angeforderte Seite befindet sich unter einer anderen URL
304 Nicht geändert	Dies ist der Antwortcode für einen Header " If-Modified-Since" oder " If-None-Match" , bei dem die URL seit dem angegebenen Datum nicht mehr geändert wurde.
305 Proxy verwenden	Auf die angeforderte URL muss über den im Standortheader angegebenen Proxy zugegriffen werden .
306 Nicht verwendet	Dieser Code wurde in einer früheren Version verwendet. Es wird nicht mehr verwendet, aber der Code ist reserviert
307 Temporäre Weiterleitung	Die angeforderte Seite wurde vorübergehend in eine neue URL verschoben

4xx: Clientfehler

Botschaft:	Beschreibung:
400 schlechte Anfrage	Der Server hat die Anfrage nicht verstanden
401 nicht Autorisiert	Die angeforderte Seite benötigt einen Benutzernamen und ein Passwort
402 Zahlung erforderlich	Sie können diesen Code noch nicht verwenden
403 Verboten	Der Zugriff auf die angeforderte Seite ist verboten
404 Nicht gefunden	Der Server kann die angeforderte Seite nicht finden
405 Methode nicht zulässig	Die in der Anfrage angegebene Methode ist nicht zulässig
406 Nicht akzeptabel	Der Server kann nur eine Antwort generieren, die vom Client nicht akzeptiert wird
407 Proxy-Authentifizierung erforderlich	Sie müssen sich bei einem Proxyserver authentifizieren, bevor diese Anforderung bearbeitet werden kann
408 Anfrage timeout	Die Anfrage dauerte länger als der Server bereit war zu warten
409 Konflikt	Die Anforderung konnte aufgrund eines Konflikts nicht abgeschlossen werden
410 weg	Die angeforderte Seite ist nicht mehr verfügbar
411 Länge erforderlich	Die "Inhaltslänge" ist nicht definiert. Der Server akzeptiert die Anfrage ohne sie nicht
412 Voraussetzung fehlgeschlagen	Die in der Anforderung angegebene Voraussetzung wird vom Server als falsch bewertet
413 Anforderungsentität zu groß	Der Server akzeptiert die Anforderung nicht, da die Anforderungsentität zu groß ist
414 Request-URL zu lang	Der Server akzeptiert die Anforderung nicht, da die URL zu lang ist. Tritt auf, wenn Sie eine "Post" -Anforderung in eine "Get" -Anforderung mit langen Abfrageinformationen konvertieren
415 Nicht unterstützter Medientyp	Der Server akzeptiert die Anforderung nicht, da der Medientyp nicht unterstützt wird
416 Angeforderter Bereich nicht erfüllbar	Der angeforderte Bytebereich ist nicht verfügbar und liegt außerhalb der Grenzen.
417 Erwartung fehlgeschlagen	Die in einem Expect-Anforderungsheaderfeld angegebene Erwartung konnte von diesem Server nicht erfüllt werden.

5xx: Serverfehler

Botschaft:	Beschreibung:
500 Interner Serverfehler	Die Anfrage wurde nicht abgeschlossen. Der Server hat eine unerwartete Bedingung erfüllt
501 Nicht implementiert	Die Anfrage wurde nicht abgeschlossen. Der Server hat die erforderliche Funktionalität nicht unterstützt
502 Bad Gateway	Die Anfrage wurde nicht abgeschlossen. Der Server hat eine ungültige Antwort vom Upstream-Server erhalten
503 Dienst nicht verfügbar	Die Anfrage wurde nicht abgeschlossen. Der Server ist vorübergehend überlastet oder ausgefallen
504 Gateway-Zeitüberschreitung	Das Gateway hat eine Zeitüberschreitung
505 HTTP-Version wird nicht unterstützt	Der Server unterstützt die Version "http protocol" nicht

HTTP-Deader-Felder enthalten die erforderlichen Informationen zur Anforderung oder Antwort oder zum im Nachrichtentext gesendeten Objekt. Es gibt folgende vier Arten von HTTP-Nachrichtenkopfzeilen:

• General-header: Diese Headerfelder sind allgemein für Anforderungs- und Antwortnachrichten anwendbar.

• Client Request-header: Diese Headerfelder sind nur für Anforderungsnachrichten anwendbar.

• Server Response-header: Diese Headerfelder sind nur für Antwortnachrichten anwendbar.

• Entity-header: Diese Header-Felder definieren Metainformationen über den Entity-Body oder, falls kein Body vorhanden ist

Allgemeine Überschriften

Cache-Kontrolle

Das Feld Cache-Control General-Header wird verwendet, um Anweisungen anzugeben, die von allen Caching-Systemen befolgt werden MÜSSEN. Es folgt die Syntax:

Cache-Control : cache-request-directive|cache-response-directive

Ein HTTP-Client oder -Server kann das verwenden Cache-controlAllgemeiner Header zum Angeben von Parametern für den Cache oder zum Anfordern bestimmter Arten von Dokumenten aus dem Cache. Die Caching-Anweisungen werden in einer durch Kommas getrennten Liste angegeben. Zum Beispiel:

Cache-control: no-cache

Es gibt folgende wichtige Cache-Anforderungsanweisungen, die vom Client in seiner HTTP-Anforderung verwendet werden können:

SN	Cache-Anforderungsrichtlinie und Beschreibung
1	no-cache Ein Cache darf die Antwort nicht verwenden, um eine nachfolgende Anforderung ohne erfolgreiche erneute Validierung mit dem Ursprungsserver zu erfüllen.
2	no-store Der Cache sollte nichts über die Clientanforderung oder die Serverantwort speichern.
3	max-age = seconds Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Alter die angegebene Zeit in Sekunden nicht überschreitet.
4	max-stale [ = seconds ] Zeigt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Ablaufzeit überschritten wurde. Wenn Sekunden angegeben werden, darf diese nicht länger als diese Zeit abgelaufen sein.
5	min-fresh = seconds Zeigt an, dass der Kunde bereit ist, eine Antwort zu akzeptieren, deren Frische-Lebensdauer nicht unter dem aktuellen Alter zuzüglich der angegebenen Zeit in Sekunden liegt.
6	no-transform Konvertieren Sie den Entity-Body nicht.
7	only-if-cached Rufen Sie keine neuen Daten ab. Der Cache kann ein Dokument nur senden, wenn es sich im Cache befindet, und sollte sich nicht an den Ursprungsserver wenden, um festzustellen, ob eine neuere Kopie vorhanden ist.

Es gibt folgende wichtige Cache-Antwortanweisungen, die vom Server in seiner HTTP-Antwort verwendet werden können:

SN	Cache-Anforderungsrichtlinie und Beschreibung
1	public Gibt an, dass die Antwort von einem beliebigen Cache zwischengespeichert werden kann.
2	private Gibt an, dass die gesamte oder ein Teil der Antwortnachricht für einen einzelnen Benutzer bestimmt ist und nicht von einem gemeinsam genutzten Cache zwischengespeichert werden darf.
3	no-cache Ein Cache darf die Antwort nicht verwenden, um eine nachfolgende Anforderung ohne erfolgreiche erneute Validierung mit dem Ursprungsserver zu erfüllen.
4	no-store Der Cache sollte nichts über die Clientanforderung oder die Serverantwort speichern.
5	no-transform Konvertieren Sie den Entity-Body nicht.
6	must-revalidate Der Cache muss den Status veralteter Dokumente überprüfen, bevor er verwendet wird. Abgelaufene Dokumente sollten nicht verwendet werden.
7	proxy-revalidate Die Proxy-Revalidate-Direktive hat dieselbe Bedeutung wie die Must-Revalidate-Direktive, außer dass sie nicht für nicht gemeinsam genutzte Benutzeragenten-Caches gilt.
8	max-age = seconds Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Alter die angegebene Zeit in Sekunden nicht überschreitet.
9	s-maxage = seconds Das in dieser Direktive angegebene Höchstalter überschreibt das in der Direktive für das Höchstalter oder im Expires-Header angegebene Höchstalter. Die s-maxage-Direktive wird von einem privaten Cache immer ignoriert.

Verbindung

Im Feld Connection General-Header kann der Absender Optionen angeben, die für diese bestimmte Verbindung gewünscht werden und nicht von Proxys über weitere Verbindungen kommuniziert werden dürfen. Es folgt die einfache Syntax für die Verwendung des Verbindungsheaders:

Connection : "Connection"

HTTP / 1.1 definiert die Verbindungsoption "geschlossen", mit der der Absender signalisiert, dass die Verbindung nach Abschluss der Antwort geschlossen wird. Zum Beispiel:

Connection: Closed

Standardmäßig verwendet HTTP 1.1 dauerhafte Verbindungen, bei denen die Verbindung nach einer Transaktion nicht automatisch geschlossen wird. HTTP 1.0 hingegen verfügt standardmäßig nicht über dauerhafte Verbindungen. Wenn ein 1.0-Client dauerhafte Verbindungen verwenden möchte, verwendet er diekeep-alive Parameter wie folgt:

Connection: keep-alive

Datum

Alle HTTP-Datums- / Zeitstempel MÜSSEN ausnahmslos in Greenwich Mean Time (GMT) dargestellt werden. HTTP-Anwendungen dürfen eine der folgenden drei Darstellungen von Datums- / Zeitstempeln verwenden:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Hier ist das erste Format das am meisten bevorzugte.

Pragma

Das Pragma-Feld für den allgemeinen Header wird verwendet, um implementierungsspezifische Anweisungen einzuschließen, die für jeden Empfänger entlang der Anforderungs- / Antwortkette gelten können. Zum Beispiel:

Pragma: no-cache

Die einzige in HTTP / 1.0 definierte Direktive ist die No-Cache-Direktive und wird aus Gründen der Abwärtskompatibilität in HTTP 1.1 verwaltet. In Zukunft werden keine neuen Pragma-Richtlinien definiert.

Anhänger

Der allgemeine Feldwert des Trailers gibt an, dass der angegebene Satz von Headerfeldern im Trailer einer Nachricht vorhanden ist, die mit einer Chunked-Transfer-Codierung codiert ist. Es folgt die Syntax des Trailer-Header-Felds:

Trailer : field-name

Nachrichtenkopfzeilenfelder, die im Trailer-Kopfzeilenfeld aufgeführt sind, dürfen die folgenden Kopfzeilenfelder nicht enthalten:

• Transfer-Encoding

• Content-Length

• Trailer

Transfer-Codierung

Das Feld " Transfer-Encoding General-Header" gibt an, welche Art von Transformation auf den Nachrichtentext angewendet wurde, um ihn sicher zwischen dem Absender und dem Empfänger zu übertragen. Dies ist nicht dasselbe wie die Inhaltscodierung, da Übertragungscodierungen eine Eigenschaft der Nachricht und nicht des Entitätskörpers sind. Es folgt die Syntax des Headerfelds "Transfer-Encoding":

Transfer-Encoding: chunked

Bei allen Übertragungscodierungswerten wird die Groß- und Kleinschreibung nicht berücksichtigt.

Aktualisierung

Mit dem Upgrade- General-Header kann der Client angeben, welche zusätzlichen Kommunikationsprotokolle er unterstützt und verwenden möchte, wenn der Server es für geeignet hält, Protokolle zu wechseln. Zum Beispiel:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Das Feld Upgrade-Header soll einen einfachen Mechanismus für den Übergang von HTTP / 1.1 zu einem anderen inkompatiblen Protokoll bereitstellen

Über

Der Via- General-Header muss von Gateways und Proxys verwendet werden, um die Zwischenprotokolle und Empfänger anzugeben. Beispielsweise könnte eine Anforderungsnachricht von einem HTTP / 1.0-Benutzeragenten an einen internen Proxy mit dem Codenamen "fred" gesendet werden, der HTTP / 1.1 verwendet, um die Anforderung an einen öffentlichen Proxy unter nirgendwo.com weiterzuleiten, der die Anforderung von abschließt Weiterleitung an den Ursprungsserver unter www.ics.uci.edu. Die von www.ics.uci.edu empfangene Anfrage hätte dann das folgende Via-Header-Feld:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Das Feld Upgrade-Header soll einen einfachen Mechanismus für den Übergang von HTTP / 1.1 zu einem anderen inkompatiblen Protokoll bereitstellen

Warnung

Der allgemeine Header " Warnung" wird verwendet, um zusätzliche Informationen zum Status oder zur Umwandlung einer Nachricht zu enthalten, die möglicherweise nicht in der Nachricht enthalten sind. Eine Antwort kann mehr als einen Warnheader enthalten.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Client-Anforderungsheader

Akzeptieren

Das Feld Anforderungsheader akzeptieren kann verwendet werden, um bestimmte Medientypen anzugeben, die für die Antwort akzeptabel sind. Es folgt die allgemeine Syntax:

Accept: type/subtype [q=qvalue]

Mehrere Medientypen können durch Kommas getrennt aufgelistet werden. Der optionale q-Wert stellt eine akzeptable Qualitätsstufe für Akzeptiertypen auf einer Skala von 0 bis 1 dar. Es folgt ein Beispiel:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Dies würde interpretiert werden als text/html und text/x-c sind die bevorzugten Medientypen, aber wenn sie nicht vorhanden sind, senden Sie die text/x-dvi Entität, und wenn das nicht existiert, senden Sie die text/plain Entität.

Accept-Charset

Das Feld Accept-Charset Request-Header kann verwendet werden, um anzugeben, welche Zeichensätze für die Antwort akzeptabel sind. Es folgt die allgemeine Syntax:

Accept-Charset: character_set [q=qvalue]

Mehrere Zeichensätze können durch Kommas getrennt aufgelistet werden. Der optionale q-Wert stellt eine akzeptable Qualitätsstufe für nicht bevorzugte Zeichensätze auf einer Skala von 0 bis 1 dar. Es folgt ein Beispiel:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

Der spezielle Wert "*", falls vorhanden in der Accept-Charset Feld, entspricht jedem Zeichensatz und wenn nein Accept-Charset Wenn der Header vorhanden ist, ist standardmäßig jeder Zeichensatz akzeptabel.

Accept-Encoding

Das Feld Accept-Encoding Request-Header ähnelt Accept, schränkt jedoch die in der Antwort akzeptablen Inhaltscodierungen ein. Es folgt die allgemeine Syntax:

Accept-Encoding: encoding types

Es folgen Beispiele:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Akzeptiere-Sprache

Das Feld Accept-Language Request-Header ähnelt Accept, schränkt jedoch den Satz natürlicher Sprachen ein, die als Antwort auf die Anfrage bevorzugt werden. Es folgt die allgemeine Syntax:

Accept-Language: language [q=qvalue]

Mehrere Sprachen können durch Kommas getrennt aufgelistet werden. Der optionale q-Wert stellt eine akzeptable Qualitätsstufe für nicht bevorzugte Sprachen auf einer Skala von 0 bis 1 dar. Es folgt ein Beispiel:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Genehmigung

Der Feldwert für den Autorisierungsanforderungsheader besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen des Benutzeragenten für den Bereich der angeforderten Ressource enthalten. Es folgt die allgemeine Syntax:

Authorization : credentials

Die HTTP / 1.0-Spezifikation definiert das BASIC-Autorisierungsschema, wobei der Autorisierungsparameter die Zeichenfolge von ist username:password in Basis 64 codiert. Es folgt ein Beispiel:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

Der Wert dekodiert in is guest:guest123 wo guest ist Benutzer-ID und guest123 ist das Passwort.

Plätzchen

Der Feldwert für den Cookie- Anforderungsheader enthält ein Name / Wert-Informationspaar, das für diese URL gespeichert ist. Es folgt die allgemeine Syntax:

Cookie: name=value

Mehrere Cookies können wie folgt durch Semikolons getrennt angegeben werden:

Cookie: name1=value1;name2=value2;name3=value3

Erwarten von

Das Feld Expect Request-Header wird verwendet, um anzugeben, dass der Client bestimmte Serververhaltensweisen benötigt. Es folgt die allgemeine Syntax:

Expect : 100-continue | expectation-extension

Wenn ein Server eine Anforderung erhält, die ein Expect-Feld enthält, das eine nicht unterstützte Expectation-Erweiterung enthält, muss er mit dem Status 417 (Expectation Failed) antworten.

Von

Das Feld Von Anforderungsheader enthält eine Internet-E-Mail-Adresse für den menschlichen Benutzer, der den anfordernden Benutzeragenten steuert. Das Folgende ist ein einfaches Beispiel:

From: [email protected]

Dieses Headerfeld kann zu Protokollierungszwecken und als Mittel zum Identifizieren der Quelle ungültiger oder unerwünschter Anforderungen verwendet werden.

Gastgeber

Das Feld Host- Anforderungsheader wird verwendet, um den Internet-Host und die Portnummer der angeforderten Ressource anzugeben. Es folgt die allgemeine Syntax:

Host : "Host" ":" host [ ":" port ] ;

EIN hostOhne nachfolgende Portinformationen wird der Standardport 80 angegeben. Eine Anforderung auf dem Ursprungsserver für http://www.w3.org/pub/WWW/ lautet beispielsweise :

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

Das If-Match- Anforderungsheaderfeld wird mit einer Methode verwendet, um es bedingt zu machen. Dieser Header fordert den Server auf, die angeforderte Methode nur auszuführen, wenn der angegebene Wert in diesem Tag mit den angegebenen Entitäts-Tags übereinstimmt, die durch dargestellt werdenETag. Es folgt die allgemeine Syntax:

If-Match : entity-tag

Ein Sternchen (*) entspricht einer Entität, und die Transaktion wird nur fortgesetzt, wenn die Entität vorhanden ist. Folgende Beispiele sind möglich:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Wenn keines der Entitäts-Tags übereinstimmt oder wenn "*" angegeben ist und keine aktuelle Entität vorhanden ist, darf der Server die angeforderte Methode nicht ausführen und muss eine 412-Antwort (Voraussetzung fehlgeschlagen) zurückgeben.

If-Modified-Since

Das Feld If-Modified-Since- Anforderungsheader wird mit einer Methode verwendet, um es bedingt zu machen. Wenn die angeforderte URL seit der in diesem Feld angegebenen Zeit nicht geändert wurde, wird keine Entität vom Server zurückgegeben. Stattdessen wird eine 304-Antwort (nicht geändert) ohne Nachrichtentext zurückgegeben. Es folgt die allgemeine Syntax:

If-Modified-Since : HTTP-date

Ein Beispiel für das Feld ist:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Wenn keines der Entitäts-Tags übereinstimmt oder wenn "*" angegeben ist und keine aktuelle Entität vorhanden ist, darf der Server die angeforderte Methode nicht ausführen und muss eine 412-Antwort (Voraussetzung fehlgeschlagen) zurückgeben.

Wenn-keine-Übereinstimmung

Das Feld If-None-Match- Anforderungsheader wird mit einer Methode verwendet, um es bedingt zu machen. Dieser Header fordert den Server auf, die angeforderte Methode nur auszuführen, wenn einer der angegebenen Werte in diesem Tag mit den angegebenen Entitäts-Tags übereinstimmt, die durch dargestellt werdenETag. Es folgt die allgemeine Syntax:

If-None-Match : entity-tag

Ein Sternchen (*) entspricht einer Entität, und die Transaktion wird nur fortgesetzt, wenn die Entität nicht vorhanden ist. Folgende Beispiele sind möglich:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

Das If-Range- Anforderungsheaderfeld kann mit einem bedingten GET verwendet werden, um nur den Teil der Entität anzufordern, der fehlt, wenn er nicht geändert wurde, und die gesamte Entität, wenn er geändert wurde. Es folgt die allgemeine Syntax:

If-Range : entity-tag | HTTP-date

Entweder ein Entitäts-Tag oder ein Datum kann verwendet werden, um die bereits empfangene Teilentität zu identifizieren. Zum Beispiel:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Wenn das Dokument seit dem angegebenen Datum nicht mehr geändert wurde, gibt der Server den im Bereichskopf angegebenen Bytebereich zurück. Andernfalls wird das gesamte neue Dokument zurückgegeben.

If-Unmodified-Since

Das Feld If-Unmodified-Since- Anforderungsheader wird mit einer Methode verwendet, um es bedingt zu machen. Es folgt die allgemeine Syntax:

If-Unmodified-Since : HTTP-date

Wenn die angeforderte Ressource seit der in diesem Feld angegebenen Zeit nicht geändert wurde, sollte der Server den angeforderten Vorgang so ausführen, als ob der Header If-Unmodified-Since nicht vorhanden wäre. Zum Beispiel:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Wenn die Anforderung normalerweise zu einem anderen Status als 2xx oder 412 führen würde, sollte der Header If-Unmodified-Since ignoriert werden.

Max-Forwards

Das Feld Max-Forwards- Anforderungsheader bietet einen Mechanismus mit den Methoden TRACE und OPTIONS, um die Anzahl der Proxys oder Gateways zu begrenzen, die die Anforderung an den nächsten eingehenden Server weiterleiten können. Es folgt die allgemeine Syntax:

Max-Forwards : n

Der Max-Forwards-Wert ist eine Dezimalzahl, die angibt, wie oft diese Anforderungsnachricht noch weitergeleitet werden kann. Dies ist nützlich zum Debuggen mit der TRACE-Methode, um Endlosschleifen zu vermeiden. Zum Beispiel:

Max-Forwards : 5

Das Max-Forwards-Headerfeld kann für alle anderen in der HTTP-Spezifikation definierten Methoden ignoriert werden.

Proxy-Autorisierung

Das Feld Proxy-Authorization Request-Header ermöglicht es dem Client, sich (oder seinen Benutzer) gegenüber einem Proxy zu identifizieren, für den eine Authentifizierung erforderlich ist. Es folgt die allgemeine Syntax:

Proxy-Authorization : credentials

Der Feldwert für die Proxy-Autorisierung besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen des Benutzeragenten für den Proxy und / oder den Bereich der angeforderten Ressource enthalten.

Angebot

Das Feld Range Request-Header gibt die Teilbereiche des vom Dokument angeforderten Inhalts an. Es folgt die allgemeine Syntax:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

Der First-Byte-Pos-Wert in einer Byte-Range-Spezifikation gibt den Byte-Offset des ersten Bytes in einem Bereich an. Der Wert für das letzte Byte-Pos gibt den Byte-Offset des letzten Bytes im Bereich an. Das heißt, die angegebenen Bytepositionen sind inklusive. Sie können eine Byteeinheit als Byte angeben. Byte-Offsets beginnen bei Null. Es folgen einfache Beispiele:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Es können mehrere Bereiche aufgelistet werden, die durch Kommas getrennt sind. Wenn die erste Ziffer in den durch Kommas getrennten Bytebereichen fehlt, wird davon ausgegangen, dass der Bereich ab dem Ende des Dokuments zählt. Wenn die zweite Ziffer fehlt, ist der Bereich Byte n bis zum Ende des Dokuments.

Referer

Im Feld Referer- Anforderungsheader kann der Client die Adresse (URI) der Ressource angeben, von der die URL angefordert wurde. Es folgt die allgemeine Syntax:

Referer : absoluteURI | relativeURI

Das Folgende ist ein einfaches Beispiel:

Referer: http://www.tutorialspoint.org/http/index.htm

Wenn der Feldwert ein relativer URI ist, sollte er relativ zum Request-URI interpretiert werden .

TE

Das TE - Anfrage-Header - Feld gibt an, welche Erweiterung Transfer-Codierung sie bereit ist , in der Antwort zu akzeptieren oder nicht und ob sie bereit ist , Anhänger Felder in einem chunked zu akzeptieren Transfer-Codierung . Es folgt die allgemeine Syntax:

TE   : t-codings

Das Vorhandensein des Schlüsselworts "Trailer" zeigt an, dass der Client bereit ist, Trailerfelder in einer Chunked-Transfer-Codierung zu akzeptieren, und es wird eine der folgenden Möglichkeiten angegeben:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Wenn der TE - Feldwert leer ist oder wenn kein TE Feld vorhanden ist, ist die einzige Übertragungscodierung wird chunked . Eine Nachricht ohne Übertragungscodierung ist immer akzeptabel.

User-Agent

Das Feld User-Agent- Anforderungsheader enthält Informationen zu dem Benutzeragenten, von dem die Anforderung stammt. Es folgt die allgemeine Syntax:

User-Agent : product | comment

Beispiel:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Server-Antwortheader

Accept-Ranges

Im Feld Antwortheader "Bereiche akzeptieren" kann der Server angeben, dass Bereichsanforderungen für eine Ressource akzeptiert werden. Es folgt die allgemeine Syntax:

Accept-Ranges  : range-unit | none

Beispielsweise kann ein Server senden, der Bytebereichsanforderungen akzeptiert

Accept-Ranges: bytes

Server, die keine Bereichsanforderung für eine Ressource akzeptieren, können Folgendes senden:

Accept-Ranges: none

Dies rät dem Client, keine Bereichsanforderung zu versuchen.

Alter

Das Feld Alter- Antwort-Header gibt die Schätzung des Absenders an, wie lange die Antwort (oder ihre erneute Validierung) auf dem Ursprungsserver generiert wurde. Es folgt die allgemeine Syntax:

Age : delta-seconds

Alterswerte sind nicht negative Dezimalzahlen, die die Zeit in Sekunden darstellen. Das Folgende ist ein einfaches Beispiel:

Age: 1030

Ein HTTP / 1.1-Server, der einen Cache enthält, muss in jeder Antwort, die aus seinem eigenen Cache generiert wird, ein Age-Header-Feld enthalten.

ETag

Das ETag -Antwortheaderfeld gibt den aktuellen Wert des Entitäts-Tags für die angeforderte Variante an. Es folgt die allgemeine Syntax:

ETag :  entity-tag

Es folgen einfache Beispiele:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Ort

Das Feld Standortantwort -Header wird verwendet, um den Empfänger zum Abschluss an einen anderen Standort als den Anforderungs-URI umzuleiten. Es folgt die allgemeine Syntax:

Location : absoluteURI

Das Folgende ist ein einfaches Beispiel:

Location: http://www.tutorialspoint.org/http/index.htm

Das Headerfeld "Content-Location" unterscheidet sich von "Location" darin, dass "Content-Location" den ursprünglichen Speicherort der in der Anforderung enthaltenen Entität angibt.

Proxy-Authentifizierung

Das Feld Proxy-Authenticate -Antwortheader muss als Teil einer 407-Antwort (Proxy-Authentifizierung erforderlich) enthalten sein. Es folgt die allgemeine Syntax:

Proxy-Authenticate  : challenge

Wiederholen nach

Das Feld Retry-After -Antwortheader kann mit einer 503-Antwort (Service nicht verfügbar) verwendet werden, um anzugeben, wie lange der Service für den anfordernden Client voraussichtlich nicht verfügbar sein wird. Es folgt die allgemeine Syntax:

Retry-After : HTTP-date | delta-seconds

Es folgen zwei einfache Beispiele:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

Im letzteren Beispiel beträgt die Verzögerung 2 Minuten.

Server

Das Feld Server -Antwortheader enthält Informationen zu der Software, die vom Ursprungsserver zur Bearbeitung der Anforderung verwendet wird. Es folgt die allgemeine Syntax:

Server : product | comment

Das Folgende ist ein einfaches Beispiel:

Server: Apache/2.2.14 (Win32)

Wenn die Antwort über einen Proxy weitergeleitet wird, darf die Proxy-Anwendung den Server-Antwortheader nicht ändern.

Set-Cookie

Das Feld Set-Cookie -Antwortheader enthält ein Name / Wert-Informationspaar, das für diese URL beibehalten werden soll. Es folgt die allgemeine Syntax:

Set-Cookie: NAME=VALUE; OPTIONS

Der Set-Cookie-Antwortheader enthält das Token Set-Cookie:, gefolgt von einer durch Kommas getrennten Liste eines oder mehrerer Cookies. Hier sind mögliche Werte, die Sie als Optionen angeben können:

SN	Optionen und Beschreibung
1	Comment=comment Mit dieser Option können Sie jeden Kommentar angeben, der dem Cookie zugeordnet ist.
2	Domain=domain Das Domain-Attribut gibt die Domain an, für die das Cookie gültig ist.
3	Expires=Date-time Das Datum, an dem der Cookie abläuft. Wenn dies leer ist, läuft das Cookie ab, wenn der Besucher den Browser verlässt
4	Path=path Das Path-Attribut gibt die Teilmenge der URLs an, für die dieses Cookie gilt.
5	Secure Dies weist den Benutzeragenten an, das Cookie nur unter einer sicheren Verbindung zurückzugeben.

Es folgt ein Beispiel für einen einfachen Cookie-Header, der vom Server generiert wird:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Variieren

Die Vary response-Header - Feld gibt an, dass die Einheit mehrere Quellen aufweist und daher ändern sich je nach festgelegten Liste der Anfrage - Header (s). Es folgt die allgemeine Syntax:

Vary : field-name

Sie können mehrere durch Kommas getrennte Header angeben, und ein Sternchen "*" signalisiert, dass nicht angegebene Parameter nicht auf die Anforderungsheader beschränkt sind. Das Folgende ist ein einfaches Beispiel:

Vary: Accept-Language, Accept-Encoding

Hier wird bei Feldnamen die Groß- und Kleinschreibung nicht berücksichtigt.

WWW-Authentifizierung

Das Feld WWW-Authenticate -Antwortheader muss in 401 (nicht autorisierten) Antwortnachrichten enthalten sein. Der Feldwert besteht aus mindestens einer Abfrage, die die Authentifizierungsschemata und -parameter angibt, die für den Anforderungs-URI gelten. Es folgt die allgemeine Syntax:

WWW-Authenticate : challenge

WWW-Authentifizierungsfeldwert, da er möglicherweise mehr als eine Herausforderung enthält. Wenn mehr als ein WWW-Authentifizierungs-Headerfeld bereitgestellt wird, kann der Inhalt einer Herausforderung selbst eine durch Kommas getrennte Liste von Authentifizierungsparametern enthalten. Das Folgende ist ein einfaches Beispiel:

WWW-Authenticate: BASIC realm="Admin"

Entity-Header

ermöglichen

Das Feld Entity-Header zulassen listet die Methoden auf, die von der durch den Anforderungs-URI angegebenen Ressource unterstützt werden. Es folgt die allgemeine Syntax:

Allow : Method

Sie können mehrere durch Kommas getrennte Methoden angeben. Das Folgende ist ein einfaches Beispiel:

Allow: GET, HEAD, PUT

Dieses Feld kann einen Client nicht daran hindern, andere Methoden auszuprobieren.

Inhaltskodierung

Das Entity-Header-Feld Content-Encoding wird als Modifikator für den Medientyp verwendet. Es folgt die allgemeine Syntax:

Content-Encoding : content-coding

Die Inhaltscodierung ist ein Merkmal der durch die Anforderungs-URI identifizierten Entität. Das Folgende ist ein einfaches Beispiel:

Content-Encoding: gzip

Wenn die Inhaltscodierung einer Entität in einer Anforderungsnachricht für den Ursprungsserver nicht akzeptabel ist, sollte der Server mit dem Statuscode 415 (Nicht unterstützter Medientyp) antworten.

Inhaltssprache

Das Feld Content-Language- Entity-Header beschreibt die natürliche (n) Sprache (n) der Zielgruppe für die eingeschlossene Entität. Es folgt die allgemeine Syntax:

Content-Language : language-tag

Für Inhalte, die für mehrere Zielgruppen bestimmt sind, können mehrere Sprachen aufgelistet werden. Das Folgende ist ein einfaches Beispiel:

Content-Language: mi, en

Der Hauptzweck von Content-Language besteht darin, einem Benutzer zu ermöglichen, Entitäten gemäß der vom Benutzer bevorzugten Sprache zu identifizieren und zu unterscheiden.

Inhaltslänge

Das Feld Content-Length- Entity-Header gibt die Größe des Entity-Body in Dezimalzahl der OCTETs an, die an den Empfänger gesendet wurden, oder im Fall der HEAD-Methode die Größe des Entity-Body, der gesendet worden wäre Die Anfrage war ein GET. Es folgt die allgemeine Syntax:

Content-Length : DIGITS

Das Folgende ist ein einfaches Beispiel:

Content-Length: 3495

Jede Inhaltslänge größer oder gleich Null ist ein gültiger Wert.

Inhaltsverzeichnis

Das Feld Entity-Header Content-Location kann verwendet werden, um den Ressourcenstandort für die in der Nachricht enthaltene Entität anzugeben, wenn auf diese Entität von einem Ort aus zugegriffen werden kann, der vom URI der angeforderten Ressource getrennt ist. Es folgt die allgemeine Syntax:

Content-Location:  absoluteURI | relativeURI

Das Folgende ist ein einfaches Beispiel:

Content-Location: http://www.tutorialspoint.org/http/index.htm

Der Wert von Content-Location definiert auch den Basis-URI für die Entität.

Inhalt-MD5

Das Content-MD5- Entity-Header-Feld kann verwendet werden, um einen MD5-Digest der Entität bereitzustellen und die Integrität der Nachricht beim Empfang zu überprüfen. Es folgt die allgemeine Syntax:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

Das Folgende ist ein einfaches Beispiel:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

Der MD5-Digest wird basierend auf dem Inhalt des Entitätskörpers berechnet, einschließlich der angewendeten Inhaltscodierung, jedoch ohne der auf den Nachrichtentext angewendeten Übertragungscodierung.

Inhaltsbereich

Das Feld Entity-Header für den Inhaltsbereich wird mit einem partiellen Entity-Body gesendet, um anzugeben, wo im vollständigen Entity-Body der partielle Body angewendet werden soll. Es folgt die allgemeine Syntax:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Beispiele für Byte-Inhaltsbereich-Spezifikationswerte unter der Annahme, dass die Entität insgesamt 1234 Bytes enthält:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Wenn eine HTTP-Nachricht den Inhalt eines einzelnen Bereichs enthält, wird dieser Inhalt mit einem Content-Range-Header und einem Content-Length-Header übertragen, der die Anzahl der tatsächlich übertragenen Bytes angibt. Zum Beispiel,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Inhaltstyp

Das Feld Inhaltstyp- Entitätsheader gibt den Medientyp des Entitätskörpers an, der an den Empfänger gesendet wurde, oder im Fall der HEAD-Methode den Medientyp, der gesendet worden wäre, wenn die Anforderung ein GET gewesen wäre. Es folgt die allgemeine Syntax:

Content-Type : media-type

Es folgt ein Beispiel:

Content-Type: text/html; charset=ISO-8859-4

Läuft ab

Das Feld Expires- Entity-Header gibt das Datum und die Uhrzeit an, nach denen die Antwort als veraltet betrachtet wird. Es folgt die allgemeine Syntax:

Expires : HTTP-date

Es folgt ein Beispiel:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Zuletzt geändert

Das Feld Zuletzt geänderter Entitätsheader gibt das Datum und die Uhrzeit an, zu denen der Ursprungsserver glaubt, dass die Variante zuletzt geändert wurde. Es folgt die allgemeine Syntax:

Last-Modified: HTTP-date

Es folgt ein Beispiel:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

HTTP wird normalerweise für verteilte Informationssysteme verwendet, bei denen die Leistung durch die Verwendung von Antwortcaches verbessert werden kann. Das HTTP / 1.1-Protokoll enthält eine Reihe von Elementen, mit denen das Caching funktioniert.

Das Ziel des Caching in HTTP / 1.1 besteht darin, in vielen Fällen das Senden von Anforderungen zu vermeiden und in vielen anderen Fällen das Senden vollständiger Antworten zu vermeiden.

Die grundlegenden Cache-Mechanismen in HTTP / 1.1 sind implizite Anweisungen für Caches, in denen vom Server Ablaufzeiten und Validatoren angegeben werden. Wir nehmen dasCache-Control Header für diesen Zweck.

Das Cache-ControlMit dem Header kann ein Client oder Server eine Vielzahl von Anweisungen in Anforderungen oder Antworten übertragen. Diese Anweisungen überschreiben normalerweise die Standard-Caching-Algorithmen. Die Caching-Anweisungen werden in einer durch Kommas getrennten Liste angegeben. Zum Beispiel:

Cache-control: no-cache

Es gibt folgende wichtige Cache-Anforderungsanweisungen, die vom Client in seiner HTTP-Anforderung verwendet werden können:

SN	Cache-Anforderungsrichtlinie und Beschreibung
1	no-cache Ein Cache darf die Antwort nicht verwenden, um eine nachfolgende Anforderung ohne erfolgreiche erneute Validierung mit dem Ursprungsserver zu erfüllen.
2	no-store Der Cache sollte nichts über die Clientanforderung oder die Serverantwort speichern.
3	max-age = seconds Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Alter die angegebene Zeit in Sekunden nicht überschreitet.
4	max-stale [ = seconds ] Zeigt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Ablaufzeit überschritten wurde. Wenn Sekunden angegeben werden, darf diese nicht länger als diese Zeit abgelaufen sein.
5	min-fresh = seconds Zeigt an, dass der Kunde bereit ist, eine Antwort zu akzeptieren, deren Frische-Lebensdauer nicht unter dem aktuellen Alter zuzüglich der angegebenen Zeit in Sekunden liegt.
6	no-transform Konvertieren Sie den Entity-Body nicht.
7	only-if-cached Rufen Sie keine neuen Daten ab. Der Cache kann ein Dokument nur senden, wenn es sich im Cache befindet, und sollte sich nicht an den Ursprungsserver wenden, um festzustellen, ob eine neuere Kopie vorhanden ist.

Es gibt folgende wichtige Cache-Antwortanweisungen, die vom Server in seiner HTTP-Antwort verwendet werden können:

SN	Cache-Antwortrichtlinie und Beschreibung
1	public Gibt an, dass die Antwort von einem beliebigen Cache zwischengespeichert werden kann.
2	private Gibt an, dass die gesamte oder ein Teil der Antwortnachricht für einen einzelnen Benutzer bestimmt ist und nicht von einem gemeinsam genutzten Cache zwischengespeichert werden darf.
3	no-cache Ein Cache darf die Antwort nicht verwenden, um eine nachfolgende Anforderung ohne erfolgreiche erneute Validierung mit dem Ursprungsserver zu erfüllen.
4	no-store Der Cache sollte nichts über die Clientanforderung oder die Serverantwort speichern.
5	no-transform Konvertieren Sie den Entity-Body nicht.
6	must-revalidate Der Cache muss den Status veralteter Dokumente überprüfen, bevor er verwendet wird. Abgelaufene Dokumente sollten nicht verwendet werden.
7	proxy-revalidate Die Proxy-Revalidate-Direktive hat dieselbe Bedeutung wie die Must-Revalidate-Direktive, außer dass sie nicht für nicht gemeinsam genutzte Benutzeragenten-Caches gilt.
8	max-age = seconds Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Alter die angegebene Zeit in Sekunden nicht überschreitet.
9	s-maxage = seconds Das in dieser Direktive angegebene Höchstalter überschreibt das in der Direktive für das Höchstalter oder im Expires-Header angegebene Höchstalter. Die s-maxage-Direktive wird von einem privaten Cache immer ignoriert.

HTTP-URLs können nur über das Internet mit dem ASCII- Zeichensatz gesendet werden , der häufig Zeichen außerhalb des ASCII-Satzes enthält. Diese unsicheren Zeichen müssen also durch a ersetzt werden% gefolgt von zwei hexadezimalen Ziffern.

Die folgende Tabelle zeigt das ASCII-Symbol des Zeichens und sein gleiches Symbol und schließlich seinen Ersatz, der in der URL verwendet werden kann, bevor er an den Server übergeben wird:

ASCII	Symbol	Ersatz
<32		Codieren Sie mit% xx, wobei xx die hexadezimale Darstellung des Zeichens ist.
32	Raum	+ oder% 20
33	!	% 21
34	""	% 22
35	#	% 23
36	$	% 24
37	%.	% 25
38	&	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	* *	* *
43	+	% 2B
44	,	% 2C
45	- -	- -
46	.	.
47	/.	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	::	% 3A
59	;;	% 3B
60	<	% 3C
61	=	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
65	EIN	EIN
66	B.	B.
67	C.	C.
68	D.	D.
69	E.	E.
70	F.	F.
71	G	G
72	H.	H.
73	ich	ich
74	J.	J.
75	K.	K.
76	L.	L.
77	M.	M.
78	N.	N.
79	Ö	Ö
80	P.	P.
81	Q.	Q.
82	R.	R.
83	S.	S.
84	T.	T.
85	U.	U.
86	V.	V.
87	W.	W.
88	X.	X.
89	Y.	Y.
90	Z.	Z.
91	[	% 5B
92	\.	% 5C
93	]]	% 5D
94	^	% 5E
95	_	_
96	`	% 60
97	ein	ein
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	G	G
104	h	h
105	ich	ich
106	j	j
107	k	k
108	l	l
109	m	m
110	n	n
111	Ö	Ö
112	p	p
113	q	q
114	r	r
115	s	s
116	t	t
117	u	u
118	v	v
119	w	w
120	x	x
121	y	y
122	z	z
123	{	% 7B
124	|	% 7C
125	}}	% 7D
126	~	% 7E
127		% 7F
> 127		Codieren Sie mit% xx, wobei xx die hexadezimale Darstellung des Zeichens ist

HTTP wird für die Kommunikation über das Internet verwendet. Daher sollten Anwendungsentwickler, Informationsanbieter und Benutzer die Sicherheitsbeschränkungen in HTTP / 1.1 kennen. Diese Diskussion enthält keine endgültigen Lösungen für die hier genannten Probleme, enthält jedoch einige Vorschläge zur Reduzierung von Sicherheitsrisiken.

Verlust persönlicher Informationen

HTTP-Clients sind häufig mit großen Mengen persönlicher Informationen wie Name, Standort, E-Mail-Adresse, Kennwörtern, Verschlüsselungsschlüsseln usw. des Benutzers vertraut. Sie sollten daher sehr vorsichtig sein, um ein unbeabsichtigtes Weitergeben dieser Informationen über das HTTP-Protokoll an andere Quellen zu verhindern.

• Alle vertraulichen Informationen sollten verschlüsselt auf der Serverseite gespeichert werden.

• Durch die Offenlegung der spezifischen Softwareversion des Servers wird der Server möglicherweise anfälliger für Angriffe auf Software, von der bekannt ist, dass sie Sicherheitslücken enthält.

• Proxys, die als Portal durch eine Netzwerk-Firewall dienen, sollten besondere Vorsichtsmaßnahmen hinsichtlich der Übertragung von Header-Informationen treffen, die die Hosts hinter der Firewall identifizieren.

• Die im Feld Von gesendeten Informationen können im Widerspruch zu den Datenschutzinteressen des Benutzers oder den Sicherheitsrichtlinien seiner Website stehen. Sie sollten daher nicht übertragen werden, ohne dass der Benutzer den Inhalt des Felds deaktivieren, aktivieren und ändern kann.

• Clients sollten kein Referer-Header-Feld in eine (nicht sichere) HTTP-Anforderung aufnehmen, wenn die verweisende Seite mit einem sicheren Protokoll übertragen wurde.

• Autoren von Diensten, die das HTTP-Protokoll verwenden, sollten keine GET-basierten Formulare für die Übermittlung vertraulicher Daten verwenden, da dies dazu führt, dass diese Daten im Request-URI codiert werden

Angriff auf Datei- und Pfadnamen

Das Dokument sollte auf die von HTTP-Anforderungen zurückgegebenen Dokumente beschränkt sein, um nur diejenigen zu sein, die von den Serveradministratoren beabsichtigt wurden.

Beispielsweise werden UNIX, Microsoft Windows und andere Betriebssysteme verwendet ..als Pfadkomponente zur Angabe einer Verzeichnisebene über der aktuellen. Auf einem solchen System MUSS ein HTTP-Server ein solches Konstrukt im Request-URI nicht zulassen, wenn es andernfalls den Zugriff auf eine Ressource außerhalb derjenigen ermöglichen würde, auf die über den HTTP-Server zugegriffen werden soll.

DNS-Spoofing

Clients, die HTTP verwenden, verlassen sich stark auf den Domain Name Service und sind daher im Allgemeinen anfällig für Sicherheitsangriffe, die auf der absichtlichen falschen Zuordnung von IP-Adressen und DNS-Namen beruhen. Daher müssen Clients vorsichtig sein, wenn sie davon ausgehen, dass eine IP-Nummer / DNS-Namenszuordnung weiterhin gültig ist.

Wenn HTTP-Clients die Ergebnisse der Suche nach Hostnamen zwischenspeichern, um eine Leistungsverbesserung zu erzielen, müssen sie die von DNS gemeldeten TTL-Informationen beachten. Wenn HTTP-Clients diese Regel nicht einhalten, können sie gefälscht werden, wenn sich die IP-Adresse eines Servers, auf den zuvor zugegriffen wurde, ändert.

Standort-Header und Spoofing

Wenn ein einzelner Server mehrere Organisationen unterstützt, die sich nicht vertrauen, MUSS er die Werte der Speicherort- und Inhaltsstandort-Header in Antworten überprüfen, die unter der Kontrolle dieser Organisationen generiert werden, um sicherzustellen, dass sie nicht versuchen, Ressourcen ungültig zu machen, über die Sie haben keine Autorität.

Anmeldeinformationen für die Authentifizierung

Bestehende HTTP-Clients und Benutzeragenten behalten Authentifizierungsinformationen normalerweise auf unbestimmte Zeit bei. HTTP / 1.1. bietet keine Methode für einen Server, um Clients anzuweisen, diese zwischengespeicherten Anmeldeinformationen zu verwerfen, was ein großes Sicherheitsrisiko darstellt.

Es gibt eine Reihe von Problemumgehungen für Teile dieses Problems. Daher wird empfohlen, den Kennwortschutz in Bildschirmschonern, Leerlaufzeitüberschreitungen und anderen Methoden zu verwenden, um die mit diesem Problem verbundenen Sicherheitsprobleme zu verringern.

Proxies und Caching

HTTP-Proxys sind Männer in der Mitte und bieten die Möglichkeit für Angriffe in der Mitte. Proxies haben Zugriff auf sicherheitsrelevante Informationen, persönliche Informationen zu einzelnen Benutzern und Organisationen sowie proprietäre Informationen von Benutzern und Inhaltsanbietern.

Proxy-Betreiber sollten die Systeme, auf denen Proxys ausgeführt werden, so schützen, wie sie jedes System schützen würden, das vertrauliche Informationen enthält oder transportiert.

Caching-Proxys bieten zusätzliche potenzielle Sicherheitslücken, da der Inhalt des Caches ein attraktives Ziel für die böswillige Ausnutzung darstellt. Daher sollten Cache-Inhalte als vertrauliche Informationen geschützt werden.

Beispiel 1

HTTP-Anforderung zum Abrufen hello.htmSeite vom Webserver, der auf tutorialspoint.com ausgeführt wird

Kundenanfrage

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Serverantwort

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Beispiel 2

HTTP-Anforderung zum Abrufen t.htmlSeite, die auf dem Webserver, der auf tutorialspoint.com ausgeführt wird, nicht vorhanden ist

Kundenanfrage

GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Serverantwort

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Beispiel 3

HTTP-Anforderung zum Abrufen hello.htmSeite vom Webserver, der auf tutorialspoint.com ausgeführt wird , aber die Anfrage geht mit einer falschen HTTP-Version einher:

Kundenanfrage

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Serverantwort

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Beispiel 4

HTTP-Anforderung zum Senden von Formulardaten an process.cgiCGI-Seite auf einem Webserver, der auf tutorialspoint.com ausgeführt wird . Der Server gibt den übergebenen Namen zurück, nachdem er als Cookies festgelegt wurde:

Kundenanfrage

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

Serverantwort

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=tutorialspoint.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>