yes, but it is the container's responsibilty. It is not Wicket adding it. Juergen
On 7/18/05, Matej Knopp <[EMAIL PROTECTED]> wrote: > > wicket.protocol.httpWebResponse#encodeURL > calls httpServletResponse.encodeURL > > -Matej > > This is the part when jsessionid is added to URL > > Juergen Donnerstag wrote: > > you won't find jsessionid anywhere in wickets code base, except in > > Include.java which is about including markup (ike #include ...) > > > > Juergen > > > > On 7/18/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > >>Below some extracts from servlet 2.3 spec. Spec 2.4 seems not to have > >>changed. > >> > >>SRV.7.1.1 Cookies > >>Session tracking through HTTP cookies is the most used session tracking > >>mechanism and is required to be supported by all servlet containers. > >>The container sends a cookie to the client. The client will then return the > >>cookie on each subsequent request to the server, unambiguously associating > >>the > >>request with a session. The name of the session tracking cookie must be > >>JSESSIONID. > >> > >>SRV.7.1.3 URL Rewriting > >>URL rewriting is the lowest common denominator of session tracking. When a > >>client will not accept a cookie, URL rewriting may be used by the > >>server as the basis > >>for session tracking. URL rewriting involves adding data, a session > >>id, to the URL > >>path that is interpreted by the container to associate the request > >>with a session. > >>The session id must be encoded as a path parameter in the URL string. The > >>name of the parameter must be jsessionid. Here is an example of a URL > >>containing encoded path information: > >>http://www.myserver.com/catalog/index.html;jsessionid=1234 > >> > >>SRV.7.3 Session Scope > >>HttpSession objects must be scoped at the application (or servlet > >>context) level. > >>The underlying mechanism, such as the cookie used to establish the > >>session, can be > >>Binding Attributes into a Session 51 > >>the same for different contexts, but the object referenced, including > >>the attributes in > >>that object, must never be shared between contexts by the container. > >>To illustrate this requirement with an example: if a servlet uses the > >>RequestDispatcher to call a servlet in another web application, any sessions > >>created for and visible to the callee servlet must be different from > >>those visible to > >>the calling servlet. > >> > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > > from IBM. Find simple to follow Roadmaps, straightforward articles, > > informative Webcasts and more! Get everything you need to get up to > > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > > _______________________________________________ > > Wicket-develop mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
