Well, you shouldn't have to do even that much. If you're using a sufficiently high-level API, the cookies should come back as name/value pairs and not require you to split them manually out of headers.
Then again, the whole point of the HttpSession object is that it
should be collecting the incoming cookies and automatically posting them out on session URL requests without any coding at all on your part. Obviously this means that you need to use the HttpSession as the URL request factory and not simply construct them directly, but that in fact is how it's supposed to be done. So that the cookies will automatically get injected. Along with any other useful appendages to the request.
BTW, for proper operation, it isn't just the Session cookie that
you should be sending back.
All cookies should be going back and forth. Subject only to two limitations:
1. Expired cookies are, of course, dropped.
2. Any application-supplied cookies are added or removed at the bidding of the application.
So if, for example, my webapp posted out a cookie to contain your approximate geolocation, you should be sending it back to me on subsequent requests until it either expires or I delete it.
Granted, using cookies this way in a J2EE app usually isn't a good idea, since session objects are less trouble and more secure, but still...