Hallo,
ich habe eine dynamische Website (php).
Im ersten Schritt schickt die Website ein Formular mit Post an sich
selbst. Darauf hin wird der Inhalt dynamisch geaendert.
Wenn ich im Browser nach einiger Zeit auf den Reload-Button druecke
(Firefox Strg-R), wird der gleiche Post wieder an die Website geschickt.
Das soll nicht sein.
Deshalb habe ich eine Hilfsloesung: Im HTML-Code befindet sich ein
modifizierter Reload-Link.
1
[a javascript:location.replace(
2
www.website.de/cgi-bin/prog.php)>Reload[/a]
Lieber waere mir, ich koennte es so programmieren, dass durch eine
javascript-Routine die Website (d.h. der Browser, der sie gerade
geoeffnet hat) den Post einfach vergisst.
D.h. Beim ersten Aufruf wird ein Post an die selbst Website geschickt.
Durch diesen 2. Aufruf wird der Inhalt dynamisch geaendert und
vergangegene Post im Browser geloescht.
Beim Druecken auf Reload-Button des Browser erfolgt dann ein dritter
Aufruf der Website ohne Post-Anhang.
Kann man sowas programmieren?
Ich will sie ja nicht automatisch aktualisieren, sondern auf Bedarf,
naemlich wenn der Benutzer auf Reload drueckt.
Nur das erste Post, wenn die Seite das erste Mal im Browser aufgerufen
wird, erfolgt automatisch.
Eine andere Hilfsloesung waere, nach dem ersten Post, d.h. zweiten
Aufruf, gleich mit location.replace() einen dritten Aufruf OHNE Post zu
erzwingen.
Die Loesung muss ich ablehnen, da die Website fuer mobile devices
bestimmt ist, und "Datendurchsatz" und "Zeit zum laden" eine Rolle
spielt.
Mit Ajax habe ich noch nicht soviel gemacht, damit koennte ich
vielleicht was probieren.
Die saubere Lösung des Problems - wenn ich das richtig verstanden habe -
heisst Session (serverseitig). Ob dabei clientseitig mit oder ohne JS
gearbeitet wird, ist nicht so wichtig. Generell sollte man nie eine
Funktionalität von der clientseitigen Verfügbarkeit von JS abhängig
machen.
Eine weitere Möglichkeit, Trafic zu reduzieren besteht in der
Manipulation des HTTP Headers. (Je nach dem, ob es serverseitig die
Änderungen tatsächlich gibt, kann man den Browser dazu bewegen, die
Seite vom Cache zu rendern, und nicht vom Server zu ziehen.)
Firebug und HTTP Spec sind da Deine beste Freunde ;)
>Generell sollte man nie eine>Funktionalität von der clientseitigen Verfügbarkeit von JS abhängig>machen.
Im Prinzip ja. Aber meine Funktionalitaet ist zu speziell, dass ich auf
JS verzichten koennte. Wenn jemand meint, er muesste aus
Sicherheitsgruenden Cookies und JS deaktivieren, dann soll er es halt
bleiben lassen.
Man kann es nie allen recht machen.
Ich braeuchte eine Methode, um von JS den aktuellen POST-Status im
Browser zu manipulieren.
Das muesste m.E. im Objekt windows.location sein, aber da gibt es keine
Funktionen in dieser Richtung.
Jürgen G. schrieb:> Ich braeuchte eine Methode, um von JS den aktuellen POST-Status im> Browser zu manipulieren.
Was meinst du damit? Es gibt kein Status bei POST... Du kannst über JS
POST eines Formulars auslösen. Um die Stati muss man sich selbst
kümmern, z.B. über coockie (kaum empfehlenswert) oder hidden-Felder
(schon etwas besser), oder noch besser - eine einzige SessionID (und der
Rest wird serverseitig gespeichert).
> Das muesste m.E. im Objekt windows.location sein, aber da gibt es keine> Funktionen in dieser Richtung.
Dort kann es sie auch nicht geben! Vergiss nicht, dass windows.location
eigentlich mit GET (und gar nicht mit POST) zu tun hat :)
Und der entscheidende Punkt: HTTP kennt keine Stati (bis auf coockies,
die den Browser ohnehin nicht interessieren und clientseitig - wenn
überhaupt - nur über JS ausgewertet werden können.)
Das ist warum man hier ohne Session (serverseitig) nicht weiter kommt :)
Ich glaube du willst soetwas machen, wie hier im Forum.
Wenn Du einen Beitrag schreibst, wird der per POST abgeschickt, das
generierte Dokument ist dann im Wesentlichen nur ein Redirect
(vermutlich auf GET) auf die Threadanzeige, in der dann der neue Beitrag
zu sehen ist.
Ein Reload bewirkt nun ein Neuladen der Threadanzeige und nicht etwa ein
erneutes Absenden des POST-Requests.
Viele Grüße,
Simon
PS: Gerade nochmal an diesem Posting getestet:
Das POST ergibt ein HTTP/1.1 302 Found, mit der Location
Beitrag "Re: Javascript/HTML: reload() - Problem"
Der Browser macht ein GET auf diese URL und erhält ein
HTTP/1.1 301 Moved Permanently mit der Location
Beitrag "Re: Javascript/HTML: reload() - Problem"
daraufhin macht der Browser noch ein GET und landet in der
Threadanzeige.
Ehrlich gesagt, kann ich deine Schwirigkeiten nicht nachvollziehen... Du
machst doch in PHP, oder? Dort gibt es seit Steinzeit eine durchaus
brauchbare Implementierung der serverseitigen Session. Und die Beispiele
sind auch wie Sand am Meer vorhanden. Warum willsd du unbedingt und auch
freiwillig diesen aussichtlosen JS-Kopfstand machen?
>Und der entscheidende Punkt: HTTP kennt keine Stati (bis auf coockies,>die den Browser ohnehin nicht interessieren und clientseitig - wenn>überhaupt - nur über JS ausgewertet werden können.)
Wenn das JS mit document.form.submit() einen Post abschickt, dann merkt
sich das der Browser irgendwie. Denn nach einen weiteren Reload-Press
wird der/das gleiche Post wieder abgeschickt. Habe ich verifiziert.
Das meinte ich mit 'Status'. Neben der HTML- und der URL-Anzeige ist
noch eine weitere Information vorhanden, die sich der Browser von einem
Seitenaufruf zum naechsten behaelt. Das meinte ich mit Status.
>Ein Reload bewirkt nun ein Neuladen der Threadanzeige und nicht etwa ein>erneutes Absenden des POST-Requests.
So will ich das (nur Neuladen), aber der Browser sendet den Post
nachmals ab.
>Ehrlich gesagt, kann ich deine Schwirigkeiten nicht nachvollziehen... Du>machst doch in PHP, oder? Dort gibt es seit Steinzeit eine durchaus>brauchbare Implementierung der serverseitigen Session. Und die Beispiele>sind auch wie Sand am Meer vorhanden. Warum willsd du unbedingt und auch>freiwillig diesen aussichtlosen JS-Kopfstand machen?
Ich arbeite ja auch mit sessions (selbst implementierte mit Cookies).
Aber das eine hat mit dem anderen in diesem Fall nichts zu tun.
PHP laeuft auf dem Server. Ich brauche aber eine clientseitige Loesung,
damit nicht die gleichen Posts wiederholt verschickt werden.
Ajax koennte eine Loesung sein. Damit kann einen Post verschicken, den
sich der Browser vielleicht nicht merkt. Kann ich aber erst heute abend
testen.
Jürgen G. schrieb:> Wenn das JS mit document.form.submit() einen Post abschickt, dann merkt> sich das der Browser irgendwie.
Ja. Das ist meines Wissens eine nett gemeinte, in der Praxis aber eher
störende Feature des Browsers. Auch bei AJAX stört das mehr als nutzt
(die berühmte Zurück-Button Problematik). Was bleibt, sind die
Workarounds wie Redirect oder die serverseitige Sessionsverwaltung :(
> Ich arbeite ja auch mit sessions (selbst implementierte mit Cookies).
Was war denn schlecht an der PHP-Implementierung? Sie nutzt ein einziges
Sessioncookie zum speichern von ID, macht das aber ziemlich transparent.
Den Client noch stärker zu entlasten ginge kaum :)
> Aber das eine hat mit dem anderen in diesem Fall nichts zu tun.
Schade, eigentlich... das wäre nämlich die einfachste Lösung deines
Problems. Wenn du das aber unbedingt komplizierter haben willst, nimm
einfach die Sourcen von Firefox und schaue, wie das dort implementiert
wurde. Fielleicht kannst du das einfach schnell fixen...
>Ja. Das ist meines Wissens eine nett gemeinte, in der Praxis aber eher>störende Feature des Browsers. Auch bei AJAX stört das mehr als nutzt>(die berühmte Zurück-Button Problematik).
Aha, das wusste ich nicht.
> Was war denn schlecht an der PHP-Implementierung?
Das ganze ist eine ziemlich umfangreiche Angelegenheit.
Da das ganze auf dem Browser eines Smartphone nutzbar sein soll,
bestehen da weitere Einschraenkungen.
Es geht nicht darum, dass die PHP-Statemaschine mit unnoetigen Posts
durcheinander kaeme, sondern dass ich nicht will, dass Daten unnoetig
verschickt werden. Eine menschliche Schwaeche also.
Zumal es sich Zugangsdaten handelt.
Jürgen G. schrieb:> Zumal es sich Zugangsdaten handelt.
Ohje... das scheint noch schlimmer zu sein :( Also, eine nach dem
anderen:
Wenn du die Seite zum ersten mal aufrufst, werden die Daten bereits
verschickt.
1
GET /index.php HTTP/1.1
2
Host: www.mysite.net
3
Accept: */*
Setzt du danach in der Serverantwort ein cookie,
1
HTTP/1.1 200 OK
2
Content-type: text/html
3
Set-Cookie: mycookie=myvalue
wird dieses bei JEDEM nachfolgenden Aufruf (auch bei "nur reload
machen") verschickt, ob du das willst oder nicht:
1
GET /index.php HTTP/1.1
2
Host: www.mysite.org
3
Cookie: mycookie=myvalue
4
Accept: */*
Du kannst natürlich dein Cookie nicht per Response Header, sondern in JS
bereits clientseitig setzen und erst später am Server auswerten. Wenn du
den Client (=einen relativ schwachbrustigen Smartphone) unbedingt mit JS
zum schwitzen/Batterie entleeren bringen willst, kannst du noch mehr
unsinnige Sachen mit erhöhten Spassfaktor anstellen. Was du aber nicht
verhindern kannst ist, dass alle gesetzten Cookies jedesmal brav zum
Server fliegen (und der böse Hacker sie dabei ohne weiteres abgreifen
kann).
Die saubere Lösung ist:
- bei dem ersten Aufruf (wen noch kein cookie da ist) eine
unique-Sessionid am Server generieren und als cookie im Browser setzen
(besser noch - kein Rad neu erfinden, sondern PHP das machen lassen);
- die Authentifizierungsdaten nur EINMALIG zum Server senden, und dort
den Status in der Session merken;
- nach der Authentifizierung über HTTP Redirect zu einer anderen Seite
verweisen, die der Benutzer refreshen kann, bis der Arzt kommt. Da diese
kein Formular enthält, wird auch nichts unnötig gepostet.
Jede andere "Lösung" bedeutet, dass du nicht weniger, sondern mehr Daten
unnötig hin und her fliegen lässt :)
>Wenn du die Seite zum ersten mal aufrufst, werden die Daten bereits>verschickt.
Nee, die werden erst verschickt, nachdem der Benutzer auf dem
HTML-Tastaturfeld (input/button) einen Code (kein Passwort) eingegeben
hat.
Wie man das ohne JS machen kann, wuerde ich gerne wissen.
Und den Code ueber die Smartphone-Tastatur ist nicht dolle.
So was sollte man bedenken.
Danach postet das JS zur php-Seite, diese wertet die Daten aus und
generiert die Session.
>nach der Authentifizierung über HTTP Redirect zu einer anderen Seite>verweisen
Vielleicht geht auch ein Redirect auf die gleiche Seite?!
Ich glaube ich habe die Loesung:
Wenn die Zugangsdaten passen (beim 2. Aufruf durch JS form.submit()),
dann wird nur der Redirect-Header zurueckgeschickt.
Danach erfolgt ein weiterer Aufruf (hoffentlich) ohne Post-Daten
Thread beobachten
Seitenaufteilung abschalten