> I dunno, but I hope one programming error doesn't mean every pointer
> dereference should be checked so a nicely formatted error can be
> displayed before crashing.
That's not necessarily the action that would be taken, though. There
are cases where a NULL pointer might be acceptable (this is
> I couldn't find it on Google, both sites that had it are gone.
> I moved a copy of it to
> http://zmbh.com/rlreturnz/
>
> Maybe this should get cleaned up and moved into SourceForge?
A client of mine is using rlreturnz with AOLserver 3.4.2. We picked
up the source in May of 2002 from www.theash
> John Caruso wrote
> >A client of mine is using rlreturnz with AOLserver 3.4.2. We picked
> >up the source in May of 2002 from www.theashergroup.com, and it has the
> >following difference from yours:
> >
> That is interesting, because the version I am looking at (
At Wednesday 03:14 PM 3/12/2003 -0500, you wrote:
Beta release 3 of AOLserver 4.0 is now available with CVS tag
aolserver_v4_r0_beta_3. It is also available via the Source Forge
download
page: https://sourceforge.net/project/showfiles.php?group_id=3152&release_id=145927";>https://sourceforge.net/p
At Thursday 06:57 AM 9/18/2003 -0600, you wrote:
Digging deeper (thanks Andrew P) the instability seems to stem from the
OpenSSL patch for RSA blinding.
I posted about a similar (and almost certainly related) issue to yours a
few months back:
http://listserv.aol.com/cgi-bin/wa?A2=ind0304&L=aolserve
[ Responding in lieu of Eric, who's out of town ]
At Thursday 10:57 AM 10/23/2003, you wrote:
Have you patched the oracle driver? Did it solve your problem?
We didn't end up having to patch the driver. Instead, at Oracle's
suggestion, we updated the Oracle client software from 9.2.0.1 to 9.2.0.3,
Since there's been discussion of the installation chapter of the admin
guide (which looks great, BTW), I thought it would be good to bring up the
issue of packaging AOLserver 4. To deploy AOLserver at Arena, we maintain
an RPM that we use to package together AOLserver and all the modules we
use wi
At Wednesday 07:23 AM 7/21/2004, you wrote:
On 2004.07.21, Rob Crittenden <[EMAIL PROTECTED]> wrote:
> Many relatively old (but not ancient) Linux distributions ship with
> autoconf 2.13 such as RedHat 7.2, 7,3 and AS 2.1. Upgrading isn't
> particularly painful but many only like using "official" r
At Wednesday 11:40 AM 7/21/2004, you wrote:
On 2004.07.21, John Caruso <[EMAIL PROTECTED]> wrote:
> >http://www.redhat.com/swr/noarch/autoconf-2.57-3.noarch.html
>
> That's a RedHat 9 RPM, not an Advanced Server 2.1 RPM.
Excuse my RedHat ignorance, but could you explain
At Monday 01:08 PM 10/25/2004, Steve wrote:
[-conn17-] Error: nsopenssl: EOF during SSL handshake
[-conn0-] Error: nsopenssl: nsdserver: connection closed by
peer
[-conn15-] Error: nsopenssl: error during SSL handshake: Connection
reset by peer
Steve,
There's a bug in NsOpenSSLSend() in nsop
At Tuesday 09:59 AM 10/26/2004, John Caruso wrote:
At Monday 01:08 PM 10/25/2004,
Steve wrote:
[-conn17-] Error: nsopenssl: EOF during SSL handshake
[-conn0-] Error: nsopenssl: nsdserver: connection closed by peer
[-conn15-] Error: nsopenssl: error during SSL handshake: Connection
reset by peer
At Tuesday 01:54 PM 10/26/2004, Steve wrote:
Thats a bit worrying as I was
under the impression that 2.1a was solid. I don't believe that I have any
large posts but could you define what your calling a large post for
me.
As I recall, larger than 8K--in our environment. It may vary in
yours. But
At Tuesday 02:58 PM 10/26/2004, Steve wrote:
I will apply it and remake the module to see if it helps. Thanks. Off
hand can you remember what symptoms you saw with your 2.1a problems? Did
the server restart? Did you get browser errors? Did it log errors? I'm
just trying to see if your problem corre
We have a standard build procedure that produces an RPM for AOLserver
3.4.2, which we're using in production. This RPM were built on a Redhat
Advanced Server 2.1 server (32-bit). When we take the 32-bit RPM and
install it on a 64-bit Redhat Enterprise Linux 4 server, it works
perfectly.
But
At Thursday 01:05 PM 7/7/2005, Dossy Shiobara wrote:
I wish I could answer this -- I've only tested AOLserver 4.0.x on 64-bit
SPARC, and yes, it does work there.
Thanks for the info. My more specific question was about sendmsg() in
binder.c, though. In looking at the compilation output, I se
What's the status of the very useful rlreturnz module? We're looking at
updating from AOLserver 3.4.2 to AOLserver 4, but it appears that this
module has been orphaned, and that the version we have doesn't work with
AOLserver 4.
If it really has been orphaned, is there some equivalent (module
At Tuesday 08:21 PM 7/26/2005, Dossy Shiobara wrote:
If this is a feature requirement that is holding you back from moving to
AOLserver 4.x, lets talk. I'm sure we can work to accomodate you in some
reasonable way.
There are other Arena folks on the list who are more qualified to answer
just
At Wednesday 02:55 PM 8/24/2005, Jim Davidson wrote:
- On all other Unix, I could
purge all the -rpath stuff from the
build so folks are required to do the right thing with
LD_LIBRARY_PATH, ld.config, whatever on their
system.
I'd cast a very strong NO vote for this. Forcing people to always
At Wednesday 07:16 PM 8/24/2005, Andrew Piskorski
wrote:
John Caruso wrote:
> Basically, AOLserver 4 is hostile to being built (or having its
> modules built) in anything other than its final installation
> directory.
Frankly, I'm not sure what you're talking about.
I explai
At Thursday 05:23 AM 8/25/2005, Dossy Shiobara wrote:
On 2005.08.24, John Caruso
<[EMAIL PROTECTED]> wrote:
> But AOLserver 4 doesn't let you do this, and in fact makes it very
> difficult to achieve at all (much more so that it was under
AOLserver
> 3.4.2, as I showed i
At Thursday 06:16 AM 8/25/2005, Jim Davidson wrote:
3. install/copy step needs to
bypass the final install location and
copy to some other root
I'd say "should be able to" instead of "needs to",
but yep, this would be very helpful.
8. finally,
something should be done to rationalize the build o
One other thing:
At Thursday 06:16 AM 8/25/2005, Jim Davidson wrote:
There was a lot of effort recently to use Tcl in the build to get
around windows/unix incompatibilities -- sounds like more work is
needed on the Unix specific pieces to get this right and draw in the
common modules.
Is this
At Friday 10:25 AM 8/26/2005, Tom Jackson wrote:
AOLserver is not in any way similar to Apache, BIND or OpenSSL, other
than
being software.
That's the only similarity I was specifically calling out. Well-designed,
widely-available open source software has converged on a standard way of
hand
At Friday 04:48 PM 8/26/2005, Tom Jackson wrote:
What is Arena? How does Arena
use AOLserver?
www.arenasolutions.com (as per my email address)
Arena uses AOLserver to deliver all of its web services.
- John
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply s
In testing AOLserver 4.0.10, we seem to have discovered that the -b
command-line parameter is now required to bind to privileged ports (e.g.
80 or 443). With AOLserver 3.4.2, you could simply specify the port
numbers in the config file and AOLserver would do the Right Thing.
So two questions:
At Friday 02:16 PM 10/7/2005, John Caruso wrote:
1) Is it true that AOLserver
4.0.10 requires -b in this circumstance, or are we just missing
something?
Ok, found this in the ChangeLog:
* Removed the child-process privleged port
Ns_SockListen
code in nsd/binder.c. Binding privleged
At Friday 04:17 PM 10/7/2005, Daniel P. Stasinski
wrote:
On Fri, 2005-10-07 at 14:16
-0700, John Caruso wrote:
> In testing AOLserver 4.0.10, we seem to have discovered that the -b
> command-line parameter is now required to bind to privileged ports
(e.g.
> 80 or 443).
The problem
At Friday 06:37 AM 1/13/2006, Dossy Shiobara wrote:
Yes, the order in which tags are parsed was changed between 3.x and
4.0.x, unfortunately. Jeremy Collins filed an RFE to change it back in
September 2004, but it hasn't been done yet:
There was further discussion of this issue on the AOLSERVE
On Tuesday 10:30 AM 10/23/2007, Dossy Shiobara wrote:
As part of the nsopenssl module, there are (IMHO, broken)
implementations of ns_httpsopen and friends.
Could you expand on what you think is broken about them?
- John
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this
On Wednesday 09:58 AM 1/9/2008, Juan José del Río [Simple
wrote:
I tried on FreeBSD, but it
didn't compile. It kept complaining about
functions that have changed name / parameters or giving linking
problems
with Tcl memory management functions, i think, but I don't recall
exactly...
The problem i
On Thursday 06:05 AM 1/10/2008, Nick Miller wrote:
I have been having some issues getting AOLServer
4.5 or 4.0.10 to run on Mac OS X 10.5
I compiled and installed AOL Server and Tcl on Mac OS X 10.5 with noÂ
issues but then tried to run the NSDs only to get a "SegmentationÂ
Fault".
The short a
On Thursday 09:42 AM 1/10/2008, John Caruso wrote:
On Thursday 06:05 AM 1/10/2008, Nick Miller wrote:
I have been having some issues getting
AOLServer 4.5 or 4.0.10 to run on Mac OS X 10.5
I compiled and installed AOL Server and Tcl on Mac OS X 10.5 with noÂ
issues but then tried to run the
Consider the following pseudocode snippet:
<<...generate file $myfile in some way...>>
ns_returnfile 200 text/plain $myfile
ns_unlink $myfile
If this snippet is executed in a tight loop on a Linux system, the chances
of returning the wrong results are very high due to AOLserver's fa
On Monday 01:33 PM 8/18/2008, Tom Jackson wrote:
It's not be a data corruption issue
because you are choosing to overwrite the old data with new data using
the exact same file name. If the data is important, don't overwrite it,
thus no corruption.
No, you've misunderstood the scenario. The fil
On Monday 03:38 PM 8/18/2008, Jeff Rogers wrote:
While I'd agree this is a bug in fastpath, the real problem is that
fastpath is being used at all in this case. The intent of fastpath is to
avoid reading a seldom-changed file from disk.
I'd agree that that's the intent, but the caching is hid
On Monday 04:56 PM 8/18/2008, Jade Rubick wrote:
Consider this use case:
* You use git or another version control system to store for a bunch
of static html files you serve with Aolserver.
* You check out all of your static html files. Because they're all
checked out at the same time, man
On Monday 05:13 PM 8/18/2008, Jeff Rogers wrote:
Simply put, fastpath caching is inherently broken because it's not
possible to guarantee that the file in question really should be served
from cache (again, short of a cache-defeating checksum).
The same can be said about nearly any caching sys
On Monday 06:21 PM 8/18/2008, russell muetzelfeldt wrote:
On 19/08/2008, at 11:06 AM, John Caruso wrote:
That'd be an improvement over the current situation, but it's still
the case that AOLserver as currently shipped has a file cache
mechanism built into it which 1) may return inco
On Tuesday 10:40 AM 8/19/2008, Jim Davidson wrote:
I would suggest
the code snippet of create temp file and use fastpath to return
contents is not a use case I was solving for or recommend.
It's also not the use case in question--just a simple illustration of the
problem. Here's a more realis
On Monday 05:53 PM 8/18/2008, Jeff Rogers wrote:
russell muetzelfeldt wrote:
fastpath is making assumptions about what means something is the "same
file", and those assumptions are not consistent with unix filesystem
semantics - how is this not a bug?
It's not a bug because no one ever said t
On Tuesday 02:10 PM 8/19/2008, Jeff Rogers wrote:
A default configuration change was suggested which seems generally viewed
as undesirable.
My impression was that support was split about evenly, actually. I take
it that means you're against changing the default? I'm a bit surprised,
since y
On Tuesday 04:57 PM 8/19/2008, Rusty Brooks wrote:
> Personally I can't
imagine any persuasive argument that a caching mechanism that can easily
confuse /usr/local/private/var/rootpass and
/var/tmp/verisign/certs/webcert.txt should be enabled by default in a
web server.
Oh, come on. Only i
On Tuesday 05:39 PM 8/19/2008, Jim Davidson wrote:
Your right, the code snippet below could trip
over a race condition as you've described.
It's not a race condition, actually; the code in
that example was serialized, so there's no race involved.
...fastpath isn't broken.
It's designed in
On Wednesday 08:45 AM 8/20/2008, Jim Davidson wrote:
Overall, it seems one thing to do would be to switch to filename-based
cache keys by default, leaving the dev/inode pair as an option for
folks who run sites with large symlinks and want to benefit from
caching objects just once. I think that
day 10:56 AM 8/20/2008, Jeff Rogers wrote:
John Caruso wrote:
BTW, Jeff, the scenario you'd outlined that you thought would trip this
up...:
13:50:21 - create file
13:50:21 - serve file (gets cached)
13:50:21 - delete file
13:50:21 - create file again (reuses inode)
...
By the way, Jeff, regarding this...:
On Wednesday 10:56 AM 8/20/2008, Jeff Rogers wrote:
And it still hurts the optimization of using a 404 adp page to generate a
heavyweight file only once that gets cached.
...which you'd explained elsewhere as...:
There is also at least one clever optimizat
On Wednesday 12:30 PM 8/20/2008, Jeff Rogers wrote:
I can very easily come up with a scenario that breaks your patched
fastpath just as easily as the original, to which you can rightly say,
"but why would you do it that way?". And you would be right.
Do it, then. This is the simplest example
On Wednesday 01:45 PM 8/20/2008, Juan José del Río wrote:
But, since Linux version 2.6.13, inotify is into the kernel, and
aolserver can subscribe to a path, so know if that file has been
deleted, modified, or anything else. That's the way a cache can know if
the file has been altered in any way,
On Thursday 08:14 AM 8/21/2008, Dossy Shiobara wrote:
4) I see the simplest (best?) solution here being a configurable
parameter that controls fastpath's cache key generation. As Jim points
out, one can quickly test whether this would solve the problem at hand by
temporarily #define'ing _WIN32
On Thursday 09:25 AM 8/21/2008, Tom Jackson wrote:
Why put newly created
files into a cache, if the point of the cache is to handle static files?
We can wait for evidence that it is static. In this case, we can wait
until it is a few seconds old, at least.
This is a very good point, actually.
On Thursday 12:08 PM 8/21/2008, Titi Alailima wrote:
It's perfectly acceptable in dealing with caching systems that the cached
value could be out of sync, but not that the cached value could be for
something entirely different from what you were looking for.
Yep. I think that aspect of the is
On Thursday 02:34 PM 8/21/2008, Jim Davidson wrote:
To clarify one point: There is no technical solution to creating temp
files with the same name and avoiding the race condition without
additional synchronization.
To clarify as well: the original code didn't involve a race condition--it
was
We've run into a bug with AOLserver 4.5.1 / nsopenssl 3.0beta26. The bug is
fully documented here:
https://sourceforge.net/tracker/?func=detail&aid=2822117&group_id=3152&atid=103152
But the short version is that when using the nsopenssl client-side routines
(e.g. ns_httpsget), the result m
On Wednesday 03:17 PM 7/15/2009, Scott Goodwin wrote:
Tell me what version of OpenSSL you're running.
OpenSSL 0.9.8k. It's been happening for many years with different OpenSSL
versions as well.
- John
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send
On Wednesday 04:26 PM 7/15/2009, Tom Jackson wrote:
Your SF bug report says that you put in a 300 millisecond delay.
Where? Even if you think that such a fix is not good, it would be
helpful to at least know what works.
There's a massive amount of debugging I've done on this that's not
include
On Tuesday 09:01 PM 7/21/2009, Mark Aufflick wrote:
You say that "This bug ONLY occurs with an AOLserver client (any
version) running against an AOLserver 4 / nsopenssl 3.0beta26 server"
- so you're saying this issue doesn't occur when using httpsget
against, say, Apache?
Yes, that's correct.
On Sunday 04:05 PM 8/2/2009, Torben Brosten wrote:
ns_httpspost depends on server's content-length header to be somewhat
accurate or greater than 0 if supplied.
That's true, though I'm not sure if it's a problem in the general case or
if it's ok based on the HTTP specs. It's definitely not an
57 matches
Mail list logo
