On 10/09/2012 08:44 PM, Mark Thomas wrote:
> On 09/10/2012 01:37, Alex Rojkov wrote:
>
>> Did we dissect a case of serving two or more connections
>> simultaneously? Even on a single machine there is a possibility of
>> executing 2 or more simultaneous requests from the same client.
>>
>> What's the proper thing to do when the first connection changes the
>> session id while the second connection offers an older session-id and
>> has yet to obtain the HttpSession using old session-id? (old
>> session-id is an id prior to change)
>>
>> I am not exactly sure yet… I think a session should be made available
>> by an old session-id to a connection that opened before session-id
>> changes. If so… how far back do we go? i.e. how many previously used
>> Ids for the same session remain valid for fetching the session?
>> (connection priority rule observed)
>
> -1. That would defeat the session fixation protection - the primary
> reason for this feature.
Yes, I agree there would be almost no point bothering with the feature.
Concurrency issues seem to exist with most session operations,
especially its creation.
Rémy