> From: Ryan Morgan [mailto:[EMAIL PROTECTED]]
> Sent: 01 October 2002 07:18
[...]
> Since Apache2 has the ability to serve multiple protocols, so the number of
> registered methods can grow quite rapidly. Since the HTTP module cannot
> be removed from the server (without some serious effort..
On Mon, Sep 30, 2002 at 07:04:49PM -0700, Greg Stein wrote:
> On Mon, Sep 30, 2002 at 05:35:40PM -0700, Ryan Morgan wrote:
> >...
> > This patch moves all the DAV method registration into the mod_dav module
> > from the http core. I'd like to do this for a couple reasons:
> >
> > 1) It makes mor
On Mon, 30 Sep 2002 12:51:43 +, Bill Stoddard wrote:
>
>> One of the known limitations of the current mod_mem_cache code is that
>> it uses a single global mutex to serialize cache additions and
>> deletions.
>>
>> I thought the easy fix for this would be to extend the cache's hash
>> table
--On Monday, September 30, 2002 7:32 PM -0700 Greg Stein <[EMAIL PROTECTED]>
wrote:
> Maybe we can being a long-term planning doc on how Apache will move away
> from knowledge about the FS to an agnostic point of view? And then
> identify the steps on that path, and which will break compat.
+1.
On Mon, Sep 30, 2002 at 06:58:45PM -0400, Ryan Bloom wrote:
> On Mon, 30 Sep 2002, Greg Stein wrote:
>...
> > A secondary issue is possibly refining mod_dav's handling. But that is a
> > *very* deep problem. The specified resource might not be in the filesystem,
> > so it would be *invisible* to A
On Mon, Sep 30, 2002 at 06:53:09PM -0400, Ryan Bloom wrote:
>...
> The problem is that the default_handler shouldn't be involved. Because
> mod_dav is now replacing the r->handler field for ALL requests, things
Woah! *NOT* "all" requests. Only those under the URL namespace which has
been assigne
On Mon, Sep 30, 2002 at 05:35:40PM -0700, Ryan Morgan wrote:
>...
> This patch moves all the DAV method registration into the mod_dav module
> from the http core. I'd like to do this for a couple reasons:
>
> 1) It makes more sense to register these methods from the same module
>they are use
Jeff,
Taking a queue from your comments, I re-config'ed openssl
"./config threads no-shared no-dso no-asm"
and then rebuilt openssl and apache.
Apache's link failure went away ...
...although I'm still getting the "incorrect file suffix" warning
messages... which you
I didnt get any feedback on this patch from a couple of weeks ago. See
below for the details.
-Ryan
--
This patch moves all the DAV method registration into the mod_dav module
from the http core. I'd like to do this for a couple reasons:
1) It makes more sense to register these methods from
Since we're on it, and since I did that already to keep up to date our 20+
Solaris machines... Do we want to include also a proto and a script for
Solaris?
Pier
I have committed a slightly modified version of this patch.
Ryan
On Fri, 20 Sep 2002, Ryan Morgan wrote:
>
> I have a quick question about some of the logic in the core_output_filter.
>
> When the core_output_filter sends data to the network (via writev_it_all,
> emulate_sendfile, or sendfil
Unless someone knows a trick that I'm not aware of
debugging Win32 crash dumps (DrWatson .dmp files) can
be a real pain unless you have symbols because
Frame Pointer Omission records make it hard to
construct the call stack from a dump. Having symbols
that match the binary build handy when you exa
"Bennett, Tony - CNF" <[EMAIL PROTECTED]> writes:
> I just downloaded 2.0.42 and attempted to build it on AIX 4.3.3
> and it failed...it appears to be building module libraries named
>
> lib$MODULE_NAME.al (for example: modules/dav/main/.libs/libmod_dav.al)
>
> instead of
> lib$MODUL
On Mon, 30 Sep 2002, Greg Stein wrote:
> On Sun, Sep 29, 2002 at 10:33:08PM -0700, Justin Erenkrantz wrote:
> > On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote:
> > > Because 2.0.42 always displays script source for CGI scripts that use
> > > POST, I believe that we should put that not
I just downloaded 2.0.42 and attempted to build it on AIX 4.3.3
and it failed...it appears to be building module libraries named
lib$MODULE_NAME.al (for example: modules/dav/main/.libs/libmod_dav.al)
instead of
lib$MODULE_NAME.a(for example: modules/dav/main/.libs/libmod_dav.a)
[...]
>> A secondary issue is possibly refining mod_dav's handling. But that is a
>> *very* deep problem. The specified resource might not be in the filesystem,
>> so it would be *invisible* to Apache if mod_dav doesn't handle it. The grey
>> area is when you're working with mod_dav_fs.
>
> It ma
Just in case anyone is interested in this, the thingy is available from
here:
http://www.rexursive.com/software.html
Bojan
PS. This patch has not been heavily tested. If you find any nasties in
it, please let me know.
On Sun, Sep 29, 2002 at 10:33:08PM -0700, Justin Erenkrantz wrote:
> On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote:
> > Because 2.0.42 always displays script source for CGI scripts that use
> > POST, I believe that we should put that notice on our main site, and stop
> > suggesting 2.
On Mon, 30 Sep 2002, Greg Stein wrote:
> On Mon, Sep 30, 2002 at 09:36:50AM -0400, [EMAIL PROTECTED] wrote:
> > On Sun, 29 Sep 2002, Justin Erenkrantz wrote:
> >
> > > On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote:
> > > > Because 2.0.42 always displays script source for CGI scripts
On Mon, Sep 30, 2002 at 09:36:50AM -0400, [EMAIL PROTECTED] wrote:
> On Sun, 29 Sep 2002, Justin Erenkrantz wrote:
>
> > On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote:
> > > Because 2.0.42 always displays script source for CGI scripts that use
> > > POST, I believe that we should put
Hi All,
I've written a module for Apache which will limit the
amount of data the server may transfer in a given time
period. (OK that's a simplistic overview anyway ;)
To do this I make use of the information gathered by
mod_status, and when the data transferred goes over a
given thres
On Mon, 30 Sep 2002 [EMAIL PROTECTED] wrote:
> Failed Test Status Wstat Total Fail Failed List of Failed
>
> ssl/env.t 28 14 50.00% 15-28
> ssl/require.t 52 40.00%
On Mon, 30 Sep 2002, Justin Erenkrantz wrote:
> --On Monday, September 30, 2002 4:43 PM -0400 [EMAIL PROTECTED] wrote:
>
> > I just tried to make a minor change to the server, and test it to ensure
> > that it didn't break anything. Unfortunately, the test suite is currently
> > broken with reg
--On Monday, September 30, 2002 4:43 PM -0400 [EMAIL PROTECTED] wrote:
> I just tried to make a minor change to the server, and test it to ensure
> that it didn't break anything. Unfortunately, the test suite is currently
> broken with regard to SSL.
>
> I haven't had time to look into this yet,
I just tried to make a minor change to the server, and test it to ensure
that it didn't break anything. Unfortunately, the test suite is currently
broken with regard to SSL.
I haven't had time to look into this yet, and probably won't until Tuesday
at the earliest.
Ryan
--
_
On Mon, 2002-09-30 at 09:51, Bill Stoddard wrote:
> > Given an efficient means of synchronizing searches
> > and updates on a linked list, we could add a "search
> > for this entry and create it if it doesn't exist"
> > function to the mod_cache hash table implementation.
> >
> > Anybody have opi
> One of the known limitations of the current mod_mem_cache
> code is that it uses a single global mutex to serialize
> cache additions and deletions.
>
> I thought the easy fix for this would be to extend the
> cache's hash table to include a mutex for each hash
> bucket. That would enable us t
Brian Pane wrote:
>
> One of the known limitations of the current mod_mem_cache
> code is that it uses a single global mutex to serialize
> cache additions and deletions.
> So the other alternative I've been thinking of is to
> use an algorithm based on atomic compare-and-swap
> operations to al
Brian Pane wrote:
> So the other alternative I've been thinking of is to
> use an algorithm based on atomic compare-and-swap
> operations to allow thread-safe searches and updates
> of each hash chain. I've found several references
> to lockless, concurrent linked list algorithms that
> might b
On Sun, Sep 29, 2002 at 05:10:09PM -0700, Ian Holsman wrote:
> >I would be more keen to use an official apache RPM than say a Redhat
> >one, as Redhat (and possibly other distros) are rather slow at releasing
> >the latest bugfixes.
> >
> +1 from me.
> I think the only technical issues stopping
On Sun, 29 Sep 2002, Justin Erenkrantz wrote:
> On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote:
> > Because 2.0.42 always displays script source for CGI scripts that use
> > POST, I believe that we should put that notice on our main site, and stop
> > suggesting 2.0.42 for production
On Mon, Sep 30, 2002 at 11:03:46AM +0100, Thom May wrote:
> > Given that we're doing a "system" install, then, I would suggest that we
> > follow the FHS (http://www.pathname.com/fhs/2.2/), and design a layout.
> >
> > (altho it would seem the discussion will revolve around whether to drop
> > e
* Greg Stein ([EMAIL PROTECTED]) wrote :
> On Sun, Sep 29, 2002 at 05:10:09PM -0700, Ian Holsman wrote:
> >...
> > I think the only technical issues stopping us are:
> > - layout to choose
>
> I was about the say the "Apache" layout, but that is best suited for
> /usr/local/apache2, rather th
On Sun, 29 Sep 2002, Sameer R. Manek wrote:
> The correct url should be
> ftp://ftp.iana.org/assignments/media-types/
Committed... thanks Sameer!
--Cliff
> I would be more keen to use an official apache RPM than say a Redhat
> one, as Redhat (and possibly other distros) are rather slow at releasing
> the latest bugfixes.
That's why independant people provide such rpms,
btw mine use 8092/8093 (configurable) as http/https default
listen ports
A minor detail, but can someone please update ./docs/conf/mime.types?
The correct url should be
ftp://ftp.iana.org/assignments/media-types/
Thanks
Sameer
-
Sameer R. Manek Email: [EMAIL PR
36 matches
Mail list logo
