users@servlet-spec.java.net

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

From: Mark Thomas <markt_at_apache.org>
Date: Fri, 31 Aug 2012 17:51:15 +0100

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.

Mark