HTTP - Überblick HTTP Kommunikation (1)Request HTTP

15. Das Hypertext Transfer Protokoll
15-1
15. Das Hypertext Transfer Protokoll
15-2
HTTP Kommunikation (1)Request
HTTP - Überblick
'
$
1. Requests und Responses
&
%
• Beispiel: Die folgende URL werde angefordert (Request)
http://www.informatik.uni-halle.de/index.html
2. Content Negotiation
• Schritte des Basis-Modells der HTTP-Kommunikation:
3. State Management (Cookies)
1. Öffnen der TCP-Verbindung zum Web-Server.
2. Senden eines Requests zum Web-Server.
3. Empfangen eines Responses vom Web-Server
(enthält die Daten der requesteten Web-Seite).
4. Schließen der Verbindung (optional).
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-3
HTTP Kommunikation (2)
Erster Schritt: Öffnen der TCP-Verbindung
• Die URL (Web-Adresse) enthält den Namen des
Web-Servers: www.informatik.uni-halle.de.
• Der Browser fragt einen DNS-Server nach der IPAdresse.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-4
HTTP Kommunikation (3)
• Der Client (Browser) öffnet eine TCP-Verbindung
zum Port 80 dieser Maschine (141.48.3.159).
80 ist die Standard Port Nummer für HTTP. Man kann eine andere
Portnummer in der URL festlegen. Wenn kein Prozess auf diesen
Port hört, Opera gibt die Fehlermeldung “Die Verbindung zum Server
konnte nicht hergestellt werden”.
• Will man den Request manuell eingeben, kann man
Wird die IP-Adresse nicht gefunden, gibt Opera z.B. aus: “Ein Zugriff
auf den Server ist nicht möglich”.
die TCP-Verbindung auch öffnen mit
telnet www.informatik.uni-halle.de 80
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-5
HTTP Communication (4)
Beispiel für einen einfachen Request - Handeingabe:
• Der Client (Browser) fordert ein Objekt (File) vom
Server. Das geschieht mit der Nachricht
GET /index.html HTTP/1.0
(Leerzeile)
• Zwischen der GET-Zeile und der Leerzeile können
viele Optionen (“Headers”) spezifiziert werden.
Die Leerzeile wird zur Markierung des Endes des GET-Requests gebraucht. Der Client schließt die Verbindung nicht sofort nach dem
Request, damit der Server eine Möglichkeit hat, festzustellen, ob der
Request vollständig ist. POST-Requests enthalten Daten nach der Leerzeile. Der Header gibt an, wie viele Bytes der Server noch nach der
Leerzeile lesen muss.
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-7
HTTP Kommunikation (6)
• Beispiel für einen Request, der von Netscape 4.76
gesendet wurde:
GET /index.html HTTP/1.0
Referer: http://www.informatik.uni-halle.de/.../c3.html
Connection: Keep-Alive
User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u)
Host: haendel.informatik.uni-halle.de:8080
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
(Leerzeile)
S. Brass, A. Herrmann: Datenbanken und WWW
15-6
HTTP Communication (5)
Zweiter Schritt: Request
S. Brass, A. Herrmann: Datenbanken und WWW
15. Das Hypertext Transfer Protokoll
Universität Halle, 2013
Öffnen der Verbindung mit TELNET:
telnet
set localecho
o dbs.informatik.uni-halle.de 80
GET /Lehre/asq10 11/stud.sql HTTP/1.1
Host:dbs.informatik.uni-halle.de
(Leerzeile)
”set localecho” hat eigentlich mit dem Request nichts zu tun. Es sichert
nur die Ausgabe der Eingabeanforderungen.
Wenn Seiten mehrsprachig angeboten werden, so können noch entsprechende Endungen ( z. B. .de .en) angehängt werden.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-8
HTTP Kommunikation (7)
• Beispiel für einen Request, vom Internet Explorer:
GET /index.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, application/vnd.ms-powerpoint,
application/vnd.ms-excel,
application/msword, */*
Referer: http://www.informatik.uni-halle.de/.../c3.html
Accept-Language: en-us,de;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0
(compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
Host: haendel.informatik.uni-halle.de:8080
Connection: Keep-Alive
(Leerzeile)
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-9
15. Das Hypertext Transfer Protokoll
HTTP Kommunikation (8)
15-10
HTTP Kommunikation (9)
• Ein Request kann Daten enthalten (z.B. aus einem
Formular):
POST /db-cgi/grades?view HTTP/1.0
Referer: http://.../Lehre/asq10 11/view.html
Connection: Keep-Alive
User-Agent: Mozilla/4.73 [en] (X11; U; SunOS 5.7 sun4m)
Host: www.informatik.uni-halle.de
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-type: application/x-www-form-urlencoded
Content-length: 46
Dritter Schritt: Response
• Der Server antwortet mit dem angeforderten (requesteten) Dokument, z. B. er überträgt eine HTMLDatei.
• Vor den Daten wird ein Status-Code gesendet (z.B.
200 “OK”), sowie Informationen über das Dokument (Meta-Daten) und über den Server.
• Header und Daten sind durch eine Leerzeile getrennt.
first_name=Annemarie&last_name=Herrmann&password=abc
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-11
HTTP Kommunikation (10)
• Beispiel für ein Response vom Apache Server:
HTTP/1.1 200 OK
Date: Thu, 02 Jul 2009 18:52:10 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Mon, 08 May 2008 09:22:58 GMT
ETag: "60304-46b-39168772"
Accept-Ranges: bytes
Content-Length: 1131
Connection: close
Content-Type: text/html
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-12
HTTP Kommunikation (11)
• Beispiel für ein Response vom Microsoft Internet
Information Server (IIS):
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Content-Location: http://141.48.3.159/Default.htm
Date: Thu, 02 Jul 2009 19:00:39 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 06 Mar 2008 23:41:04 GMT
ETag: "fca66ec6a084bf1:abe"
Content-Length: 4263
... HTML Dokument ...
... HTML Dokument ...
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-13
15. Das Hypertext Transfer Protokoll
HTTP Kommunikation (12)
HTTP Kommunikation (13)
• Auf diesem Weg können beliebige Dateien übertragen werden, nicht nur HTML:
HTTP/1.1 200 OK
Date: Fri, 03 Jul 2009 07:35:20 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Tue, 17 Jul 2008 12:11:48 GMT
ETag: "9ac90-d2f-39744984"
Accept-Ranges: bytes
Content-Length: 3375
Connection: close
Content-Type: image/jpeg
• Früher wurde der Server nach dem Transfer der
angeforderten Daten geschlossen.
• Deshalb müssen Client und Server übereinstimmen,
um die TCP-Verbindung für eine bestimmte Zeit zu
sichern.
Das geht über den Header “Connection:”.
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
Vierter Schritt: Verbindung schließen
• Das wurde jedoch ineffizient, weil öfter weitere Dateien (Bilder, mehr Webseiten ) vom selben Server
übertragen werden mussten.
... Binäre Daten von einem JPEG-File (3375 Bytes) ...
S. Brass, A. Herrmann: Datenbanken und WWW
15-14
15-15
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-16
Proxies (1)
HTTP Kommunikation (14)
• Wenn der Client weiss, dass er verschiedene Dokumente vom Server braucht, kann er einen Request
nach dem anderen senden ohne auf den Response
zu warten.
Das wird “pipelining” genannt. Frühere Browser wurden für viele
gleichzeitige Verbindungen zum selben Server geöffnet. Das belastete stark. Heute werden in der Regel vom Client nicht mehr als zwei
gleichzeitige Verbindungen auf demselben Server geöffnet.
• Manchmal kommunizieren Clients (Browser) und
Server über einen oder mehrere Proxy Server (Caches):
Request
Request
-
Browser Response
Proxy
-
Server
Response
• Browser können so konfiguriert werden, dass sie alle
Requests an einen festen Proxy-Server anstelle an
den echten Server senden.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-17
15. Das Hypertext Transfer Protokoll
Proxies (3)
Proxies (2)
• Der Proxy prüft dann, ob die gewünschte WebEr versucht auch zu überprüfen, ob die Seite immer noch aktuell ist,
siehe unten.
• Wenn ja, antwortet der Proxy mit dem Request aus
seinem Cache.
deren Proxy.
• Er leitet den Response (Antwort) an den Client und
zusätzlich in seinen Cache (für künftige Requests
auf die gleiche URL).
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-19
Syntax eines Requests (1)
• Ein Request besteht aus
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-20
Syntax eines Requests (2)
• Es gibt vier Klassen von Header:
einer Kommandozeile,
General Header: In Request und Response,
egal, ob sie die Daten enthalten oder nicht.
null oder mehreren Headern,
einer Leerzeile,
einem Body (Entity, Daten) (optional).
• Eine Request Kommandozeile besteht aus
einer Methode, z.B. GET.
einer Identifizierung der Resource, auf welche die
Methode angewandt werden soll (z.B. absoluter
Pfad)
der HTTP-Version des Requests. z.B. HTTP/1.1.
S. Brass, A. Herrmann: Datenbanken und WWW
• Wenn nicht sendet der Proxy den Request an den
realen Server (“Origin Server”) oder an einen an-
Seite in seinem Cache vorhanden ist.
S. Brass, A. Herrmann: Datenbanken und WWW
15-18
Universität Halle, 2013
Entity Header: In Request und Response,
aber nur wenn Daten enthalten sind (Entity).
Request Header: Nur in einem Request.
Response Header: Nur in einem Response.
• Die Syntax der Header ist die gleiche wie in Emails
(z.B. “From:”), siehe RFC 822.
Die spezifische Auswahl möglicher Header ist natürlich unterschiedlich.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-21
15. Das Hypertext Transfer Protokoll
Methoden (1)
Methoden (2)
• GET: Die Daten, gespeichert unter dem gegebenen
Pfad/URI werden angefordert (Request)
Dies kann der Inhalt einer Datei auf dem Server sein, aber der Pfad/URI
kann auch ein Programm identifizieren, welches Daten berechnet. Das
hängt von der Server-Konfiguration ab und sogar eine einfache URL,
die aussueht wie ein Dateiname kann berechnet worden sein. Argumente/Parameter kann im Anhang nach einem “?” folgen.
• HEAD: Wie GET, kann aber nur den Header liefern,
nicht die Daten (Body).
15. Das Hypertext Transfer Protokoll
• POST: Die Daten werden vom Client zum Server
übertragen zur gegebenen URI übertragen.
Das ist die häufigste Anwendung für Daten aus
Formularen.
Auch die GET Methode kann zum Übertragen von Formulardaten
zum Server verwendet werden. Aber die Formulardaten werden
dann auf dem Server gespeichert und nicht nur zum Berechnen
einer Ergebnis-Webseite benutzt (z.B. query forms). POST ist vorzuziehen.
Die URI kann jedoch auch den Namen einer news-
Z.B. erhält man auf diese Weise das Datum der letzten Änderung,
die Größe der Datei, den MIME-Typ, tec. (Meta-Daten).
S. Brass, A. Herrmann: Datenbanken und WWW
15-22
Universität Halle, 2013
15-23
group enthalten.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-24
Syntax eines Response (1)
Methoden (3)
• POST, weiterhin:
Die URI kann auch Datenbank-Tabellen benen-
• Ein Response besteht aus:
Status-Zeile,
nen, in die Daten als neuer Datensatz eingefügt
null oder mehreren Header,
sind.
Leerzeile,
Oder die URI benennt ein Dokument an welches
Body (Entity, Daten, Dokument) (optional).
• Eine Status-Zeile besteht aus:
Daten angehängt werden.
Was genau passiert ist abhängig von der Konfiguration des Servers (und der URI). HTTP schreibt
keine spezifische Aktion vor.
HTTP-Version,
Status-Code (drei Zahlen) (z.B. Fehlernummer),
Text, der den Status-Code erklärt.
Status-Code: für den Computer, Text: für den Nutzer.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-25
15. Das Hypertext Transfer Protokoll
Status-Codes: Beispiele
15-26
Overview
Status-Codes bestehen aus drei Zahlen. Die erste Zahl
1. Requests und Responses
legt die Hauptklasse des Status-Codes fest.
Unter Wikipedia sind alle Statuscodes aufgelistet.
'
$
2. Content Negotiation
• 2xx: Successfull:
&
200: OK
%
3. State Management (Cookies)
Die angeforderte Operation wurde erfolgreich ausgeführt. Z.B.
eine angeforderte Web-Seite wurde erfolgreich beantwortet (response).
206: Partial Content.
Der Client hat explizit nur einen teil der Resource angefordert und
dieser ist erfolgreich beantwortet worden.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-27
S. Brass, A. Herrmann: Datenbanken und WWW
15. Das Hypertext Transfer Protokoll
Medientypen (1)
15-28
Medientypen (2)
• Mit Hilfe von Content-Negotiation (Inhaltsvereinbarung) wird zwischen verschiedenen Medientypen
einer Ressource gewählt, die sich in Bezug auf
Sprache,
• Die Medientypen werden in der Art der MIME Standards (“Multipurpose Internet Mail Extensions”)
festgelegt.
• Die Medientypen haben eine Hauptklasse und einen
Qualität,
Subtyp, z.B. image/gif.
Codierung
• Wenn der Client den Subtyp nicht kennt, kann er
oder andere Parameter
unterscheiden können, aber keinen Einfluß auf den
Inhalt einer Ressource haben.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
Universität Halle, 2013
aus der Hauptklasse Informationen entnehmen, was
zu tun ist.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-29
15. Das Hypertext Transfer Protokoll
15-30
Medientypen (4)
Medientypen (3)
• Z.B., alle text/* Typen sollen so dargestellt werden,
dass der Client in der Lage ist, sie lesbar zu zeigen.
E.g. text/postscript ist falsch, es muss application/postscript geschrieben werden.
• Außer Hauptklasse und Subtyp können auch optio-
• Die zur Zeit definierten Klassen sind:
text, z.B. text/plain, text/html, text/xml.
multipart, z.B. multipart/mixed.
message, z.B. message/rfc822, message/news.
application, z.B. application/octet-stream,
application/postscript, application/pdf.
nale Parameter spezifiziert werden, (getrennt mit
image, z.B. image/jpeg, image/gif, image/png.
“;”), z.B.
audio, z.B. audio/basic, audio/mpeg.
video, z.B. video/mpeg, video/quicktime.
text/html; charset=ISO-8859-4.
model, z.B. model/vrml.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-31
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-32
Alternative Versionen (1)
Medientypen (5)
• Ein Dokument mit der gleichen Bezeichnung kann
• Die Medientypen sind registriert bei IANA (Internet
Assigned Numbers Authority) [http://www.iana.org].
• Die derzeitige Liste der Medientypen kann nachgesehen werden bei
[http://www.iana.org/assignments/media-types]
• Nicht-registrierte Formen beginnen mit “x-”.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
auf dem Server in unterschiedlichen Formaten existierenT
• Z.B. ASCII, HTML, LATEX, Postscript, PDF.
• Es ist auch möglich, dass das Dokument in verschiedenen Sprachen existiert (z.B. Deutsch und
Englisch).
z.B. Es ist möglich, dass die Homepage der Universität Halle die URI
http://www.uni-halle.de/ auf deutsch oder auf englisch geliefert wird,
je nach Vorgaben des Clients.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-33
15. Das Hypertext Transfer Protokoll
15-34
Alternative Versionen (2)
Selektion des Zeichensatzes
• Der Apache hat auch “Type Maps”.
Die URI zeigt auf ein File, das unterschiedliche Versionen beschreibt.
• Z.B. unter doc.var kann folgendes gespeichert sein:
URI: doc.html.en
Content-Type: text/html; qs=1
Content-Language: en
Description: "English Original"
• Z.B. gibt es für kyrillische Buchstaben mehrere Zeichensätze (ISO-8859-5, windows-1251).
• Der Server kann übersetzen zwischen unterschiedlichen Codierungen.
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
(encodings)er verwenden will:
Accept-Charset: ISO-8859-1, ISO-8859-5;q=0.8
URI: doc.html.de
Content-Type: text/html; qs=0.8
Content-Language: de
Description: "Deutsche Übersetzung"
S. Brass, A. Herrmann: Datenbanken und WWW
• Der Client kann spezifizieren, welchen Zeichensatz
15-35
S. Brass, A. Herrmann: Datenbanken und WWW
15. Das Hypertext Transfer Protokoll
15-36
Overview
Kompressions-Methoden
• Der Client kann wählen, welche Kompressionsme-
Universität Halle, 2013
1. Requests and Responses
thode er versteht:
Accept-Encoding: gzip;q=1, identity;q=0.5
• Formate aus der HTTP-Spezifikation:
gzip (früher x-gzip): GNU gzip .
2. Content Negotiation
'
$
3. State Management (Cookies)
&
%
compress (früher x-compress): UNIX compress.
deflate.
identity: Keine Kompression.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-37
• HTTP ist ein statusloses Protokoll: Jeder Request
wird isoliert behandelt. Es gibt keine “sessions” mit
“login” und “logout”.
Das verringert die Server-Last: Nachdem es einen Request beantwortet hat, kann das Ergebnis vollständig vergessen werden.
Demgegenüber würden Sessions irgendeinen Speicher auf dem Server während der gesamten Dauer der Session (die lang sein kann),
benötigen, um Status-Informationen zu speichern.
• Aber das bedeutet, dass wir zurück zu den Zeiten
des Batch-Prozessing gehen müssten: Der Request
muss alle notwendigen Daten enthalten.
15. Das Hypertext Transfer Protokoll
Universität Halle, 2013
15-39
• Jedoch in vielen on-line-Shops, kann man Waren
mit einer “shopping cart” erwerben und am Ende
bezahlen.
• offensichtlich werden Waren von einer ganzen Reihe
von Requests zusammen auf einem Server behandelt wie eine Session.
• das wird normalerweise mit Cookies realisiert.
Der Server sendet zum Client und
der Client schließt im allgemeinen alle künftigen
Requests des gleichen Servers mit ein.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-40
Cookies (3)
Cookies (2)
• Ein Cookie kann z.B. eine User-Nummer oder eine
Session-Nummer enthalten.
• Z.B. telnet www.altavista.com 80:
HTTP/1.0 200 OK
Date: Thu, 14 Dec 2000 16:12:20 GMT
Server: AV/1.0.1
MIME-Version: 1.0
Content-Length: 18713
Content-Type: text/html; CHARSET=ISO-8859-1
Set-Cookie: AV_USERKEY=AVSe36e6eef1b00004b0910ac0008d5f;
expires=Tuesday, 31-Dec-2013 12:00:00 GMT;
path=/; domain=.altavista.com;
S. Brass, A. Herrmann: Datenbanken und WWW
15-38
Cookies (1)
Protokoll ohne Status
S. Brass, A. Herrmann: Datenbanken und WWW
15. Das Hypertext Transfer Protokoll
Universität Halle, 2013
• Das bedeutet, dass das Cookie zu allen Web-Servern
in der Domain .altavista.com geschickt werden sollte, wenn Zugriff zu den Seiten besteht (path=/).
• Die Browser senden die Daten mit dem Header.
Cookie: AV_USERKEY=AVSe36e6eef1b00004b0910ac0008d5f;
• Auf diese Art und Weise wird das Führen von StatusInformationen vom Server auf den Client übertragen.
Aber häufig ist der Inhalt eines Cookies nur eine Referenz auf StatusInformationen, die tatsächlich auf dem Server gesichert sind.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
15. Das Hypertext Transfer Protokoll
15-41
15. Das Hypertext Transfer Protokoll
15-42
Private Probleme
• Cookies machen es möglich, Nutzer zu identifizieren. Beispiel:
Cookies (4)
• Browser so können konfiguriert werden, dass sie
Cookies ignorieren.
• Manche Online-Shops arbeiten nicht ohne Cookies.
• Man kann Cookies von Zeit zu Zeit löschen.
Ein Online-Buchshop sendet eine Nutzer-Nummer
in einem Cookie, wenn ein Nutzer zum ersten
Mal auf seine Webseite zugreift.
Der Browser sendet diese Nutzer-ID zurück, wenn
künftig auf die Seite zugegriffen wird.
Wenn der Nutzer ein Buch kauft, erfährt er Namen und Adresse von dieser Nutzer-ID.
Wenn der Nutzer später nur Angebote im BuchShop anschaut, ist sein/ihr Name bekannt.
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013
S. Brass, A. Herrmann: Datenbanken und WWW
Universität Halle, 2013