12:22 p.m.
Working with the HTTP server I have a need in some places to maintain
some state with the connection from the client.
https://issues.jboss.org/browse/AS7-664
With the current implementation I can detect the host and port of the
client but there are no guarantees that a second administrator could not
end up with the same values after the first disconnects so this proposed
change is to associate some attributes with the physical connection.
For the httpserver the changes are here: -
https://github.com/darranl/httpserver/tree/issues/AS7-664
In addition to the changes to add a new get/setAttribute method with a
scope parameter I have also moved the remaining classes to an org.jboss
package - the reason being that although for the runtime the modified
classes are easily picked up leaving them in the old package causes
plenty of issues in IDEs, test cases and compilation.
Once the HTTP server is updated the AS source can be updated to use the
modified classes: -
https://github.com/darranl/jboss-as/tree/issues/AS7-664
(If these changes are accepted it may also be time to get the httpserver
under jbossas, at the moment this is based on the copy under dmlloyd)
Regards,
Darran Lofthouse.
12:29 p.m.
A 'session' can not be distinguished by 'physical connection'.
(Assuming you refer to the port)
I think what we need is proper session management, no?
Maybe Remy has some input on this?
Ike
On Apr 27, 2011, at 12:22 PM, Darran Lofthouse wrote:
this proposed
change is to associate some attributes with the physical connection.
12:32 p.m.
On 04/27/2011 11:29 AM, Heiko Braun wrote:
A 'session' can not be distinguished by 'physical connection'.
(Assuming you refer to the port)
No I am not talking about maintaining a 'session', I am talking about
maintaining some state as the connection itself is negotiated.
I think what we need is proper session management, no?
Maybe Remy has some input on this?
Ike
On Apr 27, 2011, at 12:22 PM, Darran Lofthouse wrote:
> this proposed
> change is to associate some attributes with the physical connection.
12:56 p.m.
On Wed, 2011-04-27 at 12:29 +0200, Heiko Braun wrote:
A 'session' can not be distinguished by 'physical connection'.
(Assuming you refer to the port)
I think what we need is proper session management, no?
Maybe Remy has some input on this?
Add a cookie with an ID. No need to make it very complex.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
1 p.m.
On 04/27/2011 11:56 AM, Remy Maucherat wrote:
On Wed, 2011-04-27 at 12:29 +0200, Heiko Braun wrote:
> A 'session' can not be distinguished by
'physical connection'.
> (Assuming you refer to the port)
> I think what we need is proper session management, no?
> Maybe Remy has some input on this?
Add a cookie with an ID. No need to make it very complex.
For the moment adding a cookie with an ID for session management is more
complex that we actually need ;-)
1:10 p.m.
On Wed, 2011-04-27 at 12:00 +0100, Darran Lofthouse wrote:
On 04/27/2011 11:56 AM, Remy Maucherat wrote:
> On Wed, 2011-04-27 at 12:29 +0200, Heiko Braun wrote:
>>
>> A 'session' can not be distinguished by 'physical connection'.
>> (Assuming you refer to the port)
>>
>> I think what we need is proper session management, no?
>> Maybe Remy has some input on this?
>
> Add a cookie with an ID. No need to make it very complex.
For the moment adding a cookie with an ID for session management is more
complex that we actually need ;-)
Ok ;) But if the alternative is link encoding, it may be more annoying
to do, and it is also less secure.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
1:18 p.m.
On 04/27/2011 12:10 PM, Remy Maucherat wrote:
On Wed, 2011-04-27 at 12:00 +0100, Darran Lofthouse wrote:
> On 04/27/2011 11:56 AM, Remy Maucherat wrote:
>> On Wed, 2011-04-27 at 12:29 +0200, Heiko Braun wrote:
>> >>> A 'session' can
not be distinguished by 'physical connection'.
>>> (Assuming you refer to the port)
>> >>> I think what we need is
proper session management, no?
>>> Maybe Remy has some input on this?
> >> Add a cookie with an ID. No need to make it very
complex.
> For the moment adding a cookie with an ID for session
management is more
> complex that we actually need ;-)
Ok ;) But if the alternative is link encoding, it may be more annoying
to do, and it is also less secure.
Yes that is also another reason why I am trying to keep the state
management to the actual minimum that I need - once we add a cookie all
the clients needs to support cookies and then for the clients that don't
we have to start looking at encoding the ID in all the URLs.
4755
days inactive
4755
days old
6 comments
3 participants
participants (3)
-
Darran Lofthouse -
Heiko Braun -
Remy Maucherat