nicht angemeldet
Frame -> $_GET -> History
Hallo Tüfftler,
Da gibt es so ein hübsches Formular. Mit diesem Formular kann man Formulareinträge an ein anderes Script weitergeben, welches die Daten dann irgendwie verarbeitet.
Bislang wurden die Informationen mit $_POST weiter gegeben. Ein unhübsches Problem ist, das bei einem $_POST und einem Reload der Seite so eine doofe Meldung kommt, die man bestätigen muss. Deshalb habe ich beschlossen, diese Fehlermeldung so zu umgehen, dass ich die Sachen jetzt mit $_GET an das Script weiterleite. Da sich in dem Formular auch keine textareas befinden oder andere Massendaten übergeben werden (sondern eben wirklich nur kleinere Datenmengen), klappt das ganze jetzt auch ganz gut.
Ein Problem ist, dass $_GET die Daten in der URL anzeigt. Da meine Seiten aber in einem Frame eingebettet sind(darüber gibt's keine Diskussion, ist halt so!), und man die URL von den Frames nicht sieht, ist auch dieses Problem aus der Welt!?
Jetzt hab ich jedoch gelesen, dass es bei sowas den Vor- bzw. Nachteil gibt, dass die URL in der History gespeichert wird. Deshalb wollte ich mal fragen, ob Frame-adressen in der History gespeichert werden?
Außerdem hab ich ein dummes Gefühl bei der Sache, die Informationen über die URL zu leiten und nicht "versteckt" in einem $_POST.
Danke
-
Hi.
Ich habe ein ähnliches Problem gehabt.
Du musst dir aber dir Frage stellen, ob du die Daten einmalig senden (und diese beim Reload verwerfen) oder diese jedesmal aufs Neue senden willst.Ich habe die Sache mit einer Kombination gelöst:
- Mehrmals zu sendende Daten (Kategorien, ...) werden encoded
(base64_encode($string)) und als query angehängt: url?query=hion9ibuiv7==
Diese werden zu Beginn des Scripts wieder decoded. - Einmal zu sendende Dateien in POST-Methode:
senden, dann das gesamte POST-Query in $_SESSION abspeichern,
beim nächsten senden die gleichheit ausschließen.
Vielleicht nicht der Königsweg, aber mir hat's geholfen.
mfg,
Osiris - Mehrmals zu sendende Daten (Kategorien, ...) werden encoded
-
Hi,
Bislang wurden die Informationen mit $_POST weiter gegeben. Ein unhübsches Problem ist, das bei einem $_POST und einem Reload der Seite so eine doofe Meldung kommt, die man bestätigen muss. Deshalb habe ich beschlossen, diese Fehlermeldung so zu umgehen, dass ich die Sachen jetzt mit $_GET an das Script weiterleite.
Dieser Weg der Entscheidungsfindung ist reichlich unsinnig.
Grundsaetzlich gilt die Faustregel:
-
GET fuer Requests, die wiederholbar die gleichen Parameter uebergeben sollen, und das unabhaengig davon, welcher Nutzer den Request macht. Also bspw. fuer die Anforderung des Ergebnislistungs einer Suchmaschine wie Google, das ich damit bequem verlinken und fuer andere ebenfalls nutzbar machen kann.
-
POST fuer individuelle, nur den jeweiligen Nutzer betreffende Daten - bspw. meinen Login irgendwo, oder auch den Text, den ich hier gerade verfasse und an den Server POSTen werde - den verfasst naemlich kein anderer ausser mir.
Die Entscheidungsfindung hingegen davon abhaengig zu machen, ob bspw. ein Browser beim Reload ggf. nachfragt, ob man wirklich die gleichen Daten erneut senden will, ist bloedsinnig.
Im Falle des Abrufs eines Suchergebnisses moechte ich das vielleicht wirklich - um zu sehen, ob sich etwas am Ergebnis geaendert hat. Bei Request ueber GET problemlos moeglich, und da fragt mein Browser auch nicht nach, ob ich mir wirklich sicher bin, dass ich das will.
Bei einem Forenposting wie diesem hier, welches ich gleich per POST abschicken werde, wuerde mein Browser normalerweise bei einem anschliessenden Reload nachfragen, ob ich wirklich die gleichen Daten nochmal senden moechte - moechte ich hoechstvermutlich nicht, denn wer will schon meinen gleichen Senf in zwei Postings zum Lesen vorgesetzt bekommen ...Also treffe die Entscheidung darueber, welche Methode die geeignetere ist, danach, welche "Art" von Daten zu uebermitteln sind - und nicht danach, ob dir irgendwelche Browser-Nachfragen *dir* "doof" erscheinen.
(Wenn du die Meldung vermeiden willst, kannst du bspw. nach dem Empfang des POST-Requests auf eine per GET anzufordernde Ressource weiterleiten lassen - dann kommt beim anschliessenden Reload keine Meldung mehr, weil dann nur der GET-Request erneut ausgefuehrt wird.)
Ein Problem ist, dass $_GET die Daten in der URL anzeigt.
Siehste, da raecht es sich schon, die *falsche* Methode zu benutzen.
Da meine Seiten aber in einem Frame eingebettet sind(darüber gibt's keine Diskussion, ist halt so!), und man die URL von den Frames nicht sieht, ist auch dieses Problem aus der Welt!?
Aua.
Denkst du ueber diese Argumentation selber noch mal nach - oder soll *ich* dir gleich sagen, fuer wie meschugge ich sie halte ...?Jetzt hab ich jedoch gelesen, dass es bei sowas den Vor- bzw. Nachteil gibt, dass die URL in der History gespeichert wird. Deshalb wollte ich mal fragen, ob Frame-adressen in der History gespeichert werden?
Kommt drauf an - auf den Browser. Moeglicherweise ja, moeglicherweise nein.
Da du $browser aber gar nicht kennst, kannst du darueber keinerlei Aussage treffen. (Genausowenig wie bspw. darueber, ob $browser, den du nicht kennst, ueberhaupt die von dir nicht zur Diskussion gestellten Frames ueberhaupt anzeigen kann/mag/darf ...)Außerdem hab ich ein dummes Gefühl bei der Sache, die Informationen über die URL zu leiten und nicht "versteckt" in einem $_POST.
Gut, dann scheint ja doch ein gewisses Masz an logischem Denkvermoegen vorhanden zu sein :-)
Mit Hilfe der vorgetragenen argumentativen Untermauerung kommst du dann jetzt sicher zum richtigen Schluss.MfG ChrisB
-
Hi,
Bislang wurden die Informationen mit $_POST weiter gegeben. Ein unhübsches Problem ist, das bei einem $_POST und einem Reload der Seite so eine doofe Meldung kommt, die man bestätigen muss. Deshalb habe ich beschlossen, diese Fehlermeldung so zu umgehen, dass ich die Sachen jetzt mit $_GET an das Script weiterleite.
Dieser Weg der Entscheidungsfindung ist reichlich unsinnig.
Grundsaetzlich gilt die Faustregel:
-
GET fuer Requests, die wiederholbar die gleichen Parameter uebergeben sollen, und das unabhaengig davon, welcher Nutzer den Request macht. Also bspw. fuer die Anforderung des Ergebnislistungs einer Suchmaschine wie Google, das ich damit bequem verlinken und fuer andere ebenfalls nutzbar machen kann.
-
POST fuer individuelle, nur den jeweiligen Nutzer betreffende Daten - bspw. meinen Login irgendwo, oder auch den Text, den ich hier gerade verfasse und an den Server POSTen werde - den verfasst naemlich kein anderer ausser mir.
Ich habe gelesen, man solle GET verwenden, um Daten zu übertragen, die für die Steuerung der nächsten Seite wichtig sind. POST hingegen soll verwendet werden, wenn rein inhaltliche Daten übertragen werden, die die nachfolgende Seite nicht beeinflussen.
-
Hallo Denker,
Ich habe gelesen, man solle GET verwenden, um Daten zu übertragen, die für die Steuerung der nächsten Seite wichtig sind. POST hingegen soll verwendet werden, wenn rein inhaltliche Daten übertragen werden, die die nachfolgende Seite nicht beeinflussen.
Dann hast du entweder irgendeinen Mist gelesen, oder das gelesene nicht verstanden.
POST benutzt man, wie der Name schon sagt, um dem Server irgendwelche Daten mitzuteilen. Z.B. wenn man sich einloggt, wenn man einen Forenbeitrag schreibt, wenn man ein Kontaktformular ausfüllt, wenn man eine komplexere Abfrage startet usw. bzw. allgemein immer, wenn man irgendeine komplexere/dauerhafte Aktion auf dem Server ausführen will. Browser führen POST-Abfragen nicht mehrmals aus, sondern warnen den Benutzer z.B. mein Zurück-Gehen, dass die Aktion dann evtl. nochmal ausgeführt wird.
GET benutzt man, wenn man irgendwas vom Server abfragt, die GET-Parameter um diesem mitzuteilen, was man gerne hätte. GET-Requests verursachen im allgemeinen keine komplexeren/dauerhaften Aktionen auf dem Server (mal abgesehen von Statistiken usw.) und sind dafür gedacht, einfach normale mehr oder weniger statische Seiten abzuholen. GET-Abfragen sind dafür gedacht, auch mehrmals gemacht zu werden.
Jonathan
-
-