users@servlet-spec.java.net

[servlet-spec users] Re: Suggestions for the spec

From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
Date: Fri, 31 Aug 2012 11:02:20 -0700

On 8/31/12 9:51 AM, Mark Thomas wrote:
> On 31/08/2012 17:37, Christian Beikov wrote:
>> My main question was about whether there is a way to retrieve the https
>> port of the EE6/Servlet Container in a standard way? If not maybe a
>> method to convert an URL in a standard way to use https?
>>
>> Seems like there is no standard way for doing this kind of task. My use
>> case would be, to allow users to choose if they want to use https or
>> not.
> Why would you need this? The user is free to access your site via
> http://... or https://...
>
> Could you elaborate on the scenarios where this doesn't work?
>
>> I could do that with container specific configuration at deployment
>> time too, but that would be error-prone. Antonio Goncalves also asked
>> for a Servlet/Web-Container API which I also would like to ask for, at
>> least I would request an API to be able to access some information of
>> the underlying network and management specific stuff.
> You'll need to make a much more specific request than that for it to be
> considered.
>
>> I have some more things on my wishlist which I would like you to take a
>> look at.
>>
>> 1. The fact that only one session config per webapp can be configured
>> is very limiting. In the cookie config someone could configure the
>> path of the cookie, which is somehow useless IMO since you can only
>> use one session config. I think it would be nice to return the
>> session based on the current servlet path when calling
>> HttpServletRequest.getSession()
> Doesn't that defeat the whole point of a session? Separate sessions for
> different paths suggests (rather strongly to me) that you actually have
> separate web applications.
>
>> 2. Regenerating a session id is somehow painful and there should be a
>> method like regenerateId() in the HttpSession interface. Especially
>> after a login, someone might want to regenerate the session id for
>> security reasons. Current approaches(like the one ESAPI offers[1])
>> for regenerating that id are somehow inefficient due to the lack of
>> better access to the underlying session management.
> Already in hand.
Yes, we plan to add the following API in HttpServletRequest
+ /**
+ * Change the session id of the current session associated with this
+ * request and return the new session id.
+ *
+ * @return the original session id
+ *
+ * @throws IllegalStateException if there is no session associated
+ * with the request
+ *
+ * @since Servlet 3.1
+ */
+ public String changeSessionId();

Shing Wai Chan
>
> Mark
>