session id übergeben

[trunx]

Hallo Forum,

ich möchte nach wie vor Werte von einem Script zum anderen übergeben, u.z. direkt auf dem Server und dafür wurde mir hier u.a. die Nutzung von Sessions empfohlen. So weit, so gut...was ich dabei ein bisschen anstrengend finde ist, dass das Script natürlich versucht auf dem Client-Rechner Cookies abzulegen und das bringt Probleme:
1. gibt es eine Möglichkeit die Cookies für diesen Fall auf dem Server abzulegen (ich hab session_set_cookie_params() probiert) oder wahlweise ganz auszuschalten?
2. die einzige andere Möglichkeit, die session id zu übertragen, ist per GET im header() Aufruf, gibt es eine äquivalente Möglichkeit (also per header) für POST?
3. Welche andere Möglichkeit der Datenübergabe gibt es noch?

bye trunx

[Tom]

Hello,

1. gibt es eine Möglichkeit die Cookies für diesen Fall auf dem Server abzulegen (ich hab session_set_cookie_params() probiert) oder wahlweise ganz auszuschalten?

Einmal wird es ja auf dem Server gespeichert, aber das reicht nicht für den verfolgten Zweck.

HTTP ist in der Grundlage ein verbindungs- und zustandsloses Protokoll. Das bedeuetet grob betrachtet, dass nach erfolgter Response des Servers auf den Request vom Client keine Verbindung mehr besteht und der Server den Client auch nicht mehr kennt. Das bedeutet also, dass er sich auch nicht merken kann für den Client.

Durch die Einführung von Cookies hat man nun künstlich eine "Wiederverbindung" und damit eine Zustandsorientierung möglich gemacht. Der Server sendet dem Client ein Cookie mit. Dieser sendet das Cookie in Zukunft bei jedem Request an die URL, von der er es erhalten hat, wieder mit.

Dadurch kann der Server feststellen, welcher Client denn da was von ihm will bzw., dass dieser schon vorher einen Request gesendet hatte. Er kann also unter dieser Kennung Daten für den Client aufheben.

Das nennt man dann "eine Session führen".

Das hat noch nichts mit "Anmeldung" und "Rechten" zu tun, wird aber immer gerne in einen Topf geworfen. Eine Sesssion kann aber für eine "Anmeldung" die Basis bilden. Dafür sind dann nur noch wenige weitere Schritte notwendig.

Alternativ zu Cookies gäbe es noch die Möglichkeit von Basic Athentication, um mit dem Client eine Session zu führen. Dann öffnet sich aber am Client das "hässliche Anmeldefenster", wenn die Authentifizierungsphase begonnen werden soll.

Liebe Grüße aus Syburg

Tom vom Berg

[trunx]

Hallo,

Das nennt man dann "eine Session führen".

ich habe bereits in der Vergangenheit für Logins zu bestimmten Bereichen mit sessions gearbeitet (da es funktionierte, habe ich aber nicht weiter über die genaue Arbeitsweise nachgedacht :-) )...hier geht es um etwas anderes, den Austausch von Daten zwischen zwei Serverscripts. Ein Formular kommt daher nicht in Frage, mit fsockopen und fputs verbleibe ich in Script1 und komme nicht wirklich zu Script2, mit header() und GET möchte ich nicht arbeiten, weil ich nicht ständig an die Urls irgendwelche Parameter rangehängt haben will; sie auf dem Server zu speichern, ist sinnvoll, doch dazu müßte für jeden Scriptaufruf eine spezielle Datei abgespeichert und wenigstens der Name dieser Datei weitergereicht werden. Und das klingt doch schon nach sessions. Und deshalb wüßte ich ganz gern, was genau bei session_start() passiert. Woher weiß das Script an dieser Stelle, dass es bereits eine session id gibt? usw. wie gesagt am besten wäre es, wenn das Script1 ein cookie auf den Server legen würde, also auch für diesen Fall, dahin wo es hingehört und Script2 es dort auch findet...

bye trunx

[ChrisB]

Hi,

Und deshalb wüßte ich ganz gern, was genau bei session_start() passiert. Woher weiß das Script an dieser Stelle, dass es bereits eine session id gibt?

Weil der Client die Session-ID mit dem Request übergeben hat - per COOKIE, GET oder POST.

usw. wie gesagt am besten wäre es, wenn das Script1 ein cookie auf den Server legen würde,

Cookies "liegen" auf dem Client, begreife das bitte langsam mal.

MfG ChrisB

[trunx]

Hallo,

Weil der Client die Session-ID mit dem Request übergeben hat - per COOKIE, GET oder POST.

gut, das ist jetzt zwar nichts, was ich nicht schon wüßte, wie sieht aber ein Request von einem serverseitigen Script aus? Wie gesagt, mit fputs könnte man einen solchen Request aufbauen, aber er ist nicht zugleich mit einer Weiterleitung an das verarbeitende Script verbunden, wie das bei header() und GET oder auch Client-Server_Requests der Fall ist.

Cookies "liegen" auf dem Client, begreife das bitte langsam mal.

kein Grund persönlich zu werden, lieber Freund :-)
schau dir bitte die Funktion session_set_cookie_params() an, dort ist die Möglichkeit vorgesehen, Cookies auch an anderen Stellen zu speichern, soweit ich das verstanden hab.

bye trunx

[Tom]

Hello,

[...] wie sieht aber ein Request von einem serverseitigen Script aus?

Mal doch bitte ein Bild für uns.
So können wir dich nicht verstehen.

Was ist wo gespeichert?
Welcher Server läuft auf dem Host?
Wer soll den Vorgang anstoßen und was soll Schritt für Schritt Deiner Meinung nach dann geschehen?

Wir wollen Dir ja gerne helfen, aber Du resest zur Zeit noch eine unverständliche Sprache ;-)

Liebe Grüße aus Syburg

Tom vom Berg

[trunx]

Hallo,

Wir wollen Dir ja gerne helfen, aber Du resest zur Zeit noch eine unverständliche Sprache ;-)

ok :-)

Ich habe ein Formular mit umfangreichen Eingaben: formular.php
desweiteren ein Verarbeitungsscript: verarbeitung.php
und mehrere Ausgabescripte: ergebnis1.php ergebnis2.php ...

bisher waren das Verarbeitungsscript und die Ausgabescripte ein (mittlerweile extrem unübersichtlich gewordenes) Script, aber da gab es logischerweise keine Probleme bei der Parameterübergabe.

Jetzt möchte ich, dass je nach Ergebnis verschiedene Ausgabescripte angesprochen werden und die entsprechenden Parameter dafür erhalten; desweiteren sollen die Ausgabescripte auch so heißen wie ihr Ergebnis (Hintergrund ist der Gedanke, dass eine Seite nach ihrem Inhalt benannt und nicht alles in eine index.php reingeworfen werden sollte).

Bei einem Client-Server-Request per POST sähe das so aus:

  
<form action="ergebnis.php" method="post">  
<input type="hidden" name="data1" value="xyz">  
<input type="submit">  
</form>  

Bei einem Server-Server-Request per POST sieht das dagegen so aus:

  
$fp = fsockopen($host, $port);  
fputs($fp, "POST $path HTTP/1.0\n");  
fputs($fp, "Host: $host\n");  
fputs($fp, "Content-type: multipart/form-data;\n");  
$data = "Content-Disposition: form-data; name=\"".$data1."\"\n\n".$value1."\n";  
fputs($fp, "Content-length: ".strlen($data)."\n\n");  
fputs($fp, $data);

Die Antwort wird in beiden Fällen an das fragende Programm zurückgeschickt, also im ersten Fall an den Browser des Clienten, im zweiten Fall ans Script, doch das ist es nicht, was ich möchte, die Antwort soll auch im zweiten Fall an den Browser des Clienten geschickt werden und da fällt mir nur ein redirect ein (was ja mit header() und GET passiert).

So ich hoffe, jetzt wurde die Sache klarer, es muss doch möglich sein, dass man sich versteht :-)

bye trunx

[ChrisB]

Hi,

bisher waren das Verarbeitungsscript und die Ausgabescripte ein (mittlerweile extrem unübersichtlich gewordenes) Script, aber da gab es logischerweise keine Probleme bei der Parameterübergabe. [...]
Jetzt möchte ich, dass je nach Ergebnis verschiedene Ausgabescripte angesprochen werden und die entsprechenden Parameter dafür erhalten;

Dann lagere in sich geschlossene Scriptteile in Dateien aus, die du mittels include/require nach Bedarf einbindest oder nicht.

desweiteren sollen die Ausgabescripte auch so heißen wie ihr Ergebnis (Hintergrund ist der Gedanke, dass eine Seite nach ihrem Inhalt benannt und nicht alles in eine index.php reingeworfen werden sollte).

Wie gesagt, lagere serverseitig aus, wenn du die Übersichtlichkeit erhöhen willst.

Wenn es auch nach aussen hin getrennte Ressourcen sein sollen - dann sorge dafür, dass sie über unterschiedliche Adresse gezielt ansprechbar sind.

Die Antwort wird in beiden Fällen an das fragende Programm zurückgeschickt, also im ersten Fall an den Browser des Clienten, im zweiten Fall ans Script, doch das ist es nicht, was ich möchte, die Antwort soll auch im zweiten Fall an den Browser des Clienten geschickt werden und da fällt mir nur ein redirect ein (was ja mit header() und GET passiert).

Bitte vergiss die Idee, dass sich zwei Scriptinstanzen auf dem Server gegenseitig aufrufen, komplett wieder. Das verkompliziert das ganze nur unnötig, und führt zu erheblichem Overhead - es ist in diesem Szenario schlicht blödsinnig.

MfG ChrisB

[trunx]

Hallo,

Wenn es auch nach aussen hin getrennte Ressourcen sein sollen - dann sorge dafür, dass sie über unterschiedliche Adresse gezielt ansprechbar sind.

daran hatte ich auch schon gedacht - etwa so

  
if($erg==1)  
  header("Location:http://".$_SERVER['HTTP_HOST']."/ergebnis.php?erg=1")  
elseif($erg==2)  
  header("Location:http://".$_SERVER['HTTP_HOST']."/ergebnis.php?erg=2")  
...usw.  

und dann mit mod rewrite diese umwandeln in ergebnis1.html usw.
hmm, also wenn die andere Idee nicht funktioniert, muss ich es wohl so machen...aber ok, auch dir erstmal vielen Dank :-)

ciao trunx

[ChrisB]

Hi,

daran hatte ich auch schon gedacht - etwa so

if($erg==1)
  header("Location:http://".$_SERVER['HTTP_HOST']."/ergebnis.php?erg=1")
elseif($erg==2)
  header("Location:http://".$_SERVER['HTTP_HOST']."/ergebnis.php?erg=2")
...usw.

  
Warum willst du denn auf Teufel komm raus immer per Header irgendwohin umleiten?  
  
Mein Client hat einen Request geschickt, also verarbeite ihn, und liefere mir ein Ergebnis.  
Warum zum Geier soll mein Client den fortwährend neue Ressourcen anfordern?  
  
MfG ChrisB  
  

-- 
Light travels faster than sound - that's why most people appear bright until you hear them speak.

[trunx]

Hallo,

Warum willst du denn auf Teufel komm raus immer per Header irgendwohin umleiten?

ich bin nicht festgelegt, sondern ganz im Gegenteil offen für Ideen, es muss halt nur letztlich funktionieren - an was dachtest du?

bye trunx

[ChrisB]

Hi,

ich bin nicht festgelegt, sondern ganz im Gegenteil offen für Ideen, es muss halt nur letztlich funktionieren - an was dachtest du?

Das schrieb ich eben schon, Sven schlägt das ebenfalls vor ... was brauchst du denn jetzt *noch*?

MfG ChrisB

[trunx]

Hallo,

Das schrieb ich eben schon: "Wenn es auch nach aussen hin getrennte Ressourcen sein sollen - dann sorge dafür, dass sie über unterschiedliche Adresse gezielt ansprechbar sind."

darum geht es, da ist doch include() wohl nicht die Lösung...deshalb meine Nachfrage an was du dachtest.

bye trunx

[ChrisB]

Hi,

Das schrieb ich eben schon: "Wenn es auch nach aussen hin getrennte Ressourcen sein sollen - dann sorge dafür, dass sie über unterschiedliche Adresse gezielt ansprechbar sind."

darum geht es, da ist doch include() wohl nicht die Lösung...deshalb meine Nachfrage an was du dachtest.

Siehe meine andere, gerade eben erfolgte Antwort.

Wenn die Auswahl der Ergebnisseite dem Client obliegen würde, dann könnte ich da evtl. noch einen gewissen Sinn drin sehen - aber wenn der Server diese Entscheidung erst auf Grund der Formulareingaben, die er erhält, trifft, dann halte ich verschiedene Adressen, die Antworten liefern, für keine gute Idee.

Bevor du (Client) fragst, wie spät es ist, kannst du dir gerne überlegen, an wen du diese Frage stellen möchtest.
Wenn du aber erst mal mich (Server) gefragt hast - welchen Sinn soll es dann haben, wenn ich (auf Grund irgendwelcher Gedankengänge, die nur mir bekannt sind) mal auf Person A, mal auf Person B, und dann wenn mir danach ist auch mal auf Person Z verweise - damit diese dir dann die Frage beantworten sollen?
Das macht absolut nichts "übersichtlicher" - und eben das war ja dein anfangs erklärtes Ziel.

MfG ChrisB

[trunx]

Hallo,

Wenn die Auswahl der Ergebnisseite dem Client obliegen würde, dann könnte ich da evtl. noch einen gewissen Sinn drin sehen - aber wenn der Server diese Entscheidung erst auf Grund der Formulareingaben, die er erhält, trifft, dann halte ich verschiedene Adressen, die Antworten liefern, für keine gute Idee.

Durch das spez. Ausfüllen des Formulars obliegt es ja dem Clienten letzlich, was für ein Ergebnis ausgewählt wird, aber ich sage es mal so (um mal dein Beispiel mit der Uhrzeit fortzuführen) - wenn du mich fragst, wie spät es ist, sollte ich dir schon die Uhrzeit sagen, aber wie ich es tue, dass ist letzlich meine Sache. In diesem Falle gehört halt zum "Wie", dass ich die Ausgaben auch äußerlich trennen möchte...

Mittlerweile denke ich, dass es doch mit sessions gelöst werden sollte, die Idee mit header("location:...?erg=1") usw. funktioniert nicht.

bye trunx

[Tom]

Hello,

Durch das spez. Ausfüllen des Formulars obliegt es ja dem Clienten letzlich, was für ein Ergebnis ausgewählt wird, aber ich sage es mal so (um mal dein Beispiel mit der Uhrzeit fortzuführen) - wenn du mich fragst, wie spät es ist, sollte ich dir schon die Uhrzeit sagen, aber wie ich es tue, dass ist letzlich meine Sache. In diesem Falle gehört halt zum "Wie", dass ich die Ausgaben auch äußerlich trennen möchte...

Äußerlich "trennen" heißt abwer auch, sie einzeln und aus dem Zusammenhang gerissen von außen zugänglich machen. Das sollte man sich immer überlegen, ob ein Script direkt zugänglich sein sollte, ohne vorher irgend ein anderes der Seite benutzt zu haben.

Wenn Script-TEILE aber nur dann eingebunden werden, wenn die Steuerlogik dies anfordert, dann sind sie über HTTP i.d.R. nicht erreichbar.

Überlege also, was du brauchst.

Liebe Grüße aus Syburg

Tom vom Berg

[trunx]

Hallo,

ich hab hier viele Anregungen bekommen und denke nun, dass ich die Parameterübergabe mit sessions mache (die auch äußerlich getrennten Seiten werde ich nun wohl auch ohne Formular mit allgemeinen Infos zugänglich machen), aber es stellt sich nun folgendes Problem - was macht man eigentlich, wenn ein User cookies nicht erlaubt?

Und noch eine Verständnisfrage: wenn ich eine session starte, was genau passiert da? Ich dachte bisher, dass dann in den header der Antwort die Zeile eingefügt wird "cookie: name=WERT\n" und dass dann der Browser daraus das eigentliche cookie strickt und auf dem Client-Rechner ablegt und bei weiteren Requests darauf zugreift und in den header des Requests wieder "cookie: name=WERT\n" einfügt, woraus ein script beim Aufruf von session_start() die SID ausliest... aber so scheint das nicht zu laufen. Wie dann? Wird das Session-Cookie extra gesendet?

bye trunx

[trunx]

Hallo Forum,

ich habe es jetzt verstanden: mit session_start() wird der header-Teil für das cookie generiert und zusammen mit header("location:...") an den Browser geschickt (ob zusammen oder nacheinander ist irrelevant), wenn jetzt der Browser cookies gestattet, wird eines erzeugt, location:... ist dagegen ein redirect, d.h. der Browser schickt quasi sofort einen Request, der auch cookie-Informationen enthält, sofern erlaubt.

D.h. mein Fehler bestand in der irrigen Annahme, dass es eine direkte Kommunikation zwischen den beiden Serverscripts gibt, tatsächlich ist es aber eine Abfolge von Server-Client-Responses und Client-Server-Requests

hmm, gebraucht hätte ich eine direkte Kommunikation zwischen den beiden Serverscripts, aber gut, jetzt weiß ich erstmal Bescheid...

bye trunx

[Sven Rautenberg]

Moin!

daran hatte ich auch schon gedacht - etwa so

if($erg==1)
  header("Location:http://".$_SERVER['HTTP_HOST']."/ergebnis.php?erg=1")
elseif($erg==2)
  header("Location:http://".$_SERVER['HTTP_HOST']."/ergebnis.php?erg=2")
...usw.

  
Unsinnig, weil viel zu kompliziert.  
  
~~~php
  
if($erg==1)  
  include 'script1.php';  
elseif($erg==2)  
  include 'script2.php';  
...usw.  

Und in den Skripten sind dann die jeweils notwendigen Ergebnisbearbeitungen.

- Sven Rautenberg

[trunx]

Hallo,

Unsinnig, weil viel zu kompliziert.

der Sinn besteht darin, die unterschiedlichen Ergebnisgruppen (also $erg=1,2,...) auch nach außen hin, also in der Adresszeile des Browsers darzustellen, es geht mir nicht nur darum, ein unübersichtlich gewordenes Script zu teilen ;-)

bye trunx

[ChrisB]

Hi,

der Sinn besteht darin, die unterschiedlichen Ergebnisgruppen (also $erg=1,2,...) auch nach außen hin, also in der Adresszeile des Browsers darzustellen

Warum?

Dein gezeigtes Beispiel wollte das von $erg gleich 1 oder 2 abhängig machen.
Wo wird $erg ermittelt - serverseitig im Script, auf Grund der berechneten Daten? Dann sehe ich keinen Grund, das Ergebnis unter verschiedenen URLs zur Verfügung zu stellen.

Du sagst, du hast ein Formular, in dem der Nutzer umfangreiche Eingaben machen soll. Was interessiert es den Nutzer, unter welcher Adresse er die Antwort bekommt?
Ich fülle ein Formular aus, ich bekomme eine - wie auch immer geartete - Antwort, mehr interessiert mich als Nutzer doch nicht.
Was sollen unterschiedliche Adressen, auf die weitergeleitet wird, daran für mich als Nutzer "übersichtlicher" machen?

Was anderes wäre das ggf., wenn diese Adressen sich jeweils "auch so" direkt abrufen liessen, und dann unterschiedliche Ergebnisse liefern würden - man sie also direkt verlinken könnte, und sie keine weiteren Nutzereingaben erfordern würden.

Aber für ein Ergebnis, welches ganz spezifisch von den Eingaben, die ich im Formular mache, abhängig ist - da ergeben multiple Antwortadressen m.E. überhaupt keinen Sinn.

MfG ChrisB

[ChrisB]

Hi,

Weil der Client die Session-ID mit dem Request übergeben hat - per COOKIE, GET oder POST.

gut, das ist jetzt zwar nichts, was ich nicht schon wüßte,

Wieso fragst du dann?

wie sieht aber ein Request von einem serverseitigen Script aus?

Dann ist, auch das wurde dir bereits gesagt, der anfragende Server in diesem Falle der Client.

Cookies "liegen" auf dem Client, begreife das bitte langsam mal.

kein Grund persönlich zu werden, lieber Freund :-)
schau dir bitte die Funktion session_set_cookie_params() an, dort ist die Möglichkeit vorgesehen, Cookies auch an anderen Stellen zu speichern, soweit ich das verstanden hab.

Dann lies es noch mal, bis du's verstanden hast.

MfG ChrisB

[trunx]

Hallo,

Dann ist, auch das wurde dir bereits gesagt, der anfragende Server in diesem Falle der Client.

schön, vllt hast du ja Recht :-), dann sage mir doch bitte wie ich mit meinem "Client" php-Script einen Post-Request inkl. Redirect auf das verarbeitende Script lostreten kann (wie es bei einem tatsächlichen Client mit einem entsprechendem Formular möglich ist)...

bye trunx

[ChrisB]

Hi,

dann sage mir doch bitte wie ich mit meinem "Client" php-Script einen Post-Request inkl. Redirect auf das verarbeitende Script lostreten kann (wie es bei einem tatsächlichen Client mit einem entsprechendem Formular möglich ist)...

Weder ein POST-Request per Script (Googlen, wenn nicht bekannt) noch ein Redirect sollten ein Problem darstellen.
Was problematisch sein kann, ist das Ergebnis dann wieder vom Server, der den Client spielen soll, an den tatsächlichen Client weiterzugeben.

Aber sage du uns doch bitte erst (und endlich) mal, was du eigentlich vor hast - siehe auch Toms entsprechende Rückfrage. Ohne das zu wissen, kann man nämlich viel und lange herum-theoretisieren.

MfG ChrisB

[trunx]

Hallo,

Weder ein POST-Request per Script (Googlen, wenn nicht bekannt) noch ein Redirect sollten ein Problem darstellen.

richtig; aber beides in einem schon, sonst würde ich nicht fragen ;-)

Was problematisch sein kann, ist das Ergebnis dann wieder vom Server, der den Client spielen soll, an den tatsächlichen Client weiterzugeben.

langsam verstehen wir uns ...

Aber sage du uns doch bitte erst (und endlich) mal, was du eigentlich vor hast

siehe etwas tiefer

bye trunx

[Tom]

Hello,

schön, vllt hast du ja Recht :-), dann sage mir doch bitte wie ich mit meinem "Client" php-Script einen Post-Request inkl. Redirect auf das verarbeitende Script lostreten kann (wie es bei einem tatsächlichen Client mit einem entsprechendem Formular möglich ist)...

Da such doch einfach mal hier im Archiv und bei Google nach "post2host".
Da solltet Du fündig werden.

Dann solltest Du noch danach suchen, wie ein Cookie im HTTP-Header einzubinden ist.

Wenn Du allerdings auch noch Formulardaten übertragen willst, wird es schon etwas komplizierter. Aber dafür findest Du unter dem Thema post2host garantiert auch etwas im Netz.

Und noch eine Bitte:
Wenn Du es fertig hast, poste hier bitte Die Lösung nebst aussagefähiger Beschreibugn ;-)

Soltest Du aber noch Fragen zu den gefundenen Lösungsansätzen haben, melde Dich wieder unter genauer Angabe der Schwierigkeiten und des relevanten Codes, nebst Kontroll- und Fehlermeldungen.

Liebe Grüße aus Syburg

Tom vom Berg

[trunx]

Hallo,

Dann solltest Du noch danach suchen, wie ein Cookie im HTTP-Header einzubinden ist.

ich glaube, das könnte es sein, mal probieren...
erstmal danke :-)

bye trunx

[Cheatah]

Hi,

1. gibt es eine Möglichkeit die Cookies für diesen Fall auf dem Server abzulegen (ich hab session_set_cookie_params() probiert)

wie willst Du jemanden wiedererkennen, wenn Du ihm das Wiedererkennungsmerkmal vorenthältst? Um einem User den serverseitig gespeicherten Cookie[1] zuzuordnen, müsste er Dir die selbe Information schicken, die üblicherweise einem clientseitig gespeicherten Cookie entstammt.

oder wahlweise ganz auszuschalten?

Warum willst Du das?

2. die einzige andere Möglichkeit, die session id zu übertragen, ist per GET im header() Aufruf,

Per GET, ob Header oder nicht.

gibt es eine äquivalente Möglichkeit (also per header) für POST?

Es gibt außer einem Formular mit method="post" *keine* Möglichkeit für Dich, Daten zwischen Client und Server mittels der POST-Methode auszutauschen.

3. Welche andere Möglichkeit der Datenübergabe gibt es noch?

Warum hältst Du Cookies für etwas dermaßen Schlimmes?

Cheatah

[1] Was es genau deswegen nicht gibt

[trunx]

Hallo,

danke für deine Antwort.

Es gibt außer einem Formular mit method="post" *keine* Möglichkeit für Dich, Daten zwischen Client und Server mittels der POST-Methode auszutauschen.

der Punkt ist aber der, dass ich Daten zwischen zwei Serverscripts austauschen möchte (siehe meinen ersten Beitrag) - ansonsten gebe ich dir was die Kommunikation zwischen Client und Server betrifft vollkommen Recht...

bye trunx

[Tom]

Hello,

der Punkt ist aber der, dass ich Daten zwischen zwei Serverscripts austauschen möchte (siehe meinen ersten Beitrag) - ansonsten gebe ich dir was die Kommunikation zwischen Client und Server betrifft vollkommen Recht...

Wie meinst Du das?

Soll Host A mittels PHP bei Host B einen Request durchführen?
Dann wäre Host A ein Client und Host B ein Server.

Liebe Grüße aus Syburg

Tom vom Berg

[trunx]

Hi,

» der Punkt ist aber der, dass ich Daten zwischen zwei Serverscripts austauschen möchte (siehe meinen ersten Beitrag) - ansonsten gebe ich dir was die Kommunikation zwischen Client und Server betrifft vollkommen Recht...

Wie meinst Du das?

Soll Host A mittels PHP bei Host B einen Request durchführen?
Dann wäre Host A ein Client und Host B ein Server.

beide Scripte sind Teil eines umfangreicheren Programms und liegen im selben Verzeichnis auf dem Server.

bye trunx

[Alexander (HH)]

Moin Moin!

beide Scripte sind Teil eines umfangreicheren Programms und liegen im selben Verzeichnis auf dem Server.

Dann arbeite nicht über HTTP, sondern nutze lokale Kommunikationswege.

Alexander

[trunx]

Hallo,

Dann arbeite nicht über HTTP, sondern nutze lokale Kommunikationswege.

gerne :-) aber wie, was meinst du damit konkret?

bye trunx

[Alexander (HH)]

Moin Moin!

»» Dann arbeite nicht über HTTP, sondern nutze lokale Kommunikationswege.

gerne :-) aber wie, was meinst du damit konkret?

Wie bindet man ein PHP-Script in ein anderes ein? Wie führt man ein lokales Programm aus? Beides verrät Dir die PHP-Doku.

Alexander

[trunx]

Hi,

... Beides verrät Dir die PHP-Doku.

schön, dass auch du dich geäußert hast :p
ich hab echt überlegt, das irgendwie in mein Signum aufzunehmen, aber deine Antwort ist besser als andere Standard-Antworten, sie macht das ganze Forum überflüssig, schlag doch bitte die Schließung vor...

bye trunx

[Alexander (HH)]

Moin Moin!

Es gibt außer einem Formular mit method="post" *keine* Möglichkeit für Dich, Daten zwischen Client und Server mittels der POST-Methode auszutauschen.

*hust* XMLHttpRequest *hust*

Alexander

[Cheatah]

Hi,

»» Es gibt außer einem Formular mit method="post" *keine* Möglichkeit für Dich, Daten zwischen Client und Server mittels der POST-Methode auszutauschen.
*hust* XMLHttpRequest *hust*

sorry, ich hätte klarer machen sollen, dass ich vom Server initiierte Kommunikation meinte.

Cheatah