Re: [AOLSERVER] Generating Dynamic PDF's from AOLs
+-- 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 http://www.easysw.com/htmldoc/ 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] TCL Bug?
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] Invalid command name error
+-- 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?
+-- 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?
+-- 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] Lengthy tcl interp initialization
+-- 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
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
+-- 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] Are the weekly chats officially dead?
+-- 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] IM'ed URLs not being logged
+-- 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] Pound vs. ns_write
+-- 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
+-- 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
+-- 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]. http://dqd.com/~mayoff/aolserver/#dqd_log -- 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
+-- 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
+-- 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] can aolserver redirect to a different site
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
+-- 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
+-- 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
+-- 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] [ aolserver-Feature Requests-746579 ] Server instance controller process
+-- 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 4.x and MacOSX: cwd problem
+-- 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] AOLserver 4.x and MacOSX: cwd problem
+-- 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
+-- 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] ADP: are if's possible?
+-- 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?
+-- 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
+-- 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
+-- 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 html headtitleMy Applet/title/head body applet code='myapplet.class' width='400' height='300' param name='username' value='$username' !-- Alternate text for Java-deficient browsers. -- Get Java, Loser! /applet /body /html 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
+-- 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] Does 4.0 cache tcl page object code?
+-- 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] aolserver 3.3ad13 on RedHat 8.0
+-- 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
+-- 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] Post chat reminders a day earlier?
+-- 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] ns_mutex is likely causing our AOL web server to hung
+-- 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?
+-- 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] Is Aolserver vulnerable?
+-- 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] adp parsers and aolserver 4.0
+-- 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)
+-- 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] high ASCII in regexp (AOLserver 3.5.1 tcl8.4.1)
+-- 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 http://dqd.com/~mayoff/encoding-doc.html 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] Reminder: Weekly Chat Today (Thursday, November 20, 2002)
+-- 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
+-- 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)
The chat announcement specifies the time in UTC to eliminate any ambiguity about time zones and Daylight Saving Time.
Re: [AOLSERVER] HTTP 1.1 Pipelining.
+-- 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] AOLserver Project Update
+-- 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.
+-- 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.
+-- 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?
+-- 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] segfault in ns_malloc, _smalloc
+-- 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
+-- 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 http://dqd.com/~mayoff/encoding-doc.html. Note that this document describes the behavior of AOLserver with the ArsDigita patches.
Re: [AOLSERVER] connection thread keeps running?
+-- 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] performance of ns_write?
+-- 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] Seeking ns_cache configuration advice
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:
Re: [AOLSERVER] Seeking ns_cache configuration advice
+-- 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.
[AOLSERVER] weekly chat
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] AOLserver segfaulting
+-- 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
+-- 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] AOLserver Oracle Driver Improvements
+-- 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] Ns_TclEval / ns_sendmail documentation
+-- 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] AOLServer corrupting Form data
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: http://dqd.com/~mayoff/encoding-doc.html. 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] AOLServer corrupting Form data
+-- 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] Reminder: AOLserver weekly chat tomorrow
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
+-- 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
+-- 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
+-- 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
+-- 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] C based modules, tcl interps and memory allocators
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] Problems with nsd 2.3.3 on RH 7.2
+-- 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] Problems with nsd 2.3.3 on RH 7.2
+-- 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] Digest authorization / WebDAV
+-- 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] Digest authorization / WebDAV
+-- 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
+-- 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
+-- 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] server reload function
+-- 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.
Re: [AOLSERVER] Why can you only grab handles from one pool at a time?
+-- On Feb 26, Scott Goodwin said:
Can someone briefly explain to me why, once you have allocated handles from
a database pool, you cannot allocate more from the same pool until you
release all the ones you already have from that pool? Is it a race
condition, a performance trade-off or something else?
It's to avoid deadlock. Let's say you have a pool named mypool with 2
hnadles, and you have a proc deadlock:
proc deadlock {} {
# Step 1.
set db1 [ns_db gethandle mypool]
# Step 2.
ns_sleep 1
# Step 3.
set db2 [ns_db gethandle mypool]
}
Suppose both handles are available in mypool, and thread T1 calls
deadlock. It gets the first handle from mypool and then sleeps for one
second. Suppose that during that second, thread T2 calls deadlock. T2
will grab the second handle from mypool and sleep. Then T1 wakes up and
tries to grab another handle from mypool. There are none left, so T1
blocks. Then T2 wakes up and tries to grab another handle from mypool;
it also blocks. The threads are deadlocked, because each is waiting
for the resource that the other thread owns.
You could try to implement a deadlock-detection scheme in gethandle, but
it would be difficult or impossible to make it work in all cases. For
example, what if T2 isn't waiting for a handle owned by T1, but instead
is waiting for a mutex locked by T1? The simplest solution is to require
a thread to acquire all of its handles (from any one pool) at once. This
prevents the most likely cause of deadlock. You can still deadlock on
mutexes if you want :^), but using mutexes is more advanced than using
database handles.
In ACS, they worked around this restriction by having several pools, and
always grabbing a handle from pool main first, then from subquery,
then from log. (The names are anachronistic.) This is deadlock
avoidance by resource ordering. If you want to know more, go to the
library and find a book about concurrent programming.
Re: [AOLSERVER] Help with Dotted IP conversion
+-- On Feb 26, Jeff Hobbs said:
Also, I believe you implied that you were using a proc, but it is
important to note that toplevel code will be slower if large loops
are used without putting them in procs. This is by design.
And boy was that annoying when we (ArsDigita) wanted to cache .tcl page
bytecode, because .tcl pages are normally executed with the source
command, which doesn't compile. We ended up taking advantage of the
fact that for (in Tcl_ForObjCmd) compiles its first argument, e.g.
for [util_file_contents_cached $filename] {0} {} {}
...compiles the string returned by util_file_contents_cached.
Re: [AOLSERVER] bug using ns_ftruncate
+-- On Feb 22, Jim Wilcoxson said: set fd [open xyz w] puts $fd abcdefg close $fd set fd [open xyz r+] seek $fd 4 puts -nonewline $fd x What happens if you put flush $fd right here, after the puts and before the ns_ftruncate? ns_ftruncate $fd 3 close $fd return
Re: [AOLSERVER] bug using ns_ftruncate
+-- On Feb 22, Jim Wilcoxson said: I just tried your idea and it works correctly if flush is added. I figured this is probably a libc bug but thought I'd post it here in case others have trouble with it. Might be a good idea to add a flush inside ns_ftruncate as a workaround. Tcl doesn't use stdio for channels. Making ns_ftruncate call Tcl_Flush is the correct fix, not just a workaround.
Re: [AOLSERVER] ns_cond wait mutex - what for?
+-- On Feb 22, Andrew Piskorski said: Oh. I think I just realized (at least one reason) why. The flag value, is so if T2 does its ns_cond broadcast BEFORE T1 starts doing ns_cond wait, that T1 will know that the event already occurred, right? Is that the only reason? Yes. It doesn't really have to be a flag. It can be any data. For example, each connection thread checks the connection queue; if the queue is empty, then it waits on a condition which will be broadcast by the connection-accepting thread. Obviously, a connection could come in while all the connection threads are busy; in that case, no one will hear the signal, but the connection-accepting thread will broadcast anyway.
Re: [AOLSERVER] TCL question
+-- On Feb 22, Patrick Spence said:
My problem is I cannot insert the \ before the and then wrap with braces..
I am pulling the string to convert from a database and piping it through my
macro routine and I have not been able to figure out how to get it to work
right.
You need to do a regsub on the subspec to hide the backslashes and
ampersands:
proc insert_macro { thestring key macro} {
regsub -all {[\\]} $macro {\\} macro
regsub -all -- $key $thestring $macro thestring;
return $thestring
}
Re: [AOLSERVER] ns_returnfile
+-- On Feb 20, Steve Miskovitz said: I'm new at AOLServer and I would like to return the contents of a generated ADP page back to the user as javascript. I've been using : ns_returnfile 200 application/x-javascript Try calling the undocumented ns_adp_mime command from your ADP, e.g. % ns_adp_mime application/x-javascript % I haven't actually tried this; I just saw it in the source code.
Re: [AOLSERVER] ns_rand hangs server (again)
+-- On Feb 5, atf said: I seem to have run into a probelm previously reported back in August 2000. Namely, the server hangs when ns_rand is used (the offending function seems to be Ns_DRand in random.c). Rob Mayoff had posted a patch that applied to version 3.0. Would anybody happen to know if this bug is still in the codebase? The function has changed since the first time this bug was posted, although the behaviour appears to have remained. Jim Davidson checked in a similar, but slightly different, fix for this on 2000/8/25, according to CVS: revision 1.5 date: 2000/08/25 13:47:50; author: jgdavidson; state: Exp; lines: +46 -56 Fixed deadlock between Ns_DRand/Ns_GenSeeds. What version of AOLserver are you using?
Re: [AOLSERVER] Porting (aol 2.2 to aol 3.3.1)
+-- On Jan 23, David Valentine said: sscanf(Ns_SetGet(row, west_bounding_coor), %f, west); What is the return code from sscanf?
Re: [AOLSERVER] ns_returnfile and name of the file being downloaded
+-- On Jan 24, Ramin Naimi said: the browser pops up the dialog box asking whether to download/open from location and the file name is set to myget.adp (rather than 1.abc). A common way to do this, if Peter's content-disposition suggestion is inadequate, is to use ns_register_proc to register the script for a whole hierarchy of URLs. Then the page that links to the script can append the desired name to the end of the URL. For example, you register your script to handle all URLs beginning with /download. Then other pages can link to /download/software.zip, or /download/smut.jpg, or whatever. The script will be called in any case, and the browser will use the last component of the URL.
Re: [AOLSERVER] Porting (aol 2.2 to aol 3.3.1)
+-- On Jan 24, David Valentine said: So can anyone tell me why this would cause a bus error: sprintf(out, %f,%f,%f,%f, north, west, south, east); What is out?
Re: [AOLSERVER] Segmentation fault
+-- On Jan 17, Daniel P. Stasinski said: My second suggestion was meant as humor. The reason that your server crashes is because your code is flawed. Obviously his infinite-recursion example will always fail in some way. But his real code might not recurse infinitely. It might simply need to recurse to a greater depth than the default stack size allows. In that case, increase the stack size is the correct solution.
Re: [AOLSERVER] Ns_SetCreate is thread safe?
+-- On Jan 7, Andrew Piskorski said: Problem is, I'm sometimes getting a segfault during the malloc in the Ns_SetCreate (see below), and I don't understand why. Could someone give me advice on this, please? Thanks! Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 7] 0xff14140c in _malloc_unlocked () from /lib/libc.so.1 Looks like heap corruption. You are probably writing past the end of a block, or writing to a freed block, or freeing a block twice some time before this call. Yes, Ns_SetCreate is thread-safe.
Re: [AOLSERVER] unresolved external _h_errno?
+-- On Jan 3, Ramin Naimi said: I'm trying to compile the source under SunOS (sparc) and I get the following error where in dns.c the _h_errno has been referenced and not resolved by link time. Does anyone know what I need to do to make the source compile under SunOS? I don't know what you need to do, but perhaps this will help: The h_errno symbol is how gethostbyname (and related functions) return an error code. It ought to be either #defined in netdb.h, or defined in the same library as gethostbyname. gcc tclstub76.o stamp.o adp.o adpfancy.o auth.o binder.o cache.o callbacks.o c6 This gcc command is seriously broken. Did you misquote it?
Re: [AOLSERVER] Exposing API's to other modules?
+-- On Dec 27, Ramin Naimi said: Hello, How can a module X expose API's to other modules? Hmm. I thought a module could refer to another module's exported C functions directly. Have you tried it?
Re: [AOLSERVER] Can a worker thread return data to client on the existing HTTP connection?
+-- On Dec 18, Ramin Naimi said: - return from the routine - have the worker thread take over returning the rest of the response to the browser over the Ns_Conn that was passed to it. You can't do it. You must not return from your handler until you have fully handled the HTTP request.
Re: [AOLSERVER] We've made a code change,
+-- On Dec 7, Jim Wilcoxson said: I'm confused. Browsers are supposed to handle relative URL redirection, No, they're not. Some (including IE and Mozilla, I believe) do handle relative URLs, but the HTTP/1.1 standard requires the Location header to contain an absolute URL. http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html#sec-14.30
Re: [AOLSERVER] We've made a code change, would like opinions as to is this a good or bad idea...
+-- On Dec 7, Dossy said: However, resource starvation/denial of service is a serious potential problem. Fire up a couple hundred connections where you feed a very large Host: string ... On the contrary, AOLserver limits both the size of each HTTP header line (default 8192 bytes), and the total size of all header lines (default 16384 bytes).
Re: [AOLSERVER] Has anyone gotten nsopenssl to work with IE 5.x/6.x and Win98?
+-- On Nov 26, Nuno Santos said: For IE 5.x/6.x on Win98, a The page cannot be displayed... Cannot find server or DNS Error error is displayed for https requests. These requests never actually get to the server (there are no signs of them in the server's access log). That's not sufficient evidence. Use tcpdump to see whether any packets from the client are reaching the server machine. If no packets are reaching the server machine, then the problem has nothing to do with AOLserver or nsopenssl.
Re: [AOLSERVER] AOLserver is only available on localhost:80
Perhaps you have firewall rules that prevent the host from accepting port 80 connections from other hosts. +-- On Nov 21, Sanjivendra Nath said: From my browser on the localhost, I can see the web pages being served. But, not from other computers on the LAN.
Re: [AOLSERVER] AOLserver is only available on localhost:80
That doesn't say anything about whether you have firewall rules set up on either the client or the server. +-- On Nov 21, Sanjivendra Nath said: Its a home LAN with just a 4 port LinkSys hub. All have ip addresses dhcp served from a W2K box which is connected to the net via dialup. 2 W2K and 2 Linux boxes. All have IP addresses as 192.168.0.xxx
Re: [AOLSERVER] AOLserver is only available on localhost:80
+-- On Nov 21, Sanjivendra Nath said: Where do I start looking for a problem on my 231 linux box? Try setting up inetd or tcpserver (if you have it) on 231 to listen on port 80 and run a simple echo command. Then try telnetting to port 80 from another machine.
Re: [AOLSERVER] AOLserver 4 - Win32 not supported?
+-- On Nov 8, Jamie Rasmussen said: Is AOLserver 4 going to be unsupported on Win32? That would make me quite sad, as I just spent some time cleaning up the Visual Studio project files and was almost ready to submit them as patches. Can anyone tell me why this is happening, or if I am mistaken? This was discussed in the last weekly chat. Yes, the plan is to stop supporting Win32 in AOLserver. Reasons given, as I recall, were that it took a lot of Jim's time to implement/maintain and added significant complexity to some parts of the code, such as the threads package (especially since he's now considering supporting only pthreads, not other random proprietary threads APIs). A suggestion was floated that AOLserver could perhaps run on top of the cygwin package, which implements many Unix APIs and commands under Windows. If someone wishes to port AOLserver to run on cygwin, and it doesn't require many changes, then I suspect that Jim would accept the patches for that.
Re: [AOLSERVER] custom replacement for ns_sockopen?
+-- On Oct 29, Andrew Piskorski said: In AOLserver, the ns_sockopen Tcl commannd is implemented by NsTclSockOpenCmd which calls Ns_SockConnect (or Ns_SockAsyncConnect, etc.), which calls SockConnect. Now, all these TCP/IP socket calls return file handles, which are just integers. I have a vendor's proprietary API that works a lot SockConnect, but it's foo_connect function doesn't return a file handle, it returns a pointer to a black-box structure, and I have to pass this pointer back to a all the other foo_* API functions. So it's not really like ns_sockopen: ns_sockopen returns two Tcl channels that you can use with the standard Tcl I/O commands. It sounds like your mysterious foo package (is there some reason you can't just tell us the real package name?) doesn't do that. Anyway, if you want to restrict access to each connectionPtr to the thread that created it, then a standard way to do so would be to use Tcl_GetAssocData and related functions, with connectionId as the key. to use the connectionId as the key. If you want to access each connectionPtr from any thread, then a private Tcl_HashTable or simple array, protected by a mutex in either case, would be a good approach. Registering your own Tcl type is probably overkill.
Re: [AOLSERVER] Static vs. shared libraries?
+-- On Oct 26, Jim Wilcoxson said: ar -x blah.a Followed by ld -shared -nostartfiles -o blah.so *.o (If you're using GNU ld, anyway.)
Re: [AOLSERVER] Static vs. shared libraries?
+-- On Oct 26, Andrew Piskorski said: Rob, why did you want to use -nostartfiles ? Because AOLserver uses that on Linux. See LDSO in Makefile.global.
Re: [AOLSERVER] segmentation violation: gdb stack trace WAS RE: [AOLSERVER] Trying to debug a C module?
+-- On Oct 25, Patrick Spence said: Does it have to be compiled differently to enable the -z flag? No. every time I try to enable it on my server it prevents it from loading.. Tell us exactly what you did and exactly what the computer did.
Re: [AOLSERVER] segmentation violation: gdb stack trace WAS RE: [AOLSERVER] Trying to debug a C module?
+-- On Oct 24, Sanjivendra Nath said: Why would a malloc(10 bytes) cause a segmentation violation? Because the heap has been corrupted. Perhaps something called free twice on the same block, or wrote past the end of a block.
