HTTPApp.TWebResponse und Cookies

[bcvs]

Hallo zusammen,

ich fange gerade an, eine bestehende PHP-Webanwendung auf Delphi mit WebBroker umzustellen. Soll später eine ISAPI-DLL werden, derzeit zu Testzwecken noch eine Standalone-Exe.

Momentan kämpfe ich noch mit den Cookies. Im WebModule1DefaultHandlerAction mache ich folgendes:

Delphi-Quellcode:

    if Request.PathInfo = '/Index.html' then begin
      if Request.CookieFields.Count >0 then begin  // ist immer 0
        ShowMessage(Request.CookieFields.Text);
      end;
      LCookie := TStringList.Create;
      try
        LCookie.Add('MyApp=Test Cookies für Webserver');
        LCookie.Add('SetAt=' + FormatDateTime('dd/mm/yyyy hh:mm', Now));

        Response.SetCookieField(LCookie, 'localhost', '/', -1, False); 
        PageProducer1.HTMLFile:= HtmlPath + Request.PathInfo;
        Response.Content :=PageProducer1.Content;
      finally
        FreeAndNil(LCookie);
      end;
    end
    else begin
      PageProducer1.HTMLFile:= HtmlPath + Request.PathInfo;
      Response.Content :=PageProducer1.Content;
    end;

Dem SetCookieField gebe ich -1 als Expires mit, damit das Cookie nur so lange vorhanden ist, wie der Browser offen ist. Request.CookieFields.Count ist dann aber 0. Was mache ich da falsch?

Wenn ich Response.SetCookieField(LCookie, 'localhost', '/', Now + 1, False); mache, sehe ich das ShowMessage mit den Cookies. Dann müsste ich die Cookies nur wieder vom Browser entfernen können, wenn der User sich ausloggt. Aber wie geht das?

[Rolf Frei]

Geht nicht so richtig oder höchstens per JS im Broser direkt. Das geilste ist ja, dass Cookies die nur während der aktuellen Session gelten sollen, von Chrome etc. nicht entsprechend behandelt werden. Mit anderern Worten: Den Bowser so abstellen, dass Chrome wirklich eine neue Session macht, ist kaum noch möglich. Keine Ahnung was die da geraucht haben und sich da nicht mehr daran halten. Firefox hat auch vor einiger Zeit mit diesem dummen Verhalten angefangen.

Übrigens würde ich dir empfehlen direkt mit IIS und ISAPI oder besser CGI-Exe zu testen. CGI.Exe ist übrigens nahezu genau so schnell wie ISAPI, weil IIS die Exe im Chache hält, nur wird da halt immer alles initialisiert und wenn man eine Session führen will ist das da etwas komplexer, aber dafür kann man ohne Stress die WebApp einfach neu kompilieren und fertig. Bei ISAPI ist das dann leider viel problematischer, da man da jeweils die ISAPI-DLL im IIS entladen muss, bevor man sie ersetzen kann.

[zeras]

Zitat von Rolf Frei:

Übrigens würde ich dir empfehlen direkt mit IIS und ISAPI oder besser CGI-Exe zu testen. CGI.Exe ist übrigens nahezu genau so schnell wie ISAPI, weil IIS die Exe im Chache hält, nur wird da halt immer alles initialisiert und wenn man eine Session führen will ist das da etwas komplexer, aber dafür kann man ohne Stress die WebApp einfach neu kompilieren und fertig. Bei ISAPI ist das dann leider viel problematischer, da man da jeweils die ISAPI-DLL im IIS entladen muss, bevor man sie ersetzen kann.

Ich hatte gelesen, dass die ISAPI schneller wäre. Deshalb hatte ich gleich mit ISAPI angefangen.
Aber wenn es mit der CGI-EXE genauso geht, wäre das auch eine Alternative. Ich habe ja jetzt das Problem, dass ich IIS immer anhalten und neustarten muss. Das würde sich ja dann erübrigen, wie du oben geschrieben hattest.
Kann man die CGI-EXE genauso aufrufen, wie die ISAPI DLL? Kann man dann vielleicht auch noch Ausgaben erstellen, damit man für Tests sieht, was passiert?

[bcvs]

Zitat von Rolf Frei:

Geht nicht so richtig oder höchstens per JS im Broser direkt.

OK, was ist denn dann die best practice dafür?
Oder anders gefragt: Was wäre das Pendant zu session_start(); und den $_SESSION['xxx'] Variablen von PHP. Einfach irgendwelche Werte als globale Variablen serverseitig in Delphi speichern ist wohl keine gute Idee, da ja jeder Seitenauruf einen eigenen Thread startet, wenn ich das richtig verstanden habe. Außerdem muss sich der Seitenaufruf ja mit einer Art Session-ID identifizieren.

[Rolf Frei]

Zitat von zeras:

Ich hatte gelesen, dass die ISAPI schneller wäre. Deshalb hatte ich gleich mit ISAPI angefangen.
Aber wenn es mit der CGI-EXE genauso geht, wäre das auch eine Alternative. Ich habe ja jetzt das Problem, dass ich IIS immer anhalten und neustarten muss. Das würde sich ja dann erübrigen, wie du oben geschrieben hattest.
Kann man die CGI-EXE genauso aufrufen, wie die ISAPI DLL? Kann man dann vielleicht auch noch Ausgaben erstellen, damit man für Tests sieht, was passiert?

ISAPI ist nur in der Theorie schneller, weil das ständige Laden entfällt. In der Praxis merkst du da keinen Unterschied, weil die exe vom IIS (oder OS?) gecacht wird. Eventuell wirst du beim ersten Aufruf einen winzigen Unterschied merken (wir reden hier von ein par ms), aber alle folgenden Aufrufe sind praktisch genauso schnell. Der Stress den man mit einer ISAPI DLL hat, ist mir das nicht wert.

Ja die CGI-EXE kannst du gleich aufrufen, nur halt die exe und nicht die dll. webserver/app/deineapp.exe/... anstatt webserver/app/deineapp.dll/...

Wenn du die exe oder dll nicht in der URL haben willst, müsstest du noch eine Umschreibregel im IIS definieren, die sowas macht: webserver/app/deineapp/...

Zitat von bcvs:

OK, was ist denn dann die best practice dafür?
Oder anders gefragt: Was wäre das Pendant zu session_start(); und den $_SESSION['xxx'] Variablen von PHP. Einfach irgendwelche Werte als globale Variablen serverseitig in Delphi speichern ist wohl keine gute Idee, da ja jeder Seitenauruf einen eigenen Thread startet, wenn ich das richtig verstanden habe. Außerdem muss sich der Seitenaufruf ja mit einer Art Session-ID identifizieren.

Kann ich dir nicht so recht beantworten, kenne mich da mit PHP nicht aus, da ich bisher alles auch mit Delphi machen konnte. Ich führe bei mir eine eigene "Session" (DB-Tabelle mit weiteren Infos zur Sesssion), die ich als Session-ID Cookie und URL-Parameter mitliefere. in der Sesssion Tabelle halte ch alle Daten fest, die mit der Session zu tun haben, also in dienem Fall die Werte deiner Variablen. Diese Sessions haben einen Timeout, nachdem diese ungültig werden. Dann wird eine neue erstellt und wieder als Cookie und URL-Paramater geliefert. Will man die Session selber löschen (durch Abmelden des Benutzers), muss einfach ein leeres Session-ID Cookie gesendet werden. Dadurch ist die alte Session-ID im Browser nicht mehr gültig.

[bcvs]

Zitat von Rolf Frei:

Will man die Session selber löschen (durch Abmelden des Benutzers), muss einfach ein leeres Session-ID Cookie gesendet werden. Dadurch ist die alte Session-ID im Browser nicht mehr gültig.

Danke, das funktioniert. So werde ich es dann wohl auch machen. Und die eigentlichen Session-Daten in einer DB-Tabelle halten.