No, it isn't. There is absolutely no way to know if the browser supports
cookies or not before second request (which has cookie information set
on the response of the first request, if the cookies are supported).
Also, it's really bad idea to send redirects as long as there is
jsessionids:n on the url. That would loop forever when user's browser
(or spider) does not allow cookies.
There is not really need to strip away those jsessionid's. Web spiders
really don't care about them, at least when I last checked few years
ago. For example Google just strips them away. Also messing with the
jsessionid:s would really cause a lot of harm.
Eelco Hillenius wrote:
Why? It's part of the default header info whether a client accepts
cookies or not isn't it?
Eelco
On 11/12/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
App servers HAVE to put that in the first URL, because it's really the
second (because of the redirect). The server doesn't know if the
client is using cookies until the first request comes back, so for the
first request it has to use cookies and url rewriting.
--
Janne Hietamäki
Cemron Ltd
http://www.cemron.com/
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
