Das im WWW verwendete Protokoll HTTP ist
speziell für kurze Antwortzeiten bei der Referenzierung
verteilter Objekte entwickelt worden und sieht eine große Anzahl
von Möglichkeiten vor, die heutige WWW-Clients und -Server noch
nicht unterstützen.
Dabei ist der Ablauf einer HTTP-Operation sehr einfach:
Der Client, der ein Dokument vom Server haben möchte, baut eine
TCP-Verbindung zu diesem Server auf und schickt ihm eine Anfrage
(Request). Der Server reagiert mit dem Abschicken einer Antwort (Response)
an den Client und beendet danach die Verbindung. Die Verwendung
von Inline-Graphiken innerhalb eines HTML-Dokuments ist dagegen
etwas komplizierter. Wird eine solche HTML-Seite vom Server
angefordert, so wird der HTML-Quelltext an den Client übertragen.
Dieser entdeckt daraufhin das Vorhandensein von Inline-Graphiken
und fordert diese zusätzlich vom Server an (erneuter Request).
Wie eben schon erwähnt, ist das Request-Format von HTTP sehr einfach. In der ersten Zeile gibt der Client an, welche Protokoll-Version er spricht (aktuell ist HTTP/1.0), um welches Dokument es geht und mit welcher Methode dieses Dokument zu behandeln ist. Die am häufigsten benutzte Methode ist GET, welche den Server veranlaßt, dem Client eine Kopie des Dokuments zu schicken. Weitere Methoden sind POST und PUT. Mit der Methode PUT kann der Client im angegebenen Dokument Änderungen veranlassen. Mit der Methode POST wird der Server veranlaßt, ein neues Dokument zu erzeugen, das dem im Request angegebenen Dokument untergeordnet ist. Der Server gibt dann den URL des erzeugten Dokuments an den Client zurück. Die Verbindung zwischen über- und untergeordnetem Dokument wird dadurch charakterisiert, daß POST diese Metainformation in den Header des übergeordneten Dokuments einträgt - und zwar als <LINK>-Tag im <HEAD>-Element. Ein entsprechender Link in die Gegenrichtung gehört in den Header des untergeordneten Dokuments. Eine beispielhafte Anwendung wäre das Hinzufügen des untergeordneten Objekts 'Kapitel' zum übergeordneten Objekt 'Buch' mittels der POST-Methode und das anschließende Verändern der Objekte durch die PUT-Methode. Da die Link-Eintragungen im Header nicht im Dokument erscheinen (z.B. als Hypertextlinks) sollte ein Browser diese Beziehungen zwischen den Dokumenten in geeigneter Weise anzeigen, um den Benutzern die Navigation im Hyperspace zu erleichtern. Mit Hilfe der Methode LINK kann der schreibberechtigte Benutzer weitere Metainformationen in den Header eintragen oder sie mit UNLINK wieder löschen. Beispiele für diese Metainformationen wären Hinweise auf den Autor, auf neue oder ältere Versionen des Dokuments oder Informationen, die die (Baum-) Struktur der vorhandenen Hypertextdokumente wiederspiegeln. Der Serverbetreiber kann einem Benutzer das Recht auf Änderung der Metainformationen einräumen, ohne ihm gleichzeitig den Schreibzugriff auf den Dokumentinhalt zu gestatten. Der Benutzer kann nun LINK oder gegebenenfalls UNLINK verwenden, nicht aber die Dokumente mittels PUT verändern. Mit der Methode HEAD schließlich kann ein Client Informationen über ein Dokument anfordern, ohne die Datei selbst übertragen zu müssen. Ebenso wie eine Neueintragung durch POST und eine Änderung durch PUT muß dann auch noch ein DELETE möglich sein. Damit wären dann alle im HTTP-Protokoll spezifizierten REQUEST-Methoden aufgeführt. Allerdings ist diese Methoden-Vielfalt nur auf dem Papier vorhanden, denn bisher gibt es keine einzige implementierte HTTP-Version, die alle Methoden unterstützt. Die einzige, bisher implementierte Request-Methode ist GET.
Nach dieser ersten Zeile (des Request-Formats
von HTTP) teilt der Client (ab HTTP 1.0) dem Server optional
weitere Informationen in Form von Headern nach RFC822 , dem
Standard für Electronic Mail, mit. Die am häufigsten
verwendeten Header sind 'Accept' und 'User-Agent'. Im User-Agent-Header
steht der Name des verwendeten WWW-Clients. Besonders wichtig ist
der Accept-Header. Dieser teilt dem Server mit, welche Objekt-Typen
der Client verarbeiten kann. Dies geschieht in Form einer Liste
von MIME-Content-Types, die den Server darüber informiert, mit
welchen Datenformaten der Client etwas anfangen kann. Wenn der
Client beispielsweise ein Dokument anfordert, das dem Server
sowohl als PostScript-, als auch als ASCII-Datei vorliegt, dann
weiß er anhand der Accept-Liste 'Accept: text/plain; text/html',
daß der Client mit der PostScript-Version nichts anfangen kann
und schickt ihm die ASCII-Version (text/plain). Hätte der Client
zusätzlich noch den Content-Type 'applikation /postscript' im
Accept-Header gehabt, dann könnte der Server selbst entscheiden,
welche Version er dem Client zuschickt. Da zu jedem Datenformat
spezifiziert ist, wie gut sich dieses zur Darstellung eignet,
kann der Server in diesem Fall das Format liefern, welches er
selbst für das qualitativ bessere hält.
Künftige Server werden darüber hinaus in der Lage sein, in
diese Bewertung mit einzubeziehen, wie der Client selbst die
Qualität der verschiedenen Formate einschätzt und welche
Kompromisse er hinsichtlich Übertragungsdauer und volumen zu
machen bereit ist. Die Content-Types text/plain und text/html
sind die Mindestanforderungen, die jeder Server und jeder Client
unterstützen muß.
Weitere Informationen, die der Client im Request-Header übermitteln kann, sind der Name des Benutzers in Form einer Mail-Adresse, der URL des Dokumentes, das sich auf den angeforderten URL bezieht, und Autorisierungsdaten. Am Ende der Header-Liste folgt schließlich noch eine Leerzeile. Bei Requests mit den Methoden PUT oder POST folgen im Anschluß daran, im Request-Body, noch die eigentlichen Nutzdaten.
Im folgenden wird noch einmal kurz die
Syntax des Requests dargestellt.
Die Angabe <crlf> soll verdeutlichen, daß im HTTP-Protokoll
an dieser Stelle zwingend ein Zeilenende stehen muß (‘carriage-return’
und ‘line-feed’). Die Schreibweise {...}* soll eine
beliebig zu wiederholende Folge symbolisieren (0 bis unendlich):
<METHOD> <URL> "HTTP/1.0" <crlf>
{<Header>: <Value> <crlf>}*
<crlf<
<Body>
Ein Beispiel:
GET /index.html HTTP/1.0
Accept: text/plain
Accept: text/html
Accept: */*
User-Agent: NCSA Mosaic 2.4
Genau wie das Request-Format ist auch das
Response-Format sehr einfach gehalten. Die Antwort des Servers
auf einen Request beginnt immer mit einer Statuszeile. In dieser
Statuszeile steht die HTTP-Version, die der Server versteht,
gefolgt von einem Status-Code, der über Erfolg bzw. Mißerfolg
des Requests Auskunft gibt. Nach dem Fehler-Code steht optional
ein erläuternder Text wie z.B. 'OK', 'nicht autorisierter
Zugriff' oder 'nicht gefunden'. Unter Umständen kann dort aber
auch ein weiterer URL vermerkt sein, der das gewünschte Dokument
referenziert. Der Client kann in diesem Fall den Zugriff auf die
neue Adresse unmittelbar ausführen, ohne den Benutzer mit einer
Fehlermeldung zu schockieren.
Im Anschluß an diese Statuszeile folgt dann wieder eine Header-Liste
im Mail-Stil nach RFC822. Die Header-Liste wird beendet durch
eine Leerzeile. Anschließend folgen dann im Response-Body die
eigentlich zu übertragenden Daten. Die wichtigsten Header beim
Response sind die MIME-Header ‘Content-Type’ und ‘Content-Length’.
Content-Type informiert den Client über den Typ der vom Server
gelieferten Daten. Content-Length gibt die Größe des
gelieferten Objekts an. Weitere Header informieren den Client über
den Namen des implementierten Servers, die verwendete MIME-Version,
das Datum der Erstellung und der letzten Änderung, Version,
Sprache, Kosten, Metainformationen aus dem
-Teil des HTML-Dokuments und so weiter. Der Expires-Header liefert darüber hinaus dem Client einen Hinweis, ab welchem Zeitpunkt er die Information als veraltet betrachten darf und gegebenenfalls erneut vom Server anfordern sollte. Zwar sind beim Response alle Header optional und haben im Normalfall (Anfrage nach einem vorhandenen HTML-Dokument) keinen Einfluß auf die Übertragung der Informationen, in einigen Fällen können aber für den Empfänger wichtige Daten auch in den HTTP-Headern stehen. So steht im Header z.B. der MIME-Content-Type der folgenden Daten, und auf einen HEAD-Request antwortet der Server lediglich mit der Übertragung der Header-Liste und den Metainformationen, die im HEAD-Teil des HTML-Dokuments stehen, ohne die Nutzdaten also den BODY-Teil des angeforderten HTML-Dokuments mit zu übertragen.
Auch hier soll noch einmal kurz die Syntax des Response dargestellt werden. Erläuterungen zu den Zeichen <crlf> und {...}* stehen bei der Syntax-Beschreibung des Requests. Die Zeichen [...] sollen ein optionales Vorhandensein darstellen:
"HTTP/1.0" <result-code> [<message>] <crlf>
{<Header>: <Value> <crlf>}*
<crlf>
<Body>
Auch hier wieder ein Beispiel:
HTTP/1.0 200 OK
Server: NCSA/1.5
MIME-version: 1.0
Content-type: text/plain; text/html
Last-Modified: Thu Jul 7 00:25:33 1994
Content-Length: 2003
<html><head><title>HTTP-Hypertext Transfer Protocol</title></head>
<body>
....
</body></html>
Der in der Status-Zeile des HTTP-Response stehende dreistellige Status-Code gibt Auskunft über die Reaktion des WWW-Servers auf den vorhergehenden Request. Der hinter dem Status-Code stehende Text ist optional und wird bei der Auswertung des Status-Codes nicht beachtet. Dieser Text kann also wegfallen oder geändert werden, ohne die Reaktion des WWW-Client auf den vorhergehenden Request zu beeinträchtigen.
Die folgende Aufzählung gibt Auskunft über die Numerierungslogik und über bereits standardisierte bzw. noch unbelegte Status-Codes:
Die erste Stelle des dreistelligen Status-Codes definiert die Art des Response:
| 1xx : | Informational | Momentan unbenutzt,
aber reserviert für zukünftige Anwendungsfälle. |
|---|---|---|
| 2xx : | Success | Der Request wurde
vollständig empfangen, verstanden und bearbeitet. |
| 3xx : | Redirection | Der Request kann
noch nicht vollständig abgearbeitet werden, weitere
Aktionen sind nötig. |
| 4xx : | Client Error | Der Request
beinhaltet einen Syntax-Fehler oder kann nicht bearbeitet
werden. |
| 5xx : | Server Error | Beim Bearbeiten des
letzten gültigen Requests ist ein Server-Fehler
aufgetreten. |
Die letzten beiden Stellen des Status-Codes beinhalten keinerlei Klassifizierungen. Im, zum Zeitpunkt der Entstehung dieser Arbeit, gültigen HTTP-Standard (HTTP/1.0 V5 - gültig bis 19. August 1996) sind folgende Status-Codes definiert:
In HTTP 1.0 sind keine 1xx-Status-Codes definiert. Sie sind lediglich provisorischer Art und für zukünftige Anwendungsfälle gedacht oder können bei experimentellen Anwendungen außerhalb des HTTP-Standards verwendet werden.
Ein 2xx-Status-Code bedeutet, daß der vorhergehende Request des Clients erfolgreich empfangen, verstanden und akzeptiert wurde.
200 OK
Der Request hatte Erfolg.
201 Created
Der Request wurde erfolgreich ausgeführt und die neue Ressource
erzeugt. Diese kann mit dem/den im HTTP-Response angegebenen URL(s)
referenziert werden. Die Ressource sollte allerdings vor
Benutzung dieses Status-Codes erzeugt werden. Falls die zu
erzeugende Ressource noch nicht erreichbar ist, muß der WWW-Server
im Response-Body mitteilen, ab wann diese erreichbar ist;
ansonsten sollte der 202-Status-Code verwendet werden.
Bei den in HTTP/1.0 spezifizierten Methoden kann nur POST eine
Ressource erzeugen.
202 Accepted
Der Request wurde akzeptiert und bearbeitet, ist allerdings noch
nicht fertig. Vorgesehen wurde dieser Status-Code für den Fall,
daß ein Server einen Request annehmen kann, ohne ihn gleich
vollständig abzuarbeiten (z.B. im Falle eines Batch-Betriebs,
der nur einmal am Tag läuft). Der WWW-Client kann also den
Erfolg seines Requests nicht sofort überprüfen (Anzeige im
Client bei GET oder Existenz einer neuen Ressource bei POST),
sondern erhält im Response-Body lediglich eine Meldung über den
aktuellen Zustand der Bearbeitung und entweder einen Hinweis auf
einen Status-Monitor oder eine Abschätzung, wann der Benutzer
seinen Request als erfüllt betrachten kann.
204 No Content
Der Request wurde vollständig abgearbeitet, aber es gibt keine
Informationen, die zurückgeschickt werden könnten. Bei einem
Request durch einen Hyperlink von einer HTML-Seite aus würde
sich die im WWW-Client dargestellte Seite (mit dem entsprechenden
Hyperlink) also nicht ändern. Lediglich neue Metainformationen
in Form von Response-Header-Feldern könnten zusammen mit dem
Response übertragen werden. Diese sind dann zusammen mit den
aktuell im WWW-Client abrufbaren Header-Informationen gültig.
Ein Status-Code mit einer '3' an erster Stelle deutet darauf hin, daß zum Erfüllen des Requests weitere Aktionen des WWW-Clients erforderlich sind. Wenn die Methode des vorausgehenden Requests GET oder HEAD war, können die weiteren erforderlichen Aktionen des WWW-Clients ohne weitere Interaktion mit dem Benutzer durchgeführt werden. Um eine unendliche Schleife zu verhindern, darf ein WWW-Client eine solche, quasi automatische Weiterleitung (Redirection) nur maximal fünfmal durchführen.
300 Multiple Choices
Die im Request angesprochene Ressource ist mehrmals vorhanden. Außer
bei einem vorhergehenden HEAD-Request, sollte der Response-Body
eine Liste mit Beschreibungen und Adressen der vorhandenen
Ressourcen beinhalten. Bei einer bevorzugten Alternative sollte
der URL der entsprechenden Ressource-Alternative im ‘Location’-Feld
des Response angegeben werden (für eine automatische
Weiterleitung der Anfrage durch den WWW-Client).
301 Moved Permanently
Die im Request angeforderte Ressource ist permanent unter einem
neuen URL zu finden. Der neue URL steht im Location-Feld. Außer
bei einem HEAD-Request sollte im Response-Body eine kurze
Mitteilung mit einem Hyperlink zum neuen URL stehen.
Bei einem vorangehenden POST-Request darf der WWW-Client keine
automatische Weiterleitung durchführen (es sei denn, der
Benutzer kann dieses bestätigen).
302 Moved Temporarily
Die im Request angeforderte Ressource ist vorübergehend unter
einem neuen URL zu finden. Der neue URL steht im 'Location'-Feld.
Da sich die Umadressierung wieder ändern kann, sollte der WWW-Client
auch bei weiteren Requests den 'alten' (Request ) URL benutzen.
Außer bei einem HEAD-Request sollte im Response-Body eine kurze
Mitteilung mit einem Hyperlink zum neuen URL stehen.
Bei einem vorangehenden POST-Request darf der WWW-Client keine
automatische Weiterleitung durchführen (es sei denn, der
Benutzer kann dieses bestätigen).
304 Not Modified
Bei einen GET-Request mit Datumsangabe im 'If-Modified-Since'-Request-Header
antwortet der Server mit einem Response mit Status-Code 304 und
ohne Response-Body, wenn das im Request referenzierte Dokument
seit der entsprechenden Datumsangabe nicht geändert wurde.
Diese Gruppe von Response-Status-Codes ist auf alle Request-Methoden anwendbar und wurde für Fälle vorgesehen, in denen der WWW-Client einen Fehler verursacht. Wenn der Client einen 4xx-Response empfängt, bevor er seinen Request vollständig abgeschickt hat, muß er sofort aufhören, Daten an den Server zu senden. Außer bei einem Head-Request sollte der Server im Response-Body eine Erklärung der Fehlersituation liefern.
400 Bad Request
Der vorangegangene Request konnte vom Server nicht verstanden
werden - im allgemeinen wegen Syntax-Fehlern. Der WWW-Client
sollte den Request nicht ohne Änderungen wiederholen.
401 Unauthorized
Der Request bedarf der Benutzer-Authentifizierung. Im 'WWW-Authenticate'-Header-Feld
teilt der Server dem Client mit, welche Authentifizierung
erforderlich ist. Der Client kann dann den Request mit der
entsprechend zugehörenden Authentifizierung wiederholen.
403 Forbidden
Der Server hat den Request verstanden, kann ihn aber nicht ausführen.
Die Authentifizierung hat nicht funktioniert, und der Request
sollte nicht wiederholt werden. Wenn es kein Head-Request war und
der Server bekanntgeben möchte, warum der Request nicht ausgeführt
werden konnte, kann er den Grund im Response-Body vermerken.
Normalerweise wird dieser Status-Code benutzt, wenn der Server
den wahren Grund für die Ablehnung des Requests nicht
bekanntgeben will oder wenn alle anderen Response-Codes
unzutreffend sind.
404 Not Found
Unter dem im Request angegebenen URL konnte nichts gefunden
werden. Es gibt auch keinen Hinweis darauf, ob dieser Zustand
dauerhaft oder temporär ist. Wenn der Server diese Information
nicht publik machen möchte, kann statt dessen der Status-Code
403 (Forbidden) verwendet werden.
Response-Status-Codes, die mit der Nummer
'5' beginnen, bedeuten, daß der Server einen Fehler bemerkt hat
oder unfähig ist, einen Request zu bearbeiten. Wenn der Client
einen 5xx-Respond empfängt, bevor er seinen Request vollständig
abgeschickt hat, dann muß er sofort aufhören, Daten an den
Server zu senden. Außer bei einem Head-Request sollte der Server
im Response-Body eine Erklärung der Fehlersituation liefern.
Diese Art von Response-Codes sind für alle Request-Methoden
anwendbar und benötigen keinerlei Response-Header-Felder.
500 Internal Server Error
Ein unbekannter Fehler ist aufgetreten, der den Server daran
hindert, den Request auszuführen.
501 Not Implemented
Der Server besitzt nicht die für die Erfüllung des Requests
erforderliche Funktionalität. Dieser Response-Code wird immer
dann benutzt, wenn der Server die verwendete Request-Methode
nicht erkennt und nicht fähig ist, diese Methode bezüglich
irgendeiner Ressource anzuwenden.
502 Bad Gateway
Wenn ein Server als Gateway oder Proxy konfiguriert ist und einen
ungültigen Response eines vorgelagerten Servers erhält, setzt
er diesen Response-Code, um den Request trotzdem behandeln zu können.
503 Service Unavailable
Diesen Response-Code sendet ein Server, der z.B. aufgrund zu
hoher Auslastung oder Installationsarbeiten momentan nicht in der
Lage ist, einen Request zu erfüllen. Dieser Status-Code ist für
kurzfristige Zustände vorgesehen, die sich nach einiger Zeit
wieder bereinigen.
Dieser Abschnitt beschreibt alle im HTTP-Request und HTTP-Response verwendeten Header-Felder.
Allow
Dieser Header listet die Methoden auf, die von der im Request
referenzierten Ressource unterstützt werden. Sinn ist es, den
Empfänger über die für diese Ressource gültigen Methoden zu
informieren. Die Angabe enthält aber keinerlei Hinweis darauf,
welche Methoden der Server implementiert hat.
Allow: GET, HEAD
Authorization
Ein WWW-Client authentifiziert sich gegenüber einem WWW-Server (z.B.
nach einem 401-Response) mittels der Angaben in diesem Response-Header-Feld.
Responses auf Requests mit Authorization-Header sind nicht cache-fähig.
Content-Encoding
Der Content-Encoding-Header gibt den Typ der Daten an, die im
HTTP-Body übertragen werden. Typischerweise wird dieser Header
verwendet, wenn die übertragenen Daten modifiziert (z.B.
komprimiert) sind. Dann definiert diese Angabe den modifizierten
Datentyp und gibt damit einen Hinweis, wie die Daten behandelt
werden müssen (z.B. entkomprimieren), damit die eigentlichen
Informationen (deren Datentyp weiterhin im Content-Type-Header
vermerkt ist) wieder zugänglich sind.
Ein typisches Beispiel sind komprimiert übertragene Daten:
Content-Encoding: x-gzip
Content-Length
Diese Angabe beschreibt die Größe der im HTTP-Body stehenden
Daten dezimal. Bei allen HTTP/1.0 Requests, die einen Request-Body
beinhalten, ist die Angabe eines gültigen Content-Length-Werts
erforderlich.
Content-Length: 3495
Content-Type
Diese Angabe definiert den Daten-Typ der Daten, die im HTTP-Body
gesendet werden. Bei einem HEAD-Request steht in Content-Type der
Daten-Typ, der im Fall eines GET-Requests gesendet worden wäre.
Content-Type: text/html
Date
Der HTTP-Header Date gibt das Datum (nach ‘Greenwich Mean
Time’) an, zu dem die entsprechende Nachricht initiiert
wurde. Das zu verwendende Datums-Format ist in RFC 822 (überarbeitet
durch RFC 1123) beschrieben.
Date: Tue, 15 Nov 1994 08:12:31 GMT
Expires
Der Expires-HTTP-Header gibt an, wann die gesendete Information
ihre Gültigkeit verliert. Er bewirkt nicht, daß die
entsprechenden Daten sich zu diesem Zeitpunkt wirklich ändern
oder gelöscht werden. Er bedeutet lediglich, daß eine im Cache
stehende Information ab diesem Zeitpunkt neu vom Orginal-Server
geladen werden sollte. Die im Expires-Header stehende
Datumsangabe ist also nicht zwingend und auch nicht zwingend
richtig, sollte aber benutzt werden, um z.B. Cache-Strategien,
die diese Angabe auswerten, zu unterstützen.
Expires: Thu, 03 Sep 1996 14:00:00 GMT
From
Wenn der From-Request-Header gesetzt ist, enthält er die
Internet e-mail Adresse des Users, der über einen WWW-Client
diesen Request veranlaßt hat. Diese Angabe sollte nicht für
Sicherheits-Mechanismen verwendet werden, da der Benutzer sie
sowohl verändern, als auch unterdrücken kann.
From: auert@cs.tu-berlin.de
If-Modified-Since
Diese Angabe im GET-Request-Header bedeutet, daß der Server die
angeforderte Ressource nur dann senden soll, wenn sie, seit dem
im If-Modified-Since-Header angegebenen Datum, verändert wurde.
Wenn nicht, soll der Server einen 304-Response (Not-Modified)
ohne die Ressource im Response-Body senden.
If-Modified-Since: Sat, 06 Jul 1996 12:45:26 GMT
Last-Modified
Das Last-Modified-Header-Feld bedeutet, daß der Sender annimmt,
daß die entsprechende Ressource zu diesem Datum letztmalig geändert
wurde. Die Syntax dieser Angabe ist zwar fest vorgegeben, die
Semantik dieses Feldes (also die Bedeutung der Datumsangabe) hängt
aber von der Implementierung beim Sender und der Art der
entsprechenden Ressource ab (bei Dateien: Datumsangabe des
Dateisystems; bei Datenbank-Anfragen: Zeitstempel des Datensatzes;
...).
Last-Modified: Sat, 06 Jul 1996 12:45:26 GMT
Location
Der Location-Response-Header definiert die exakte Adresse der
Ressource, die im Request-URL angefordert wurde. Bei einem 3xx-Response
beinhaltet Location den vom Server bevorzugten URL und wird zum
automatischen Weiterleiten verwendet.
Location: http://www.w3.org/hypertext/WWW/NewLocation.html
Pragma
Der Pragma-Header beinhaltet implementationsspezifische Angaben
und wird daher von Empfängern, die mit diesen Angaben nichts
anzufangen wissen, ignoriert.
Referer
Diese Angabe enthält die Adresse (URL) der Ressource, von der
aus der Request ausgelöst wurde. Genau wie beim From-Header
sollte auch hier der Benutzer die Möglichkeit haben, diese
Angabe zu unterdrücken, da die Übermittlung dieser beiden
Header die Privat-sphäre des Benutzers betreffen.
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Server
Dieser Response-Header beinhaltet Informationen über die
verwendete Server-Software und weitere wichtige Produkte/Produkterweiterungen.
Server: NCSA/1.5
User-Agent
Dieser Request-Header informiert über die verwendete Client-Software,
mit der der Request ausgelöst wurde, und weitere wichtige
Produkte bzw. Produkterweiterungen dieser Software.
User-Agent: Mozilla/2.0 (Win16;I)
WWW-Authenticate
Dieser Response-Header muß in jedem 401-Response (Unauthorized)
vorhanden sein. Er beinhaltet Angaben zur Art der
Authentifizierung und für die entsprechende Ressource notwendige
bzw. auf sie anwendbare Parameter. In HTTP/1.0 ist bislang nur
eine Authentifizierungs-Art definiert: Basic-Authentication.
WWW-Authenticate: Basic realm="Dirks Privat-Bereich"