you do have to tell container that you want to create or use a session, but container takes care of generating the session ID, creating new Cookie object, stuffing the session ID into the cookie; and setting the cookie as part of the response.
Keep in mind, if the container doesn't get a session Id from the client, container wouldn't know that this is the next request from the client. The container won't have any way to know that it tried cookies the last time, and they didn't work. THE ONLY way the container can recognize that it has seen this client before is if the client sends a session ID.
Now the next request from this same client, it will have the sessionID appended to the request URL, but if the client accepts cookies, the request will also have a session id cookie. When servlet calls request.getSession(), the container reads the session Id from the request, find the session, and thinks to itself that this client accepts cookie so it ignores request.encodeURL() calls, or else it will use URL rewriting.
You as a developer you shouldn't be bothered whether client has disabled cookies or not, as container by itself will fallback to URL rewriting.
Tough in space?, <a href="http://tjws.sf.net" target="_blank" rel="nofollow">Get J2EE servlet container under 150Kbytes here</a><br />Love your iPod and want it anywhere?<a href="http://mediachest.sf.net" target="_blank" rel="nofollow">Check it here.</a><br /><a href="http://7bee.j2ee.us/book/Generics%20in%20JDK%201.5.html" target="_blank" rel="nofollow">Curious about generic in Java?</a><br /><a href="http://7bee.j2ee.us/bee/index-bee.html" target="_blank" rel="nofollow">Hate ant? Use bee.</a><br /><a href="http://7bee.j2ee.us/addressbook/" target="_blank" rel="nofollow">Need contacts anywhere?</a><br /><a href="http://searchdir.sourceforge.net/" target="_blank" rel="nofollow">How to promote your business with a search engine</a>