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
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.
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=detailaid=2822117group_id=3152atid=103152
But the short version is that when using the nsopenssl client-side routines
(e.g. ns_httpsget), the result may
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
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
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
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
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
:
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)
... time passes ...
13:55:11 - serve file
...actually
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
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
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
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
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
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
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
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
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
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
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,
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
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 incorrect data
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
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
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
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
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
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
ports (e.g
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 with this -B
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
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
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 explained one facet
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 in my posting).
Maybe I'm
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 of
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 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 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
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 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
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 rpms
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 the difference?
RedHat split
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
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:
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: A
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
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
http://zmbh.com/rlreturnz/ ) uses
48 matches
Mail list logo
