Re: [AOLSERVER] nssession 1.0RC1

2007-06-20 Thread Ian Harding

Great!  Thank you!  We are using it and it works great.  Just one
little gripe is that if you try to check a session variable and you
don't have a connection (nscp or scheduled proc) it crashes the
server.  Like the doctor said, Don't do that.  In procs that might
be scheduled I just check for a connection first.

- Ian

On 6/19/07, Bas Scheffers [EMAIL PROTECTED] wrote:

I just posted RC2 on http://bas.scheffers.net/aolserver/

This adds the keyword never to the possible values of expires.
Using this instead of a date a long time into the future will make it
possible to change the underlying code to not have a Y2033 problem
when cookie specs finalize.

I also updated the documentation of this in the README.

Cheers,
Bas.


On 20 Jun 2007, at 10:08, Bas Scheffers wrote:

 On 20 Jun 2007, at 09:36, Dossy Shiobara wrote:
 Hey everyone!  Look at Bas, planting the seed for the Year 2033 bug!
 Haha! yeah, you have a valid point. But I didn't do it, some dude
 at Netscape in 1995 did! AOL bought Netscape, you work for AOL, so
 it is all your fault, really! :P

 There are two RFCs concerning cookies that address the problem of
 needing hard expiry times (as set by the Netscape spec) but from
 what I read, they may not be well supported by all clients. For
 now, the netscape spec works reliable as long as you don't do
 stupid things like setting the expire one hour into the future; if
 the user's computer clock is off your application might well not
 work at all. Either go for a session cookie, or set it to expire
 many years into the future.

 Cheers,
 Bas.


 --
 AOLserver - http://www.aolserver.com/

 To Remove yourself from this list, simply send an email to
 [EMAIL PROTECTED] with the
 body of SIGNOFF AOLSERVER in the email message. You can leave the
 Subject: field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.




--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-20 Thread Ian Harding

OK, so it turns out it was my Firefox settings.  Doh!  Thanks for
never though, that's handy.

On 6/19/07, Bas Scheffers [EMAIL PROTECTED] wrote:

I just posted RC2 on http://bas.scheffers.net/aolserver/

This adds the keyword never to the possible values of expires.
Using this instead of a date a long time into the future will make it
possible to change the underlying code to not have a Y2033 problem
when cookie specs finalize.

I also updated the documentation of this in the README.

Cheers,
Bas.


On 20 Jun 2007, at 10:08, Bas Scheffers wrote:

 On 20 Jun 2007, at 09:36, Dossy Shiobara wrote:
 Hey everyone!  Look at Bas, planting the seed for the Year 2033 bug!
 Haha! yeah, you have a valid point. But I didn't do it, some dude
 at Netscape in 1995 did! AOL bought Netscape, you work for AOL, so
 it is all your fault, really! :P

 There are two RFCs concerning cookies that address the problem of
 needing hard expiry times (as set by the Netscape spec) but from
 what I read, they may not be well supported by all clients. For
 now, the netscape spec works reliable as long as you don't do
 stupid things like setting the expire one hour into the future; if
 the user's computer clock is off your application might well not
 work at all. Either go for a session cookie, or set it to expire
 many years into the future.

 Cheers,
 Bas.


 --
 AOLserver - http://www.aolserver.com/

 To Remove yourself from this list, simply send an email to
 [EMAIL PROTECTED] with the
 body of SIGNOFF AOLSERVER in the email message. You can leave the
 Subject: field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.




--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-19 Thread Ian Harding

Hello,

I am trying to use ns_cookie for the first time and am not having any
luck getting a persistent cookie set.  Session cookies seem to get set
regardless of the value I send for expires.  Am I doing something
wrong?

ns_session is working great, this is the first time I tried to use the
ns_cookie commands.

Thanks,

Ian

On 2/24/06, Bas Scheffers [EMAIL PROTECTED] wrote:

Jeremy Collins wrote:
 Is this the same module that is in AOLserver CVS?  Doesn't look like it
 but they have the same name.
No, it isn't. I think that is one someone started many eons ago and is
still alpha. I think it needs replacing with something that is
maintained! :)

 One thing that might be useful is a way to provide storage plugins for
 session data.  If I could write a few routines, my_session_save and
That is a good idea, one I have thought about but didn't need and so
didn't implement.

But all operations are in an Ns_Set, so it doesn't matter where it comes
from, as long as it is put into a set for getting/setting. So all the
implementation module would need to provide is GetSet(), SaveSet() and
Destroy() functions. And maybe a request done function the trace calls
so the memory cache your implementation would probably have can be
committed to the back end storage at the end of the request.

It could just be a loadable module that registers the functions to call
with Ns_Session and overwrites the default ones.

One thing I would like is a small core change, it would be nice to have
a simple char* in the NsConn struct to store the session ID, rather than
my nasty request parameters hack.

Another slight performance improvement would be a pointer to the cache
in NsServer, saving the find that is now needed on every access to the
cache.

Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.




--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-19 Thread Bas Scheffers

Hi Ian,

Good to hear someone is using it!

I guess I didn't document it very well. You need to pass it a valid  
HTTP time string. The easy way to get it to never expire is to pass  
the value of:

[ns_httptime 20]

That tells it to expire Wed, 18 May 2033 03:33:20 GMT, which ought  
to be long enough in the future! :)


Cheers,
Bas.

On 20 Jun 2007, at 05:04, Ian Harding wrote:


Hello,

I am trying to use ns_cookie for the first time and am not having any
luck getting a persistent cookie set.  Session cookies seem to get set
regardless of the value I send for expires.  Am I doing something
wrong?

ns_session is working great, this is the first time I tried to use the
ns_cookie commands.

Thanks,

Ian

On 2/24/06, Bas Scheffers [EMAIL PROTECTED] wrote:

Jeremy Collins wrote:
 Is this the same module that is in AOLserver CVS?  Doesn't look  
like it

 but they have the same name.
No, it isn't. I think that is one someone started many eons ago  
and is

still alpha. I think it needs replacing with something that is
maintained! :)

 One thing that might be useful is a way to provide storage  
plugins for

 session data.  If I could write a few routines, my_session_save and
That is a good idea, one I have thought about but didn't need and so
didn't implement.

But all operations are in an Ns_Set, so it doesn't matter where it  
comes

from, as long as it is put into a set for getting/setting. So all the
implementation module would need to provide is GetSet(), SaveSet()  
and
Destroy() functions. And maybe a request done function the trace  
calls

so the memory cache your implementation would probably have can be
committed to the back end storage at the end of the request.

It could just be a loadable module that registers the functions to  
call

with Ns_Session and overwrites the default ones.

One thing I would like is a small core change, it would be nice to  
have
a simple char* in the NsConn struct to store the session ID,  
rather than

my nasty request parameters hack.

Another slight performance improvement would be a pointer to the  
cache
in NsServer, saving the find that is now needed on every access to  
the

cache.

Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to  
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave  
the Subject: field of your email blank.





--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to  
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the  
Subject: field of your email blank.



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-19 Thread Dossy Shiobara
On 2007.06.20, Bas Scheffers [EMAIL PROTECTED] wrote:
 Hi Ian,
 
 Good to hear someone is using it!
 
 I guess I didn't document it very well. You need to pass it a valid  
 HTTP time string. The easy way to get it to never expire is to pass  
 the value of:
 [ns_httptime 20]
 
 That tells it to expire Wed, 18 May 2033 03:33:20 GMT, which ought  
 to be long enough in the future! :)

Hey everyone!  Look at Bas, planting the seed for the Year 2033 bug!

:-P

-- Dossy

-- 
Dossy Shiobara  | [EMAIL PROTECTED] | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-19 Thread Jeff Rogers

Bas Scheffers wrote:

Hi Ian,

Good to hear someone is using it!

I guess I didn't document it very well. You need to pass it a valid HTTP 
time string. The easy way to get it to never expire is to pass the value 
of:

[ns_httptime 20]

That tells it to expire Wed, 18 May 2033 03:33:20 GMT, which ought to 
be long enough in the future! :)


Cheers,
Bas.


Just in case this is running for 5 or so years, is this susceptable to a 
Y2038 bug?


-J


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-19 Thread Bas Scheffers

On 20 Jun 2007, at 09:36, Dossy Shiobara wrote:

Hey everyone!  Look at Bas, planting the seed for the Year 2033 bug!
Haha! yeah, you have a valid point. But I didn't do it, some dude at  
Netscape in 1995 did! AOL bought Netscape, you work for AOL, so it is  
all your fault, really! :P


There are two RFCs concerning cookies that address the problem of  
needing hard expiry times (as set by the Netscape spec) but from what  
I read, they may not be well supported by all clients. For now, the  
netscape spec works reliable as long as you don't do stupid things  
like setting the expire one hour into the future; if the user's  
computer clock is off your application might well not work at all.  
Either go for a session cookie, or set it to expire many years into  
the future.


Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-19 Thread Bas Scheffers

On 20 Jun 2007, at 09:44, Jeff Rogers wrote:
Just in case this is running for 5 or so years, is this susceptable  
to a Y2038 bug?
No, it wouldn't because the 2,000,000,000 value is hardcoded and not  
relative to now.


But there is, as Dossy pointed out a Y2033 bug if you leave this  
unchanged for 26 years or so.


Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2007-06-19 Thread Bas Scheffers

I just posted RC2 on http://bas.scheffers.net/aolserver/

This adds the keyword never to the possible values of expires.  
Using this instead of a date a long time into the future will make it  
possible to change the underlying code to not have a Y2033 problem  
when cookie specs finalize.


I also updated the documentation of this in the README.

Cheers,
Bas.


On 20 Jun 2007, at 10:08, Bas Scheffers wrote:


On 20 Jun 2007, at 09:36, Dossy Shiobara wrote:

Hey everyone!  Look at Bas, planting the seed for the Year 2033 bug!
Haha! yeah, you have a valid point. But I didn't do it, some dude  
at Netscape in 1995 did! AOL bought Netscape, you work for AOL, so  
it is all your fault, really! :P


There are two RFCs concerning cookies that address the problem of  
needing hard expiry times (as set by the Netscape spec) but from  
what I read, they may not be well supported by all clients. For  
now, the netscape spec works reliable as long as you don't do  
stupid things like setting the expire one hour into the future; if  
the user's computer clock is off your application might well not  
work at all. Either go for a session cookie, or set it to expire  
many years into the future.


Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to  
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the  
Subject: field of your email blank.



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


[AOLSERVER] nssession 1.0RC1

2006-02-24 Thread Bas Scheffers

Hi all,

I did some work yesterday finishing off my nssession module and even 
optimistically labeled is 1.0RC1.


You can find it at http://bas.scheffers.net/aolserver/

I hope some of you can try it out and give me some feedback on it!

CHANGES
version 1.0RC1
- added keys command
- added list command
- added contains command
- added default argument to get command
- added -id option
- added cleanup of stale session files that can occur if the server is 
restarted.

- created sessions.adp for displaying sessions in the server.
- fix mtime compile bug, now compiles on Linux/Solaris as well as on 
BSD/Mac.


Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2006-02-24 Thread Jeremy Collins

On Feb 24, 2006, at 5:27 AM, Bas Scheffers wrote:


Hi all,

I did some work yesterday finishing off my nssession module and  
even optimistically labeled is 1.0RC1.


You can find it at http://bas.scheffers.net/aolserver/

I hope some of you can try it out and give me some feedback on it!



Is this the same module that is in AOLserver CVS?  Doesn't look like  
it but they have the same name.


One thing that might be useful is a way to provide storage plugins  
for session data.  If I could write a few routines, my_session_save  
and my_session_load for example, that handle saving sessions how I  
want then this module would be much more flexible.  This way I could  
write a storage routine to save sessions in a database which would  
allow me to access them from another server running nssession.  Of  
course by default you would provide the in-memory and disk-based  
storage routines.


Thoughts?

- Jeremy


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2006-02-24 Thread Bas Scheffers

Jeremy Collins wrote:
Is this the same module that is in AOLserver CVS?  Doesn't look like it 
but they have the same name.
No, it isn't. I think that is one someone started many eons ago and is 
still alpha. I think it needs replacing with something that is 
maintained! :)


One thing that might be useful is a way to provide storage plugins for 
session data.  If I could write a few routines, my_session_save and
That is a good idea, one I have thought about but didn't need and so 
didn't implement.


But all operations are in an Ns_Set, so it doesn't matter where it comes 
from, as long as it is put into a set for getting/setting. So all the 
implementation module would need to provide is GetSet(), SaveSet() and 
Destroy() functions. And maybe a request done function the trace calls 
so the memory cache your implementation would probably have can be 
committed to the back end storage at the end of the request.


It could just be a loadable module that registers the functions to call 
with Ns_Session and overwrites the default ones.


One thing I would like is a small core change, it would be nice to have 
a simple char* in the NsConn struct to store the session ID, rather than 
my nasty request parameters hack.


Another slight performance improvement would be a pointer to the cache 
in NsServer, saving the find that is now needed on every access to the 
cache.


Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2006-02-24 Thread Jeremy Collins

On Feb 24, 2006, at 10:54 AM, Bas Scheffers wrote:

One thing I would like is a small core change, it would be nice to  
have a simple char* in the NsConn struct to store the session ID,  
rather than my nasty request parameters hack.




You could probably use the Ns_Cls* API (Connection Local Storage) to  
store the session data.  Including the cache pointer so that you only  
look it up once per connection.


- Jeremy


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] nssession 1.0RC1

2006-02-24 Thread Bas Scheffers

On 24 Feb 2006, at 18:54, Jeremy Collins wrote:
You could probably use the Ns_Cls* API (Connection Local Storage)  
to store the session data.  Including the cache pointer so that you  
only look it up once per connection.
Would that be the completely undocument Ns_Cls API that I thus did  
not know about? :)


I'll have a look at it, though it still leaves me a bit puzzled,  
especially the cleanup part.


Cheers,
Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.