Re: [AOLSERVER] hacking around
Don Baccus wrote: On Jun 6, 2011, at 12:25 PM, Andrew Piskorski wrote: In general, I don't think the ACS/OpenACS 4.x request processor design was EVER carefully thought out with respect to all of AOLserver's features and use cases. Or, in this case, didn't understand the bug that the internal redirects on various errors like 404 didn't run the filters. Of course, in AOLserver 3.0 (underwhich the rp was first written) perhaps AOLserver did ... I actually checked this before my initial post. It's been this way as far as SF CVS goes back. Which is why I'm trying to tread lightly and not break something that relies on the current behavior. I admit to being somewhat astonished by the lack of orthogonality when I figured this out in the AOLserver code. It wasn't documented, and actually, rather than being an example of the rp's design not being carefully thought out in regard to AOLserver's features, I'd say that the design exposed a bug. Could be a bug or a deliberate design decision. I recall one of the AOL devs (Jim and Dossy?) at one point say that the featureset was very much driven by internal AOL demands. Of course, that was then, this is now. AOL is no longer the driving force, or I don't think any force. And my first impression is to call this behavior a bug, because it makes one kind of request (internal redirects) act differently than a normal request, with no way to change that. Others may agree or disagree, which is that I'm trying to find out. And once that's clear, what to do about it. I think it should be fixed to treat all requests, internal and external, the same; but to be compatible this behavior should be switchable and off by default. I have a half-patch for this (it's not switchable yet) that I can clean up and commit sometime soon, if no one objects. The OpenACS rp_* Tcl code just grabs control from the AOLserver mechanisms. And this is just stupid. If the AOLserver paradigm is that people shouldn't write filters, it should not provide the facility to write filters. I got the impression (based on my reading alone, not talking to anyone about it) that the request processor was created largely to give more control (especially at the tcl level) than aolserver's native procs and filters allow. So for instance the order of execution of filters could be controlled rather than being executed in a strictly fifo by definition order. As with any implementation it was a choice; a different person might have patched the core to allow better control of filters, and another person might have felt that the existing builtins were good enough and relied more on them. No matter, it's there now and it works and no one is complaining about it. -J PS: I really wasn't trying to stir up any arguments, I just wanted to contribute something. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Problem with file uploads larger than maxinput
A thought for an alternate way to handle this - if the content-length is too large, the just don't read the content, but set an error flag on the conn. That way, an adventurous system could return a custom error page, or even handle reading the content through custom code. I think this could also allow handling of uploaded files larger than 2G as someone else was having. The default handling by returning a 413 error could be implemented as a pre-queue filter, which would still handle the error without needing a conn thread. If anyone's messing around in there, this might be a good time to also think about how to handle http/1.1's 'Expect: 100-continue', which should be most beneficial for large entity bodies anyway. -J Dossy Shiobara wrote: Yes, on E_CRANGE, the driver thread should return HTTP 413 Request too large, IMHO. And, we should be able to configure a custom response for status code 413 ... Patches welcome ;) On 6/23/11 11:28 AM, Fenton, Brian wrote: I'm using OpenACS hence the TCL. I just want to let the user know that their file is over the size limit. Could we, in driver.c instead of closing the connection socket, return a custom template (like Apache does) ? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Problem with file uploads larger than maxinput
Jim Davidson wrote: I think today, in 2011, some of the flexibility we imagined back in 1995 isn't really so needed. This includes general purpose logging plugins and network drivers when there really is just the common log format, ordinary and SSL sockets. More in the core for the base HTTP processing could make things easier to maintain. I may be the only one, but I miss some of the flexibilty that has already been removed; in particular the nsunix driver that let me run multiple servers with different credentials. There are also arguments for leaving flexibility in other things. I suspect they're the same arguments you had in 1995, but I'll offer my thoughts too. Some people do want more than common log format written to a file (distributed logging, or writing to a database). There are extensions to HTTP on the horizon (websockets and SPDY come to mind). These things don't need to be directly supported, but a framework for letting someone add in support without rewriting major parts of the server is, IMHO, a good thing. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Progress in Aolserver
Maurizio Martignano wrote: Well… ehm... the version in the tar ball compiles and runs well under Windows… Not so for the version under CVS HEAD: many of the changes introduced have been implemented with a careful eye only for *nix, and not for Windows. By looking at the code I have the feeling that the interest in supporting Windows is fading down… Speaking only for myself... Keeping the windows port current is valuable, both to support more users, and to force proper coding practices. The problem isn't so much lack of interest as lack of capability. I am a unix developer, and I don't have the time or money (looks like $500 for Visual Studio) to set up a proper windows development environment. That said, it's possible that many of the compilation problems are quite simple to address when faced with the error messages, provided the build is simple to set up. To have things in perspective… please go to the ]project-open[ web site, go to the download section and see how many people have downloaded the Windows version and how many have downloaded any of the other version… I'm curious, but I didn't see anywhere to view these numbers - do you have a direct link? I’m not a big organization, I cannot influence you, but I have to say I am very sorry and sad for this… evolution…. Being so small I don’t have the energy to look at all your changes and additions and make sure they work properly on Windows. If this trend continues I will be forced to generate a sort of fork and incorporate, add the new changes, the new additions to my code base on a case by case basis, driven by the actual needs. AFAIK AOL abandoned all support of AOLserver several years ago, so there's no big organization involved; your voice is as loud as any other. -J Any opinion? Thanks in advance, Maurizio -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
Dossy Shiobara wrote: It's probably safer to define this as SOCKET, but windows.h says SOCKET is: The source comment is misleading, because trigger is set up as a socket pair, not as a pipe. Not sure why it's this way, but there it is. And ns_sockpair is already prototyped as ns_sockpair(SOCKET *socks) so if this is a problem it really should be triggering a compiler warning about it. In any case, since unix defines SOCKET as int, it should make zero difference on the unix side to change the structure definition. -J typedef u_int SOCKET; And: typedef unsigned int u_int; Since Windows is LLP64 and most Unix-like systems are LP64, I don't understand how AOLserver's defining trigger[2] as (int) is the problem -- Windows might complain about some signed/unsigned thing at compile time, but in both cases, (int) is 32 bits. On 8/4/11 3:24 AM, Maurizio Martignano wrote: int trigger[2]; /* Wakeup trigger pipe. */ ß Why is this an int when it was a SOCKET (any justification) -- Dossy Shiobara | He realized the fastest way to change do...@panoptic.com | is to laugh at your own folly -- then you http://panoptic.com/| can let go and quickly move on. (p. 70) * WordPress * jQuery * MySQL * Security * Business Continuity * -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
Maurizio, I think we're all in agreement at this point. Could you put together a patch? -J Maurizio Martignano wrote: Don In Aolserver source code 95% of more of the times sockets are declared as SOCKET; the other times as int. This is an inconsistency and is a fact. If you wanted to develop only for Unix why did you use SOCKET in some occasions and int in some others? The source code is inconsistent and it just happens to work on Unix because there SOCKET and int have the same size. And this is also a fact. But I believe we should stop here, I admit all the faults you want, but please let's use SOCKET everywhere Cheers, Maurizio -Original Message- From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Don Baccus Sent: 04 August 2011 19:25 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Aolserver Progress - Some few examples On Aug 4, 2011, at 9:55 AM, Maurizio Martignano wrote: All of this depends on the week type system of C, were types with different names, supposed to be used for different needs are considered equivalent is their size is the same. If we had used Ada none of this would have had happened: types with different names are different no matter what their size is. If we were using Ada a file descriptor in Unix would still be described as an integer. I'm not saying that the Unix code you've uncovered is portable between Unix and Windows. I'm just pointing out that pipes are defined as an array of two integers in Unix, so that the code isn't wrong for Unix, as you originally claimed. I did so hoping it would increase your understanding, i.e. your claim that it appears to be a bug even in Unix is incorrect. If you want to make progress here, just accept that the code is perfectly good Unix code and then figure out how to make the code work for both Unix and Windows, instead of trying to argue incorrectly that the code's not correct for Unix. It's not portable, but it's correct for Unix. Thank you. Anyhow in the base code 95% of the times or even more sockets are declared as SOCKET sockets. Here and there they are declared as int. This is an inconsistency and it should be removed. I do beg the community to do this little change because it is in the benefit and interest of everybody. I'm sure that the community will accept a patch that declares the pipe in a way that makes both Unix and Windows happy if you'll provide one. Meanwhile, quit complaining because I pointed out that, in Unix, int pipefd[2] is the correct declaration for a pipe. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email tolists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] adp null end tags
Hi all, I'm implementing a minor enhancement to the adp parser to make null end tags (aka empty elements or minimized tags) work. Or more simply, if you have a registered adp tag where the end tag matches the opening tag, then rather than mytag name=value/mytag you can simply write mytag name=value / to create the tag with empty contents. What my code does is to check that the element ends with a '/', the endtag begins with a '/', and the endtag matches the beginning tag, and if all that holds, then parse it as a complete tag pair with blank contents. Two minor caveats: there must be something in between the tag and the closing /, i.e., mytag/ will not work. And to keep the attributes clean, a trailing '/' in *any* attribute string (including those without an endstring) will be dropped. (So the attribute set will no longer contain /=/) This does not make it into an xml parser, but merely allows a common xml-ish construct to work. Two questions: 1. Is the a good idea / does anyone object? 2. Have I forgotten anything? Cheers, -J PS: in case you doubted that macros in C suck, remember that #define STREQ(a,b) (((*a) == (*b)) (strcmp((a),(b)) == 0)) is NOT the same as #define STREQ(a,b) ((*(a) == *(b)) (strcmp((a),(b)) == 0)) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Fwd: AOLserver 4.5.0 - ns_returnfile does not find file - file name contains special chars
Another thing you could do is to set tcl's default encoding to utf-8, so that the filenames passed to Ns_ConnReturnFile are the same encoding as what the core tcl commands do. Set the default encoding with encoding system utf-8 in some tcl file. It's possible this could have some side effects. I'm trying to figure out what needs to be patched in the server for this to do the right thing, but encoding is a messy business. -J Jim Davidson wrote: Howdy, Looking at the code, ns_returnfile passes the filename through to the core Ns_ConnReturnFile without any of the care that core Tcl does handling filenames. You may be able to replace ns_returnfile with ns_returnfp, passing a file handle returned from Tcl's open command which should be smarter with filesystem encoding. The downside is that would bypass some of the smarts within the underlying Ns_ConnReturnFile used by ns_returnfile: It appears to set Last-Modified headers, optionally cache small files, mmap large files, etc. All this may not matter if you're doing one-shot type work, e.g., returning a custom crafted file for just one user, just once. -Jim On Sep 22, 2011, at 3:27 PM, Peter Sadlon wrote: Just a guess here, but by default, TCL is compiled with Latin-1 encoding. This causes some issues when you are trying to do certain things in utf-8, even if you set all possible TCL config variables to use the UTF-8 charset. You could attempt to recompile TCL with --with-encoding utf-8 But in the end, your final comment is correct, it is best to encode the filename, then you don't have to worry about a bunch of special cases. Date: Thu, 22 Sep 2011 22:59:02 +0200 From: klaus.hofed...@project-open.com mailto:klaus.hofed...@project-open.com Subject: [AOLSERVER] Fwd: AOLserver 4.5.0 - ns_returnfile does not find file - file name contains special chars To: AOLSERVER@LISTSERV.AOL.COM mailto:AOLSERVER@LISTSERV.AOL.COM Hi all at ]project-open[ we currently use AOLserver 4.5.0 with OpenACS 5.6.0 on CentOS release 5.3 (Final) We suddenly encountered the problem that ns_returnfile can't find a file which filname contains special chars such as 'umlaute' (ä, ö, etc.) --- convmv tells me that the file name is utf-8 encoded. --- Config.tcl has the standard settings: ns_param HackContentType1 ns_param DefaultCharset utf-8 ns_param HttpOpenCharsetutf-8 ns_param OutputCharset utf-8 ns_param URLCharset utf-8 --- Following CentOS locale: LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= --- File System is 'ext3' --- Files have been created with exec /bin/cp $filename $dest_path out of a tcl file or using 'touch/emacs' on OS level. Same results. --- We did have the problems using AOLserver 3.3 Anybody an idea what the cause might be? Probably its better to always encode file names of uploaded filesto avoid trouble when creating multi-plattform applications. Thanks for your support! Klaus -- AOLserver -http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com mailto:lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com mailto:lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Fwd: AOLserver 4.5.0 - ns_returnfile does not find file - file name contains special chars
Klaus Hofeditz ]project-open[ wrote: I gave it a try since some of our users do upload files using tools such as WINSCP. Since these files would also need to be accessible through the ]project-open[ file manager, we need to come up with a slightly more complex solution to detect files with special chars. I have a patch (not checked in yet) that will let ns_returnfile use the same files as native tcl commands (by doing the same utf-8 to external decoding that tcl does internally). It would make sense to apply this to all file-handling commands. But it would make more sense to replace these where possible (and simple) with tcl versions that map to the builtin tcl commands?. I think the docs even say that many of these date back to the time when tcl did not include these functions. Would anyone have any objection to replacing these c-coded commands with tcl ones? The commands that could be easily replaced are ns_chmod, ns_cp, ns_rename, ns_link, ns_mkdir, ns_rename, ns_rmdir, ns_symlink, ns_unlink, and ns_ftruncate. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Unable to install nssolid database driver on aolserver4.5.0
Thorpe Mayes wrote: Hi, I am trying to install the solid database drivers and cannot do it. I am running aolserver 4.5.0. I added the nssolid_3.0 driver. I then added solid-fix.tar, which updated the Makefile file and added the nssolid.h file to the nssolid directory. Where is solid-fix.tar from? I didn't see it in the SF repository. Anyway, these errors are typical of a missing header file. It may be that no one has tried to build nssolid in a very long time and the headers have changed; in particular the reference to ‘Ns_DbRegisterDriver’ suggests that nsdb.h was not included (I think nsdb used to be part of the core, but it is now a separate module). Try adding '#include nsdb.h' to nssolid.c after '#include ns.h' and see if that gets you fewer errors. -J When I run make I get this result: make gcc -pipe -I/usr/local/solid/solidSDKe352/Linux_glibc2/include -DSOLVER=350 -O2 -Wall -Wno-implicit-int -fno-strict-aliasing -fPIC -I/usr/local/aolserver/include -I/usr/local/include -DNO_CONST -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_ATFORK=1 -DTCL_THREADS=1 -DPEEK_XCLOSEIM=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1 -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -D P! ACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_TIMEGM=1 -DHAVE_DRAND48=1 -DHAVE_RANDOM=1 -DHAVE_POLL=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETNAMEINFO=1-c -o nssolid.o nssolid.c nssolid.c:89: error: expected ‘)’ before ‘*’ token nssolid.c:90: error: expected ‘)’ before ‘*’ token nssolid.c:91: error: expected ‘)’ before ‘*’ token nssolid.c:92: error: expected ‘)’ before ‘*’ token nssolid.c:93: error: expected ‘)’ before ‘*’ token nssolid.c:94: error: expected ‘)’ before ‘*’ token nssolid.c:95: error: expected ‘)’ before ‘*’ token nssolid.c:96: error: expected ‘)’ before ‘*’ token nssolid.c:97: error: expected ‘)’ before ‘*’ token nssolid.c:101: error: expected declaration specifiers or ‘...’ before ‘Ns_DbHandle’ nssolid.c:105: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘odbcProcs’ nssolid.c: In function ‘Ns_DbDriverInit’: nssolid.c:133: warning: implicit declaration of function ‘Ns_DbRegisterDriver’ nssolid.c:133: error: ‘odbcProcs’ undeclared (first use in this function) nssolid.c:133: error: (Each undeclared identifier is reported only once nssolid.c:133: error: for each function it appears in.) nssolid.c: In function ‘Ns_ODBCShutdown’: nssolid.c:154: warning: passing argument 2 of ‘ODBCLog’ makes integer from pointer without a cast nssolid.c:154: error: too many arguments to function ‘ODBCLog’ nssolid.c: At top level: nssolid.c:182: error: expected ‘)’ before ‘*’ token nssolid.c:227: error: expected ‘)’ before ‘*’ token nssolid.c:244: error: expected ‘)’ before ‘*’ token nssolid.c:291: error: expected ‘)’ before ‘*’ token nssolid.c:352: error: expected ‘)’ before ‘*’ token nssolid.c:411: error: expected ‘)’ before ‘*’ token nssolid.c:417: error: expected ‘)’ before ‘*’ token nssolid.c:443: error: expected ‘)’ before ‘*’ token nssolid.c:499: error: expected ‘)’ before ‘*’ token nssolid.c: In function ‘ODBCCmd’: nssolid.c:552: error: ‘Ns_DbHandle’ undeclared (first use in this function) nssolid.c:552: error: ‘handle’ undeclared (first use in this function) nssolid.c:562: warning: implicit declaration of function ‘Ns_TclDbGetHandle’ nssolid.c:566: warning: implicit declaration of function ‘Ns_DbDriverName’ nssolid.c:566: warning: comparison between pointer and integer nssolid.c:573: error: too many arguments to function ‘ODBCLog’ nssolid.c:583: error: too many arguments to function ‘ODBCLog’ nssolid.c: At top level: nssolid.c:617: error: expected declaration specifiers or ‘...’ before ‘Ns_DbHandle’ nssolid.c: In function ‘ODBCLog’: nssolid.c:633: warning: pointer targets in passing argument 4 of ‘SQLError’ differ in signedness nssolid.c:633: warning: pointer targets in passing argument 6 of ‘SQLError’ differ in signedness nssolid.c:638: error: ‘handle’ undeclared (first use in this function) make: *** [nssolid.o] Error 1 Thanks, Thorpe Thorpe Mayes 405.514.9753 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email
[AOLSERVER] recent updates
Hey all, me again. For those of you who don't monitor the commits list I wanted to share a few changes I've recently made as well as a few I'm still thinking about. - implemented native decoding of strings in ns_returnfile. This allows filenames that are not utf-8 to be passed, similar to tcl core functions. - committed a long-outstanding patch to address a fastpath caching bug where incorrect file content could be delivered in a system when inodes are rapidly being reused. Added a new config option cacheminage to control this behavior. - implemented a suggestion to re-run pre-auth and post-auth filters on internal redirects. As this could break assumptions in unusual situations, there is a config option filterredirect to disable it. Among other things, this addresses an issue in openacs that made it complicated to handle 404 errors. Also fixed a server crash when there is an error in the configured error page. - added flags to insert a filter at the beginning of the list of registered filters instead of only at the end, and to order filters by priority. - exposed the gzip flag to tcl scripts (ns_conn gzip) - added another new filter, pre-write which runs after content has been returned but before it has been sent over the network. To make this useful, there is a new method to ns_conn to examine and set the response content that is about to be sent. This could be useful for implementing something like apache's mod_pagespeed, which rewrites content to do things like merge javascript and css files to reduce external requests, or just strip extraneous whitespace from a page. - added a tuning knob maxaccept to let the driver accept more than one connection per spin. The SF RFE for this referenced a paper that found this type of change could improve performance and reduce dropped connections under load; I unfortunately don't have a network capable of simulating enough load to stress this so I cannot claim any measured improvement. I also have a few other ideas I haven't gotten around to adding (or even necessarily thinking through completely) yet: - removing encoding and gzip compression from the normal response writing codepath (Ns_ConnFlush) and making them into pre-write filters. - adding an api to name C-coded filters and handler procs such that they could be used by the tcl ns_register_filter/ns_register_proc commands. This could eliminate a few special-purpose commands that do this same thing for particular operations (ns_register_fastpath and ns_register_filter_shortcut). - add support for chunked encoding for requests, digest authentication, and Expect: 100-continue. I've heard that these are already supported in NaviServer, so this may be a fairly simple cutpaste enhancement. - replace c-coded versions of many file operations with equivalent tcl-coded versions. Many of these functions (e.g., ns_mkdir, ns_cp) come from before tcl had equivalent functionality, but tcl now has that functionality, and it's better (native decoding). - replace ns_share with tcl version built around nsv, if not eliminating it entirely. - remove other really old code like tclx keylist support. I honestly don't know if this is still being used, perhaps it could be kept around in a nscompat module along with other things like ns_var and ns_share). I'm a bit reluctant to break compatibility without an easy switch to un-break it. - make content sending event based, by pushing it back to the driver thread, a task thread, or a completely new writer thread, rather than blocking a conn thread if the content is big and the network is slow. There is support for doing this at the tcl level, but it would be nice to have it implicitly happen everywhere. - let queue-waits be set up from a conn thread and the conn re-queued in the driver thread. This would let you do database operations before making network calls and still wait for those calls to complete without tying up conn threads. This would mean a rather esoteric coding style but I think it would make for a really powerful mashup engine. Some of these are pretty disruptive (especially the last two), and introducing incompatibilities (even ones with an easy off switch) is not something to be taken lightly; does anyone else think a new 4.5.2 release with the recent bugfixes and non-disruptive new features could be done, and then slightly disruptive stuff (i.e., moving c-coded commands to tcl) could be targeted at 4.6? Naturally, I'm also interested in any feedback on anything I've done or suggested also. Cheers, -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Fwd: AOL Listserv to be Discontinued
Sourceforge seems a reasonable choice to me. -J Dossy Shiobara wrote: Everyone, It appears that AOL is going to be shutting own its LISTSERV, which includes several AOLserver mailing lists. Since there's still activity on this mailing list, I think it would be worth moving to a new list. SourceForge offers GNU Mailman lists as part of its project hosting offering. Does anyone have a strong preference as to where to relocate the lists? Any good reasons why they shouldn't move to SourceForge? I'd like to try and wrap up discussion around this by Wednesday, October 26th, to give us time to actually perform the relocation of the list, if possible. Thanks, Dossy Shiobara Original Message Subject:AOL Listserv to be Discontinued Date: Tue, 18 Oct 2011 00:59:58 + From: AOL Listserv Serviceaol.listserv.serv...@teamaol.com To: AOL Listserv Serviceaol.listserv.serv...@teamaol.com Dear AOL Listserv Administrator, You are receiving this email because you have been listed as the administration for one or more lists hosted by AOL’s listserv service. We would like to inform you that AOL will be discontinuing the listserv service on November 1^st , 2011. If your list is still actively used, please make arrangements to find another service prior to the shutdown date and notify your list members of the transition details. If you are no longer actively using this service then no other action is required. If you have any questions, please contact aol.listserv.serv...@teamaol.com. Thank you. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] recent updates
Fenton, Brian wrote: Hi Jeff congrats on all the great work. That all sounds super. A new AOLserver release would be amazing, but maybe seeing as 4.0 was first released 8 years ago, we could consider that it's about time for a move to 5.0? Not wanting to get too Firefox-y about it, but I think it would be good for the project. I think that any new release would be benificial; but I'm a bit old-school about version numbers. The hairs on the back of my neck stand up every time I get the monthly popup message for a new major version of FireFox. Major versions = can break functionality in a non-backwards compatible way Minor versions = can have fairly sizable changes and new features, but things can generally be expected to keep working Point versions = small new features, bugfixes, no incompatible changes I realize at least one of my changes can violate that, I'm hoping it's enough of an edge case to slide. IMO, a 5.0 release is a chance to incorporate major changes, such as to the way that interps are iinitialized (there's some ideas from Jim on this somwhere). The stuff I've done so far I think is still in the point release realm. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] recent updates
Brett Schwarz wrote: I'll grab the latest and greatest from SF and start messing around with your changes. Is SF the main repo for aolserver? What about the modules (specifically nspostgres)? Yep, SF is still the place for aolserver and nspostgres (which looks like it has been updated to work with 9.x). RE: TclX...can't that be loaded as an extension, so that those who still need it can load it? Good question .. from what I can gather from old threads the main users of this was internal AOL users who are probably all gone now, or at least not upgrading any longer. So this might be a pretty unimportant thing to maintain compatibility on from several angles. -J Thanks for your effort. --brett -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Discussing AOLserver at the Tcl/Tk conference
I think from the tcl perspective the interp management is interesting. Interps are initialized with a startup script (created through introspection) and reused by multiple requests without reinitializing (cleaned up after each request, again using introspection). -J Matthew M. Burke wrote: Later this week, the 18th Tcl/Tk conference will be held and one of the sessions is a panel discussing the different ways to use Tcl to do web development. I have been asked to discuss AOLserver and as I finish up my notes, I thought I should check with the folks on this list to see if there's anything that you'd recommend I mention. If I was more organized, I'd post my notes for folks to peruse in advance. But, alas, I'm not... I will get them posted as soon as I can. Just to give you a rough idea of my perspective: I started using AOLserver at Ars Digita in the late 90s. Since then I've used it (in conjunction with .LRN) while on the faculty at St. Mary's College to support my classes, and have off-and-on used it to run a few, very low-traffic, personal sites. Thanks for your advice/suggestions, Matt -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] recent updates
Daniël Mantione wrote: Maybe I could point again at the ipv6 patch I wrote in 2008. Back there was even not even a response on this list, but maybe today, now the world has run out of ipv4 addresses, the interrest in serving ipv6 is a bit higher. Patch still available for download here: http://www.freepascal.org/~daniel/aolserver-ipv6support.diff Best regards, Daniël Mantione I'll take a swing at getting this integrated sometime soon (available time waxes and wanes, as I'm sure it does for all of us). This patch is a bigger piece of functionality that the others I put in; I think 4.6 is the right target for this. I think now is the right time to mark a 4.5.2 cvs branch; I'll try to remember how to do that and tag it. Sorry if I missed this (now as then); I was mostly going off the SF RFEs looking for stuff to add. Actually, that's another thing I'd like to see happen tho I can't do it - clean up the bug reports and RFEs. There's a bunch of stuff sitting around from 2004 or earlier that's no longer relevant and much as I dislike closing bugs as old version I think that's what's needed for many of them. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
I had problems starting at the exact same time but on Solaris, where they manifested as a EINVAL return from pthread_cond_tomedwait. After a day of tracing the problem with debug builds and working with my sysadmin to track what changed (of course, nothing had) I cam to the same 1 billion second issue. Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on my database connections. My system is ACS-derived, so I wouldn't be surprised if these database settings are common in other ACS-derived systems. The only bug is that Ns_CondTimedWait doesn't do any wraparound on the time parameter. All the same, I've been enjoying telling people that I hit my first y2038 bug. -J Bas Scheffers wrote: On 17 May 2006, at 21:34, Dossy Shiobara wrote: Dave Siktberg seems to have narrowed it down to 2006-05-12 21:25. In what timezone? It sound like that could equate to Sat May 13 02:27:28 BST 2006, or 1147483648 seconds since epoch, which makes it *exactly* 1,000,000,000 seconds until expiry of 32 bit time. Coincidence? Seems too strange as to a computer that is not a nice round number. I wonder what Dan Brown would have to say about it! :) Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Weird memory leak problem in AOLserver 3.4.2/3.x
dhogaza@PACIFIER.COM wrote: I have three servers running identical installations of AOLserver/3.3.1+ad13. On two (development and production, very low and relatively low traffic volumes respectively) all scheduled procs have stopped firing. My God, it sounds to me like you're all being bit by the Y2.006K problem! :) That answer is closer than you think (at least if everyone is having the same problem I was) ... actually it's Y2.038K -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
I fixed it by simply changing my MaxOpen/MaxIdle settings to 0 which is interpreted as forever which is probably what the original one BILLION seconds was undoubtedly intended to be. It probably wouldn't hurt for Ns_AdjTime (in nsthread/time.c) to check for negative seconds and have it fail in a nicer manner, but that problem won't affect anyone for years :) -J Janine Sisk wrote: On May 19, 2006, at 1:04 PM, 'Jesus' Jeff Rogers wrote: The only bug is that Ns_CondTimedWait doesn't do any wraparound on the time parameter. All the same, I've been enjoying telling people that I hit my first y2038 bug. So are you saying you've fixed it, or just that you've narrowed it down to this? If you've fixed it, do tell! :) janine -- 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] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
Stan Kaufman wrote: Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on my database connections. My system is ACS-derived, so I wouldn't be surprised if these database settings are common in other ACS-derived systems. What do you think is the reason that not all systems encounter this 1B second issue? The passage of time is the one factor inevitably shared by every system running aolserver, yet not every system barfs in the same fashion. Why? Simple, because it's a config file setting, not anything to do with the underlying system. If your config file has [ns/db/pool/main] MaxOpen=10 MaxIdle=10 (which I think was done to work around some ancient bug in an ancient version of the nsoracle driver) then you get the problem. If your timeouts are more reasonable or 0 to explicitly specify never timeout, then no problem. It took me longer than it should have to track down this problem, since it was happenning immediately after the database connections were started, and other servers with no database connections (like the keepalive server) had no problems; we of course thought there was some database issue but didn't think about looking at the settings or that the unix daemon dogging your heels for removing that comment would stop so soon (obscure humor there...) I imagine on Linux it manifests differently; on Solaris I got the EINVAL return from pthread_cond_timedwait (of course it isn't documented that this can mean a bad time, it usually means a bad pointer) but on linux with a different pthreads implementation it could result in locking up or just never returning (which presumably would result in all timed events after it in the queue which us sorted by time getting blocked and not running, as others reported. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Tcl interpreter bloating
John Buckman wrote: Right restarting is not something I like to doing, because most of the time when I ctrl-c aolserver, it exists uncleanly with one of these errors: Would it work any better/more reliably to have aolserver exit itself, by calling ns_shutdown and hopefully allowing any registered shutdown handlers to run and current requests to complete? Maybe even run the server under inittab or daemontools and set up a scheduled job that checks how much memory it is using and shutting down if it is over some threshold, so the server becomes a little more self-managing. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] aolserver focus
Daniël Mantione wrote: Ok, practical example: We have a server, two users want to run OpenACS, and 20 users simply wants to code PHP/MySQL. Proposal to the system administrator: Put pound on Port 80 and have requests for the two OpenACS users redirected to their own AOLserver process. Now, everyone on the server will see all requests coming from localhost. Big chance is the PHP/MySQL users won't like that and put the argument just use what everyone else uses in place against the OpenACS users. Lots of proxies support adding in additional http headers to indicate that it is a proxied request. In certain environments (firewalled corporate paranoia) you can't avoid everything being proxied and must deal with this. And more to the point, there are simple ways (about 4 lines of code in a PerlFixupHandler) to recover the proxied connection address from such an added-in header if people are really upset about it. Or as an alternate answer: use apache itself as the proxy. The poor saps who subject themselves to PHP will be happy and the OACS users can have a real system to work with. Obnoxious alternate answer 2: tell the php users, sorry, there's people doing real work on this system. :) Bottom line is, there's no reason why they can't coexist peacefully. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
Don Baccus wrote: On Apr 12, 2008, at 8:46 AM, Brett Schwarz wrote: For *my* application, I would have the config params do the decision almost all of the time. However, I concede that other people's use cases may be different...so I think a hook into the compression decision making from application code is a good idea. I believe what I proposed covers the bases...although the details would need to be worked out... I agree with this, too. Tying in with a different thread, my suggestion for an improvement would be to ship AOLserver should with (or alongside) a standard/sample library that is intended to be looked at and tweaked (the standard library that ships currently is boilerplate). This standard library could include a filter proc to call 'ns_conn gzip 1' (or however it is exposed at the tcl level) based on the config file setting. Another thing to include in this standard library could be compatibility code for the old thread configuration directives mapping them onto the new 4.5 thread configuration commands. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
