Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4C8F8E96.4030609@christopherschultz.net>
Date: Tue, 14 Sep 2010 11:02:46 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: HtttServletRequest.getSession()
References: <4C8F4323.2000808@googlemail.com> <4C8F62A2.9070305@apache.org>
 <4C8F7DED.1010602@googlemail.com>
In-Reply-To: <4C8F7DED.1010602@googlemail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian,

On 9/14/2010 9:51 AM, Brian McBride wrote:
>    https request: get session returns ?

Heh. I should have read your question before I posted my own.

> i.e. will the newly created session B replace session A, or will A
> continue to be returned for https requests?  I suspect it will return B,
> on the assumption the client does not store separate JSESSIONIDs for
> secure and insecure channels, but I'm not sure.

The client may differentiate between secure and non-secure cookies.
(I'll have to double-check that with the spec).

> I just had another extensive search and failed to find what I'm looking
> for.  One might think that section SRV.7.2 Creating a Session might
> cover it, but it doesn't and nor does any of SRV.7, the section on
> Sessions, that I have found.  The APIs define the result of the
> getSession() to be the "session associated with" this request.  A text
> search for "session associated with" finds nothing useful.

I'm not sure what you're asking. "The session" refers to an HttpSession
object, which should be obvious from the spec and the API itself. "The
request" should also be obvious, since we're talking about HTTP and a
HttpServletRequest object. The only question is what "associated" means.
This is pretty much entirely up to the client: either the client
provides a JSESSIONID cookie, provides a jsessionid URL parameter, or
provides nothing. In the first two cases, the session id is used to
associate the request with an HttpSession. In the latter case, there is
no session associated with the request. It's also possible that the
provided session id is not valid, in which case there is also no session
associated with the request.

If you call HttpServletRequest.getSession(true) and a session must be
created, then that newly-created HttpSession object becomes the session
associated with the request.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyPjpYACgkQ9CaO5/Lv0PBGHgCeIcRPMgctGxEfeN+dY/ObIylI
qMAAn1heka97qvTzM+47U68zD/YmHyLZ
=B9aZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org