What is the mechanism by which a session attribute passes from a filter to a servlet?

Question

In a webapp I'm using several filters and in one of the filter I'm using something that BalusC described as "session abuse". Basically in the Filter I do something like this:

request.getSession().setAttribute("abuse", ...);

while, later on, in a Servlet, I read back this attribute.

I'm using a session attribute instead a request attribute because I'm doing a redirect and that's where I'm lost...

After the browser receives the 302 and does the redirection, how does Tomcat (or any other Java webapp server) knows that the subsequent GET (the one after the redirect) belongs to the same "session" as the session returned while inside the first Filter (the one before the redirection took place)?

Does this work even if the client's browser has both JavaScript and Cookies turned off AND if I'm disabling JSESSIONID?

I should point out that JSESSIONID is disabled for SEO and for user-friendliness purposes: just like stackoverflow.com does never show super long URLs with pointless technobabbles in them, my webapp doesn't either while JavaScript and Cookies could be turned off by the user. So I want to know if the "session abuse" I'm doing would be working even if these three "client-side features" are not available.

Answer 1

If you have cookies disabled and url rewriting disabled, then the Servlet container cannot track sessions. Actually I think a few still can using SSL - there's a session tracking built into SSL, but I am not sure many servlet containers support this methodology and it requires pure SSL.

If you don't track sessions, then each session gets created and then orphaned.