URL Rewrite hängt keine sessionid an

[Raphalon]

Hallo,

ich verwende eine jsp-Seite welche ein Servlet aufruft. Dieses Servlet erzeugt direkt eine response und schreibt eine URL mit

out.println("<a href=\"" + response.encodeURL("/Beispiel.do") + "\">click here</a>");

Obwohl im Browser (ausprobiert mit Mozilla und Opera) Cookies definitiv deaktiviert sind, wird die jsessionid nicht angehängt. Warum? Verwende NetBeans und Glassfish 3.1.2. Muss da noch etwas konfiguriert werden?

Gruß,

Raphalon

 

[Terminator]

Also bei GlassFish gibs enableCookies und enableURLRewriting
Normal sollten die beide standardmässig aktiviert sein.
Hatte da aber in früheren Versionen schon einige Probleme mit.
GlassFish : Session ID

 

[tagedieb]

Mal eine blöde Frage...

In deinem Beispiel hast du denn auch eine HttpSession erstellt?
Wenn keine Session vorhanden ist wird er auch nichts encoden.

 

[Raphalon]

@tagedieb: das ist keine blöde Frage. Bis jetzt bin ich davon ausgegangen, dass der WebContainer immer automatisch eine Session erstellt, wenn noch keine existiert. Dem ist wohl nicht so. Habe zunächst im Servlet-Code ein

HttpSession session = request.getSession(false);

und gebe dann weiter unten

out.println("SessionId: " + session().getId());

aus. Das führt zu einer NullPointerException. Wenn ich true einsetze, wird eine Session entsprechend erstellt. Warum wird eine Session nicht automatisch erstellt? Geschieht dies nur, wenn Cookies erlaubt sind?

Aber auch wenn die Session manuell erstellt wird, wird die JSESSIONID nicht an die URL angehängt und das ursprüngliche Problem nicht gelöst. Genügt es nicht, im Servlet die Session wie oben angegeben zu erstellen?

 

[tagedieb]

Weiss nicht genau...

Aber eine Session wird so erstellt:

HttpSession session = request.getSession(true);

 

[nillehammer]

Aber auch wenn die Session manuell erstellt wird, wird die JSESSIONID nicht an die URL angehängt und das ursprüngliche Problem nicht gelöst. Genügt es nicht, im Servlet die Session wie oben angegeben zu erstellen?

Ist ist nur eine Vermutung, aber bei einer neuen Session weiß der Server noch nicht, ob der Client Cookies akzeptiert. Vieleicht verhält sich die Glassfish-Implementierung von HttpServletResponse in einer Weise, dass die Session-ID nur an URLs gehängt wird, wenn Glassfish sicher weiß, dass der Client keine Cookies akzeptiert. Das weiß es aber erst, wenn ein kompletter Request-/Response-Zyklus durchlaufen wurde bei dem ein Cookie gesendet wurde, der dann bei dem nächsten Request zurück kommt (oder eben nicht). Verifizieren könntest Du das, indem Du einen Request mehr zum testen machst.

 

[Raphalon]

Habe die Lösung gefunden. Der Fehler lag in der Verwendung eines Slash in dem URI, also

falsch:

out.println("<a href=\"" + response.encodeURL("/Beispiel.do") + "\">click here</a>");

richtig:

out.println("<a href=\"" + response.encodeURL("Beispiel.do") + "\">click here</a>");

Mir ist jedoch nicht ganz klar, was da genau passiert. Wenn man ein Mapping erstellt z.B. mit

@WebServlet(name = "URLRewrite", urlPatterns = {"/URLRewrite"})

(im urlPatterns/value muss ein Slash erscheinen, wenn Pfadmapping verwendet wird) dann darf bei einem direkten Link (z.B. via Formular) kein Slash am Anfang stehen, sonst erhält man einen 404.

Wenn man wie oben einen Slash verwendet, dann findet er das Servlet jedoch, hängt aber die Sessionid nicht an. In beiden Fällen oben (mit und ohne slash) bringen request.getContextPath(), request.getRequestURI() und request.getRequestURL() jeweils dasselbe Ergebnis. Die Servlet Spec 3.0 Abschnitt 12 gibt da leider nicht mehr Infos her. Es scheint also so zu sein, dass egal, wo ein URI eingefügt wird (stream aus Servlet, jsp-Seite oder direkt html-Seite), am Anfang kein Slash stehen darf/sollte.

Weiss das jemand genau?

Addon:
Ein Test hat gezeigt, dass die Session tatsächlich zuerst manuell erstellt werden muss, es wird keine automatisch erstellt, auch nicht nach mehrmaligen request/response-Zyklen.

@tagedieb:
false hatte ich nur zu Testzwecken verwendet - ich wollte überprüfen, ob denn eine Session vorhanden ist (mit true wäre sie ja sonst automatisch erstellt worden)