Bill Stoddard wrote:
To be honest, I don't think the content-length header should be removed
in the first place in proxy. If a filter needs to modify the content
length for any reason, it should update the value of the content-length
header itself.
That sounds right to me.
Making proxy
-- Original Message --
Reply-To: [EMAIL PROTECTED]
Date: Sun, 28 Jul 2002 20:33:02 +0200
From: Graham Leggett [EMAIL PROTECTED]
Subject: Re: ldap
mod_ldap* was supposed to be part of v2.0, but happened too close to GA
for people to feel comfortable with it's stability. It looks like people
Justin Erenkrantz wrote:
On Sun, Jul 28, 2002 at 08:35:13PM +0200, Graham Leggett wrote:
Justin Erenkrantz wrote:
In the past, people have suggested a CPAN/PEAR-approach where
modules are downloaded when needed.
Modules in source form or binary form?
Source. Binaries are too
Aaron Bannert [EMAIL PROTECTED] writes:
I like the idea of decoupling the modules from the core, leaving
only the ability to serve static files in the base distribution.
That would allow us to make releases without as many constraints,
freeing up the modules to release on their own
Graham Leggett [EMAIL PROTECTED] writes:
Justin Erenkrantz wrote:
I believe it would be possible for the proxy to delete the
content-length header and replace it with another mechanism
of its choosing to signal the entity-length.
From what I can see proxy removes the content-length,
Jeff Trawick wrote:
Agreed, as long as you really mean zap the content-length header
when you say update the value of the content-length header.
A filter can't ever be *required* to put in the proper content-length
value. All it can usually do is zap the content-length header and
rely on
[EMAIL PROTECTED] wrote:
People didn't want it to be a part of the core more because of module bloat.
As Aaron says, there is no reason to add all these modules to the core
only to have to release them on the same schedule - I like it as a sub project.
When proxy was a subproject, it
Bill,
I am chewing on my tounge now to not be nasty. Where are you going with
this? Perhaps I missed it but was this change discussed on list? And the
commit log message describing the change is quite poor.
Bill
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Seperating out the routines that run only in the child (and putting them in
child.c) is not a bad thing but this patch is difficult to review for
several reasons:
1. The commit log did not mention the biggest change. Easy to intuit looking
at the code, but it should have at least been mentioned
Graham Leggett [EMAIL PROTECTED] writes:
Jeff Trawick wrote:
Agreed, as long as you really mean zap the content-length header
when you say update the value of the content-length header.
A filter can't ever be *required* to put in the proper content-length
value. All it can usually do
On Sunday, July 28, 2002, at 07:00 PM, Aaron Bannert wrote:
I like the idea of decoupling the modules from the core, leaving
only the ability to serve static files in the base distribution.
I don't. It's a pain in the ass for the users if they have to download and build
every single
I see the same thing happening to LDAP. For the most part it has
been ignored. If it is considered to be unstable at this point, why not
put it in /experimental with the other modules that are considered to be
not yet ready for prime-time but still very useful? In this way, it
will get the
Mod_proxy wasn't added back to the server until the developers had
proven that there was a development community around it, and most of the
bugs had been fixed. The same must be true for ldap before it can be
added to the base distribution.
Also, as a counter-point to this. Adding a module to
The patch below will add a Linux Standard Base (LSB) layout. This will make
it easier to create an LSB compliant version of the http server. The LSB
team from the Free Standards Group (FSG) has already used this layout to
make a binary image that passes all the tests for LSB compliance. If this
At 08:15 AM 7/29/2002, you wrote:
Seperating out the routines that run only in the child (and putting them in
child.c) is not a bad thing but this patch is difficult to review for
several reasons:
1. The commit log did not mention the biggest change. Easy to intuit looking
at the code, but it
Being Novell which is the leading provider of directory services, we
obviously have a great interest in LDAP. What if I were able to get the
Novell LDAP developers to step up and support AUTH_LDAP? Would that be
enough to get AUTH_LDAP put back into the mainstream?
Brad
Brad Nicholes
Marvin
Your layout mixes read-only information with read-write information. Specifically
the manual, icons, sample CGIs, and info files are all part of the standard
http server that sites shouldn't need to change. They can also be shared among
http servers on the same machine or via NFS etc. The
Ryan Bloom wrote:
Mod_proxy wasn't added back to the server until the developers had
proven that there was a development community around it, and most
of the bugs had been fixed. The same must be true for ldap before
it can be added to the base distribution.
Unless the httpd committer
From: Brad Nicholes [mailto:[EMAIL PROTECTED]]
Being Novell which is the leading provider of directory services,
we
obviously have a great interest in LDAP. What if I were able to get
the
Novell LDAP developers to step up and support AUTH_LDAP? Would that
be
enough to get AUTH_LDAP
Wilfredo Sanchez wrote:
I'm in favor of putting new modules in their own projects,
then when they are stable and generally complete, if they
are still just a couple of files small, and have become
reasonably popular/useful, I have no problem including them
in the HTTPd project.
+1
--
Marvin Heffler wrote:
The patch below will add a Linux Standard Base (LSB) layout.
H'm. I thought Red Hat's was LSB compliant.
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
Millennium hand and shrimp!
William A. Rowe, Jr. wrote:
And I, for one, wouldn't want to see ldap in the tree anywhere
but experimental
I'd just as soon not see it in the tree at all, if it's that
complex.
The word I have from the author of the 1.3 mod_auth_ldap module
is that he stopped working on it when he found
FYI - on http://www.apache.org/~dirkx/oscon2002 is my talk on apache
modules from Oscon 2002.
Feel free to use/rip it for your own presentations. The presentation and
the two modules are under an ASF license and/or can be donated to the ASF
on request.
Also there is a copy of a 2.0 version of
So it seems like we burned all of our bridges. We had somebody
working on it until we added it in. Then the author stopped so we took
it out. Now we not only don't have anybody working on it, we also don't
have it. IMO, if we put it back at least in experimental, maybe we can
get developers
I'm struggling with some Apache 1.3 logic and would like some advice in
order to make changes specific to the TPF operating system.
Various routines call ap_set_callback_and_alarm() to set a timeout
value, such as ap_keepalive_timeout() and ap_hard_timeout() in http_main.c.
The read in
I'm running 2.0.36 with the mod_auth_digest module. It seems to
work great in your basic browser.
I've got a custom browser that gets the pages with partial
requests. Apache, on the first request, instead of returning a
401 I get a 206. I don't seem to have this problem on 1.3 but
there I'm
26 matches
Mail list logo
