gerhard <[EMAIL PROTECTED]> writes: > [ eingabe-von bzw ausgabe-an webbrowser gesucht ] > > Wieso versuchst du es nicht mit perl? > weil _ich_ mit perl nicht zurechtkomme.
Perl ist eine write-once/read-never Sprache. Für größere Sachen (und eigentlich auch für kleinere) gehört das schlicht verboten (und ich habe bis heute nicht verstanden, wie ein *Linguist* so etwas verbrechen kann). > > > ausserdem soll eine "session" aufgebaut werden (mit anmeldung > > > bzw authentifizierung per user/password und so), wofür > > Wie willst du das denn machen, über htaccess oder mit Hilfe von Cookies? > cookies will ich vermeiden - htaccess muss ich mir erst anschauen. HTACCESS ist nur eine weitere Einstellungsdatei für den Webserver -- wenn du Zugriff auf den ganzen Webserver hast, kannst du entsprechende Einstellungen auch in dessem zentraler Konfigurationsdatei machen. > > > http als "stateless" protokoll ja nicht so toll geeignet ist. > > Was verstehst du denn unter stateless? > 1) browser sendet anfrage an webserver > 2) webserver schickt antwort (webseite) > 3) ende der aktion > 4) browser sendet neue anforderung, usw > aber es ist nicht sichergestellt, dass die anfragen aus > 1) und 4) zusammengehören - der browser kann theoretisch > einen anderen absenderport wählen, usw. Zumindest schreibt > das protokoll nicht vor, dass der server mehrere hintereinander > erfolgende anforderungen eines clienten als "zusammengehörig" > betrachten muss bzw kann nicht festgestellt werden, ob > eventuell dazwischen anforderung (z.b. durch netzwerkprobleme) > verloren gegangen sind. > Das ganze ist für den ursprünglichen zweck ja auch ok. Von persistenten Verbindungen mal abgesehen, gehören alle Daten, die z.B. in ein Form eingegeben werden zu einer Verbindung, d.h. die werden auch komplett abgeliefert oder es gibt eine Fehlermeldung (hierfür ist TCP zuständig). Nur zwischen verschiedenen Forms gibt es keine direkte Verbindung (aus Sicht des Servers) und er kann ohne persistente Verbindungen auch nicht feststellen, wie lange der Benutzer so benötigt, ob er überhaupt noch etwas macht und von wo nach wo er wandert. Die Persistenz ist also, neben einer Reduzierung des Datenverkehrs und der Serverlast, nur für die Verfolgung des Benutzers innerhalb eines größeren Angebots von Bedeutung. Wenn man die Applikation ereignisorientiert gestaltet und mittels HTTP-AUTH für eine Wiedererkennbarkeit des Benutzers sorgt, dann ist es eigentlich völlig egal, ob die Verbindung nun persistent ist, man also eine session hat, innerhalb der der Benutzer verfolgbar ist, oder nicht. -- Until the next mail..., Stefan. -- ----------------------------------------------------------- Um sich aus der Liste auszutragen schicken Sie bitte eine E-Mail an [EMAIL PROTECTED] die im Subject "unsubscribe <deine_email_adresse>" enthaelt. Bei Problemen bitte eine Mail an: [EMAIL PROTECTED] ----------------------------------------------------------- 938 eingetragene Mitglieder in dieser Liste.
