was ist $_SERVER['UNIQUE_ID']?

[Matze]

Hallo,

kann mir bitte einer sagen woraus die $_SERVER['UNIQUE_ID'] besteht bzw. woraus sie zusammen gesetzt wird?
Ich weiß nur das Apache die ID bei jedem Aufruf generiert, nur nicht warum und woraus.
Im PHP-Handbuch habe ich $_SERVER['UNIQUE_ID'] nicht einmal unter den vordefinierten Variablen gefunden. Nur unten bei den Kommentaren erwähnt.

Eine andere Frage wäre, wozu man diese ID verwenden kann bzw. wofür sie verwendet wird?

Danke und Grüße, Matze

[Sven Rautenberg]

Moin!

kann mir bitte einer sagen woraus die $_SERVER['UNIQUE_ID'] besteht bzw. woraus sie zusammen gesetzt wird?
Ich weiß nur das Apache die ID bei jedem Aufruf generiert, nur nicht warum und woraus.

Steht in der Doku zu mod_unique_id.

Im PHP-Handbuch habe ich $_SERVER['UNIQUE_ID'] nicht einmal unter den vordefinierten Variablen gefunden. Nur unten bei den Kommentaren erwähnt.

Logisch. In $_SERVER stehen Werte, die individuell vom Server übergeben werden - abhängig von der Serverkonfiguration. Das gehört nicht in die PHP-Dokumentation, sondern in die Serverdokumentation.

Eine andere Frage wäre, wozu man diese ID verwenden kann bzw. wofür sie verwendet wird?

Wenn du weißt, wie sie generiert wird, bieten sich ggf. Anwendungsmöglichkeiten.

- Sven Rautenberg

[Matze]

Hallo,

Steht in der Doku zu mod_unique_id.

Auch wenn ich mir das jetzt durchgelesen habe,
befriedigt mich diese Antwort nicht wirklich:

Wenn du weißt, wie sie generiert wird, bieten sich ggf. Anwendungsmöglichkeiten.

Kennst du ein Beispiel wo die ID unverzichtbar wäre?
Ich glaub ich hab es noch nicht richtig verstanden und denke,
dass ich mir das Ganze anhand eines Beispiels besser vorstellen könnte.

Grüße, Matze

[Sven Rautenberg]

Moin!

Auch wenn ich mir das jetzt durchgelesen habe,
befriedigt mich diese Antwort nicht wirklich:

Wenn du weißt, wie sie generiert wird, bieten sich ggf. Anwendungsmöglichkeiten.

Kennst du ein Beispiel wo die ID unverzichtbar wäre?

Keins aus der Praxis.

Ich glaub ich hab es noch nicht richtig verstanden und denke,
dass ich mir das Ganze anhand eines Beispiels besser vorstellen könnte.

Eindeutige IDs sind immer dann notwendig, wenn es darum geht, gleichartige Dinge trotzdem eindeutig auseinanderhalten zu können. Im Webserverkontext ist das üblicherweise der gleichzeitige Zugriff auf eine einzelne URL (vgl. die Überlegungen in der Doku zu Obergrenzen von parallelen Requests). Eine eindeutige ID würde beispielsweise einer hinter dem Webserver platzierten Business-Logik ein Auseinanderhalten paralleler Anforderungen erlauben - und das Modul mod_unique_id wäre eine sehr simple Methode, solche IDs zu generieren.

Aber wenn man sich mal PHP-Skripte und eine abgefragte Datenbank vorstellt, dann stellt jeder einzelne Prozess gleichzeitig eine individuelle Verbindung (über Sockets oder TCP/IP) zur Datenbank her und ist allein schon deshalb eindeutig identifizierbar - anders würde eine Datenbank gar nicht funktionieren können, sie arbeitet - zwar mit anderen Aufgaben und Datenprotokollen - genauso, wie der Webserver selbst, kann sich also ebenfalls selbständig eindeutige IDs generieren, wenn es intern notwendig sein sollte.

- Sven Rautenberg

[Matze]

Hallo,

danke für deine ausführliche Antwort!

Zusammenfassend kann ich also folgendes feststellen (korrigier mich bitte wenn ich etwas falsch verstanden habe)

1. Die unique_id hat nichts mit PHP zu tun, denn sie wird vom Apache für dessen Aufgaben generiert. Also noch 'über' PHP.

2. Wird sie dann gebraucht, wenn der Server eine bestimmte Aufgabe mehrmals aber gleichzeitig für verschiedene Anfragen ausführen muss.

3. Die unique_id besteht aus dem Unix-timestamp, IP, Pid und dem Counter in der Reihenfolge.

Danke nochmals, ich hab im Web leider wenig dazu gefunden.

Grüße, Matze

[Tom]

Hello,

1. Die unique_id hat nichts mit PHP zu tun, denn sie wird vom Apache für dessen Aufgaben generiert. Also noch 'über' PHP.

2. Wird sie dann gebraucht, wenn der Server eine bestimmte Aufgabe mehrmals aber gleichzeitig für verschiedene Anfragen ausführen muss.

Nein, sie ist nicht für eigene Prozesse des Servers reserviert.

Sie wird vom Server allen Prozessen bereitgestellt, die sie nutzen wollen.
Sie ist besser, als eine im Prozess gernerierte "Zufallszahl", da diese bei Systemen in der Praxis in einer Server-Farm doch schon einmal eine Doublette haben könnte.

Bei jedem Request wird eine neue UNIQUE_ID generiert.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Matze]

Hallo,

Nein, sie ist nicht für eigene Prozesse des Servers reserviert.

Sie wird vom Server allen Prozessen bereitgestellt, die sie nutzen wollen.

Also generiert der Server sie, damit z.B. PHP, CGI, Java etc. verschiedene Anfragen gleichzeitig bearbeiten und die Antworten dann wieder an den richtigen Anfragenden zurück liefern kann?

Bei jedem Request wird eine neue UNIQUE_ID generiert.

Das habe ich verstanden, glaub ich.
Also bei jeder Anfrage an HTML, PHP, MySQL, CGI etc.?

Danke und Grüße, Matze

[Tom]

Hello,

Sie wird vom Server allen Prozessen bereitgestellt, die sie nutzen wollen.

Also generiert der Server sie, damit z.B. PHP, CGI, Java etc. verschiedene Anfragen gleichzeitig bearbeiten und die Antworten dann wieder an den richtigen Anfragenden zurück liefern kann?

Fast getroffen ist auch vorbei ;-))
Der Server generiert sie, damit  z.B. PHP, CGI, Java etc. verschiedene Anfragen gleichzeitig bearbeiten können, und sie erkennen können, ob diese Anfrage von ihnen stammt und noch eine Antwort (ein weiterer Request) erwartet wurde. Das muss der Programmierer natürlich selber implementieren in seine Anwendung.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Matze]

Hallo,

Fast getroffen ist auch vorbei ;-))

manomanoman^^

Der Server generiert sie, damit  z.B. PHP, CGI, Java etc. verschiedene Anfragen gleichzeitig bearbeiten können, und sie erkennen können, ob diese Anfrage von ihnen stammt und noch eine Antwort (ein weiterer Request) erwartet wurde.

O.kay...... äääähm das ist ein langer Satz.
Ich versuchs nochmal zu vereinfachen.
Also der Server generiert sie, damit PHP verschiedenen Anfragen gleichzeitig bearbeiten und erkennen kann, ob diese Anfrage von PHP stammt und stammt und noch eine Antwort erwartet wurde?

Was wäre der Grund für eine weitere Antwort?
Läuft jeder Befehl/Funktion in einem extra Request?
Wär logisch, oder wird ein komplettes Script in einem Abwasch abgearbeitet?
Nur wann wüsste der Server dann wann das Script zu Ende ist...
Hm ihr merkt schon, dass ich irgendwie 'hänge'...
Irgendwie steig ich nicht so richtig dahinter.

Das muss der Programmierer natürlich selber implementieren in seine Anwendung.

Den Satz versteh ich hoffentlich wenn ich oberes verstanden hab ^^

Danke und Grüße, Matze

[Tom]

Hello,

Beispiel:

Du baust Dir eine Kundenverwaltung.

Die hat eine alphabetische Liste, in der die Kunden in Kurzform aufgelistet werden.
Jede Zeile hat einen "Bearbeiten-Button"
Dieser löst einen Request auf eine Einzeldarstellung des Kunden (in einem separaten Fenster aus)

Wenn Du nun bei mehreren Kunden dieses Fenster anforderst, dann hast Du nachher eben (sagen wir mal) drei davon auf dem Schirm.

Die polymorphen Daten müssen in Deiner Session aber auch verarbeitet werden können.
Die Unique_ID eignet sich bestens dafür.

OK, Du könntest sagen: das regel ich doch über die ID des Kunden.
Sag ich: Und was ist, wenn Du in Deinem Klick-Chaos für denselben Kunden viermal dasselbe Fenster anforderst?

Dann wird es kritisch.
Das kann dann einerseits durch einen Konfliktzähler im Datensatz abgefangen werden (also ausschließlich auf Datenbankseite, wenn man eine vernünftige zur Verfügung hat), oder eben durch ein Formular-Zertifikat.

Wenn man "DISTINCT only" für den Prozess und die Daten wählt, dann würde das ältere Zertifikat durch das neuere erledigt (noch nicht unbedingt gelöscht) und dessen Daten in der Session könnten beseitigt werden. Wenn man aber Prozesse hat, die durchaus paralleles Arbeiten mit unterschiedlichen Instanzen desselben Objektes benötigen, dann bleiben die Zertifikate eben alle gültig, bis sie erledigt sind (durch Request oder durch Timeout).

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Matze]

Hallo Tom,

danke, ich versuche dir zu folgen.
Ich werde mich dahingehend erstmal belesen, denn trotz deines blumigen Beispiels erkenn ich den Sinn nicht.

Mir fehlt noch der "was passiert wenn... Effekt" vor Augen.
Also was wenn es keine unique_id gibt und was wenn...
und ich komm eigentlich recht gut mit mehreren Fenstern klar.

Ich hab bis jetzt allerdings noch nie hinterfragt warum.

Leider fehlt mir heut und die kommenden Tage die Zeit mich weiter damit zu beschäftigen,
also werde ich eventuell einen neuen Thread eröffnen, falls dieser hier
bis dato ins Archiv gewandert ist.

Eure Antworten haben mir zumindest erst einmal sehr weiter geholfen, Danke!

Grüße, Matze

[Sven Rautenberg]

Moin!

Ich werde mich dahingehend erstmal belesen, denn trotz deines blumigen Beispiels erkenn ich den Sinn nicht.

Geht mir genauso.

Mir fehlt noch der "was passiert wenn... Effekt" vor Augen.
Also was wenn es keine unique_id gibt und was wenn...
und ich komm eigentlich recht gut mit mehreren Fenstern klar.

Richtig. Toms Beispiel zeigt keine Notwendigkeit für die Nutzung dieser UID.

- Sven Rautenberg

[Tom]

Hello,

Richtig. Toms Beispiel zeigt keine Notwendigkeit für die Nutzung dieser UID.

Heute hast Du es mal wieder stärker, oder?

Wie würdest Du denn Reentranz in einer Session unter HTTP-Protokoll ausschließen?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Matze]

Hallo,

ich glaub ich habe ein Beispiel für ein Problem im Zusammenhang mit der Unique_ID gefunden:

"CGIWrap Error: Access Control

CGIWrap access control mechanism denied execution of this script for the following reason:

UID of script userid less than configured minimum."

Diese nette Fehlermeldung habe ich vorgestern mit der Bitte um Hilfe
von einem Bekannten bekommen. "Timing" dachte ich mir^^

Nun, da ich immernoch nicht hinter das System gestiegen bin muss ich wohl auch erstmal fragen wo der Zusammenhang zwischen Fehlermeldung und UID ist.
Der Fehler trat auf, als er eine phpinfo.php als root auf seiner Domain gespeichert hatte und sie dann über den Browser aufrief.

Grüße, Matze

[Sven Rautenberg]

Moin!

UID of script userid less than configured minimum."

Diese nette Fehlermeldung habe ich vorgestern mit der Bitte um Hilfe
von einem Bekannten bekommen. "Timing" dachte ich mir^^

Leider meint "UID" in diesem Fall "User ID". Denn die kann man numerisch sortieren, und alle IDs, die "niedrig" genug sind, gehören üblicherweise zu bestimmten besonderen Systemaccounts, so dass es sinnvoll ist, für potentiell  gefährliche Aufgaben die ID auf Einhaltung eines gewissen Minimums zu prüfen, damit diese Systemaccounts mit den mit ihnen verbundenen Rechten nicht mißbraucht werden können.

Nun, da ich immernoch nicht hinter das System gestiegen bin muss ich wohl auch erstmal fragen wo der Zusammenhang zwischen Fehlermeldung und UID ist.
Der Fehler trat auf, als er eine phpinfo.php als root auf seiner Domain gespeichert hatte und sie dann über den Browser aufrief.

Dann wirken sowieso noch ganz andere Dinge, wie z.B. der Safe-Mode von PHP. Und es hat absolut nichts mit dieser Unique ID zu tun.

- Sven Rautenberg

[Matze]

Hallo,

Leider meint "UID" in diesem Fall "User ID".

Dann ist die Meldung natürlich selbsterklärend und ich hätte auch selbst drauf kommen können. Danke.

Zur Unique_ID versuch ich mich immernoch im Netz zu belesen.
Sehr theoretisch das Ganze und das mag ich nun wieder gar nicht ;)

Grüße, Matze

[Matze]

Hallo,

jetzt hab ich wahrscheinlich alles gelesen was man auf deutsch so zu dem Thema im Internet über Google findet^^

Ich versuch es also nochmal :)
Ich glaub die Unique_ID ist dafür, damit der Apache die Anfragen im Netzwerk richtig zuordnen kann weil die ID von z.B. PHP im Netzwerk schonmal doppelt vor kommen kann. Mehr nicht.

Leider hab ich keinen eigenen Server und den XAMPP zu konfigurieren trau ich mir nicht zu.
Ich hab sowas noch nie gemacht und wüsste jetzt gar nicht wo ich anfangen sollte.
Dafür gibts aber sicher auch noch Lesenswertes.
Jedenfalls werd ich mal versuchen ein bisschen mit der UID rumzuspielen.
Vielleicht lern ich ja noch was dabei ^^

Für weitere Gedanken zu dem Thema wär ich nach wie vor sehr dankbar.

Grüße, Matze

[Sven Rautenberg]

Moin!

jetzt hab ich wahrscheinlich alles gelesen was man auf deutsch so zu dem Thema im Internet über Google findet^^

Lesen bildet. :)

Ich versuch es also nochmal :)
Ich glaub die Unique_ID ist dafür, damit der Apache die Anfragen im Netzwerk richtig zuordnen kann weil die ID von z.B. PHP im Netzwerk schonmal doppelt vor kommen kann. Mehr nicht.

Nein, das erscheint mir doch etwas sehr weit hergeholt.

Was bedeutet denn "Anfragen im Netzwerk zuordnen"? Was ist "die ID von PHP"?

- Sven Rautenberg

[Matze]

Hallo,

Lesen bildet. :)

Wenn man denn versteht was man da gelesen hat...

Was bedeutet denn "Anfragen im Netzwerk zuordnen"? Was ist "die ID von PHP"?

Ich nehm mal an, das PHP, genauso wie der Apache eine interne ID generiert um Anfragen richtig zuzuordnen. Wenn in einem Netzwerk jetzt mehrere Server laufen kann es meinem Verständiss nach dazu kommen, dass eine ID doppelt vorhanden ist. Und die Unique_ID des Apache löst das Problem wohl.

Ich merk schon, es will einfach nicht in meinen Kopf. Mist :(

Grüße, Matze

[Sven Rautenberg]

Moin!

Was bedeutet denn "Anfragen im Netzwerk zuordnen"? Was ist "die ID von PHP"?

Ich nehm mal an, das PHP, genauso wie der Apache eine interne ID generiert um Anfragen richtig zuzuordnen. Wenn in einem Netzwerk jetzt mehrere Server laufen kann es meinem Verständiss nach dazu kommen, dass eine ID doppelt vorhanden ist. Und die Unique_ID des Apache löst das Problem wohl.

Nö, nicht wirklich. Jedenfalls nicht im normalen Betrieb. Was soll denn da besonderes zugeordnet werden?

Ein Skriptaufruf auf einem Server ist vollkommen eindeutig zum aufrufenden Client zugeordnet: Die Kombination aus anfragender IP und Port ist auf dem Server eindeutig und wird ja auch exklusiv von einem Prozess bearbeitet.

- Sven Rautenberg

[Matze]

Hallo,

Nö, nicht wirklich. Jedenfalls nicht im normalen Betrieb. Was soll denn da besonderes zugeordnet werden?

Wenn du es schon verneinst, warum fragst du trotzdem nach?
Was wär denn kein "normaler Betrieb"?

Ein Skriptaufruf auf einem Server ist vollkommen eindeutig zum aufrufenden Client zugeordnet: Die Kombination aus anfragender IP und Port ist auf dem Server eindeutig und wird ja auch exklusiv von einem Prozess bearbeitet.

Da die IP ja bekanntermaßen nicht einem einzigen Nutzer zuzuprdnen ist,
gäb es nur noch den Port. Ob man die Portanfrage auf den Server beeinflussen kann weiß ich nicht, aber selbst dann käme sie wahrscheinlich irgendwann doppelt vor oder nicht?
So viel Ports gibts ja nun mal nicht.

Wie gesagt, kenn ich mich mit Servern (egal ob Apache oder sonstwas) überhaupt nicht aus. Ich vermag nur die php.ini zu konfigurieren.

Ist es wirklich so kompliziert oder stell ich mich grad ein bisschen blöd an?
Kann ja auch sein und ich brauch nur einen Wink mit dem Zaunspfahl...

Dank und Grüße, Matze

[Tom]

Hello,

Da die IP ja bekanntermaßen nicht einem einzigen Nutzer zuzuprdnen ist,
gäb es nur noch den Port. Ob man die Portanfrage auf den Server beeinflussen kann weiß ich nicht, aber selbst dann käme sie wahrscheinlich irgendwann doppelt vor oder nicht?
So viel Ports gibts ja nun mal nicht.

Das funktioniert etwa so:
Ein xbeliebiger Client sendet über die ihm zur Zeit zugeordnete IP einen Request an den Server auf dessen Port 80. Der Server habe bitte hier eine feste IP, obwohl da auch anderes denkbar wäre.
Beim Client wird pro Browserfenster ein Port geöffnet. Dieser Port hat eine Nummer. Es sind z.B. 30.000 verfügbare Ports am Client. Die Nummer des Ports wird ins Anfragepaket gepackt, und weitergeleitet.

Wir tun jetzt mal so, als würde das Paket beim Server genauso ankommen, wie es abgeschickt wurde. Also (Ziel-IP, Ziel-Port) (Absende-IP, Absende-Port)
Das Paket enthält jetzt auch mal (nur als Modellvorstellung) den gesamten Request.
Dieser wird vom Server ausgepackt und an den Ziel-Port weitergeleitet. Hinter diesem versteckt sich der Apache, weil wir ja Port 80 angegeben hatten. Der Apache macht jetzt einen Prozess auf, und merkt sich, dass der für (Absende-IP, Absende-Port) läuft.

Wärend der Prozess läuft, kann der Apache an Port 80 schon weitere Requests von anderen Clients annehmen und verteilen.

Nun ist der Request abgearbeitet und der Serverprozess auf dem Apachen möchte die Antwort loswerden. Das tut er, indem er sie dem Apachenhauptprogramm zurückgibt mit dem Hinweis "Das ist für Port X auf IP Y..., bzw. der Hauptprozess hat sich das natürlich unter der Prozess-ID des Kindprozesses gemerkt. Ist ja nur ein Vorstellungsmodell (das hoffentlich nicht zu sehr hinkt).

Nun geht das Antwortpaket wieder auf die Reise und kommt Beim Client bei IP Y an. Der schaut, für welchen Port es denn war. Ist dieser noch offen, dann leitet er es an den Port weiter und das Browserfenster bekommt seine Antwort. Der Host kann den Port jetzt schließen.

Wenn der Client an AOL angeschlossen ist, dann setzt der AOL-Proxy das entsprechend um. Eine Anfrage von der Clientleitung wird auf das Internet unter einer IP L und einem Port K vermittelt und weitergesendet. Kommt das Antwortpaket bei IP L und Port K wieder an, weiß der Proxy, dass er es auf die passende Clientleitung weiterschicken muss. Der Tabelleneintrag (Proxy-IP, Proxy-Port) <-> (Client-IP, Client-Port) kann dann gelöscht werden und die Proxy-IP steht mit einem anderen Port dem nächsten Surfer zur Verfügung.

Wenn es einer besser erläutern kann, sollte es /sie es bitte zun.

Die UNIQUE-ID des Servers wird also hierfür nicht benötigt.
Sie ist aber wunderbar einsetzbar für gleicheartige Anfragen des gleichen Clients an dasselbe Script (dieselbe Ressource). Die muss ja für jede Anfrage einen eigenen Variablenbereich in der Session eröffnen, wenn Mulit-Thread erlaubt sein soll. Wenn Du also einen (mehrstufigen) Datenbank-Suchvorgang vom selben Client mehrfach öffnest, also z.B. drei Suchfenster aufmachst für Kunden, um die Eintragungen vergleichen zu können, dann muss in der Session (es ist ja immer dieselbe) auch für alle drei Suichprozesse der aktuelle Zustand gespeichert werden.

Im Suchfomrular wird aleo eine eindeutige ID benötigt, um dem Fenstern auf dem Client (also den Formularen) immer den passenden Speicherblock zuordnen zu können.

Die abgearbeiten Blöcke müssen dann von Zeit zu Zeit entsorgt werden. Dafür baut man sich einen Garbage Collector, so wie ihn PHP für die Sessiondateien selber auch hat.

Die Unique-Id wird in diesem Beispiel also dafür benutzt, um das "Speicherobjekt" in der Session eindeutig zuordnen zu können, da der Client gleichzeitig drei Threads derselben Klasse eröffnet hat.

Noch eine Bitte:
----------------
Könnten wir uns darauf einigen, dass Gegenhaltungen, Korrekturen und Ergänzungen in höflichem Ton unter Beistellung der notwendigen Informationen stattfinden?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Die UNIQUE-ID des Servers wird also hierfür nicht benötigt.
Sie ist aber wunderbar einsetzbar für gleicheartige Anfragen des gleichen Clients an dasselbe Script (dieselbe Ressource). Die muss ja für jede Anfrage einen eigenen Variablenbereich in der Session eröffnen, wenn Mulit-Thread erlaubt sein soll.

Wozu eine Session? Wir reden von HTTP, da gibts erstmal keine Session. Und die Abschottung der einzelnen Webserver-Prozesse gegeneinander darf man als gegeben voraussetzen, die überschreiben sich ihre eigenen Variablen erst einmal nicht.

Wenn Du also einen (mehrstufigen) Datenbank-Suchvorgang vom selben Client mehrfach öffnest, also z.B. drei Suchfenster aufmachst für Kunden, um die Eintragungen vergleichen zu können, dann muss in der Session (es ist ja immer dieselbe) auch für alle drei Suichprozesse der aktuelle Zustand gespeichert werden.

Wenn man für so eine Aufgabe einen Sessionmechanismus bemühen möchte, könnte das sein. Ohne Sessions kommt man prima ohne sie aus.

Im Suchfomrular wird aleo eine eindeutige ID benötigt, um dem Fenstern auf dem Client (also den Formularen) immer den passenden Speicherblock zuordnen zu können.

Session-ID plus beliebiger Counter in der Session würden das perfekt erledigen.

Die Unique-Id wird in diesem Beispiel also dafür benutzt, um das "Speicherobjekt" in der Session eindeutig zuordnen zu können, da der Client gleichzeitig drei Threads derselben Klasse eröffnet hat.

Wenn ich in einer Session einen Speicherbereich für den ersten, zweiten, dritten etc... Suchvorgang anlegen müßte, würde ich numerisch aufwärts zählen und diesen Index als Parameter weiterreichen - nicht die doch eher obskure UniqueID des Apachen nutzen, deren Verfügbarkeit mir nicht auf jedem Server garantiert ist. Alternativ uniqid().

- Sven Rautenberg

[Tom]

Hello,

Session-ID plus beliebiger Counter in der Session würden das perfekt erledigen.

Wenn ich in einer Session einen Speicherbereich für den ersten, zweiten, dritten etc... Suchvorgang anlegen müßte, würde ich numerisch aufwärts zählen und diesen Index als Parameter weiterreichen - nicht die doch eher obskure UniqueID des Apachen nutzen, deren Verfügbarkeit mir nicht auf jedem Server garantiert ist.

Das macht die Vorgangsverarbeitung über HTTP enorm viel sicherer ;-)

Dann könnten wir doch Session-IDs auch einfach aufsteigend numerisch vergeben.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Session-ID plus beliebiger Counter in der Session würden das perfekt erledigen.

Wenn ich in einer Session einen Speicherbereich für den ersten, zweiten, dritten etc... Suchvorgang anlegen müßte, würde ich numerisch aufwärts zählen und diesen Index als Parameter weiterreichen - nicht die doch eher obskure UniqueID des Apachen nutzen, deren Verfügbarkeit mir nicht auf jedem Server garantiert ist.

Das macht die Vorgangsverarbeitung über HTTP enorm viel sicherer ;-)

Jetzt musst Du uns nur noch erklären, warum es eine Sicherheitslücke sein sollte, wenn man eine derartige ID in einem Formular durch eine andere ID austauschen kann - zumal das bereits mit zufälligen IDs möglich ist - die sind ja nur für andere Browserfenster oder -tabs gedacht, dort kann man die sich ja auch rausfischen...

Dann könnten wir doch Session-IDs auch einfach aufsteigend numerisch vergeben.

Andere Session-IDs kennt man dagegen idR. nicht.

Viele Grüße,
Christian

[Christian Seiler]

Hallo Tom,

Ein xbeliebiger Client sendet über die ihm zur Zeit zugeordnete IP einen Request an den Server auf dessen Port 80. Der Server habe bitte hier eine feste IP, obwohl da auch anderes denkbar wäre.

Soweit richtig...

Beim Client wird pro Browserfenster ein Port geöffnet.

...das hier ist allerdings falsch. Und nachdem Du in Deinem restlichen Posting auch eine ganze Menge Dinge vermischt, die erst einmal gar nichts miteinander zu tun haben, möchte ich hier noch einmal ein paar Grundlagen von TCP/IP erläutern. Nicht, weil Dein Posting komplett falsch wäre, sondern weil da so viel richtiges mit falschem vermischt ist.

Zuerst muss man klar "IP" und "TCP" trennen. IP ist ein Protokoll, das dafür sorgt, dass die Pakete, die geschickt werden, zum richtigen Zielcomputer gelangen. Dazu besitzten alle Computer, die mit IP miteinander kommunizieren wollen, eine sogenannte IP-Adresse. Ich lasse im folgenden Mal "Sonderfälle" wie NAT-Router außen vor, da sie zum eigentlichen Verständnis dessen, was ich hier erklären will, nicht sonderlich viel beitragen (wenn auch "Sonderfall" bei der heutigen Verbreitung von NAT wohl etwas daneben ist ;-)). Stelle Dir nun vor, Du hast zwei Rechner A und B, die gerne auch an anderen Enden der Welt stehen können, solange es zwischen ihnen irgend eine Verbindung durchs Internet gibt (es müsste übrigens nicht das Internet sein, aber ich beschränke mich mal auch hier auf den Normalfall). Wenn nun Rechner A an Rechner B ein Paket schicken will, dann muss er einfach ein IP-Paket erzeugen, das vor allem 2 Informationen enthält: Als Ausgangsadresse ("Source IP address") muss er seine eigene hineinschreiben, als Zieladresse ("Destination IP address") die IP-Adresse des Rechners B. Bis auf ein paar Details zum Protokoll selbst, ist alles andere erst einmal irrelevant: Das Paket wird (sofern es nicht verloren geht) von der Internet-Infrastruktur automatisch an Rechner B weitergeleitet. Genauso kann Rechner B umgkehrt ein Paket mit seiner eigenen Adresse als Ausgangsadresse und der Adresse von Rechner A als Zieladresse an den Rechner A weitergeleitet.

Das ist es, was IP leistet. Was in dem Paket konkret enthalten ist, ist IP egal. Wenn man nun ausschließlich IP zur Kommunikation nutzen würde, hätte man Probleme, die Pakete sinnvoll zuzuordnen. Daher gibt es weitere Protokolle, die auf IP aufsetzen, die dann die tatsächlichen Daten enthalten. Diese weiteren Protokolle sind u.a. ICMP, IGMP, UDP, TCP, SCTP usw. usf. Praktisch relevant sind vor allem ICMP (Kontroll- und Statusnachrichten wie z.B. »ping«), UDP (einfache, verbindungslose Pakete) und TCP (2-Wege-Verbindungen). Jedes IP-Paket enthält zusätzlich zu Ausgangs- und Zieladresse nämlich noch ein Feld "Aufbauendes Protokoll", in dem angegeben wird, was für ein zusätzliches Protokoll verwendet wird.

Was hat es nun mit Ports auf sich? Ganz wichtig: Ein Port ist ein Konzept, das in TCP (und auch UDP, aber das ignoriere ich jetzt mal) vorhanden ist - ICMP zum Beispiel kennt keine Ports! Ein Port hat also NICHTS damit zu tun, ob ein Paket den Weg zum Zielrechner findet, oder nicht (von Filtern wie Firewalls mal abgesehen), denn das erledigt ja, wie bereits oben erwähnt, IP. Alles, was man erst einmal über Ports wissen sollte, ist, dass sie eine Nummer sind, bei TCP/IP zwischen 0 und 65535.

Was macht nun TCP? Zwei Dinge: Erstens sorgt es dafür, dass Verbindungen zwischen zwei Rechnern aufgebaut werden können, d.h. ein eindeutig identifizierter Datenkanal, zwischen dem Programme auf beiden Rechnern Daten austauschen können (ein Programm auf Rechner A könnte dann zum Beispiel "Hallo" schreiben und ein anderes Programm auf Rechner B mit "Welt" antworten). Wodurch wird dieser Datenkanal nun eindeutig identifiziert? Durch 4 Angaben: Ausgangsadresse, Ausgangsport, Zieladresse und Zielport. (Es gibt dann noch weitere Angaben, die dazu dienen, dass es nicht ganz so einfach ist, in eine bestehende Verbindung einzudringen, die sind aber für den reinen Transport irrelevant.) Mit den vier Angaben kann jeder der beiden beteiligten Rechner Pakete zu TCP-Verbindungen eindeutig zuordnen.

TCP macht noch ein paar mehr Dinge, zum Beispiel kümmert es sich darum, dass verloren gegangene Pakete erneut geschickt werden und es kümmert sich um so Dinge wie Fragmentierung (zusammen mit ICMP), das ist aber für die folgende Erklärung irrelevant.

Wie kommunizieren nun Programme über TCP/IP? Dazu gibt es auf allen mir bekannten Betriebsystemen das Konzept der "Sockets" (wenn auch einige Betriebsysteme das etwas anders umsetzen, als andere, das Grundprinzip bleibt das gleiche): Eine Socket ist (allgemein gesprochen) ein Objekt, für das das jeweilige Betriebsystem vorrangig zwei Funktionen zur Verfügung stellt: "Lese aus dem Socket" und "Schreibe ins Socket". Nehmen wir nun erst einmal den Fall an, dass die Verbindung bereits aufgebaut ist: Dann führt ein Befehl "Schreibe ins Socket" von einem Programm dazu, dass der Betriebsystemkern ein oder mehrere TCP/IP-Pakete generiert, die dann an den Zielrechner gesendet werden, automatisch mit den korrekten Ports gesetzt. Genauso wird jedes ankommende TCP/IP-Paket in einem Puffer gespeichert und wenn ein Programm nun den Aufruf "Lese aus dem Socket" tätigt, wird der Inhalt des Puffers zurückgegeben, d.h. das Programm kann die Nachricht der Gegenseite auslesen. Der Betriebsystemkern besitzt also Intern eine Zuordnung Socket <-> (Quadruplet von Ausgangs- und Zieladressen und -ports), die ist aber für das Programm, das kommuniziert, erstmal irrelevant (es sieht nur das Socket, außer es will explizit mehr sehen).

Wie wird nun eine Verbindung aufgebaut? Das Betriebsystem stellt (stark vereinfacht gesagt) eine Funktion "Verbinde mit (IP, Port)" zur Verfügung. Das Programm ruft die auf und erhält dann einen Socket zurück, das mit der offenen TCP-Verbindung mit der Gegenseite verknüpft ist - oder eine Fehlermeldung, falls etwas nicht geklappt hat. Was ist nun der Ausgangsport und die Ausgangsadresse der Verbindung? Das Betriebsystem weiß in der Regel, welche Adresse es zu verwenden hat, um eine Verbindung zu dem und dem Ziel durchzuführen und der Ausgangsport wird beliebig gewählt. Das heißt: Beim Aufbau einer Verbindung kann einem Programm der EIGENE Port, der dann genommen wird, egal sein, das übernimmt das Betriebsystem für einen, das ist dem Programm vollkommen egal - es will ja nur eine Verbindung (es KANN allerdings auch dem Betriebsystem mitteilen, welche Wünshe es für den Ausgangsport hat, aber Browser machen sowas definitiv nicht).

Und es stimmt auch nicht, dass hierbei ein Port "aufgemacht" wird - "offen" bezeichnet bei einem Port den Zustand, dass hinter dem Port eine Anwendung auf eingehende Verbindungen wartet (s.u.) - beim Verbindungsaufbau wird jedoch AUSSCHLIESSLICH ein zufälliger Ausgangsport ins erste TCP/IP-Paket hineingeschrieben und wenn dann eine Antwort von dem RICHTIGEN Rechner kommt, wird diese zugeordnet und der Anwendung zur Verfügung gestellt, alle anderen Pakete an den Port werden entweder ignoriert oder mit Fehler-Paketen ("Sorry, Du hast Dich verwählt") beantwortet.

Was machen nun Server, um einen Port "öffnen" zu können, damit Anfragen von beliebigen Clients beantwortet werden können? Sie sagen dem Betriebsystem, sie möchten ein Socket erstellen, damit aber keine Verbindung aufbauen, sondern diese auf dem und dem Port entgegen nehmen. Damit erhalten sie dann das "Haupt-Socket". Jedes Mal, wenn nun ein Client eine Verbindung aufgebaut hat, wird ein "Unter-Socket" erstellt, über das das Serverprogramm dann mit dem konkreten Client kommunizieren kann. Um mal ein Beispiel zu machen: Ein Webserver öffnet Port 80, indem es so ein "Haupt-Socket" erstellt. Dann kommt eine eingehende Verbindung von Client A herein. Hier wird nun ein "Untersocket" erstellt, das mit der konkreten Verbindung zwischen Client A und dem Server verknüpft ist. Kommt jetzt nun auch noch eine Verbindung von Client B herein, wird ein weiteres "Untersocket" erstellt, das mit der anderen Verbindung verknüpft ist. Auf welche Weise das Serverprogramm nun Verbindungen abarbeitet, ist ihm überlassen - es könnte die zum Beipsiel einfach eine nach der anderen verarbeiten (wird allerdings in der Praxis aus Performancegründen meist anders gemacht ;-)). Die heißen übrigens nicht wirklich "Haupt-" und "Untersocket", mir fiel nur kein besserer Term ein, das zu Veranschaulichen.

Noch kurz ein paar Worte zu HTTP: Die einfachste Vorstellung von HTTP, die man haben kann, ist folgende: HTTP setzt auf TCP/IP auf, der Standardport ist 80. Was passiert nun, wenn ein Browser eine Resource abrufen will? 1. Er baut eine TCP/IP-Verbindung zum Zielwebserver auf (meist Port 80). 2. Er schickt dem Server einen Anfrage ("Request"). 3. Er erhält vom Webserver eine Antwort ("Response"). 4. Der Webserver schließt nach der Anfrage die Verbindung, der Client weiß, dass die Antwort zu Ende ist. Gut, seit HTTP/1.1 ist dank Keep-Alive und Pipelining das ganze noch viel komplizierter geworden (Keep-Alive bedeutet, dass eine Verbindung wiederverwendet werden kann), aber das Grundprinzip, dass JEDER Request bei HTTP isoliert ist, bleibt das gleiche und die obige Vorstellung ist sehr hilfreich für das Verständnis von HTTP - auch wenn es heutzutage in Wirklichkeit etwas anders abläuft.

Und ganz wichtig: Das hat NICHTS, aber auch GAR NICHTS mit Browserfenstern zu tun! Ob ein Browser pro Fenster (oder Tab oder was auch immer) mehrere Verbindungen gleichzeitig aufmacht, um zum Beispiel mehrere Bilder gleichzeitig zu laden oder ob er für ALLE Fenster insgesamt immer nur eine einzige Verbindung nach der anderen aufmacht, ist dem Programmierer des Browsers überlassen.

Was hat es nun mit mod_unique_id auf sich beim Apachen? Das Modul erzeugt für jeden Request eine hinreichend eindeutige ID, die dann Programme oder Scripte, die bei dem Request ausgeführt werden, für eigene Zwecke nutzen können. In der Doku zu mod_unique_id steht außerdem, dass:

| Unique identifiers are useful for various reasons which are beyond the
| scope of this document.

Sprich: Wofür ein Programm oder Script das dann einsetzt, bleibt dem Programmierer überlassen, diese Unique-ID ist lediglich eine Hilfestellung des Apachen, damit das Programm eine eindeutige ID erhält und sich nicht erst überlegen muss, wo es sich eine erzeugen kann. Wenn man das Modul deaktiviert, funktionieren Requests jedoch weiterhin und diese eindeutige ID wird schlichtweg nicht erzeugt.

---------------------------- schnipp ------------------------------------

[Sessions und Threads und so ein Zeug.]

Mir ist nach mehrmaligem Lesen endlich klar geworden, worauf Du hinaus willst mit Deinem Beispiel. Zum einen: Das hat mit Threads oder keinen Threads ABSOLUT nichts zu tun, genausowenig (wie Sven schon erzählt hat) mit der Abschottung von Requests zueinander innerhalb des Webservers (das kann der nämlich prima alleine, ohne deratige IDs und so einen Kram). Zum anderen: Ich halte Dein Beispiel definitiv nicht für den idealen Einsatzzweck für mod_unique_id - im Gegenteil, für Dein Szenario gibt es diverse andere Lösungsmöglichkeiten, die in meinen Augen viel sinnvoller sind (siehe z.B. Svens Antwort). Zudem führt Dein Szenario eben gerade weil Sessions Request-übergreifend sind und die Unique-ID, die vom Apache erzeugt wird, auf Request-Ebene generiert wird, zu sehr viel vollkommen unnötiger Verwirrung.

Viele Grüße,
Christian

[Tom]

Hello Christian,

ich finde es toll, dass Du Dir nochmal soviel Mühe gemacht hast, es ausfühlich zu erklären.
Obwohl, da könnte jetzt auch noch der nächste kommen, und es noch genauer auseinandernehmen.
Dann würde ich aber viellicht auch nichts mehr verstehen.

Beim Client wird pro Browserfenster ein Port geöffnet.

...das hier ist allerdings falsch.

Hätte ich vielleicht besser schreiben sollen

Beim Client wird pro Browserfenster i.d.R. mindestens ein Port geöffnet.

Ich habe noch keinen einzigen Browser gesehen, der beim Öffnen eines neuen Fensters (natürlich mit Inhalt, also beim Verbindungsaufbau mit dem Partner) keine Portöffnung verursacht hat. Ich habe nirgends behauptet, dass der Browser den Port öffnet. Das würde ich mir auch schön verbitten.

Deine Klarstellung ist natürlich erst recht nicht falsch. Sie benötigt nur mehr Sätze.

Was mir aber überhaupt nicht einleuchten will ist, was passiert, wenn ein Server einfach ein Response-Paket schickt auf eine Frage die der Client nie gestellt hat, oder die schon sehr lange her ist?

Das Paket kommt ja beim Client an dank IP, soll nun "zugestellt" werden dank TCP an den Port des Clients. Und der sagt gar nix, weil er nämlich gar keine Frage an die IP gestellt hatte in der letzten Stunde und auch sonst nix los aist auf dem Host. Was macht ein solcher Port dann?

Wenn du das noch erläutern könntest, wäre das für mich ein Schritt in Richtung Sicherheitsverständnis.

Und die zweite korrespondierende Frage wäre:
Wenn der Client ünter Nennung des Ports zwar mal eine Frage "an die IP" gestellt hat, und nun auch eine Antwort bekommt, aber der Absender hat nur mal eben schnell die Leitung angezapft ist nun also unrechtmäßiger Besitezr der IP, ist nur einfach schneller als der rechtmäßige Besitzer.

Ist das Szenario nun unsinnig oder ist es möglich?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Beim Client wird pro Browserfenster i.d.R. mindestens ein Port geöffnet.

Das wäre genauso falsch gewesen. Wie ich bereits gesagt habe, ist "offen" ein Fachbegriff, der hier schlichtweg nicht zutrifft. Eine clientseitig initiierte Verbindung von einem bestimmten Port aus heißt NICHT dass der Ausgangsport "offen" ist. "offen" heißt, dass auf diesem Port ein Dienst lauscht, der NEUE Verbindungen entgegen nimmt.

Ich habe noch keinen einzigen Browser gesehen, der beim Öffnen eines neuen Fensters (natürlich mit Inhalt, also beim Verbindungsaufbau mit dem Partner) keine Portöffnung verursacht hat.

Ich habe noch keinen Browser gesehen, der so etwas verursacht hat (naja, evtl. können einige Browser aktives FTP, aber das ist nochmal eine andere Geschichte). Du kannst es ja gerne mal selbst ausprobieren: Lade Dir eine große Datei herunter, schaue in netstat nach, welchen Client-Port Dein Browser verwendet, um den Webserver zu kontaktieren und versuche Dich z.B. per telnet localhost port mit dem Port zu verbinden - das wird fehlschlagen - weil der Port eben NICHT offen ist, sondern lediglich an einer Verbindung teilnimmt.

Was mir aber überhaupt nicht einleuchten will ist, was passiert, wenn ein Server einfach ein Response-Paket schickt auf eine Frage die der Client nie gestellt hat, oder die schon sehr lange her ist?

Dann wird sie wenn der Client freundlich ist mit einer Fehlermeldung beantwortet (z.B. einem TCP-Paket, in dem das RST-Flag gesetzt ist oder einer speziellen ICMP-Nachricht - wann welches Verfahren genau eingesetzt wird, müsste ich nachlesen) oder wenn der Client nicht so freundlich ist, wird das Paket einfach verworfen.

Das Paket kommt ja beim Client an dank IP, soll nun "zugestellt" werden dank TCP an den Port des Clients. Und der sagt gar nix, weil er nämlich gar keine Frage an die IP gestellt hatte in der letzten Stunde und auch sonst nix los aist auf dem Host. Was macht ein solcher Port dann?

Der Port macht gar nichts. Der Port ist wie ich schonmal gesagt habe nur eine Nummer, die vom Betriebsystem augsewertet wird. Das Betriebsystem sieht "oh, zu dem Port kenne ich nichts in meiner Verbindungstabelle, also ist das Paket ungültig, also ignoriere ich's entweder oder ich schicke ne Fehlermeldung zurück".

Und die zweite korrespondierende Frage wäre:
Wenn der Client ünter Nennung des Ports zwar mal eine Frage "an die IP" gestellt hat, und nun auch eine Antwort bekommt, aber der Absender hat nur mal eben schnell die Leitung angezapft ist nun also unrechtmäßiger Besitezr der IP, ist nur einfach schneller als der rechtmäßige Besitzer.

Ist das Szenario nun unsinnig oder ist es möglich?

Das Szenario ist möglich. Es gibt diverse Details des TCP/IP-Protokolls, die das erschweren (z.B. bestimmte Zähler, die korrekt hochgezählt werden müssen). Allerdings: Wenn jemand die komplette Kommunikation belauschen kann oder bestimmte Dinge ausnutzen kann (wie z.B. nicht zufällig gewählte Startwerte der Zähler), kann durchaus in die Kommunikation eingegriffen werden, ja. Deswegen sollte man wichtige Daten auch kryptographisch absichern, d.h. verschlüsseln und signieren.

Viele Grüße,
Christian

[Tom]

Hello Christian,

hab Dank für die weiteren Erläuterungen.

[...] der Port ist offen

ich werde mir das als Fachterminus also merken.
Ein Port wird als "offen" bezeichnit, wenn ihm ein empfangsbereiteer Handler zugeordnet ist.
Ich hoffe, dass das jetzt richtig ist.

Aber das klärt immer noch nicht die Frage, wie man einen Port nennt, der (wie Du es nennst) einfach nur an der Kommunikation teil nimmt. Also ein Port, über den das OS eine Verbindung eine Kommunikation initiiert hat mit einer Gegenstelle. Darf man hier ohne weiteres auch sagen "Verbindung aufgebaut hat mit einer Gegenstelle"?

So ein Port hat doch einen andern Zustand, als ein unbeteiligter.
Müsste wahrscheinlich dann auch wieder anders ausgedrückt werden?
Man spricht hier von "Port", meint doch aber eigentlich den Status des zugeordneten Programmes.
(Der eigentliche Port auf Hardwareebene hat damit ja nur indirekt zu tun, oder?)

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Ein Port wird als "offen" bezeichnit, wenn ihm ein empfangsbereiteer Handler zugeordnet ist.

Jetzt wirf doch bitte nicht weitere Terminologie in den Raum, die bereits für andere Dinge verwendet wird. Du meinst zwar das richtige, aber es gibt im Bereich TCP/IP schlichtweg keinen Begriff "Handler" - dafür jedoch in anderen Gebieten, die nichts mit TCP/IP zu tun haben, was dann wieder nur totale Verwirrung stiftet.

Wenn Du's formalistisch ganz korrekt haben willst:

Ein Port wird als "offen" bezeichnet, wenn ein Socket, das vorher an den Port gebunden wurde, in den Listen-Modus versetzt wurde.

Oder, wenn Du's lieber einfach - dafür aber ohne Terminologieverirrungen haben willst:

Ein Port wird als "offen" bezeichnet, wenn ein Programm hinter ihm auf Anfragen lauscht.

Aber das klärt immer noch nicht die Frage, wie man einen Port nennt, der (wie Du es nennst) einfach nur an der Kommunikation teil nimmt.

Man gibt ihm gar keinen Namen. Der Port ist wie gesagt eine schlichte Nummer, NICHT MEHR, NICHT WENIGER. Es ist möglich (und wird bei aktivem FTP zum Beispiel auch so eingesetzt), dass von dem SELBEN Port auf der CLIENT-Seite aus multiple Verbindungen initiiert werden - solange es unterschiedliche Ziele sind, kann der Kernel sie eindeutig zuordnen.

Rufe doch bitte mal das Programm netstat auf (gibt's sowohl unter Linux als auch unter Windows, wenn auch die Parameter etwas anders sind). Dort wird Dir eine Tabelle mit Verbindungen angezeigt, die Dein Kernel gerade kennt. Kommt nun ein Paket an, wird geschaut, ob es zu irgend einer Verbindung passt. Sollte dies der Fall sein, sucht sich der Kernel das zugehörige Programm und dort das zugehörige Socket und speichert die neuen Daten im Puffer des Sockets, damit das Programm beim nächsten Aufruf einer Socketfunktion diese Daten abfragen kann. Es gibt schlichtweg keine Tabelle "Port X ist in Zustand Y", nur eine Tabelle mit Verbindungen (und den zugehörigen Programmen). Und wenn ein Programm sich an einen Port bindet und den dann in den Listen-Modus versetzt, dann wird das auch in die Verbindungstabelle geschrieben (netstat zeigt's per Default nur nicht an, nimm -l als Parameter unter Linux, unter Windows weiß ich's nicht) - halt nur mit einer speziellen Kennzeichnung - dann ordnet der Kernel Verbindungsaufbaupakete genauso zu.

Dass man Ports im Sprachgebrauch (!) überhaupt einen Zustand "offen" / "geschlossen" gibt hat praktische Gründe - denn diese Information ist relevant (lauscht hinter diesem Port überhaupt ein Dienst oder nicht?) - aber ob von einem Port jetzt nun eine Verbindung ausgeht oder von einem anderen (die werden ja sowieso zufällig zugewiesen, wenn das Programm nicht explizit einen bestimmten Port will), ist vollkommen irrelevant.

Man spricht hier von "Port", meint doch aber eigentlich den Status des zugeordneten Programmes.

DU sprichst hier von Port, nicht MAN.

(Der eigentliche Port auf Hardwareebene hat damit ja nur indirekt zu tun, oder?)

Herrjemine. Nur, weil "port" der englische Begriff für "Hafen" ist gehst Du doch auch nicht davon aus, dass ein Hafen mit einem TCP-Port auch nur im entferntesten etwas zu tun hat? (Von irgendwelcher Symbolik, die die Etymologie inspiriert haben könnte, mal abgesehen.)

Viele Grüße,
Christian

[Siechfred]

Und wenn ein Programm sich an einen Port bindet und den dann in den Listen-Modus versetzt, dann wird das auch in die Verbindungstabelle geschrieben (netstat zeigt's per Default nur nicht an, nimm -l als Parameter unter Linux, unter Windows weiß ich's nicht) - halt nur mit einer speziellen Kennzeichnung - dann ordnet der Kernel Verbindungsaufbaupakete genauso zu.

Kleine Ergänzung: Unter Windows 2k sollte das der Schalter -a leisten, der alle Verbindungen anzeigt, lauschende werden als "ABHÖREN" aufgeführt.

Herrjemine.

Heißt die nicht Hermine? Naja, ist schon länger her, dass ich Harry Porter gelesen habe...

Siechfred

[Matze]

Hallo,

ich möchte mich bei euch bedanken. Also, Danke! ;-)

Ich kann jetzt endlich behaupten, dass ich es verstanden habe.
Zusammenfassend kann ich also behaupten, dass die Unique_ID
vom Apache anderen Programmen und Scripten zur Verfügung gestellt wird.
Und das nur weil er so freundlich ist und das 'andere Programm oder Script' sie eventuell benötigen könnte.

Das Leben kann so einfach sein :)

Danke nochmals, auch eure ausführlichen Beispiele haben mir sehr geholfen einige Dinge zu verstehen.

Grüße, Matze

[Vinzenz Mai]

Naja Christian,

Herrjemine. Nur, weil "port" der englische Begriff für "Hafen" ist [...]

ich denke, dass Port hier im Englischen eher im Sinne von "Eingang",
"Anschluss" verwendet wird, was der lateinischen Herkunft des Fremdwortes
(in der englischen Sprache) port sicher näher kommt.

porta (lat.): Tor, Tür

Und ein Hafen ist nicht viel mehr als ein Tor zur See, was Du vermutlich
mit der Symbolik der Ethymologie meintest.

Freundliche Grüße

Vinzenz

[bascombe]

he

Leider fehlt mir heut und die kommenden Tage die Zeit mich weiter damit zu beschäftigen,
also werde ich eventuell einen neuen Thread eröffnen, falls dieser hier
bis dato ins Archiv gewandert ist.

Ich würde mich über eine Fortsetzung des interessanten Threads auch freuen.

gruß bascombe

[dedlfix]

echo $begrüßung;

kann mir bitte einer sagen woraus die $_SERVER['UNIQUE_ID'] besteht bzw. woraus sie zusammen gesetzt wird?

Die wird vom Apache-Modul mod_unique_id erzeugt, falls dieses aktiviert ist.

Im PHP-Handbuch habe ich $_SERVER['UNIQUE_ID'] nicht einmal unter den vordefinierten Variablen gefunden.

Beachte dazu den einleitenden Satz im Handbuch: The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here.

Es gibt noch mehr Werte, die der Webserver bereitstellen kann, ohne dass alle im PHP-Handbuch aufgelistet werden (können).

echo "$verabschiedung $name";

[Tom]

Hello,

Eine andere Frage wäre, wozu man diese ID verwenden kann bzw. wofür sie verwendet wird?

Sie wird als Dokument- bzw. Formularzertifikat eingesetzt zur Vermeidung von Reentranzproblemen.

Wenn ein Client ein Formular (mit einer Ressource) mehrfach aufruft, kann man bei logging der noch offnenen "Antworten" vom Client feststellen, in welchen "Thread" die gehören, wenn sie dann eintreffen.

"Antworten" steht hier für Request.

So können Clientdaten auf dem Server in der Session den unterschiedlichen Stati zugeordnet werden.

Man kann sich ein solches Zertifikat natürlich auch selber generieren mit einer Zufallszahl oder sonstigen Methoden, aber die Gefahr ist dann groß, das bei einer Serverfarm doch gelegentlich Doubletten auftreten könnten.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom