--On Wednesday, March 23, 2005 4:36 PM + [EMAIL PROTECTED] wrote:
another @@ -1008,7 +1023,15 @@
rnew-status = HTTP_OK;
-rnew-headers_in = r-headers_in;
+/* did the original request have a body? (e.g. POST w/SSI tags)
+ * if so, make sure the subrequest doesn't
--On Wednesday, April 6, 2005 1:30 PM -0400 Rich Bowen [EMAIL PROTECTED]
wrote:
Have you ever used mod_imap? Or, at least, since 1996? I have a hard
Yes. Yes.
I do wish it were renamed to mod_imagemap though! mod_imap is a poor name.
Note that we could always re-introduce the imagemap CGI
--On Wednesday, April 6, 2005 12:49 PM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
The reason not to drop them is that when the gods of httpd
([EMAIL PROTECTED]) decide to change their minds about the 'default'
choice, it doesn't harm existing installations which were
explicitly
--On Wednesday, April 6, 2005 12:54 PM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
At 12:17 PM 4/6/2005, you wrote:
Author: jerenkrantz
Remove merged backport, block one, vote for one.
@@ -382,6 +381,7 @@
non experimental status.
+1: bnicholes, wrowe
+0: minfrin (wait
On Mon, Apr 04, 2005 at 03:01:34PM -0700, Greg Stein wrote:
Sorry, but I very much disagree. I think back to the old days of
access.conf, httpd.conf, and srm.conf. As an administrator, I absolutely
detested that layout. I could NEVER figure out which file a given
configuration was in. I always
--On Saturday, April 2, 2005 2:58 PM -0500 Joshua Slive [EMAIL PROTECTED]
wrote:
If you have suggestions for the implementation, speak up or just commit
away on the branch.
Thanks for taking this on.
Here are some things I would like to see done on this branch. Feel free
to jump in.
1. Fix make
--On Wednesday, March 30, 2005 7:40 PM +0200 Sander Striker
[EMAIL PROTECTED] wrote:
In short: Some eyes please...
+1. Looks fine to me. -- justin
--On Tuesday, March 29, 2005 11:22 AM -0700 Brad Nicholes
[EMAIL PROTECTED] wrote:
Are we BETA yet or not? I am assuming that the true status is:
OtherBill has consistently repeated that he will -1 anything entering beta.
So, until he resolves his issues, we're at a standstill.
My current
--On Wednesday, March 23, 2005 12:11 PM -0500 Brian Akins
[EMAIL PROTECTED] wrote:
Is there a list of supported compilers? I am having to compile using
gcc 2.96 and having some wierdness, but works fine on 3.3. It may be
something else with the box, but just wanted to know if there was an
--On Tuesday, March 22, 2005 3:22 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Of course! Now I'm on the same page with you. Actually,
I believe a buildconf.nice is a better solution (for reasons
in my other note.) We really have no say-so about what is
sitting in the directory
On Mon, Mar 21, 2005 at 05:19:56PM -0600, William A. Rowe, Jr. wrote:
grumf I'm not keen on this change, since it complicates things
unnecessarily - some day we discover a tag and roll organized like
this out of the blue?
Does config.nice not do what you want? Especially if you rename
it
--On Friday, March 18, 2005 5:59 AM -0500 Jeff Trawick [EMAIL PROTECTED]
wrote:
...snip, snip...
AIX:
Doesn't really fail in the normal sense of not putting the right data
on the wire, but can trigger a kernel memory issue if some kernel
tuning is incorrect. So always fail if the
--On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom [EMAIL PROTECTED] wrote:
funny, I took the list of exceptions to be so large and hard to
maintain that it made more sense to go with Jeff's original idea of
just disabling sendfile by default unless a user specifically decided
to enable it. I
--On Friday, March 18, 2005 11:51 AM -0500 Jeff Trawick [EMAIL PROTECTED]
wrote:
ouch, add one more brain-dead OS to the list: FreeBSD; some levels
have had filesystems which don't handle sendfile correctly (same type
of issue which hits some Linux users)
Do you have details? FreeBSD's sendfile
--On Friday, March 18, 2005 11:27 AM -0500 Ryan Bloom [EMAIL PROTECTED] wrote:
That's fine. Pay attention to what I suggested. Default to
non-native sendfile, until we have know that it works. If you have an
OS that you know for a fact does sendfile correctly, then that would
be a case where we
--On Friday, March 18, 2005 4:34 PM + Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
In my experience, more users are brain-dead than OS's ;) Surely it's the
users who don't have a hope of diagnosing the kinds of intermittent problems
that using sendfile can trigger who should be kept in mind?
--On Friday, March 18, 2005 11:53 AM -0500 Jeff Trawick [EMAIL PROTECTED]
wrote:
there are fixes available for the default tuning;
So, will we be able to isolate down to a revision of AIX that has these
fixes?
I have no
information on whether or not users have shot themselves in the foot
in
--On Friday, March 18, 2005 12:20 PM -0500 Jeff Trawick [EMAIL PROTECTED]
wrote:
google does; keywords ntfs smbfs and some other UDF (Universal
Disk Format (UDF) , which I've never heard of
ntfs sendfile freebsd 2nd hit on Google is a patch I sent to FreeBSD lists
years ago about a sendfile()
--On Friday, March 18, 2005 5:18 PM + Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
I think it's just one of those cases where it would be highly
non-trivial and inefficient to put all of the checks in APR, simply due
to the real-world nature of the bugs, but that at the same time there is
a
--On Friday, March 18, 2005 7:44 PM + Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
either lacklist or whitelist fstypes per OS, I don't much care. And, we
can check for IPv6 sockets on Linux.
This is still unfair on admins. Some network cards work fine, why
shouldn't their owners get the
On Thu, Mar 17, 2005 at 02:12:50PM +, Colm MacCarthaigh wrote:
On Thu, Mar 17, 2005 at 08:47:08AM -0500, Joshua Slive wrote:
+1, as before.
From the users' perspective, sendfile results in unexplained corruption
or uninterpretable error messages pretty much any time a network
On Thu, Mar 17, 2005 at 05:37:38PM +, Colm MacCarthaigh wrote:
On Thu, Mar 17, 2005 at 07:27:54AM -0800, Justin Erenkrantz wrote:
These seem like broken OSes and not a suitable justification to disable
sendfile. We should fix the code - perhaps by teaching APR not to enable
On Thu, Mar 17, 2005 at 07:01:49PM -0500, Jeff Trawick wrote:
Is that -1 a vote, or a veto against the idea? If the latter,
please explain in at least a little detail how a technical solution
can be implemented that will avoid some of the types of problems
triggered by the use of sendfile.
On Thu, Mar 17, 2005 at 05:37:01PM -0600, William A. Rowe, Jr. wrote:
First, I'm -1 on moving 2.1.4 to -beta- until the conflicts
between apr-iconv 0.9 and 1.x are resolved. The apr team is
currently addressing this.
Would you be against re-rolling 2.1.4 with an updated apr-iconv that uses
--On Wednesday, March 16, 2005 10:00 PM +0100 Sander Striker
[EMAIL PROTECTED] wrote:
Hi all,
There are some 2.1.4-alpha tarballs waiting to be tested at:
http://httpd.apache.org/dev/dist/
Please report back with any problems.
+1 for beta on Darwin (modulo httpd-test issues from last
On Mon, Mar 14, 2005 at 08:03:43PM -0800, Paul Querna wrote:
I would like to roll the 2.1.4 alpha right after APR 1.1.1 is released.
I plan on rolling APR tonight or Tuesday morning. If there arent any
problems, I am hoping to create 2.1.4 on Thursday. Any big outstanding
issues?
As far
--On Friday, March 11, 2005 9:33 AM + Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
Does anyone know what the story is with the website? I've been trying
to submit a presentation, but the website is down, and I've not gotten
a response from info@ , though admitadly I only tried this last night,
--On Wednesday, March 9, 2005 9:47 AM +0200 Eli Marmor [EMAIL PROTECTED]
wrote:
Time to define the exact directive and names?
I'd start with all of the directive that mod_cache currently exposes that
are binary (on/off).
At a quick glance, that looks like CacheIgnoreCacheControl,
--On Wednesday, March 9, 2005 10:00 AM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
With the approach of httpd 2.1-beta (in anticipation of 2.2 GA)
I'd like to propose the httpd project integrate apreq into the
core distribution. This project has evolved considerably since
it was first
--On Wednesday, March 9, 2005 7:42 PM +0200 Eli Marmor [EMAIL PROTECTED]
wrote:
That's all?!
Let me quote myself (and this is not the complete list):
If I recall correctly, there were MANY conditions in mod_cache that
prevented caching (like checking for a POST method, no-store, no-cache,
auth,
--On Wednesday, March 9, 2005 1:12 PM -0800 Paul Querna
[EMAIL PROTECTED] wrote:
I don't see how an optional module that depends on an external library is
that helpful compared to the current situation. (Module bundled with the
Library.)
It makes the most sense to me to include the library and
On Tue, Mar 08, 2005 at 08:49:52AM +0100, Sander Striker wrote:
So what is failing to build? 2.1.3? Or trunk? Only on
win32, or on other platforms as well? Can you reproduce?
Note that 2.1.3 fails to build on Win32 because APR 1.1.0 doesn't build.
This Win32 failure is *not* an httpd
On Tue, Mar 08, 2005 at 06:01:35PM +0100, Sander Striker wrote:
While I think this is a good idea, I'd like to consider renaming this
particular directive as I think the name is really confusing.
Does that mean you want me to hold off on committing this patch pending
a directive rename?
--On Tuesday, March 8, 2005 8:12 PM +0200 Eli Marmor [EMAIL PROTECTED]
wrote:
If I recall correctly, there were MANY conditions in mod_cache that
prevented caching (like checking for a POST method, no-store, no-cache,
auth, GET args, private, public, must-revalidate, maxage, etc.).
My idea was
--On Tuesday, March 8, 2005 9:38 PM +0200 Eli Marmor [EMAIL PROTECTED]
wrote:
It depends if you need it only for the server configuration, or for
dir_config;
In the latter case, you don't have another choice, you just NEED the +-
Actually, cache can't respect any dir config's (because it is a
On Mon, Mar 07, 2005 at 12:16:05AM -0600, William A. Rowe, Jr. wrote:
These choices overlook Brad's suggestion, which I still think is the best:
[ ] Implement across providers
Single AuthProviderAlias real-provider-name alias directive.
I did not overlook it.
What layer do you
On Mon, Mar 07, 2005 at 12:19:45AM -0600, William A. Rowe, Jr. wrote:
At 07:22 AM 3/6/2005, Sander Striker wrote:
I assume we are in agreement that the current AAA discussion shouldn't
hold up moving to 2.2 either.
Absolutely it does. Either 2.1-dev has made implementing this
worse (my
--On Monday, March 7, 2005 5:47 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Absolutely not my intention. Again, I do not want to have each
provider have to reimplement the same code and parsing. I want
a single module to do so, and the providers to be oblivious
(but still work.)
--On Monday, March 7, 2005 5:37 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
++1 - and I've always agreed. My only question is does the new API
make it impossible to do simple things.
...
If the new API makes things more difficult, it's a regression.
This AAA provider discussion just
On Sat, Mar 05, 2005 at 10:59:30PM -0600, William A. Rowe, Jr. wrote:
Ok, as Justin and I are in significant disagreement ... to summarize;
we (collectively) would like to see some mechanism for multiple
configurations of the same 'provider' (defined above). There are
logically three places
--On Sunday, March 6, 2005 1:54 PM +0100 Sander Striker [EMAIL PROTECTED]
wrote:
I completely agree. So much even that I just committed it (r156306).
Why are we storing the header fd in the disk object anyways? I haven't
gone through mod_disk_cache.c yet, but at least for store_headers() it
--On Monday, March 7, 2005 2:03 AM +0100 Sander Striker [EMAIL PROTECTED]
wrote:
However, I do think you are right that ap_meets_conditions() doesn't do the
right thing. But that is in general, not just in this case. It doesn't
seem to take responses other than 2xx into account. In those
--On Monday, March 7, 2005 7:47 AM +0100 Sander Striker [EMAIL PROTECTED]
wrote:
That's what I initially thought when I glanced over it. Then I started
wondering why headers are retrieved from h-req_hdrs, instead of
r-headers_in. I noticed we save the request headers of the request
that got a
--On Friday, March 4, 2005 11:55 PM +0100 Sander Striker [EMAIL PROTECTED]
wrote:
--
modules/cache/mod_cache.c:271
/* If the request has Cache-Control: no-store from RFC 2616, don't store
* unless CacheStoreNoStore is active.
*/
cc_in = apr_table_get(r-headers_in,
--On Friday, March 4, 2005 12:42 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
We have a naming problem. Provider is meaningless.
No, it's not. It's directly from the code and API itself. See
ap_provider.h.
Is a provider Basic, Digest?
No. These are the auth mechanisms which *call*
--On Friday, March 4, 2005 8:56 AM -0700 Brad Nicholes
[EMAIL PROTECTED] wrote:
Actually I think the better syntax would be:
AuthProviderAlias ldap Myldap1
...config options for mod_authnz_ldap...
/AuthProviderAlias
AuthProviderAlias ldap Myldap2
...config options for mod_authnz_ldap...
--On Friday, March 4, 2005 11:27 AM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
yup, that's what mod_auth_config did. However, mod_auth_config;
1. invokes auth for the local directives (not Auth sectioned)
2. invokes auth for all Auth sections.
providing the explicit list in
On Thu, Mar 03, 2005 at 08:40:22PM -0600, William A. Rowe, Jr. wrote:
And attached is the module for comment. I have no time till this
weekend if then, so I've got the build system changes and will
commit if we like.
My question as to how this would interact with the auth providers is still
On Wed, Mar 02, 2005 at 07:26:29AM -0500, Geoffrey Young wrote:
I think we just need another status besides
typedef enum {
AUTH_DENIED,
AUTH_GRANTED,
AUTH_USER_FOUND,
AUTH_USER_NOT_FOUND,
AUTH_GENERAL_ERROR
} authn_status
something like AUTH_DECLINED, which would
On Wed, Mar 02, 2005 at 07:52:30AM -0600, Jess Holle wrote:
This is essentially describing Graham's first option -- which is
workable. It just requires extra work from each and every auth module
author -- thus leading to a likelihood of some providing this and others
not doing so. It
On Wed, Mar 02, 2005 at 08:24:25AM -0500, Geoffrey Young wrote:
while I don't claim to have more than a cursory understanding of ldap, I
would think these cases could be handled by extending the current situation
a bit. for instance, for the file provider something like
AuthBasicProvider
On Wed, Mar 02, 2005 at 04:10:35PM +0200, Graham Leggett wrote:
The end goal is to simplify the providers so that you do not have to teach
each one how to handle multiple sources. The problem with implementing
multiple sources in one provider is that the end users assumes that the
same is
--On Wednesday, March 2, 2005 12:14 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Bleh. Wouldn't it be easier not to rearchitect the whole thing?
I believe this config syntax is orthogonal to the auth provider scheme.
There are completely independent of each other.
What about the
--On Wednesday, March 2, 2005 12:36 PM -0700 Brad Nicholes
[EMAIL PROTECTED] wrote:
Although I agree that this would probably be the best way to go, I don't
think it will be that simple. Authnz_ldap stores the LDAPurl and other
information (bind user id, bind password, certs, etc) in a per-Dir
--On Wednesday, March 2, 2005 2:07 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
No - simply create a per-dir config, and use dirconfig to represent;
AuthConfig
AuthFile users1
/AuthConfig
This would give us the best of both worlds. It's no different from
the use of Location,
--On Monday, February 28, 2005 2:10 PM -0800 Paul Querna
[EMAIL PROTECTED] wrote:
Sure, it would be nice if everyone upgraded, but I hack on Apache 2 for
myself. Other people using it is just a bonus.
+1. Exactly my feelings as well. -- justin
--On Monday, February 28, 2005 10:08 PM + Wayne S. Frazee
[EMAIL PROTECTED] wrote:
Core directives to definitively control the amount of memory, et al, that
Apache 2 uses would be a DEFINITE functional upgrade-driver for some
businesses and applications to upgrade to 2.0. Apache has
--On Monday, February 28, 2005 6:24 PM -0500 Jeffrey Burgoyne
[EMAIL PROTECTED] wrote:
I can go even one step further. 255 servers, 2.5 Gig of ram, huge config
(200 virtuals hosts, 1500 redirect rules, 2000 rewrite rules, 300 proxy
rules) and I never go into swap using prefork.
I believe 255
--On Wednesday, February 23, 2005 3:07 AM +0100 Branko ?ibej [EMAIL PROTECTED]
wrote:
A number of public functions in mod_dav.h aren't properly exported with
DAV_DECLARE. This recently became a problem for Subversion, because
mod_dav_svn now supports DAV locking, and mod_dav's locking functions
--On Friday, February 25, 2005 10:35 PM +0100 Branko ?ibej [EMAIL PROTECTED]
wrote:
Ah! I'm afraid you seem to have failed. trying, anyway. This would probably
work:
env LANG=en_US.UTF-8 svn propedit --revprop -r??? svn:log
https://svn.apache.org/repos/asf/httpd/httpd
then paste in the name
No idea why I'm suddenly hitting this, but in preparation for 2.1.3, I spent
another one of my patented hours searching for bugs in httpd that end up being
bugs in the perl-framework tests. =(
perl-framework generates Listen directives in the order of:
'Listen 0.0.0.0:8529'
For me, this causes
--On Wednesday, February 23, 2005 9:42 AM + Joe Orton [EMAIL PROTECTED]
wrote:
But there is no way to differentiate between any different interfaces
for the address (without doing magic), so I would say that is a resolver
misfeature.
But, the resolver was explicitly told that the socket
--On Wednesday, February 23, 2005 10:19 AM + Nick Kew [EMAIL PROTECTED]
wrote:
Justin Erenkrantz wrote:
By this point, I think that if a super-cool feature hasn't made it in
yet, it's time to admit that the feature missed the boat and it needs to
wait until 2.4.
Never mind about super-cool
--On Wednesday, February 23, 2005 10:09 AM +0100 Mladen Turk
[EMAIL PROTECTED] wrote:
Well, the tarballs are unbuildable on WIN32.
The problem is with apr and apr-util provided with the tarball,
and broken build/win32ver.awk that creates invalid .rc files.
If I use apr and apr-utils from HEAD,
--On Wednesday, February 23, 2005 8:46 AM -0600 Ben Collins-Sussman
[EMAIL PROTECTED] wrote:
The attached patch (against the 2.0.x branch) fixes the problem.
Shouldn't this patch be applied to *both* the 2.0 and 2.2 httpd lines? Does
that mean applying to httpd /trunk, then backporting to the
Assuming that we can get a beta approved to eventually become 2.2.x, I'd like
to propose the following policy that tries to balance the need for review with
the need for stability:
Any code changes can be backported to a release candidate branch from trunk
via lazy consensus (CTR) if it does
--On Wednesday, February 23, 2005 5:55 PM +0200 Graham Leggett
[EMAIL PROTECTED] wrote:
As soon as you install httpd + APR in a system location, you no longer can
install subversion + APR in a system location. This was the basis of
getting vendor packaging files (like RPM and PKG) into APR and
--On Wednesday, February 23, 2005 12:44 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
-1 veto - there is no reason for us -not- to adopt apr 1.2.0.
I'm confused why we would be so pedantic as to not adopt a
current release? APR signatures were broken on all 1.0/1.1
APR 1.2.0 isn't
--On Thursday, February 24, 2005 1:03 AM +0100 Guenter Knauf
[EMAIL PROTECTED] wrote:
minor patch for correct copyright in ./build/NWGNUtail.inc:
Heh. Applied. Thanks! -- justin
--On Wednesday, February 23, 2005 10:37 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Uhm, no. By that definition, all the pollution spewed from typical
Linux libraries would be considered 'public api.' Other platforms
are using the construct to extract public symbol lists now, IIUC.
--On Tuesday, February 22, 2005 11:56 AM +0100 Guenter Knauf
[EMAIL PROTECTED] wrote:
Hi,
not much more to say than the subject;
I think a couple of folks are waiting for any next alpha/beta/gamma
release of the 2.1-dev line; and its only fair also for the developers of
third-party modules that
2.1.3 tarballs at: http://httpd.apache.org/dev/dist/
I'd like to get enough votes for 2.1.3 to be a beta and commence the feature
freeze towards a 2.2.0 GA.
As we discussed at ApacheCon in November (over three months ago), this would
mean we create a 2.2.x branch from the 2.1.3 tag and bump
--On Tuesday, February 22, 2005 11:04 PM -0800 Justin Erenkrantz
[EMAIL PROTECTED] wrote:
2.1.3 tarballs at: http://httpd.apache.org/dev/dist/
I'd like to get enough votes for 2.1.3 to be a beta and commence the feature
freeze towards a 2.2.0 GA.
For the record, +1.
2.1.3 passes httpd-test
On Fri, Feb 18, 2005 at 08:32:07PM -, [EMAIL PROTECTED] wrote:
Modified: httpd/httpd/trunk/Makefile.win
URL:
http://svn.apache.org/viewcvs/httpd/httpd/trunk/Makefile.win?view=diffr1=154339r2=154340
==
---
On Fri, Feb 11, 2005 at 03:05:01PM +0100, Sander Striker wrote:
The point of this small patch is to allow mod_dav to take an easy
out instead of actually going through the (expensive) delivery
step, in case of a conditional request. Think of cache
validating requests for instance.
Makes
--On Wednesday, February 9, 2005 3:55 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
I did exactly that for win32.
The old win32 build system recompiled buildmark.c as a build
step (bleh.) The new win32 build system has the compilation
of buildmark.c as a prelink step - if we aren't
--On Thursday, February 10, 2005 4:38 PM + [EMAIL PROTECTED] wrote:
Author: jorton
Date: Thu Feb 10 08:38:47 2005
New Revision: 153273
URL: http://svn.apache.org/viewcvs?view=revrev=153273
Log:
* Makefile.in: Use buildmark.o not .lo since it was COMPILEd
not LT_COMPILEd.
I'm wondering if
--On Thursday, February 10, 2005 4:57 PM -0800 Paul Querna
[EMAIL PROTECTED] wrote:
So, there is no guaranteed binary compat for any module that defines
CORE_PRIVATE?
I would think that any module that #define's CORE_PRIVATE is on its own and
righly so. -- justin
--On Wednesday, February 9, 2005 10:47 AM +0100 Sander Striker
[EMAIL PROTECTED] wrote:
[...]
+/* RFC 2616 10.3.5 states that entity headers are not supposed
+ * to be in the 304 response. Therefore, we need to load in the
+ * cached headers before we update the cached
I'd like to see what we can do to minimize our need to always recompile
buildmark.c. Ideally, it should only need to be recompiled if httpd is
being relinked for some other reason - not every single time make is run.
One possibility might be to do something via the $(PROGRAM_NAME) target in
--On Tuesday, February 8, 2005 6:06 PM +0100 David Lichteblau
[EMAIL PROTECTED] wrote:
Thanks for your help! With these commits things work better, but then
something funny happens:
The cached response _body_ is delivered to the client just fine, but
together with the 304 response _header_ just
--On Tuesday, February 8, 2005 10:46 PM +0100 David Lichteblau
[EMAIL PROTECTED] wrote:
info-status at this point is zero, because file_cache_recall_mydata()
does not initialize it.
But setting it properly does not help either. The client gets the bogus
304 no matter what info-status is at this
On Mon, Feb 07, 2005 at 02:28:17PM +0100, Oden Eriksson wrote:
I meant if you unpack the tar ball, the root directory name is
httpd-2.0.53-rc1 and not httpd-2.0.53. Does that matter?
Ah, darn. I'll fix it before I make it public. -- justin
--On Monday, February 7, 2005 11:08 AM -0600 Jess Holle [EMAIL PROTECTED]
wrote:
It appears that 2.0.53 does not include the LDAP socket timeout
configuration patch.
Is this true?
If so, is there a 2.0.x-ready patch for this?
We'll be building 2.0.53 binaries shortly and I'm interested in this
--On Monday, February 7, 2005 1:50 PM -0500 Greg Ames
[EMAIL PROTECTED] wrote:
I'm working on it. log replay is not behaving at the moment but it looks
more like a client problem than a server problem. I'm tempted to just
switch production over but would feel better if my usual tests would
--On Monday, February 7, 2005 6:45 PM +0100 David Lichteblau
[EMAIL PROTECTED] wrote:
we are trying to use mod_proxy/mod_cache as a `reverse proxy' in front
of our webserver. In our configuration, we would like Apache to cache
all responses from our server, but revalidate them for every new
On Sun, Feb 06, 2005 at 09:39:47PM +0100, Oden Eriksson wrote:
I'd say +1, but I think I have no rights to vote. It seems to work just fine
on several Mandrakelinux 10.0 production boxes and also on Cooker.
Even if you aren't a committer, you can always cast a vote. Everyone's input
is
Tarballs for 2.0.53 are available and at:
http://www.apache.org/~jerenkrantz/httpd-2.0.53/
Once we receive 3 +1s (and no -1s, hopefully!), I'll move it over to the
mirrors. I then hope to be able to do the announcement and email some time
on Monday.
With httpd-test on Darwin, I get:
On Thu, Feb 03, 2005 at 09:06:04AM +0200, Graham Leggett wrote:
Justin Erenkrantz wrote:
I don't see any way to implement that cleanly and without lots of undue
complexity. Many dragons lay in that direction.
When I put together the initial framework of mod_cache, solving this
problem
On Thu, Feb 03, 2005 at 01:38:26PM -, [EMAIL PROTECTED] wrote:
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Thu Feb 3 05:38:24 2005
@@ -1,4 +1,3 @@
On Thu, Feb 03, 2005 at 07:43:48AM -0500, Jeff Trawick wrote:
which is not portable... z/OS doesn't have it, and I would assume
that z/OS isn't the only reason we've been dragging around PrintPath
all this time...
Yikes. Are there really other supported Unix's that don't have which?
what
On Thu, Feb 03, 2005 at 03:55:33PM +, Joe Orton wrote:
Yes, it might have side-effects like /etc/csh.login running yppasswd and
prompting on /dev/tty to change an expired NIS password ;) It's not safe
to use at all.
How exactly do we safely know if a program exists then? We can't execute
--On Thursday, February 3, 2005 8:17 AM -0500 Jeff Trawick
[EMAIL PROTECTED] wrote:
I am not aware of a reliable mechanism at present, but I would greatly
appreciate any hints.
If there is not an existing mechanism, I'd like to add something prior
to 2.2 APIs being cast in stone.
The local port
--On Thursday, February 3, 2005 11:31 PM + Max Bowsher [EMAIL PROTECTED]
wrote:
BugZilla link:
http://issues.apache.org/bugzilla/show_bug.cgi?id=29740
Applied in r151255. Thanks! -- justin
--On Friday, February 4, 2005 12:59 AM + Max Bowsher [EMAIL PROTECTED]
wrote:
Is it suitably small to be considered for 2.0.x backport?
I'm one step ahead of you - I already proposed it. =) It's unlikely that
it'll get two more votes by tomorrow morning when I start the 2.0.53
release
On Fri, Feb 04, 2005 at 02:38:47AM -, [EMAIL PROTECTED] wrote:
Author: jim
Date: Thu Feb 3 18:38:45 2005
New Revision: 151297
URL: http://svn.apache.org/viewcvs?view=revrev=151297
Log:
Merge in mod_dumpio
Thanks for merging it in! I didn't know exactly how to treat the Win32 and
On Thu, Feb 03, 2005 at 08:44:03AM +1100, dean wrote:
Im not sure where to find out the revision, but I checked out the src
from cvs just before my first post. I just did another update and
nothing has changed. Hope Im using the right command:
cvs checkout -d httpd-2.1 httpd-2.0
Oh. In
--On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski
[EMAIL PROTECTED] wrote:
Any reason why we don't enable reporting of Req? I have
a 2.1 patch ready to go, but I don't know why we don't
do this
I have no earthly idea what you are talking about. =)
Can you please provide some more
--On Wednesday, February 2, 2005 8:49 PM +0200 Graham Leggett
[EMAIL PROTECTED] wrote:
Mod_cache already supports the concept of spooling files to disk (or
memory, or shared memory), and can be taught how to serve an incompletely
downloaded file to other clients (apparently it cannot at the
--On Wednesday, February 2, 2005 11:38 PM +0200 Graham Leggett
[EMAIL PROTECTED] wrote:
If mod_cache was taught to serve a being-cached URL directly from the
cache (shadowing the real download), there would be no need for parallel
connections to the backend server while the file is being cached,
501 - 600 of 1873 matches
Mail list logo
