Re: [AOLSERVER] Generating Dynamic PDF's from AOLs

[Rob Mayoff]

+-- On Dec 9, Steve Manning said:
| I want to create a PDF version of a database report for downloading.
| Does anyone know of a way to dynamically generate PDF's within
| AOLserver?

At ArsDigita I used  to do this for one
particular customer.


--
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] Ns_SetRequestAuthorizeProc has no Tcl Command

[Rob Mayoff]

+-- On Nov 4, russm said:
| that's ridiculous - if you can't secure your server enough to protect
| the user passwords then you can't secure it enough to protect the
| content protected by those passwords, and you're already up the
| proverbial creek without a paddle.

Suppose an intruder breaches security to the point where he can see
but not modify data on your server. If a password is stored in a
recoverable way (e.g. plaintext) on the server, then the intruder gains
the privileges granted by that password, which may include the ability
to modify data. Typically, a breach allowing modification is worse than
a breach allowing only inspection.

Therefore, it's better to store a password in a way that allows
verification of the password, without allowing recovery of the
passwords. Two ideas that come to mind are storing a one-way hash of
the password (as the Unix passwd file does) and storing the password on
some other device (smartcard or other computer) that supports a limited
protocol.


--
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] TCL Bug?

[Rob Mayoff]

I must disavow my earlier claim that all four regexp commands would
always be executed.  This test seems to indicate otherwise:

$ rpm -q tcl
tcl-8.3.5-88
$ tclsh
% if [puts A;expr 1] {puts 1} elseif [puts B;expr 2] {puts 2}
A
1
% if [puts A;expr 0] {puts 1} elseif [puts B;expr 2] {puts 2}
A
B
2
%

Note that this behavior is in violation of the Tcl language syntax
described by the Tcl(n) man page.


--
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] TCL Bug?

[Rob Mayoff]

Your if statement has four regexp command substitutions, all of which
will always be executed. All four have side effects which change the
values of dummy, p, and ver. When your MSIE regexp matches, your Mozilla
regexp will usually also match. You don't know whether Tcl will execute
your Mozilla regexp command first or second. If it executes the Mozilla
regexp command second, then p will be "Mozilla" even when it's executing
the IE code block. The order in which it executes the commands might
change between different versions of Tcl.

Try putting braces around the [regexp ...] commands. E.g.

if {[regexp -- {(Opera).([0-9\.]{1,})} $browser dummy p ver ]}   {
puts "Opera Detected: $p $ver"
} elseif {[  regexp -- {(MSIE).([0-9.]{1,})} $browser dummy p ver ]} {
puts "IE Detected: $p $ver"
} elseif {[regexp -- {(Mozilla)\/([0-9\.]{1,})} $browser dummy p ver ]}  {
puts "Mozilla Detected: $p $ver"
if { ($ver < 5 ) || [regexp -- Netscape $browser]} {
   set p Netscape
}
} elseif {[regexp -- {(\w+)\/([0-9\.]{1,})} $browser dummy p ver]} { }


--
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] tcl q: how to see escape chars

[Rob Mayoff]

+-- On Oct 17, Scott Laplante said:
| Is there a way in tcl to puts(?) a string, but instead of intrepreting,
| showing all special characters?

There's no built-in way that I know of, but if you give us a more
precise definition of "special characters" I'm sure we can help you out.

Tcl strings are Unicode. What's a special character? Just control
characters (0-31 and 127)? Characters outside the printable ASCII set
(control characters and characters 128-infinity)?


--
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] nspostgres driver won't load

[Rob Mayoff]

+-- On Oct 12, Tom Brown said:
| I am running Aolserver (3.3.1_ad13) without the OACS system. I created an
| aolserver config file using the nspostgres.so driver, version 1.6,
| 2002/12/16, and code from OpenACS' sample aolserver config. I am starting
| the server with nsd-postgres.

Are you running AOLserver chrooted?
What user does AOLserver run as?
Does that user have read and execute access to /, /usr, /usr/local,
/usr/local/pgsql, and /usr/local/pgsql/lib?
Does that user have read access to /usr/local/pgsql/lib/libpq.so.2?


--
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] Invalid command name "" error

[Rob Mayoff]

+-- On Oct 9, Tom Brown said:
| [09/Oct/2003:03:06:32][187.6958089][-conn917-] Error: invalid command name ""
| invalid command name ""
|  while executing
| "[ns_puts [clock format $fullpath(ctime) -format "%m/%d/%Y"]
| ]"

You have an extra set of brackets around your ns_puts command.


--
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] Can you help me get rid of the temp files in this exec?

[Rob Mayoff]

+-- On Sep 7, Jerry Asher said:
| Do I basically have it or is there a better way to do this?

Talk to the payment processor from the PK, not the WS. That way, a
decrypted CC# only exists on the WS when the user first enters it. It's
immediately encrypted and stored in the DB. It never again appears in
decrypted form on the WS.

The PK needn't be accessible from the Internet, needn't run the same OS,
needn't have a web server, etc.


--
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] is ns_conn peeraddr spoofable?

[Rob Mayoff]

+-- On Aug 20, russm said:
| There has also been talk on the list of having [ns_conn peeraddr]
| return the address in the "X-Forwarded-For:" header (if one exists).

I don't think anyone is pushing for XFF to be honored by default.


--
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] is ns_conn peeraddr spoofable?

[Rob Mayoff]

+-- On Aug 19, Andrew Piskorski said:
| Or could a client outside the router somehow spoof the peer address to
| make it look like the request is coming from a machine on my LAN?

A client outside might be able to spoof the peer address, if your router
doesn't drop the packets. Perhaps it does by default or you can
configure it to.

You have to make it drop any packet arriving on the WAN port with a
source address that belongs on the LAN port. For example, I use the 10.*
network number on my LAN, and I'm assigned 216.30.134.152/29, so my
router is configured to drop any packet arriving from my T1 that has a
10.* or 216.30.134.152/29 source address.

In fact there are four address-filtering rules your router should use:

- Drop a packet from the WAN with a LAN source address
- Drop a packet from the WAN without a LAN destination address
- Drop a packet from the LAN without a LAN source address
- Drop a packet from the LAN with a LAN destination address


--
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] Lengthy tcl interp initialization

[Rob Mayoff]

+-- On Aug 13, Zoran Vasiljevic said:
| Although I doubt that this kind of function is possible to implement
| generically in mt-safe fashion, one may get a good approximation
| which would (could) be satisfactory for the AS usage.

AOLserver could keep an initialized "donor" interpreter around (for
each VS) that is never used to execute code after it executes the init
script. Initializing another interpreter becomes a matter of cloning the
donor interpreter. Serializing the cloning operation between threads
might be necessary, but shouldn't have a significant performance impact.


--
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] IM'ed URLs not being logged

[Rob Mayoff]

+-- On Aug 1, Daniel P. Stasinski said:
| In the tcpdump thats I posted in the last hour, the first hit
| returned the image (and response 200) but it was never logged .
| The second hit was when I clicked the refresh button and it
| returned 304 and WAS logged.  It works the same way with text
| files.

Sounds like you need to put AOLserver under the debugger and step
through a request.


--
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] IM'ed URLs not being logged

[Rob Mayoff]

I don't see anything weird about the HTTP request.  Try creating a dummy
file, like /foo.txt, containing just a few ASCII characters, and see if
you can reproduce the problem with that URL.  If so, post a tcpdump of
that.


--
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] IM'ed URLs not being logged

[Rob Mayoff]

+-- On Jul 31, Daniel P. Stasinski said:
| I have pasted URL's in AIM and on irc, and also typed in the
| specific url into the url box on IE 6 and Linux/Mozilla and in
| each case it was not logged.

Capture the entire HTTP request that isn't logged, using "tcpdump -s
2000 -w tcpdump.out port 80" or similar. Give us a URL to download
tcpdump.out so we can examine it.


--
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] Are the weekly chats officially dead?

[Rob Mayoff]

+-- On Jul 31, Roberto Mello said:
| - Readline support for nscp.

You could just get a better client program. For example, connecting to
nscp from inside Emacs can give you editing and history support.

If you have a separate program that puts readline on top of a TCP
connection, you can use it for things besides nscp, like testing HTTP
and SMTP connections.


--
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] Pound vs. ns_write

[Rob Mayoff]

+-- On Jul 21, Gustaf Neumann said:
>  If the community prefers to keep [ns_conn peeraddr] as it is, we would
>  would not alter these 70+ occurances, but modify our local copy
>  of [ad_conn ...]

So it sounds like you don't even HAVE the problem you're complaining
about!  It would be nice to hear from people who DO have that problem.
Then we could assess its severity.


--
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] Pound vs. ns_write

[Rob Mayoff]

+-- On Jul 19, Jim Wilcoxson said:
> Separate routines makes it harder to find out "how do I do this
> thing?",

That sounds more like a problem of inadequate documentation.

> Overloading ns_conn is easy in TCL:

It's not as easy as NOT overloading it, and it slows down every
invocation of ns_conn. That might or might not be a problem. If you have
several libraries that each want to add ns_conn subcommands, you get an
extra layer of overhead for each library.


--
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] Pound vs. ns_write

[Rob Mayoff]

+-- On Jul 19, Dossy said:
> If someone's going to hack your system, presumably they're not going to
> be dumb enough to do it from their OWN IP address.  (That's like making
> threatening phone calls from your home landline phone!  Duh!)

Presumably the FBI will want to investigate the computer from which you
were attacked, in case it contains clues that will lead back up the
trail to the attacker. Presumably knowing the IP address will help the
FBI determine whether you're being attacked by the same entity that is
attacking other servers.


--
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] Pound vs. ns_write

[Rob Mayoff]

+-- On Jul 19, Dossy said:
> Why even record their IP address if you have their user ID?

When someone hacks your system and costs your thousands of dollars, the
FBI might find the IP address useful in tracking down the hacker.


--
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] Pound vs. ns_write

[Rob Mayoff]

+-- On Jul 19, Dossy said:
> Configuring an optional whitelist of peeraddrs to trust would be neat
> (only look for the X-Forwarded-For header if the peeraddr belongs to a
> list of IPs).

My dqd_log module has an "AccelAddresses" parameter.  If [ns_conn
peeraddr] is in the AccelAddresses list, then it logs the last word of
X-Forwarded-For instead of [ns_conn peeraddr].




--
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] Pound vs. ns_write

[Rob Mayoff]

+-- On Jul 19, Nathan Folkman said:
> Actually I think Dossy is proposing to add a new arg to the ns_conn
> command, and not changing the current behavior of "ns_conn peeraddr" in
> order to keep backwards compatibility. I believe the proposal was to add
> something like "ns_conn clientaddr". Dossy, please correct me if I'm wrong.

A totally separate command, like "ns_clientaddr", would be better. It's
easy to backport a standalone command - particularly when it can be
easily implemented in Tcl alone. It's more involved to backport a new
ns_conn subcommand.


--
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] can aolserver redirect to a different site

[Rob Mayoff]

proc redirect_t_site1a {args why} {
ns_returnredirect "http://www.site1a[ns_conn url]"
return filter_return
}

ns_register_filter GET /* redirect_to_site1a


--
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] AOLserver4 beta 8 can't be killed by daemontools svc

[Rob Mayoff]

+-- On Jun 13, Tom Jackson said:
> /usr/local/aolserver4/bin/nsd -it /web/control/iunicycle-dev/iunicycle-dev-nsd.tcl 
> -u tom -b 192.168.111.100:80

You need to use "exec /usr/local/aolserver4/bin/nsd ...".  The way you
have it now leaves bash running, waiting for nsd to exit.  When you say
"svc -t /service/nsd" (or whatever), supervise kills bash but not nsd.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] AOLserver4 beta 8 can't be killed by daemontools svc

[Rob Mayoff]

+-- On Jun 13, Tom Jackson said:
> What happens is that AOLserver continues to run, yet daemontools starts
> up another one.

Show us your run script.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] [ aolserver-Feature Requests-746579 ] Server instance controller process

[Rob Mayoff]

+-- On Jun 2, Ian Harding said:
> Same as Daemontools.  If nsd gets told to exit any other way than 'svc -d nsd'', it 
> will get started again (if set up to re-start)

You could give nsd the ability to do "svc -d" on itself.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] [ aolserver-Feature Requests-746579 ] Server instance controller process

[Rob Mayoff]

+-- On May 31, Dossy said:
> I haven't used daemontools yet, but does running nsd under daemontools
> require you to run nsd -f?  Or, will daemontools monitor the PID of nsd
> and do the right thing if nsd disappears?

You use -f.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] [ aolserver-Feature Requests-746579 ] Server instance controller process

[Rob Mayoff]

+-- On May 31, Zoran Vasiljevic said:
> Doable, but messy. IMHO. nsd already takes care about pid-file
> logfiles, etc when going to background. This is all nice stuff
> and I wouldn't like to reimplement all this in an external shell-script.
> Why just not put this logic on the C-level in the nsd?

Why not just use daemontools? You avoid the race conditions of pidfiles
and get several other useful features.

> This is right. It is the convenience of having a well tested, working solution
> which you just use w/o shell-script workarounds. Somebody has to write,
> update, maintain, etc... this shell-script, right?

Daemontools is a well-tested, working solution, maintained by someone
known to write bulletproof code.

> Now, what I did not say (nor done yet, but I'm planning to) is: win32.
> You have no shell there. By having all built-in, you have no worry.

Wouldn't it be better to run nsd as an NT service?


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] BIG problem with Tcl8.4.(1|2)

[Rob Mayoff]

+-- On Mar 27, Andrew Piskorski said:
> And if that object were TLS, per-thread, then the error could not
> occur.  It might cause OTHER problems, which is what my questions
> above were getting at, and it might plain not be feasible to
> implement.  But a TLS pwd would solve the "blindly passing a
> process-wide object to other threads" problem above, because it
> wouldn't be process-wide anymore, it'd be per-thread.

Perhaps you do not realize that a process's current working directory
is tracked by the kernel, not by the process. Tcl keeps track of its
CWD for speed, but ultimately it's the kernel, not the process, that
resolves relative pathnames, so it's the kernel's idea of the CWD that
matters.

I believe that POSIX requires that all threads in a process share a
working directory. Making each thread appear to have its own working
directory requires either non-standard kernel support for per-thread
CWD (which Linux has, but I don't think you can get to it through the
pthreads interface), or intercepting every system call that involves
a pathname (open, link, symlink, unlink, rename, access, stat, lstat,
chdir, chroot, chmod, chown, lchown, mknod, mkdir, rmdir, bind, connect,
and probably some more that I've forgotten). You might be able to
ignore some of these for AOLserver, but intercepting any of them isn't
necessarily easy, and it's definitely not possible to do so portably.

It still might be the best way to fix this problem, though.

> What's the TSD?

Thread-specific data.  Same thing as TLS.

> The fact that some system calls apparently change pwd and then change
> it back when they complete is really obnoxious,

No. Some library calls change the CWD. The only system calls that change
the CWD are chdir() and fchdir().


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem

[Rob Mayoff]

+-- On Mar 27, Rob Mayoff said:
> Actually, now that I think about it, realpath is documented to take
> an output buffer of only PATH_MAX bytes, so this doesn't apply to
> PATH_MAX.

It meant "doesn't apply to realpath()", of course.  Darn it.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem

[Rob Mayoff]

+-- On Mar 27, Rob Mayoff said:
> A correctly working realpath() must use chdir() at least sometimes.
> System calls only accept paths up to PATH_MAX bytes long, but the
> filesystem allows us to construct paths of any length. The only reliable
> way to access those long paths is by using chdir().

Actually, now that I think about it, realpath is documented to take
an output buffer of only PATH_MAX bytes, so this doesn't apply to
PATH_MAX. But the problem remains for any program that wants to reliably
compute pathnames. And realpath should have been written to allocate a
suitably-sized output buffer...


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem

[Rob Mayoff]

+-- On Mar 27, Zoran Vasiljevic said:
> Tcl. This solves this issue cleanly. The ultimate fix, of course, is
> to modify the Darwin realpath() to behave better.

I wonder what you mean by "behave better". Does realpath() leave the cwd
changed? Or do you simply mean that you don't want realpath() to ever
use chdir()?

A correctly working realpath() must use chdir() at least sometimes.
System calls only accept paths up to PATH_MAX bytes long, but the
filesystem allows us to construct paths of any length. The only reliable
way to access those long paths is by using chdir().

realpath() could safely use chdir() even in a multithreaded program by
forking, computing the path (possibly using chdir()) in the child, and
passing the result back to the parent over a pipe. Obviously this could
be optimized to only fork when it discovers that it must call chdir().


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ADP: are if's possible?

[Rob Mayoff]

+-- On Mar 16, Jim Davidson said:
> 1. Current simple script block isolated mode.
> 2. Connected script blocks via use of the Tcl_CommandComplete checks (Rob's
> idea)
> 3. Full compile into a single script in the style of ASP.

It's easy to do #3 using #2 on a per-page basis. Just put "<% if 1 { %>"
at the top of the page and "} %>" at the bottom. But a mode would be
useful if you want to do it for all ADPs.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ADP: are if's possible?

[Rob Mayoff]

+-- On Mar 15, Kevin Lawver said:
> Is there some super-good reason why this very nice feature hasn't been
> included in the default fancy parser?

The idea was to have standalone code segments, so that if a code segment
has an error, the remainder of the page can still be rendered.

I suggested an implementation strategy a while ago for allowing the
code style in your example, with the error-tolerance of the current ADP
system. Jim Davidson seemed to agree that it was a good idea, so perhaps
it will be implemented in a future release.



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] IP vs ServerName and ns_perm

[Rob Mayoff]

+-- On Mar 7, Franclim Bento said:
> But now I need to move it to another machine and the DNS server that the users are 
> using don't know this new machine. When I try to reach my web pages indicating the 
> servername (with an alias in the hosts file) everything works fine. But if I use the 
> IP the dialog box for the authentication also appears but after indicating (the 
> right) user and password, I receive "The page cannot be displayed". When accessing a 
> simple html page, outside the protected branch over ns_perm module control, using 
> the IP everything goes fine too.

Please wrap your text at 80 columns or less.

What HTTP error code do you get when it says "The page cannot be
displayed"?

> Can anyone please help me ?

Yes.  The guy who runs your DNS server can help you.  Tell him to set up
a name for the machine.



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] AOLserver Authentication and Applet

[Rob Mayoff]

+-- On Mar 6, Karthik said:
> I need to pass the username that the user enters to my java code as an applet
> parameter. How can I do it ?

Instead of typing in "hostname:port/xyz.html", you should type in
"hostname:port/xyz.tcl". Make xyz.tcl a Tcl program that generates the
HTML that loads the applet. xyz.tcl can get the HTTP username using
[ns_conn authuser] and put it in a PARAM tag in the APPLET entity. For
example:

set username [ns_quotehtml [ns_conn authuser]]
ns_return 200 text/html "
My Applet





Get Java, Loser!



"

In your applet, you can access that parameter using the getParameter
method of the Applet class.



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] broken images with requests from pre5.5 IE browsers

[Rob Mayoff]

+-- On Feb 26, Elizabeth Thomas said:
> We are having problems here with an international site returning broken
> images from https requests from older IE browsers.

Define "international site". Do you have non-ASCII characters in your
URLs? Does your access log indicate that IE is asking for the correct
URL?



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] Root-server switches from BIND to NSD.

[Rob Mayoff]

+-- On Feb 25, Patrick Spence said:
> I'd certainly be willing to use it here :)  it would be a lot easier to
> administer than bind is for me..

There are alternatives to BIND that many consider easier to administer.



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] Root-server switches from BIND to NSD.

[Rob Mayoff]

+-- On Feb 25, Dossy said:
> Added bonus would be a web interface for viewing zones and editing
> them, which would persist changes back down to the DBMS.

Note that a web interface to your DNS data doesn't require that
AOLserver respond to DNS requests.



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] Root-server switches from BIND to NSD.

[Rob Mayoff]

+-- On Feb 25, Tom Ivar Helbekkmo said:
> Really cool, in fact!  If it were efficient enough, it would save the
> trouble of generating BIND zone files from an RDBMS;

There are already servers available that can serve DNS directly from
MySQL or Postgres. They are not nearly as fast as a dedicated DNS server
that uses a specialized static database. And unless you've got a really
huge amount of data (tens of thousands of records or more), you can
create the static database from a SQL database very, very quickly.



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] Tcl bytecode caching for Tcl pages

[Rob Mayoff]

+-- On Feb 23, Don Baccus said:
> The code's been used successfully in many sites so seems stable.

But has it been proven to be effective?  I haven't seen any numbers.  I
helped implement it, but I don't recall that we (ArsDigita) ever did a
serious analysis of whether it improved performance.



I. To remove yourself from this list:

Send a message to "[EMAIL PROTECTED]"  with the following text in
the BODY of your message:

signoff aolserver

II. For a complete list of listserv options please visit:

http://listserv.aol.com/

III. For more AOLserver information please visit:

http://www.aolserver.com/

Re: [AOLSERVER] Does 4.0 cache tcl page object code?

[Rob Mayoff]

+-- On Feb 17, Andrew Piskorski said:
> When AOLserver 4.0 is running with EnableTclPages on, does it cache
> the compiled Tcl page bytecode?  Or does it recompile from source to
> bytecode every single time the Tcl page is hit?

It reloads the file every time.  The code is in aolserver/tcl/file.tcl.

> I believe Rob Mayoff added that bytecode cacheing feature to 3.3+ad13
> (actually earlier, I think to 3.3+ad12), but I was never clear on just
> where in the code he implemented it, so I can't just check by
> comparing the code against 4.0...

That is implemented in file.tcl and tclcache.tcl.  It relies on the
ns_cache command provided by the nscache.so module.  Perhaps someone has
ported that to 4.0.

Re: [AOLSERVER] 4.0 ClientData arg ??

[Rob Mayoff]

+-- On Feb 15, Dossy said:
> In 3.x, it seems the ClientData parameter is either 's' or 'g' to
> indicate setter or getter.  Evil hackery.  :-)

Actually, in 3.x, the 's' has no meaning to the code. NsTclVSetCmd does
not look at its ClientData (which is why it's named "dummy" in that
function). NsTclVGetCmd, on the other hand, looks at its ClientData. If
ClientData is 'g', the function implements nsv_get; if ClientData is
'e', the function implements nsv_exists.

In 4.0, nsv_get and nsv_exists are implemented by separate C functions,
so no argument is needed to determine which command was invoked.

I speculate (having looked at the 4.0 source but not having run 4.0)
that 4.0 gives each virtual server its own set of NSVs. So when a
virtual server invokes an some NsTclNsv*ObjCmd function, the function
needs access to the NSV data structures specific to that virtual server.
The ClientData contains a pointer to an NsInterp, and the NsInterp's
servPtr points to the invoking NsServer. The NsServer contains the
virtual server's NSV data structures.

So if you're invoking some NsTclNsv*ObjCmd directly, you should pass an
NsInterp pointer as its ClientData. Note that those functions do not
appear to be part of the AOLserver C API. If you had a Tcl_Interp that
belongs to the appropriate virtual serve, you could legally fish out a
pointer to an NsTclNsv*ObjCmd using Tcl_GetCommandInfo. You'd get both
the pointer to the function (in infoPtr->objProc) and the appropriate
ClientData to pass to it (in infoPtr->objClientData).

Re: [AOLSERVER] aolserver 3.3ad13 on RedHat 8.0

[Rob Mayoff]

+-- On Feb 12, Jerry Asher said:
> I would think that if I am really pushing a stack frame onto a stack,
> then I presumably have to know where the base of the stack is and the
> top of stack.

You don't need to know where the base of the stack is normally. If
you did, you'd have to keep it somewhere. Where? There's no register
dedicated to that purpose. You'd have to look in TLS, or a global table
(sound familiar?), or walk up the stack (which is only possible if
every function on your call stack has played by the rules, which ain't
necessarily so under heavy optimization).

Re: [AOLSERVER] aolserver 3.3ad13 on RedHat 8.0

[Rob Mayoff]

+-- On Feb 12, Jerry Asher said:
> At any rate, I had thought we were talking about, for the most part,
> rare occasions when new threads are created.

I thought we were talking about checking SP every time something (like
a stack frame) is pushed onto the stack. That means you have to know
the limit for SP every time you push a stack frame. The limit depends
on which stack you're using, which in turn depends on which thread is
executing. So you can either store the limits in TLS, or in a global
table which you search using the current SP as the key.

Re: [AOLSERVER] aolserver 3.3ad13 on RedHat 8.0

[Rob Mayoff]

+-- On Feb 12, Jerry Asher said:
> I am trying to understand where the thread-specific limit is involved
> but I can't.

Heap--><--stack3   <--stack2   <--stack1

Stack 3's limit is the top of the heap.  Stack 2's limit is the bottom of
stack 3.  Stack 1's limit is the bottom of stack 2.

If you are willing to allocate the same amount of address space for
every stack, then you can compute the current SP's limits from the
current SP. I'm not sure if that would be faster than looking up a limit
in TLS.

If each stack can be a different size (in terms of address space
allocated to it), then you cannot compute the SP limits from the SP.

> If as a thread, I ask for a new thread to be created and hence a new
> stack, I would guess (but I don't know) that the base for all stack
> pointers are stored in some global, locked, table, along perhaps with
> the limits of the stack which are either stored in that table, or
> local to the stack itself.

Suppose it is. Now you've got to locate the table - which, unless you're
willing to limit the number of simultaneous threads, must be able to
grow and therefore cannot be at a fixed address. Once you've located
the table, you've got to search it using the current SP as the search
key. Maybe you do it by binary search; maybe you do it by hashing the
high bits of SP. Whichever way you choose, I think it's going to require
several instructions.

On some architectures (like all the modern RISCs with 32 general-purpose
registers), you could probably just dedicate a register to being the
stack limit. In such a system, the SP check would probably just take 3
instructions.

The i386 doesn't have any GPRs to spare, but you might still be able to
make it reasonably fast. I think Linux now uses the GS segment register
to point to TLS, so you could put the stack limit at a fixed location in
the GS segment and do the check pretty fast.

Re: [AOLSERVER] aolserver 3.3ad13 on RedHat 8.0

[Rob Mayoff]

+-- On Feb 11, Jerry Asher said:
> It might not solve the problem of one thread still corrupting
> another thread's memory or stack, but assuming a page was larger than
> several stack frames, it would certainly catch most typical stack
> overflows.  Wouldn't it?

Yes, it would catch most overflows. But not all. I suspect that guard
pages are disabled by default, at least on Linux, and that the gcc
"-fstack-check" flag enables them. Try "info libc" and search for
"guardsize".

> But again, maybe I'm missing something here.  When I was writing
> compilers for some small functional languages, I knew, or rather the
> compiler knew at every subroutine push, just how large the new stack
> frame had to be.  It would seem to be pretty easy math, and not too
> harsh of an efficiency hit to have the compiler/interpreter check
> available stack size at each function entry.

Note that each time you create a stack from (or otherwise dynamically
extend the stack), you need to compare the SP to a thread-specific
limit, which means using TLS. I'm not sure how long Linux (for example)
has supported TLS, and I'm pretty sure that its support has changed over
time, so checking SP is not necessarily trivial.

I agree that SP checking would be useful, at least as an option.

Re: [AOLSERVER] aolserver 3.3ad13 on RedHat 8.0

[Rob Mayoff]

+-- On Feb 11, Jerry Asher said:
> Are you really saying you cannot imagine how in a multithreaded
> environment one can automatically and efficiently extend the stack?

Depends on what you mean by "extend the stack".

A single-threaded program has a heap and a stack in a single address
space.  We put the heap at the bottom and the stack at the top and let
them grow towards each other.  Obviously this allows each the maximum
room for growth; we don't have to put a fixed division point into the
address space.

If the stack grows down into a page that the heap wasn't already using,
the OS can detect that and simply map physical memory to that part of
the program's address space. This form of "extending the stack" is easy.

Now, in a program with N threads, we have a heap and N stacks in a
single address space. We must create N-1 divisions in the address space.
(We could get away with floor((N-1)/2) divisions if we let half the
stacks grow towards lower addresses and the other half grow towards
higher addresses, but we'd still need O(N) divisions and the code would
be messy.) The heap and one stack can share one part of the address
space, but each of the other stacks needs its own part of the address
space:

Heap--><--StackN ... <--Stack3  <--Stack2  <--StackN

When thread 2 is created, only the address space at the top of stack
2 needs to be mapped to physical memory. As stack 2 grows, the memory
allocation can be extended as in the single-threaded program. But once
stack 2 exhausts its allocated address space, there's no where else to
go. A C stack cannot be moved, so we can't slide stack 3 down to make
more room.

So the question is, how much address space should we allocate for each
stack? I claim that any automatic method of choosing the allocation is
going to fail for some class of programs. The programmer must ultimately
take responsibility for choosing how much address space to allocate to
each thread. In the case of AOLserver, the programmer may be the guy
writing AOLserver, or it may be the guy writing the .tcl page that uses
a lot of memory.

One might argue that AOLserver's default allocation is wrong. But's a
much different claim.

OK, one more possibility occurs to me: you could allocate stack frames
on the heap. This has an entirely different set of ramifications. If
this is what you had in mind as a way to "automatically and efficiently
extend the stack", great, but I'll be surprised if it's what you were
using on the DEC-10 in 1979.

Re: [AOLSERVER] aolserver 3.3ad13 on RedHat 8.0

[Rob Mayoff]

+-- On Feb 11, Jerry Asher said:
> Sigh, that must've been some sort of computing golden age  Oh for
> the renaissance!

Yep, the golden age - before multithreaded programming.

Re: [AOLSERVER] Post chat reminders a day earlier?

[Rob Mayoff]

+-- On Feb 7, Nathan Folkman said:
> In a message dated 2/7/03 2:31:40 AM, [EMAIL PROTECTED] writes:
> > As an FYI - digest customers of this list get the reminder about the chat
> > on the midnight AFTER the chat ..
>
> Easy enough to fix. Thanks for the feedback.

When I first started sending the chat reminder, I purposely chose to
send it the day of the chat, even though I knew that digest readers
would receive the reminder too late. I did this because a whole day
between the reminder and the chat was enough time for me to forget the
chat almost every time, but an hour or two between the reminder and the
chat was short enough that I usually remembered. Perhaps no one else is
as forgetful as me. It's just something you might want to consider when
setting the reminder schedule.

Re: [AOLSERVER] Offtopic dumb security policy example, at um, aol

[Rob Mayoff]

+-- On Jan 27, Jerry Asher said:
> So I figure out Dossy's aolscreen name, I cons together your daughters
> name and guess your password, and then I get to steal your email.

A secure interface for changing your forwarding address must verify that
you control both the old address (if it has no other way of verifying
your identity) and the new address. The only reasonable way to do so
is by sending passwords of some sort to both the old address and the
new address, and requiring both passwords to be entered somehow before
effecting the address change. If someone needs help implementing such a
mechanism in AOLserver, I can provide some code. (I wrote it over a year
ago for mail.mayoff.com.)

Re: [AOLSERVER] ns_mutex is likely causing our AOL web server to hung

[Rob Mayoff]

+-- On Jan 27, Seena Kasmai said:
> sorry, there is no $ sign in the actual code.
>
> So, is it worth trying to substitute ns_share with nvs stuff (nsv_set &
> nsv_get) to see if the problem goes away ?

Your most effective action, if you want to maximize the utility of
the advice from this mailing list, would be to create a test case
that reproduces the problem, and post it in its entirety. Posting a
"simpified" version of your problematic production code is not very
helpful, because the simplified version is likely to omit whatever is
causing the problem.

That said, I doubt that using nsv_* instead of ns_share will help.
Given your description of the problem, the most likely cause is that
an error is occurring in a critical section (a section where the mutex
is locked), preventing the Tcl interpreter from reaching the "ns_mutex
unlock" command. You have not yet proved to us that this is not the
case.

So the next logical step (other than creating a test case) is to test
the hypothesis that such is the case, by putting catch commands around
your critical sections. For example, suppose the critical section looks
like this:

ns_mutex lock L
SCRIPT
ns_mutex unlock L

Then you should change that to this:

ns_mutex lock L
set code [catch {
SCRIPT
} result]
ns_mutex unlock L
if {$code != 0} {
return -code $code -errorinfo $::errorInfo \
-errorcode $::errorCode $result
}

(You'll need to use different variable names if you already have
variables named "code" and "result".) You can see that this guarantees
that L will be unlocked, no matter what happens when SCRIPT is executed.

Another approach would be to create a procedure like this:

proc ns_mutex_eval {lock script} {

ns_mutex lock $lock
set code [catch {uplevel 1 $script} result]
ns_mutex unlock $lock

return -code $code -errorinfo $::errorInfo \
-errorcode $::errorCode $result
}

Then you would change the example critical section above to this:

ns_mutex_eval L {
SCRIPT
}

This way you don't have to worry about reusing the variable names "code"
and "result", and you don't have to repeat as much code at each critical
section.

Re: [AOLSERVER] Is Aolserver vulnerable?

[Rob Mayoff]

+-- On Jan 23, Jim Davidson said:
> Are byte ranges useful outside big static file downloads?

I don't know.  One level of possibly useful support would be simply to
have AOLserver parse the byte-range request and make it available via an
API.  For example, a site that stores large binary objects in a database
could use the API to return a byte range.

Another level of support would be to make fastpath and ns_returnfile use
the byte-range info to return just the requested portion of a file. API.
A site that delivers large binary files from a database might find this
useful.  I implemented this in 3.3+ad12.  At ArsDigita we only used
AOLserver - we didn't have a separate server for static files.

Re: [AOLSERVER] Is Aolserver vulnerable?

[Rob Mayoff]

+-- On Jan 23, Nathan Folkman said:
> What portions do you think would make the most sense to support, and what
> benefits would supporting those features provide?

Keep-alive enabled by default - allows persistent client/server
connections without negotiation.

Chunked transfer coding - allows streaming content within persistent
connections.

Byte ranges - allows a client to resume an interrupted transfer.

Re: [AOLSERVER] adp parsers and aolserver 4.0

[Rob Mayoff]

+-- On Jan 20, Jim Davidson said:
> No, it doesn't.  Each "chunk" of ADP must be a valid Tcl script as they're
> all executed independently.  A parser which could handle the above would
> basically convert the whole page into a single script.  Downside with that
> solution is an error anywhere in the page would generally result in no output
> which is why it's not done that way.  Perhaps it could be a config option,
> maybe mapped to specfic files when the single-script approach would be
> useful?

You could combine the two features. Accumulate enough alternating
code/text blocks to get a complete set of Tcl commands (as defined by
"info complete" or Tcl_CommandComplete). Wrap that up as one chunk
of error-protected script. Sometimes the chunk will contain just one
<%...%> block, and sometimes it will be several (with interspersed
raw text blocks). This approach is completely compatible with all ADP
scripts supported by the existing system.

Here's the algorithm expressed as a Tcl script. (It could easily be done
in C too.) Suppose the ADP has been parsed into a list of alternating
chunks of raw text and Tcl code, stored in variable `chunks'. Let the
first chunk always be raw text. This code creates a Tcl program in
variable `script' that represents the entire ADP.

set script ""
set partial_script ""

foreach {text code} $chunks {

# First, handle the raw text chunk.  If we have no partial
# script accumulated, we'll just append a print command
# to the full script.  If we do have a partial script
# accumulated, we append the print command to the partial
# script.
set svar [expr {$partial_script == "" ? script : partial_script}]
append $svar [list ns_adp_puts -nonewline $text] "\n"

# Now handle the code chunk.  Append it to the (possibly empty)
# partial script.
append partial_script $code

# Now see if the partial_script is complete and non-empty.
# If so, append it to the full script.
if {[info complete $partial_script] && $partial_script != ""} {
append script [list _ns_adp_eval_code $partial_script] "\n"
set partial_script ""
}
}

if {$partial_script != ""} {
# We expect that _ns_adp_eval_code will always get an
# error on this partial script, but oh well...
append script [list _ns_adp_eval_code $partial_script] "\n"
}

You need one new run-time command, _ns_adp_eval_code.  It's pretty
simple:

proc _ns_adp_eval_code {script} {
set code [catch {uplevel 1 $script} result]
if {$code != 0} {
ns_log Error "[ns_conn url]: ADP script evaluation error: code $code, 
result [list $result], traceback:\n$::errorInfo"
}
}

Re: [AOLSERVER] high ASCII in regexp (AOLserver 3.5.1 & tcl8.4.1)

[Rob Mayoff]

+-- On Nov 22, Dossy said:
> This doesn't make sense.  How do you explain this:

[deletia]

> $u is getting set to what I'd expect it to, but $m isn't.

Tcl stores strings internally in UTF-8. Sometimes it converts strings to
UCS-16 (16-bit characters), for example to do regexp matching, and then
converts them back to UTF-8. Tcl is careful to make sure it uses only
UTF-8 internally by translating all input, via the channel mechanism, to
UTF-8.

AOLserver blows that care away by handing non-UTF-8 strings to Tcl via
C interfaces that were only intended to receive UTF-8. (This is exactly
what nscp is doing.) Tcl doesn't look at or modify the contents of the
string unless it has reason to. So if you don't do anything to the
string via Tcl, nscp gets the string back unchanged, and sends it to you
over a raw socket (not a Tcl channel), so you see it unchanged.  Hence
the $u behavior.

As soon as you start to manipulate the string, especially when you do
so using something like regexp (which converts the string to UCS-16),
you're likely to generate garbage, because the functions that manipulate
UTF-8 strings are operating on non-UTF-8 strings. Hence the $m behavior.

BTW, this is exactly the same problem that I described in
 two years ago.

> Also, this is reproducible in an ADP page as well.  (Actually,
> that's where the problem I was seeing originally started -- I've
> just distilled it down via nscp so I could demonstrate what I
> was seeing in my actual code.)

Same thing. The ADP processor doesn't honor the C API's UTF-8
requirements, so sometimes you get garbage.

> Funny enough, tclsh8.4 does the right thing:

Of course.  tclsh reads the input via a Tcl channel, so it does charset
translation.  As I said, nscp doesn't use a Tcl channel and does no
charset translation.

Re: [AOLSERVER] high ASCII in regexp (AOLserver 3.5.1 & tcl8.4.1)

[Rob Mayoff]

+-- On Nov 22, Dossy said:
> Any idea what I'm doing wrong?

You're typing iso8859-1 into nscp. nscp doesn't use a Tcl channel for
input, so it does no charset translation on that input. Hence the system
encoding is irrelevant. You must only send UTF-8 to nscp, and you'll
only get UTF-8 back.

Re: [AOLSERVER] Reminder: Weekly Chat Today (Thursday, November 20, 2002)

[Rob Mayoff]

+-- On Nov 21, Steve Manning said:
> I think that you possibly mean 19:00 UTC not 18:00. I'm sitting here in
> the chat room at 18:30 GMT and its very quiet. :o)

People never figured out that the chat time was independent of DST back
when I was sending out the reminder, either.

Re: [AOLSERVER] using aolserver for mail

[Rob Mayoff]

+-- On Nov 18, Gabriel Ricard said:
> Or am I just nuts?

You'd be nuts to pursue this path without at least trying other mail
servers. I recommend qmail.

Re: [AOLSERVER] Reminder: Weekly Chat Today (Thursday, November 14, 2002)

[Rob Mayoff]

The chat announcement specifies the time in UTC to eliminate any
ambiguity about time zones and Daylight Saving Time.

Re: [AOLSERVER] AOLserver Project Update

[Rob Mayoff]

+-- On Nov 11, Peter M. Jansson said:
> I'm happy to stand corrected regarding the implementation, but for someone
> writing Tcl code, is there a meaningful difference between my flawed
> conceptual model and the implementation?

"{" is a string but not a list.

Re: [AOLSERVER] HTTP 1.1 Pipelining.

[Rob Mayoff]

+-- On Nov 11, Patrick Spence said:
> Hopefully if this is ever implemented it would be a toggleable item so we
> aren't forced to have it available...

You could set up a preauth filter that removes Range header from ns_conn
headers.  But I don't know why you'd want to disable it.

Re: [AOLSERVER] HTTP 1.1 Pipelining.

[Rob Mayoff]

+-- On Nov 10, Nathan Folkman said:
> HTTP 1.1 is not currently supported, and so far there are no plans for adding
> support for it to the 4.0 version. To be honest it's been a while since I've
> looked at the 1.1 spec - what's it all about, and what benefits would there
> be if we were to support it? Would we need to support all of it, or are there
> particular parts, such as the pipelining you mention, which would be more
> beneficial then others?

It's probably not too hard to get AOLserver to be HTTP/1.1-compliant. I
don't think there are too many additional requirements in HTTP/1.1 over
HTTP/1.0. Mostly there are a bunch of new optional features.

HTTP/1.1 supports byte ranges. AOLserver 3.3.1+ad13 has support for
returning a byte range via fastpath and ns_returnfile. This can be
very helpful for returning large static files to users with unreliable
connections. I think Acrobat may also take advantage of this.

HTTP/1.1 has persistent connections enabled by default.

HTTP/1.1 supports chunked transfer encoding. This means that the server
doesn't need to know the entire entity size in advance (and set the
Content-Length response header appropriately) to enable a persistent
connection. This is useful when a dynamic page takes a long time to
generate.

Re: [AOLSERVER] URL case insensitivity.

[Rob Mayoff]

+-- On Nov 8, Lamar Owen said:
> This may be an obvious one, but I'm trying to move a site over from an IIS
> host to an AOLserver one, and the web pages link to mixed-case filenames.
> However, the filenames are all actually lower case, meaning I get a lot of
> 404's.

Write a module that provides a Tcl binding for Ns_SetRequestUrl. Then
use a that to write a Tcl preauth filter that smashes the URL to
lowercase.

Or write a module that does the same entirely in C.

Re: [AOLSERVER] malloc replacement libraries?

[Rob Mayoff]

+-- On Nov 7, Peter M. Jansson said:
> On Wednesday, November 6, 2002, at 11:03 PM, Nathan Folkman wrote:
>
> > What are the major differences that would need to be bridged between the
> > stock 3.5.1 code base and 3.3+ad13
>
> The ACS version of AOLserver has i18n support and changes in the DB
> interface to support bind variables for the Oracle driver.

It's the "ArsDigita" version, not the "ACS" version.

There were no changes to AOLserver for the sake of bind variables. That
was implemented entirely in the Oracle driver.

Below is the "DISTRIBUTION.txt" file from 3.3.1+ad13. It lists all the
differences between 3.3.1+ad13 and stock 3.3.1. Since ArsDigita began
moving off of AOLserver after that release (due to the reimplementation
of ACS in Java), I never ported the patches to 3.4. I've never looked at
the code for 3.5 or later.  The character encoding support is the
biggest, ugliest change.

/**/
This is an ArsDigita distribution of AOLserver 3.3.1 (patchlevel 13).
It returns

  Server: AOLserver/3.3.1+ad13

as an HTTP header. It includes the following patches on top of the
standard AOLserver 3.3.1.

@@@ Carried over from 3.2+ad12:

- Patches to support character encodings.  Described in
  encoding-doc.html.

- Add errorminsize to doc/config.txt.

- Added byte range support in fastpath.c and ns_returnfile.

- Added Tcl command "ns_db stats poolname", which returns a two-element
  list.  The first element is the maximum number of handles in the pool
  (equal to the "connections" config parameter).  The second element is
  the number of handles currently available in the pool.

- Reset ADP exception before executing an ADP, in case previous ADP
  called ns_adp_break, etc.

- Ns_QueryToSet will not allow parameters whose names end with ".tmpfile".

- Added boolean database parameter "WarnEmpty".  If this is set, then
  AOLserver will log a warning when the last handle in a database pool
  is empty, and when a thread tries to get a handle from an empty pool.
  Set this in the ns/db/pool/poolname section.

- Patch to op.c to not crash on bad HTTP request line if nsd.tcl has a
  401 redirect.

- Patch to NsHandleSignals to actually exit on Linux if a SIGSEGV is
  received.

- Patch to ns_sourceproc to cache Tcl pages (including bytecodes) if
  nscache module is installed.

- Set system encoding to ns/server/server1/SystemEncoding (default
  utf-8) in modules/tcl/init.tcl.

- Fix channel memory leak in tclIO.c.

@@@ New in 3.3.1+ad13

- Declare Ns_ConnWriteRawData in ns.h.

- Fix switch statement in ns_choosecharset.

- Import fix for freeing of Tcl TSD from AOLserver 4.0 tree.

- Merged additional i18n support from Henry Minsky, allowing programs
  to translate form data to multiple charsets within a single HTTP request.

Re: [AOLSERVER] malloc replacement libraries?

[Rob Mayoff]

+-- On Nov 6, Andrew Piskorski said:
> That is good advice in general, but probably isn't relevent for my
> particular problem.  I want to make the vendor code more robust by
> sliding a different malloc in underneath it, not simply wall it off in
> its own sandbox and let it corrupt itself as much as it wants there.

If you could restart the proxy and have it restore its state somehow,
then it's relevant to your problem.

You haven't said what errors Purify reports in the vendor library. If
the library double-frees, or writes to freed memory, then adding padding
around allocated blocks won't help.

On systems with GNU libc (such as Linux systems), you can easily use
__malloc_hook and friends to do what you want. See the "Hooks for
Malloc" node in the libc info. Perhaps you can do something similar if
you're on another system.

Re: [AOLSERVER] segfault in ns_malloc, _smalloc

[Rob Mayoff]

+-- On Oct 25, Andrew Piskorski said:
> What could possibly be causing it to segfault in _smalloc, of all
> places?

Heap corruption. Segfaults in malloc or free are virtually always due to
heap corruption. Probably something is overflowing a buffer, or freeing
something twice, or writing to freed memory.

> I normally use gcc 2.95.2, but I also tried Sun cc (aka, Sun WorkShop
> 6 update 2 C 5.3 2001/05/15) - seems to make no difference.  Purify
> (with both gcc and Sun cc) reports various sorts of "errors", none of
> which I can do anything about (in the vendor library), and I'm not at
> all convinced they have anything to do with this problem anyway.

Sounds suspicious.  If they're just UMRs, they're probably not the
culprit.  If they are writes to unallocated/freed memory, they are
definitely problems and probably related to your segfaults.

Here's one method I used with occasional success when debugging this
sort of problem (back at ArsDigita, before I got Purify working): Dump
the instruction that got the fault, which you can do with "x/1i $pc".
>From that you can figure out what register malloc is dereferencing.
Look at the contents of that register. Suppose the register contains
something like 0x6E647265. It just so happens that all of those bytes
are ASCII characters; they spell "ndre". So if you have some idea of
what code handles the string "ndre", you have an idea of where to look.
Usually you won't be so lucky and the bogus pointer won't just be ASCII
characters. Then you can try to examine the code leading up to faulting
instruction to try to figure out where the bogus pointer got loaded
from, and look in that part of memory for clues - ASCII strings, and
things that look like structs used by your C code.

It's a rather difficult process, and probably not necessary. You have
Purify. It's pretty darn good about these things. If you're running nsd
with the -z flag, turn it off while debugging this, because it might
make Purify work even better. You say that Purify is already reporting
errors - you should get those fixed. If you can't get your vendor to fix
his library, then either replace that library or isolate it in another
process and talk to it over a socket or pipes.

Re: [AOLSERVER] Extended ASCII (accented) characters rendered as Atilde + proper-char-minus-64

[Rob Mayoff]

+-- On Oct 15, Jeff Hobbs said:
> My guess is that whatever finally outputs (to stdout?) isn't doing
> the conversion correctly.  Perhaps 'fconfigure stdout' will show
> something not correct?

The output doesn't go to stdout. Indeed, the output doesn't go through
the Tcl channel mechanism at all. I investigated this at length a
couple of years ago at ArsDigita and hacked some fixes/workarounds into
AOLserver. That was the major difference between 3.3+ad13 and stock 3.3.

See .  Note that this document
describes the behavior of AOLserver with the ArsDigita patches.

Re: [AOLSERVER] Ns_TlsAlloc needs Ns_MasterLock ?

[Rob Mayoff]

+-- On Oct 14, Andrew Piskorski said:
> I am kind of confused, as a lot of the code in AOLserver DOES use
> Ns_MasterLock like that, but some of it does not, and nothing in the
> docs suggest that you need to or should.
>
> E.g., aolserver/nsd/adp.c and aolserver/nsd/dbinit.c both use
> Ns_MasterLock.  aolserver/thread/test.c seems to sometimes use it
> sometimes not.  nscache/tclcache.c definitely does not use it.

tclcache.c should use it.  That it doesn't use it is a bug, but it's
unlikely to be triggered.

Any time you call Ns_TlsAlloc, you should ensure that no other thread
can be calling Ns_TlsAlloc on the same Ns_Tls object at the same time.
You can do that with Ns_MasterLock/Ns_MasterUnlock.

My normal usage (and therefore ArsDigita's) was to create all caches at
server startup time, when only a single thread is running. There's no
possibility of a race condition if you only call "ns_cache create" at
startup time (or if you never create thread-private caches).

Re: [AOLSERVER] Sharing Files Between Interpreters

[Rob Mayoff]

+-- On Sep 5, Sunil Samuel said:
> But tcl does not have a detach command and aolserver complaints that the detach
> command is not found.
>
> Any ideas?

You can use my dqd_utils module.  It provides attach and detach
commands.

Re: [AOLSERVER] performance of ns_write?

[Rob Mayoff]

+-- On Aug 14, Andrew Piskorski said:
> Or is it just that ns_write will block if the
> socket send buffer is full?

I believe that's the case.  ns_write just puts the data into the kernel's
socket buffer and returns immediately if possible.

> And if so, how do I find out how big my
> TCP/IP send buffer is?

Call getsockopt with SO_SNDBUF.  The default, and the manner in which
you set the default, varies from system to system.  On Linux the default
is in /proc/sys/net/core/wmem_default.  In AOLserver 3.4 I think you can
set sndbuf in the nssock section of the config file to change it.

Re: [AOLSERVER] connection thread keeps running?

[Rob Mayoff]

+-- On Aug 14, Andrew Piskorski said:
> In AOLserver 3.x (and 3.3+ad13 in particular), I believe that a
> connection thread continues to execute until it eiter finishes all the
> code it's running or errors out.  The thread never "knows" that the
> client is no longer waiting for a request, and so can never try to
> stop running because of that.  And, nothing else ever prevents a
> thread from running to completion.
>
> Is that true?

Yes.

> And if you do want to detect whether the client is still waiting (aka,
> the client tcp/ip connection is still live?), is there any way to do
> that?  (I think this was discussed here before, but I couldn't seem to
> find it in the archives.)

Usually the return value of ns_write is ignored, but as I recall,
ns_write returns "0" if the socket has been shut down (or an error
occurred) and "1" otherwise.

Re: [AOLSERVER] Seeking ns_cache configuration advice

[Rob Mayoff]

+-- On Jul 31, Dave Siktberg said:
> Using google I did find this location serving the documentation page,
> which will whet your appetite until you get the code:
>
> http://java.cms.livjm.ac.uk/local/as23docs/html/tapi-c22.htm

Unfortunately, that's not the documentation for my module. AOLserver 2.3
had an ns_cache Tcl command, but it was removed in AOLserver 3. I don't
know why it was removed. I did not know about 2.3's ns_cache command
when I wrote the nscache module, so the ns_cache command in the nscache
module does not have the same syntax as the ns_cache command in 2.3.

I have put the last version of nscache on my web page:



The documentation is here:



This is version 1.1, though it isn't marked as such. I encourage
any interested party to put the code in sourceforge or some other
repository.

Re: [AOLSERVER] Seeking ns_cache configuration advice

[Rob Mayoff]

+-- On Jul 30, Jim Wilcoxson said:
> I'm not complaining, because this isn't particularly important to me,
> but I can't imagine a relatively new AOLServer developer figuring any
> of this out.  I'm lost, and I've been developing on it for 8 years.

The ns_cache module was part of the ArsDigita release. I think it
was also downloadable separately. I don't know if it ever made it to
sourceforge.

Re: [AOLSERVER] Seeking ns_cache configuration advice

[Rob Mayoff]

Jim, are you aware that AOLserver 3 has C API for caches that
automatically flush outdated entries and automatically evict LRU entries
to limit memory use, and that there's an ns_cache module that provides a
Tcl layer for the C API?

+-- On Jul 30, Jim Wilcoxson said:
> Just roll your own cache, whereever you need it, or put it in a routine:

[AOLSERVER] weekly chat

[Rob Mayoff]

I haven't actually joined the weekly chat in months, as I am no longer
working on AOLserver and am busy with other things. Therefore I'm going
to turn off the program that sends out the weekly-chat reminder message.
Anyone who wishes to take it over can e-mail me for a copy of the shell
script that generates and sends the message.

Re: [AOLSERVER] ns_duphigh error

[Rob Mayoff]

Probably means you have too many open file descriptors. Maybe you could
just get away with increasing the per-process file limit. How you do
that may depend on the system. You might start by trying 'ulimit -n
4096' in the script that starts nsd.

+-- On Jun 20, [EMAIL PROTECTED] said:
> Has anyone seen this error or know what it means?  It caused our webserver to
> completely stop responding today.  AS 233 (yes I know we need to upgrade ;)
>
> [20/Jun/2002:14:39:42 -0400][6458.6][-Sockets-] Warning: ns_duphigh:
> fcntl(9, F_DUPFD, 256) failed:  Too many open files
>
>

Re: [AOLSERVER] AOLserver segfaulting

[Rob Mayoff]

+-- On Jun 3, Jeremy Collins said:
> I am having some trouble with our AOLserver setup.  It crashes
> frequently under extremely light load.  Below is the backtrace.  It
> appears that something in libc6 (gethostbyname) or oci (OCIServerAttach)
> is causing the problem, in particular when ns_db tries to open a new
> connection to Oracle.

Can you get any db handles from this pool successfully?  Show us the
config section for the "prod" pool.

Re: [AOLSERVER] AOLserver Oracle Driver Improvements

[Rob Mayoff]

+-- On May 30, Andrew Piskorski said:
> I believe the latest Oracle driver is version 2.6, from c. June 11
> 2001.  At least, that's the version I have, and it came with the
> AOLserver 3.3+ad13 from ArsDigita.

As I recall, I never packaged version 2.6 separately from AOLserver
3.3+ad13.

Re: [AOLSERVER] AOLserver Oracle Driver Improvements

[Rob Mayoff]

+-- On May 30, Jeff Hobbs said:
> How far apart is this from the general oratcl extension?

Very, in the sense that it is a completely different codebase (as far as
I know) and implements the AOLserver database driver API.

Re: [AOLSERVER] AOLserver Oracle Driver Improvements

[Rob Mayoff]

+-- On May 30, Jeremy Collins said:
> Who currently maintains the AOLserver Oracle driver?

No one, as far as I know. I was the last maintainer at ArsDigita. Since
I no longer use AOLserver professionally and do very little with it in
my spare time, and since the Oracle driver source code is incredibly
ugly, I have no interest in doing any further work on it.

Therefore I suggest that you package up your version and call yourself
the maintainer.

Re: [AOLSERVER] bug in ns_cond broadcast?

[Rob Mayoff]

+-- On May 23, Todd Volkert said:
>   nsv_set global cond [ns_cond create]
>   nsv_set global mutex [ns_mutex create]
>
>   proc foo {} {
> set cond [nsv_get global cond]
> set lock [nsv_get global mutex]
> ns_cond wait $cond $lock
>   }
>
>   proc bar {} {
> ns_cond boadcast [nsv_get global cond]
>   }

You have to lock $lock before calling ns_cond. ns_cond atomically
unlocks $lock and begins waiting for $cond to be signalled. When $cond
is signalled, ns_cond will reacquire $lock before returning. Note that
only one thread can own $lock at a time, so if you have multiple threads
waiting on the same $cond and $lock, they'll have to take turns owning
$lock.

You also almost always need to lock $lock before calling ns_cond
broadcast and unlock it afterwards to avoid race conditions.

> You run foo as many times as you want in different threads of AOLServer,
> then you run bar from another thread, and only one of the other threads
> wakes up.  All other threads are stuck until you bounce your virtual server.

Sounds like one thread (the live one) gets $lock and never releases it.
So the hung threads are all hung in ns_cond waiting for $lock.

Re: [AOLSERVER] AOLServer corrupting Form data

[Rob Mayoff]

+-- On May 9, atfrost said:
> Tedious stuff, eh?  But I'm not convinced that this isn't a bug.

Oh, I'm sure it's a bug.  I'm just saying that it's probably not
something easily solved, or something that can be solved simply by
implementing published standards.

> As far as I can tell, the current (5.0+) versions of IE and Netscape
> submit form data using whatever encoding is being used to view the form
> submit page.  At least, this has been my emperical experience - I'm not
> too sure what happens when you do something like submit Japanese
> characters from an iso-8859-1 encoded page...

But then you have to ask whether you can rely on users having those
versions of the browsers.  When I worked on this stuff some two years
ago, I suggested just doing everything in UTF-8.  But Henry Minsky (in
the ArsDigita Japan office) said browsers that support UTF-8 had only
50% penetration in Japan at the time, so we couldn't just do that.
Maybe by now the fraction is close enough to one that transmitting and
receiving only in UTF-8 is feasible.

> Does AOLServer perform any implicit silent conversion on received form
> data?

Through version 3.3, standard AOLserver doesn't do any "silent
conversion". However, Tcl does, in some circumstances.  It depends on
what you do with the data.

I never looked much at AOLserver 3.4, but I think they might have added
a little bit of I18N support in that version.  I'm pretty sure it wasn't
as complete as what I did for ArsDigita, though.  You might want to try
switching to that version.

> It seems that there must be a way to correct the modification
> that's happening to the data, since AOLServer undoes whatever it's
> doing when it ships the data back out to the client.

The problem is that Tcl may perform uninvertable transformations on
strings that are not in normalized UTF-8 format.

Re: [AOLSERVER] AOLServer corrupting Form data

[Rob Mayoff]

This happens due to various factors. AOLserver didn't historically do
anything about character sets, but Tcl 8.1 (and later) assumes that
strings in memory are in UTF-8 and performs conversions at its
boundaries.  AOLserver puts stuff in Tcl's memory without doing that
conversion.

And HTTP and HTML are weak when it comes to specifying character sets.
When you submit a form using the GET method, it has to put the form data
in the URL. But what encoding should it use? As I recall, there's no way
for the server to ask the client to use a specific charset, and no way
for the client to tell the server what it used.

I wrote a document about this a while back when I tried to make it all
work at ArsDigita: . However,
the code examples in that document apply to the ArsDigita versions of
AOLserver (the last of which is 3.3+ad13). I hacked those versions to do
character set translations. Probably none of the example code will work
in the standard versions of AOLserver.

You can probably find some other documents about these problems on
arsdigita.com or elsewhere. I think Henry Minsky wrote a couple of
things about it.

+-- On May 9, atfrost said:
> I posted a few days ago regarding some problems I was having using
> data received by AOLServer via form submission in certain charsets.

Re: [AOLSERVER] Ns_TclEval / ns_sendmail documentation

[Rob Mayoff]

+-- On May 9, Jason Saunders said:
> If the " " are there for the gaps between to, from and subject, why isn't
> there one between "ns_sendmail" and to?

Because the example code is buggy.

> The other thing that puzzles me is that the documentation for
> NS_DStringVarAppend says the list must end with a NULL, and this is missing
> from the code example.

The solution to the puzzle is that the example code is buggy.

> To make it completely obvious even to a buffoon like me, can someone please
> give an example of how to send an email to: [EMAIL PROTECTED], from:
> [EMAIL PROTECTED], subject: Hiya, body: How u doin? Email me back!

Ns_DString result;
Ns_DStringInit(&result);
Ns_TclEval(&result, Ns_ConnServer(conn),
"ns_sendmail [EMAIL PROTECTED] [EMAIL PROTECTED] "
"Hiya {How u doin? Email me back!}");

Re: [AOLSERVER] Reminder: AOLserver weekly chat tomorrow

[Rob Mayoff]

Has the listserv been down?  I don't know why else this would have taken
two days to be sent.

+-- On May 1, [EMAIL PROTECTED] said:
> The AOLserver weekly chat takes place tomorrow, 2002-05-02, and
> every Thursday. Common topics include AOLserver, Tcl, SQL, ACS,
> and general web-related questions.

Re: [AOLSERVER] setting password in nsperm's password file

[Rob Mayoff]

+-- On Apr 26, Janine Sisk said:
> How are we supposed to generate the password for modules/nsperm/passwd?  I
> tried using crypt and I tried making a user via adduser and copying their
> password out of /etc/shadow, but neither worked.  Older users copied from an
> old users.dat file do work, so I know it's a password-encrypting issue and
> not a configuration issue.

The ns_crypt command will do it, but I usually use this perl script:

#!/usr/bin/perl
# $Id: crypt,v 1.1 1999/11/29 06:29:01 mayoff Exp $

$password = shift;
$salt = shift;

print crypt($password, $salt), "\n";

Run "man 3 crypt" for an explanation of the crypt function.

Re: [AOLSERVER] Oracle connections going defunct

[Rob Mayoff]

+-- On Apr 25, Janine Sisk said:
> Well... I concluded that I was not using BEQUEATH because I looked at
> listener.ora, sqlnet.ora and tnsnames.ora and saw only "PROTOCOL = TCP" and
> "PROTOCOL = IPC".  But I just noticed that when I do a ps, I see

You need to set your datasource properly in your config file.  For
example, my tnsnames.ora contains these stanzas:

TEST_IPC.JET.DQD.COM =
  (DESCRIPTION =
(ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = IPC)(KEY = TEST))
)
(CONNECT_DATA =
  (SERVICE_NAME = TEST.jet.dqd.com)
)
  )

TEST_TCP.JET.DQD.COM =
  (DESCRIPTION =
(ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
)
(CONNECT_DATA =
  (SERVICE_NAME = TEST.jet.dqd.com)
)
  )

If I set my datasource to "test_tcp.jet.dqd.com", I get a TCP
connection.  If I set my datasource to "test_ipc.jet.dqd.com", I get a
System V IPC connection.  If I set my datasource to "", then I get a
BEQUEATH connection to the instance named by $ORACLE_SID.

Re: [AOLSERVER] Oracle connections going defunct

[Rob Mayoff]

+-- On Apr 23, Barry Books said:
> I have not run on Linux in a while but when I did I remember having to set
> the database handle timeout to a very large number otherwise I had this
> problem. I think there is a bug in the database driver on Linux since I
> don't have this problem on Solaris.

There was a bug where closing a handle would hang, but I'm pretty sure
that only happened when using the BEQUEATH adapter, which Janine isn't
using.

Janine, I assume you've looked in your bdump, cdump, and udump
directories for evidence.

Is the defunct process a child of nsd?

Re: [AOLSERVER] C based modules, tcl interps and memory allocators

[Rob Mayoff]

> Also, is there a significant difference between sequential and random reads
> within an Intel processor cache?

Whether the difference is significant really depends on your
application. The processor loads an entire 32-byte level-1 cache line
whenever it needs any byte from that line. The data in the cache line
becomes available in address order (low to high). Therefore it's
better to access the data sequentially. But this will probably only be
significant when you're doing low-cycle pipelined operations on millions
of numbers.  You haven't given any indication that you're doing that
sort of thing.  (In fact, you haven't even told us what you're really
doing.)

Read the Pentium optimization manual for more.  You can get it from
Intel's web site somewhere.

Re: [AOLSERVER] C based modules, tcl interps and memory allocators

[Rob Mayoff]

+-- On Apr 16, Jason Saunders said:
> Well, it seems the Ns_Cache functions weren't what I was looking for, but I
> have an idea of what might work...

Have you prototyped any of this code to determine whether you even need
to worry about this?  Premature optimization is the root of all evil.

> To ensure locality of the linked lists (of type Y objects), I can allocate a
> stack of 4k or 8k and a stack access mutex as each type X object is created,
> to be used to store the type Y objects associated with the new type X
> object. And then by keeping a pointer to the top of the stack I can then add
> type Y objects to the stack and keep them local to each other.
>
> Then the type X objects could be put in hashes.
>
> How does that sound?

If you're only talking 8K bytes of objects, then I question whether you
really have enough objects to worry about locality of reference. How
many Xs are you talking about?

Furthermore, given such a small number of Ys, you might be better off
storing the Ys in an array, and simply shifting the tail of the array
when you need to insert an element. This will maximize your cache hits
during sequential access (which is probably what you really mean when
you talk about locality).  Whether this is a better approach depends on
the ratio of insertions to accesses.

None of this is worth doing until you have a prototype on which you can
actually measure the performance.

Re: [AOLSERVER] Ns_Cache questions (Was Re: C based modules, tcl interps and memory allocators)

[Rob Mayoff]

+-- On Apr 15, Jason Saunders said:
> Pete's idea of using the Ns_Cache() functions looks ideal. As I understand
> it, when you call Ns_CacheCreateSz(), you specify the maximum size of the
> cache that you want and then Ns_CacheMalloc() allocates memory from that
> cache. I then have some questions:

No, that's not what Ns_CacheMalloc does. Ns_CacheMalloc allocates memory
from a heap owned by the cache, but there is no limit on the size of
that heap. A cache tracks its current size based on the size parameter
of the Ns_CacheSetValueSz function. You have to use that function to
control the size of the cache.

> 1. Apart from the limitations of main memory, is there a limit to the number
> of caches I can have? Could I have, say, 1000 caches of 8k each?

Yes.  But there is some overhead for each cache.  I don't know exactly
what it is, but I wouldn't be surprised if it's on the order of 256
bytes.

> 2. Is the memory allocated on executing Ns_CacheCreateSz() contiguous?

Ns_CacheCreateSz only allocates a small amount of memory, irrelevant to
the size limit you specify for the cache.

> 3. Is there a way of deleting a cache once it is no longer needed? In the
> online documentation, I can see Ns_CacheDeleteEntry() but that refers to the
> cache entries and not the cache itself.

Ns_CacheDestroy.

> 4. As an alternative to 3, is it possible to re-name a Cache after it has
> been created?

No.

Re: [AOLSERVER] Problems with nsd 2.3.3 on RH 7.2

[Rob Mayoff]

+-- On Apr 10, Janine Sisk said:
> Wait, I take that back.  Right now there are 42 nsd processes running but
> only 24 showing up as connected in netstat.  So what does that mean?

Well, it may mean that you have in the neighborhood of 16 idle
connection threads.  What are your minthreads, maxthreads, and
threadtimeout config values?

Re: [AOLSERVER] Problems with nsd 2.3.3 on RH 7.2

[Rob Mayoff]

+-- On Apr 10, Lamar Owen said:
> 7.2's glibc is so much newer than 6.2's that the linkage may be broken.
> Binaries linked/compiled under 6.2 usually do _not_ work properly on 7.2.
> Even with the compat libraries installed.  The reason seems to be kernel 2.4.

To use some JVMs on 2.4, you have to set LD_ASSUME_KERNEL=2.2.5.  Maybe
setting it will help with AOLserver 2.3.3.

Re: [AOLSERVER] Problems with nsd 2.3.3 on RH 7.2

[Rob Mayoff]

+-- On Apr 10, Tom Jackson said:
> I would try using daemontools to start and restart AOLserver. This tool
> should correctly handle killing all children of the main process.

It probably won't. It sends signals only to its direct child.

> I have one process I control with daemontools using fghack that allways
> creates a zombie process (portsentry), but killing and restarting cleans up
> this mess (and then re-creates a new zombie).

This indicates that portsentry is simply not calling wait on the child
process.  When you kill portsentry, the child is inherited by init,
which calls wait.

>From Janine's description, it sounds like the "defunct" threads are not
actually zombies, or else they are not direct children of the nsd
process that she's killing and their actual parent is not dead.

Since she's running AOLserver 2.3.3 on Redhat 6.2, this could be rather
hard to debug.  She said she's using Oracle.  My first action would be
to tell the Oracle driver to use a TCP or IPC connection to Oracle,
rather than the "bequeath" adapter, if she hasn't already.  I have seen
too many problems with the bequeath adapter to trust it for production
use.

Re: [AOLSERVER] Digest authorization / WebDAV

[Rob Mayoff]

+-- On Apr 9, Zoran Vasiljevic said:
> So what should I do ?

It seems to me that you would be best served by a module, in either Tcl
or C, that runs as a preauth or postauth filter and implements Basic and
Digest authentication and IP/hostname checking.  I don't see much point
in trying to work with nsperm as is, though its code would perhaps be a
useful starting point.

I don't see a point in modifying the core to also parse Authentication:
Digest headers. I think Ns_SetRequestAuthorizeProc should be ripped
out and replaced with a new filter type, "auth". Auth filters should
simply be run after preauth filters and before postauth filters. I don't
see any advantage in the current, completely separate mechanism for
authorization.

Re: [AOLSERVER] Digest authorization / WebDAV

[Rob Mayoff]

+-- On Apr 9, Goodwin Scott S GS-13 96 CG/SCTOB said:
> You could use a single server but only allow DAV access on a separate
> nsopenssl port. Could even use client PKI certs on that port to make the
> authentication more secure. Then deny any kind of DAV access on any other
> nssock or nsopenssl port.

I understand, but that still doesn't put write access in a separate
process.

Re: [AOLSERVER] Digest authorization / WebDAV

[Rob Mayoff]

+-- On Apr 9, Zoran Vasiljevic said:
> If I'm not mistaken (correct me if I'm wrong, please),
> but, if I do not load the ns_perm module then:
>
>   - I do not get the "allowuser" functionality (or is it "ns_perm allowuser"?)
>   - I lose all other user's hostname (ip/domain) checking
>   - Ns_AuthorizeRequest always grants access if I do not register
> my own authorization callback function
>
> If above holds true, then this can be used as a starting point
> when developing DAV, indeed.

Yes, it holds true.

Personally, I'd not be inclined to use a single server for both DAV and
normal web serving. By separating the services into different processes,
you can run the normal web server as a uid that only has read access to
the files, and the DAV server as a uid that has write access. Then you
can restrict the DAV server to only allow SSL connections (and not even
load nssock), and use different firewall rules for the two servers.

In fact, this is how I set up some sites I host: I use nsd as the web
server with read-only access to the files, and Apache/mod_dav to allow a
select few to update the content. I don't even allow direct connections
to the DAV server over the Internet - I require the remote users to
connect through an SSH tunnel.

> But, I'm afraid that people would really need both (basic and digest
> and/or some other scheme in the future) at the same time when it comes
> to deployment. That's why a hook in the Ns_AuthorizeRequest allowing
> other schemes would be a good thing. Hopefully this thread will serve
> as a kick for somebody to consider doing a proper integration work in
> the core server.

It as already possible to use both at the same time (for different
URLs), as I described.  Just make nsperm allow "" to access any URL that
is handled by the Digest filter.

I agree that the authorization hooks could be improved.  However, it's
possible to use Digest authorization today, without writing or changing
any C code.  You just have to write a Tcl filter.

Re: [AOLSERVER] Digest authorization / WebDAV

[Rob Mayoff]

+-- On Apr 9, Zoran Vasiljevic said:
> On Monday 08 April 2002 22:04, Dossy wrote:
>
> >
> > Could auth schemes not be implemented via trace filters?
> >
>
> Well, almost...

Actually, it's can't.  A trace filter runs after the main request
handler - too late to block access.

A preauth or postauth filter can perform authorization. It will have to
parse the Authorization header itself. If the client is not authorized,
then the filter must send a 401 response with a WWW-Authenticate header,
and return "filter_return".  If the client is authorized, the filter
should just return "filter_ok" (and not send anything to the client).

If you load ns_perm, then it will also attempt to authorize requests.
The simplest solution is to not load ns_perm. If you do load ns_perm,
then (I think) you may simply tell it to allow user "" to access any
URLs that are otherwise protected by your Digest filter. Here's how.

Make sure this line is in nsperm's passwd file:

""::

(It is already in the default passwd file.)  Then put this line in the
perms file:

allowuser inherit GET /my/digest-protected/url ""

Substitute the appropriate URL in place of "/my/digest-protected/url".
Repeat with different URLs as required.

Re: [AOLSERVER] how to set cookies

[Rob Mayoff]

+-- On Apr 5, ÕÅÏþº£ said:
> Excuse me, how can i set the cookies use aolserver c api?
> I want set two params : domain and one id

If you mean that you want to set a cookie named "domain": you cannot.
The word "domain" cannot be used as the name of a cookie.  Try using
something like "mydomain" instead.

char s[1000];
snprintf(s, sizeof buf, "id=%s; mydomain=%s; path=/", id, domain);
Ns_SetPut(Ns_ConnOutputHeaders(Ns_GetConn()), "Set-Cookie", s);

See  for more
details about the Set-Cookie header.

Re: [AOLSERVER] server reload function

[Rob Mayoff]

+-- On Mar 11, å¼ æ^ٓ海 said:
> I  have my AOLserver in inittab already.
> But i should maintain many online user's information and i should not stop the 
>sevice.

You can enable and use the ns_eval function to make all threads
re-source a .tcl file.  You cannot change ns_config data after the
server starts.  Instead, you can copy the config data to an nsv in a
startup .tcl file, and then you can update the nsv as necessary while
the server is running.

Also, it's a bad idea to keep user data only in memory.  You should keep
it on disk somewhere.  AOLserver does crash on occasion; so does the OS,
and sometimes even the hardware fails.