Re: merging httpd-pop3 into httpd-2.0?

[Aaron Bannert]

On Saturday, January 25, 2003, at 11:52  PM, Harrie Hazewinkel wrote:

Just another thing comes to mind. How about CVS access??
I beleibe if people are willing to work on this a seperate CVS
repository would allow quicker people to develop on it.
People working on the pop module, do not neccessarly have and
get CVS access to the httpd reposotory and in such a case
the POP development is depending on people who have CVS access
to httpd.

This is a practical matter, but IMHO valid.


Actually, I think this is a great point and I agree.
A decoupling of the modules from the core will IMHO
encourage more independent development and probably
encourage better interfaces as well.

-aaron

Re: merging httpd-pop3 into httpd-2.0?

[Aaron Bannert]

On Sunday, January 26, 2003, at 05:59  AM, Martin Kutschker wrote:

SASL is such a plugable authentication. Though it fails to be easily 
extendable. Perhaps an ASF xp implementation of the RFC is of > interest.

We'd be happy to entertain proposals. :)

-aaron

Re: merging httpd-pop3 into httpd-2.0?

[Aaron Bannert]

On Saturday, January 25, 2003, at 02:41  PM, Erik Abele wrote:

Perhaps there is not much interest because it is somewhat 'hidden'? 
IMHO mod_pop3 would gain more visibility and therefore perhaps a 
better community when folded into httpd. Imagine windoze users: they 
mostly rely on binary distributions and up to now there are just the 
sources around. If mod_pop3 gets used more widely, there probably will 
be also more developers who will be attracted to contribute.

If this module become actively maintained for the purpose
of making a pop3 server, I am pretty sure that would not
fit within the scope of the charter (I don't have an
internet connection handy to check the actual charter though...)


Leaving it in it's own repo-module as it is now, without any person in 
charge of it, will let it die on the long run.

It's already been stated on this and other lists that
the code as-is has been useful.

-aaron

Re: merging httpd-pop3 into httpd-2.0?

[Aaron Bannert]

On Saturday, January 25, 2003, at 12:43  PM, Harrie Hazewinkel wrote:

3)Why for instance, could this not stay as a seperate module??


I don't think we should be moving more code into the core.
It would be nice if we could make the core lean and mean
and keep the modules on their own independent development
paths.

Besides, this module is a great example module, so it should
stay that way (and stay out of the base distribution).

-aaron

Re: merging httpd-pop3 into httpd-2.0?

[Thomas Eibner]

On Sun, Jan 26, 2003 at 08:31:14AM +0100, Harrie Hazewinkel wrote:
> 
> On Sunday, January 26, 2003, at 12:18 AM, Erik Abele wrote:
> >Well, than let's move it in. A quick overview of the last mails shows 
> >the following votes:
> >
> >justin +0 modules/pop3
> >jim +1 modules/experimental
> >bills -0 !modules/pop3
> >willrowe -0 modules/experimental / +0 modules/pop / +1 for it's 
> >current repository
> >
> >plus some positive votes from Daniel Lopez, Thomas Eibner, Harrie 
> >Hazwinkel and Chris Taylor.
> 
> Sorry, but I am positive about this module, but negative (-1) to fold
> it in the main distribution. Reasons see other email of me.

It doesn't matter in the big picture, but I believe I had negative
opinion about folding it into httpd-2.0 ;)

Unless someone actually makes a distribution of httpd where pop3 is
built-in I don't see it "taking" off anyway. Once it is folded into
httpd I'm not sure I see much more work happening on it again. The
few times I had a question or a patch the pop3 list has worked fine.
If it's exposure for the module why not whip up a webpage and someone
make a binary with only auth and pop3 (If noone of the developers are
interested in this I'm sure Gunther Knauf would build one). As far as
other exposure I know Rich Bowen showed off what the pop3 module could
do at one of his talks last year.

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  
  !(C)  
  Putting the HEST in .COM 

Re: mod_pop3

[Cliff Woolley]

On Sun, 26 Jan 2003, Daniel Lopez wrote:

>
> So, when I volunteered to integrate mod_pop3 I thought I would have to
> do some modifications to the code to bring it up to date, but that is
> not the case. I tested it over the weekend both in Apache 2.0 and Apache
> 2.1 and compiles and works just fine.

Oh good, glad to hear it.  I'd thought I remembered that we were careful
to update it the last time the related API's changed... but around here
you never know.  ;)

Re: mod_pop3

[Joshua Slive]

On Sun, 26 Jan 2003, Daniel Lopez wrote:
> I followed the examples that exist for other modules, but I do not have a
> setup for converting it to html, so somebody in the docs projects should
> have a look at it to check I did not screw up. In particular, some
> of the references to mod_auth may not be valid for 2.1 branch

That's no problem.  But a couple quick notes:

-  is not a  environment, so you need to end lines with  if you want them to break.

- I would recommend a

mod_pop3

[Daniel Lopez]

So, when I volunteered to integrate mod_pop3 I thought I would have to do
some modifications to the code to bring it up to date, but that is not the
case.
I tested it over the weekend both in Apache 2.0 and Apache 2.1 and
compiles and works just fine.
If people decide to include it in experimental/ instead of in its own
directory, some trivial changes will be required to config.m4
but that's about it

So, the other (boring :) piece left to do was documentation.
You can find the XML manual page that I wrote here:
http://www.apacheworld.org/pop3/

I followed the examples that exist for other modules, but I do not have a
setup for converting it to html, so somebody in the docs projects should
have a look at it to check I did not screw up. In particular, some
of the references to mod_auth may not be valid for 2.1 branch

Best regards

Daniel

-- 
Teach Yourself Apache 2 -- http://apacheworld.org/ty24/

[patch] PR 9076: Satisfy Any without AuthType set is broken

[André Malo]

actually this bug happened over 5 years ago ...

However, try a standard installation and put a single "Satisfy Any" into 
the DocumentRoot's Directory section. If you then try to access 
http://localhost: in 1.3 you'll get a weird 500 without an errorlog 
message. In 2.x you'll loose all MIME and handler information (in fact it 
won't be set).

I've attached patches for 1.3, 2.0 and 2.1, which all do the same. They 
remove the bogus !auth_type check for the access_checker run.
Since it's a sensitive area, some review would be appreciated.

nd
-- 
sub the($){+shift} sub answer (){ord q
[* It is always 42! *]   }
   print the answer
# André Malo # http://pub.perlig.de/ #

Index: server/request.c
===
RCS file: /home/cvs/httpd-2.0/server/request.c,v
retrieving revision 1.123
diff -u -r1.123 request.c
--- server/request.c23 Jan 2003 21:34:13 -  1.123
+++ server/request.c27 Jan 2003 01:22:05 -
@@ -251,8 +251,7 @@
 break;
 
 case SATISFY_ANY:
-if (((access_status = ap_run_access_checker(r)) != 0)
-|| !ap_auth_type(r)) {
+if (((access_status = ap_run_access_checker(r)) != 0)) {
 if (!ap_some_auth_required(r)) {
 return decl_die(access_status, ap_auth_type(r)
   ? "check access"

Index: server/request.c
===
RCS file: /home/cvs/httpd-2.0/server/request.c,v
retrieving revision 1.121.2.1
diff -u -r1.121.2.1 request.c
--- server/request.c23 Dec 2002 09:03:55 -  1.121.2.1
+++ server/request.c27 Jan 2003 01:25:33 -
@@ -242,8 +242,7 @@
 break;
 
 case SATISFY_ANY:
-if (((access_status = ap_run_access_checker(r)) != 0)
-|| !ap_auth_type(r)) {
+if (((access_status = ap_run_access_checker(r)) != 0)) {
 if (!ap_some_auth_required(r)) {
 return decl_die(access_status, ap_auth_type(r)
   ? "check access"

Index: src/main/http_request.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_request.c,v
retrieving revision 1.166
diff -u -r1.166 http_request.c
--- src/main/http_request.c 21 May 2002 12:50:09 -  1.166
+++ src/main/http_request.c 27 Jan 2003 01:22:24 -
@@ -1267,7 +1267,7 @@
 }
 break;
 case SATISFY_ANY:
-if (((access_status = ap_check_access(r)) != 0) || !ap_auth_type(r)) {
+if (((access_status = ap_check_access(r)) != 0)) {
 if (!ap_some_auth_required(r)) {
 decl_die(access_status ? access_status :
 HTTP_INTERNAL_SERVER_ERROR,

Re: does apr_file_inherit_set() work??

[Günter Knauf]

Hi Bill,
thanks for further details. 
My question came up while I'm in contact with a module author and we are trying to get 
the fresh ported 2.0 modules up on Netware and Win32. I found apr_file_inherit_set() 
in the headers and suggested using this instead of chown() in the hope that APR will 
do the right thing on every platform, but we both didnt find the implemetation; so I 
posted my question. 

Below I forward his answer to your last post:

> Actually, the confusion may stem from the fact of looking at /arch/win32/
> which are noops ...  Only Unix toggles the 'close handle on fork' option

I don't look at W32 stuff. My modules were designed for Apache 1.3 
prefork model. Thats the based line of compatiblity, cause 1.3 
module authors had to know it.  Probably one of the major reasons 
modules authors are not moving quickly to 2.0 is because there is 
no one memory/process model, making it difficult write a portable 
module.

> ... because Win32 can create handles for inheritence, but we have no method
> of actually *sending* the handles to the client, we've forgone that implementation
> so far.  It does no good to have a dozen log handles when we can't reconnect
> them in the child process; they are just wasted resources.

My concern is NOT about open file handles (and other system 
resouces like mutexes and share memory) at the time of a fork(). 
In my thinking, there is no clear/clean way to create a file and 
close it in the parent process with the correct file ownership 
permissions such that a child process could open that file again 
when it needs to.

I have to #ifdef __unix__ the code around a chown() in the 
ap_hook_post_config() that executes during the parent process for 
files that will be later might be accessed by a child process. 
apr_file_inherit_set() would appear to be the clean way to do it 
for open file handles, but not for the files themselves and 
unixd.h does not have any equivalent (except for global mutexes).


-- 
Anthony C Howe+33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561  AIM: Sir Wumpus
"Will the real email please stand up..."

server to "fast" for browser?

[Josef Zellner]

Hi all!
For some reasons I had to put the structure "request_rec" into a class like:

RequestHandler
{
	private:
	struct request_rec *r;
	public:
		print(const char *data)
		{
			ap_rprintf(r,"%s",data);
		}
}

If I use this class for sending data (250 KB) to a browser (IE 5.0), the 
 browser will handle it as no data and shows a blank page. But if I a 
make the process slower (some pause statements or debug output to a 
file), the browser shows all the data correctly.

Can anyone tell me, what i am doing wrong? Must I handle the request_rec 
structure (or one of it's element) in a certain way?

Thanks in advanve,
Josef

Re: does apr_file_inherit_set() work??

[William A. Rowe, Jr.]

At 11:02 AM 1/26/2003, Thom May wrote:
>* Günter Knauf ([EMAIL PROTECTED]) wrote :
>> > * Guenter Knauf ([EMAIL PROTECTED]) wrote :
>> >> Hi,
>> >> I can see that mod_log_config, mod_rewrite and mod_file_cache have it in;
>> >> but where in the source tree is APR_INHERIT as set by
>> >> apr_file_inherit_set() actually handled?
>> >> A grep of the source tree does not find any application of this flag.
>> >> Is it really implemented yet, or just a dummy?
>> >>
>> > see apr_arch_inherit.h in include/arch/*/
>> Thats a useless answer.  I want to see a .c that implements whats defined in a .h.
>
>Both Will Rowe and I have replied to you, on seperate threads with *exactly
>the same answer*. Have you looked in the header file?

Actually, the confusion may stem from the fact of looking at /arch/win32/
which are noops ...  Only Unix toggles the 'close handle on fork' option
by togging the cleanup.  We should probably also implement the recent
cleanups patch to Apache 1.3 in a similar manner right here at this point
in the macros.

... because Win32 can create handles for inheritence, but we have no method
of actually *sending* the handles to the client, we've forgone that implementation
so far.  It does no good to have a dozen log handles when we can't reconnect
them in the child process; they are just wasted resources.

I've been trying to come up with a schema for sending such handles to the
child process.  Either 1) we have to register them such that the child process
can recover the handles and their purposes, or 2) we set up a mechanism for
giving the child an unlimited handle to the parent process, and the parent's 
own handles.  For security, once we are done duplicating any parent handles
we want to use, we close the handle to the parent process (which we can
never regain again.)

It's not exactly a coin toss, the design paradigms are very different.  Once
my head is above water (post 2.0.45) I'd be happy to implement both of these
flavors (store meanings and let the child inherit the handles, v.s. pass parent 
handles for the child to duplicate at it's discresion) and we can compare the
benefits of each.

One downside to the inherited handles, when we don't fork, is the (modestly)
high probability of extra handle leaks for no good cause.  The downside to 
either solution (and the real meat of the issue) is; which model causes
module authors the least extra pain to support non-forked platforms?
We shall see.


> From apr_arch_inherit.h in include/arch/unix/
>
>#define APR_IMPLEMENT_INHERIT_SET(name, flag, pool, cleanup)\
>apr_status_t apr_##name##_inherit_set(apr_##name##_t *the##name)\
>{   \
>if (!(the##name->flag & APR_INHERIT)) { \
>the##name->flag |= APR_INHERIT; \
>apr_pool_child_cleanup_set(the##name->pool, \
>   (void *)the##name,   \
>   cleanup, apr_pool_cleanup_null); \
>}   \
>return APR_SUCCESS; \
>}

Re: API for getting the MPM?

[Justin Erenkrantz]

--On Sunday, January 26, 2003 5:55 PM +0100 Günter Knauf 
<[EMAIL PROTECTED]> wrote:

is there an API for getting the MPM which is in use??


Not the specific MPM per se, but if you look in ap_mpm.h, you'll see 
that you can query the properties of the running MPM.  -- justin

Re: merging httpd-pop3 into httpd-2.0?

[Jim Jagielski]

Martin Kutschker wrote:
> 
> 
> > Also by adding a module like this,
> > the complete group should also think of making Apache
> > somehow a bit more 'different protocol friendly'. I understand
> > this is already a topic of the past (2 years ago), but
> > now it becomes valid request to ask, IMHO.
> 
> I'm not sure if it makes sense to turn an http server in an all-purpose
> multi-protocol beast.
> 

But it already *is*. The whole reason for implementing protocols
as modules was to *allow* this. Also, that's the reason for a
lot of the thinking about pools and filters. If Apache was just
"supposed" to do HTTP, then the current design would be very
different (and a lot of the headaches in making it so would
have been avoided).

Apache 2.0 supports different protocols. It ships with HTTP. POP3
is available, at the least, as an example. We have other experimental
modules in A2.0 (mpm *and* "regular" modules), we should also
include pop3.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: does apr_file_inherit_set() work??

[Thom May]

* Günter Knauf ([EMAIL PROTECTED]) wrote :
> > * Guenter Knauf ([EMAIL PROTECTED]) wrote :
> >> Hi,
> >> I can see that mod_log_config, mod_rewrite and mod_file_cache have it in;
> >> but where in the source tree is APR_INHERIT as set by
> >> apr_file_inherit_set() actually handled?
> >> A grep of the source tree does not find any application of this flag.
> >> Is it really implemented yet, or just a dummy?
> >>
> > see apr_arch_inherit.h in include/arch/*/
> Thats a useless answer.  I want to see a .c that implements whats defined in a .h.

Both Will Rowe and I have replied to you, on seperate threads with *exactly
the same answer*. Have you looked in the header file?
Cheers,
-Thom



 From apr_arch_inherit.h in include/arch/unix/

#define APR_IMPLEMENT_INHERIT_SET(name, flag, pool, cleanup)\
apr_status_t apr_##name##_inherit_set(apr_##name##_t *the##name)\
{   \
if (!(the##name->flag & APR_INHERIT)) { \
the##name->flag |= APR_INHERIT; \
apr_pool_child_cleanup_set(the##name->pool, \
   (void *)the##name,   \
   cleanup, apr_pool_cleanup_null); \
}   \
return APR_SUCCESS; \
}

Re: does apr_file_inherit_set() work??

[Justin Erenkrantz]

--On Sunday, January 26, 2003 5:48 PM +0100 Günter Knauf 
<[EMAIL PROTECTED]> wrote:

see apr_arch_inherit.h in include/arch/*/

Thats a useless answer.  I want to see a .c that implements whats
defined in a .h.


No, it's not useless.  I'd suggest actually reading the files Thom 
pointed you at.

All of the inherit functionality is implemented as macros in the .h 
file - there is no .c file that implements APR_INHERIT because of the 
way we use this functionality.  Particular structures (namely socket 
and files) will call these macros for their implementation.

And, please pay attention to what list you send questions like this 
on.  dev@httpd is not the right place for APR questions.  In the 
future, please only post to dev@apr.  -- justin

API for getting the MPM?

[Günter Knauf]

Hi,
is there an API for getting the MPM which is in use??

Guenter.

Re: does apr_file_inherit_set() work??

[Günter Knauf]

> * Guenter Knauf ([EMAIL PROTECTED]) wrote :
>> Hi,
>> I can see that mod_log_config, mod_rewrite and mod_file_cache have it in;
>> but where in the source tree is APR_INHERIT as set by
>> apr_file_inherit_set() actually handled?
>> A grep of the source tree does not find any application of this flag.
>> Is it really implemented yet, or just a dummy?
>>
> see apr_arch_inherit.h in include/arch/*/
Thats a useless answer.  I want to see a .c that implements whats defined in a .h.

Guenter.

Re: merging httpd-pop3 into httpd-2.0?

[Harrie Hazewinkel]

Sander,

On Sunday, January 26, 2003, at 05:16 PM, Sander Striker wrote:

Somehow it could be, since you can reuse parts of Apache and APR
for instance. But then one does not need to use Apache to make a POP
server while still using APR. Simply download APR and use it as a 
library.

*Buzzz*  What about the mpm's?  And all the other support functionality
that is in the 2.0 framework?  Do you suggest we move it all out to 
APR?
Or would you suggest reimplementing it all for the 
you'd like to implement?

It is not that I don't think the Apache framework cannot do this. Most
of it is there, I mainly refered to the fact of using APR and APR-UTIL
does not require to use Apache (httpd).


Harrie
--
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server

RE: merging httpd-pop3 into httpd-2.0?

[Sander Striker]

> From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 26, 2003 5:00 PM

[...]
>>> Also by adding a module like this,
>>> the complete group should also think of making Apache
>>> somehow a bit more 'different protocol friendly'. I understand
>>> this is already a topic of the past (2 years ago), but
>>> now it becomes valid request to ask, IMHO.
>>
>> I'm not sure if it makes sense to turn an http server in an all-purpose
>> multi-protocol beast. I'd favour a number of servers which rely on a 
>> set of well-defined libs (APR, APR-util and what else?).
> 
> I agree here as well. Does it make sense to make Apache an all-purpose
> server.

Why not?  The framework is certainly up for it.  There are a few glitches
to work out, but it could very well be used as a multi-purpose framework.
Doing that will keep us hold the abstractions in check aswell.

> Somehow it could be, since you can reuse parts of Apache and APR
> for instance. But then one does not need to use Apache to make a POP 
> server while still using APR. Simply download APR and use it as a library.

*Buzzz*  What about the mpm's?  And all the other support functionality
that is in the 2.0 framework?  Do you suggest we move it all out to APR?
Or would you suggest reimplementing it all for the 
you'd like to implement?

>> A super-server would not be easy to administer (bringing down pop just
>> to restart http?).

You would run two instances, so you don't have to bring one down to touch
the other.

> And perhaps some memory models suit one protocol better than others.

That would be more of an APR issue.

Sander

Re: merging httpd-pop3 into httpd-2.0?

[Harrie Hazewinkel]

HI,

On Sunday, January 26, 2003, at 02:59 PM, Martin Kutschker wrote:


Date: Sat, 25 Jan 2003 21:43:41 +0100
From: Harrie Hazewinkel <[EMAIL PROTECTED]>
Cc: Ben Hyde <[EMAIL PROTECTED]>


1) [snip] I believe it would be better to
add first a good message store API in such a way that different
types of mailboxes and databases can be used. The protocol
module should do only do the protocol part plus an example
message store.


I disagree. If you intend to introduce a message store API, then
separate module should implement an 'message store'. Otherwise it would
make little sense to create the API at all. Though I agree, that a
message store API sounds interesting.


Maybe I did not phrase my self right, but we are in agreement here.
Another layer of an message store API is needed for this and potentailly
a new module.
IMHO, preferably also one who could support for instance, IMAP and the 
other
mail protocols.



2) Also the module/protocol is not a complete. For instance, it does
not implement AUTH command.


This leads to other, new auth-type-modules (especially for
message store protocols - pop, imap, nntp?).


That is correct, it leads to another auth-type module.


SASL is such a plugable authentication. Though it fails to be easily 
extendable. Perhaps an ASF xp implementation of the RFC is of > interest.

That is a different issue, but I agree.




Also by adding a module like this,
the complete group should also think of making Apache
somehow a bit more 'different protocol friendly'. I understand
this is already a topic of the past (2 years ago), but
now it becomes valid request to ask, IMHO.


I'm not sure if it makes sense to turn an http server in an all-purpose
multi-protocol beast. I'd favour a number of servers which rely on a 
set
of well-defined libs (APR, APR-util and what else?).

I agree here as well. Does it make sense to make Apache an all-purpose
server. Somehow it could be, since you can reuse parts of Apache and APR
for instance. But then one does not need to use Apache to make a POP 
server
while still using APR. Simply download APR and use it as a library.

A super-server would not be easy to administer (bringing down pop just
to restart http?). And perhaps some memory models suit one protocol
better than others.


I agree here. The difference between POP and HTTP is somehow relative
little (OK, over simplified). But protocols do in the most cases a 
request
and get a download of data. Then in most of the cases the connection
gets closed.
If one compares this to IMAP, you make once a connection, authenticate
and select a mailbox. If needed you retrieve data (or send data to the
server). The connection then stays idle for some time and after some
time the IMAP client asks just for updates.

As a model of CPU usage, connection usage and so forth they are 
completely
different. For instance, load-balancing on CPU load would not do it,
since the amount of 'idle' connections in IMAP can occupy the complete
server (max clients) while still the CPU load is very low.
(Just some example).


Harrie
--
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server

Re: Can't build HEAD on Linux

[Jeff Trawick]

Did you do "cvs update" without doing "make extraclean"?

Sebastian Bergmann wrote:


gawk: /usr/src/httpd-2.0/build/make_exports.awk:138:
(FILENAME=/usr/src/httpd-2.0/include/pcreposix.h FNR=99) fatal: cannot
open file `/usr/src/httpd-2.0/include/rfc1413.h' for reading (No such file
or directory)
make[2]: *** [/usr/src/httpd-2.0/server/exports.c] Error 2
make[2]: Leaving directory `/usr/src/httpd-2.0/server'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/httpd-2.0/server'
make: *** [all-recursive] Error 1

Filters for apache 1.3

[fabio rohrich]

HI all,
always the same problem.
I have to work with the content generated from the
server.
I cannot get it,even if in the API I have BUFF *client
in the conn_rec is used internally to read and write
data to the client.
I dont know how to get the content, any ideas? Can I
interact with the BUFF *client or not?

Thanks!!!


__
Mio Yahoo!: personalizza Yahoo! come piace a te 
http://it.yahoo.com/mail_it/foot/?http://it.my.yahoo.com/

Re: merging httpd-pop3 into httpd-2.0?

[Martin Kutschker]

Date: Sat, 25 Jan 2003 21:43:41 +0100
From: Harrie Hazewinkel <[EMAIL PROTECTED]>
Cc: Ben Hyde <[EMAIL PROTECTED]>

> 1) [snip] I believe it would be better to
> add first a good message store API in such a way that different
> types of mailboxes and databases can be used. The protocol
> module should do only do the protocol part plus an example
> message store.

I disagree. If you intend to introduce a message store API, then
separate module should implement an 'message store'. Otherwise it would
make little sense to create the API at all. Though I agree, that a
message store API sounds interesting.

> 2) Also the module/protocol is not a complete. For instance, it does
> not implement AUTH command.

This leads to other, new auth-type-modules (especially for
message store protocols - pop, imap, nntp?).

SASL is such a plugable authentication. Though it fails to be easily extendable. 
Perhaps an ASF xp implementation of the RFC is of interest.

> Also by adding a module like this,
> the complete group should also think of making Apache
> somehow a bit more 'different protocol friendly'. I understand
> this is already a topic of the past (2 years ago), but
> now it becomes valid request to ask, IMHO.

I'm not sure if it makes sense to turn an http server in an all-purpose
multi-protocol beast. I'd favour a number of servers which rely on a set
of well-defined libs (APR, APR-util and what else?).

A super-server would not be easy to administer (bringing down pop just
to restart http?). And perhaps some memory models suit one protocol
better than others.

Masi 

Re: (forw) [thor@pivx.com: RE: TRACE used to increase the dangerousof XSS.]

[Rich Bowen]

On Thu, 23 Jan 2003, Thom May wrote:

> I think this covers most of the points...


We're getting more and more paniced people coming on IRC and asking
about TRACE, what they should do about it, and why there isn't a
flashing red sign about it on the apache.org front page. It was my
understanding, now reinforced by Thor's note, that this was a lot of
hogwash and hype, but, the argument goes, WhiteHat is a *company*, and
they have a *cool name*, so they can't be full of crap, can they? So, I
was wondering if there's any chance we can make come kind of official
statement about this that I can point people to. People tend to get
quite offended and beligerent when I try to explain to them the points
made in Thor's note.

-- 
Rich Bowen - [EMAIL PROTECTED]
Author - Apache Administrator's Guide
http://www.ApacheAdmin.com/

Can't build HEAD on Linux

[Sebastian Bergmann]

gawk: /usr/src/httpd-2.0/build/make_exports.awk:138:
(FILENAME=/usr/src/httpd-2.0/include/pcreposix.h FNR=99) fatal: cannot
open file `/usr/src/httpd-2.0/include/rfc1413.h' for reading (No such file
or directory)
make[2]: *** [/usr/src/httpd-2.0/server/exports.c] Error 2
make[2]: Leaving directory `/usr/src/httpd-2.0/server'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/httpd-2.0/server'
make: *** [all-recursive] Error 1

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

RE: merging httpd-pop3 into httpd-2.0?

[Sander Striker]

> From: Jim Jagielski [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 11:53 PM

> Erik Abele wrote:
>> Perhaps there is not much interest because it is somewhat 'hidden'? IMHO mod_pop3 
>would gain more visibility and 
>> therefore perhaps a better community when folded into httpd. Imagine windoze users: 
>they mostly rely on binary 
>> distributions and up to now there are just the sources around. If mod_pop3 gets 
>used more widely, there probably will be 
>> also more developers who will be attracted to contribute.
>> 
>> Leaving it in it's own repo-module as it is now, without any person in charge of 
>it, will let it die on the long run.
>> 
>> Personally I'm +/-0 towards folding it into httpd, since I won't have the time to 
>contribute...just my 2c.
> 
> Once again, I'm +1 in getting it moved in. It's an example of an
> protocol module. It's a good module. It's a worthwhile module. It
> would benefit from more people working on it, and people are
> interested in doing so.

+1.

Sander

RE: merging httpd-pop3 into httpd-2.0?

[Sander Striker]

> From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 26, 2003 8:52 AM

> Just another thing comes to mind. How about CVS access??
> I beleibe if people are willing to work on this a seperate CVS
> repository would allow quicker people to develop on it.
> People working on the pop module, do not neccessarly have and
> get CVS access to the httpd reposotory and in such a case
> the POP development is depending on people who have CVS access
> to httpd.
> 
> This is a practical matter, but IMHO valid.

Invalid.  We have fine grained access control and can allow/disallow
commits to a subdirectory or even single files.

Sander