# URL Rewrite hängt keine sessionid an



## Raphalon (12. Jul 2012)

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 *de*aktiviert sind, wird die jsessionid nicht angehängt. Warum? Verwende NetBeans und Glassfish 3.1.2. Muss da noch etwas konfiguriert werden?

Gruß,

Raphalon


----------



## Terminator (13. Jul 2012)

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 (13. Jul 2012)

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 (13. Jul 2012)

@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 (13. Jul 2012)

Weiss nicht genau...

Aber eine Session wird so erstellt:

```
HttpSession session = request.getSession(true);
```


----------



## nillehammer (13. Jul 2012)

Raphalon hat gesagt.:
			
		

> 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 (14. Jul 2012)

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)


----------

