Per your request, here is a -d lwp=2 trace of the negotiation
tests from httpd-2.0 HEAD. Enjoy. =) Please let me know if
there's anything else I can do. -- justin
modules/negotiation.1..98
GET http://localhost.localdomain:8529/modules/negotiation/en/:
User-Agent: libwww-perl/5.63
HTTP/1.1
On Sun, Feb 03, 2002 at 03:19:41AM -, [EMAIL PROTECTED] wrote:
jwoolley02/02/02 19:19:41
Modified:.STATUS
Log:
I was leaning toward the configurable flavor, but OtherBill convinced me
we should be more concerned with keeping the parent rock solid than adding
Greg Stein [EMAIL PROTECTED] writes:
On Sun, Feb 03, 2002 at 03:19:41AM -, [EMAIL PROTECTED] wrote:
jwoolley02/02/02 19:19:41
Modified:.STATUS
Log:
I was leaning toward the configurable flavor, but OtherBill convinced me
we should be more concerned with
[EMAIL PROTECTED] writes:
stoddard02/02/02 22:24:55
Modified:modules/experimental cache_storage.c cache_util.c
mod_cache.c mod_cache.h mod_mem_cache.c
Log:
Support files for mod_disk_cache. Some tweaks to arguments on various hook
calls. Still lots
William A. Rowe, Jr. wrote:
It would be rather cool, however, to have and index.html
and full.html in one place, and not rely on QUERY_STRING
so much.
*shrug* Go ahead and break it apart -- but only if you
personally commit to keep all the pieces in sync, and easily
accessible/printable
William A. Rowe, Jr. wrote:
++1... this shouldn't be a huge hangup. But Josh has a point...
What is the resistance to bumping? It seems to me that we're
back to that -- a meaningless effort to keep the numbers from
incrementing. The conclusion drawn a while ago (thanks to Roy's
clewbat)
Ryan Bloom wrote:
Yes, at this point, we have announced the tarball, and we can't replace
it again. However, at the time, the tarball was just being discussed on
the development list, and it hadn't been officially announced as a beta
candidate, so replacing it was fine to do.
I disagree.
On Sun, Feb 03, 2002 at 10:15:51AM -0500, Rodent of Unusual Size wrote:
I disagree. Once the tarball has been created the number cannot
be used again. Too many eyes watch this list and the site and
siphon off tarballs as soon as they're created (much less
announced).
Part of that was
From: Zvi Har'El [mailto:[EMAIL PROTECTED]]
RedHat uses suexec by default, and this could be the reason. But I don't
really see why HTTPS=on is less safer then all the SSL_
variables. For me it is
a method to decide if my script should redirect to HTTP or HTTPS
URL's, and
there is no
Ryan Bloom wrote:
Yes, at this point, we have announced the tarball, and we can't replace
it again. However, at the time, the tarball was just being discussed on
the development list, and it hadn't been officially announced as a beta
candidate, so replacing it was fine to do.
Ryan Bloom wrote:
My point is that I disagree with that. We have been bumping tags on
files when releasing 2.0 since 2.0.16, and we aren't even talking about
bumping a tag here. We are just talking about rolling the tarball on a
different machine than was originally used. The code didn't
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
Ian was hesitant to bump to 2.0.32 because he was under the
impression that it was not permitted to bump so close to a previous
tag. He was the RM, so it was his call.
This argument has been had befor (ad naseum), but...
This is based on
Hi,
I agree with Joshua completely that the conditioning on mod_ssl is not
necessary. However, comparing with the apache 1.3 version of suexec.c, and the
fact that in 2.0 ssl_engine_kernel.c (line 1035) still sets the SSI/CGI
environment variable HTTPS=on , I would recommand to have a triple
...in /usr/local/apache2_0_31/corefiles/httpd.core.1
#0 0x2815c990 in kill () from /usr/lib/libc.so.4
#1 0x28198a7e in abort () from /usr/lib/libc.so.4
#2 0x806836e in ap_log_assert (szExp=0x8082359 totalread 0,
szFile=0x8082284 http_protocol.c, nLine=664) at log.c:586
#3 0x805ed10 in
On Sun, Feb 03, 2002 at 09:40:31AM -0800, Justin Erenkrantz wrote:
Oh, no. That assert should be = 0. I wanted to limit -1 brigades
not 0-length ones. *sigh*
I hate asserts. I don't even know why I put it in there. This is
exactly why it is a bad idea to have debug asserts change
On Sun, 3 Feb 2002, Justin Erenkrantz wrote:
I hate asserts. I don't even know why I put it in there. This is
exactly why it is a bad idea to have debug asserts change code.
Seriously.
How about rolling .32 as the same as .31 with that line changed?
(Could you make this change on
On Sun, Feb 03, 2002 at 01:28:44PM -0500, Cliff Woolley wrote:
How about rolling .32 as the same as .31 with that line changed?
(Could you make this change on daedalus - that should fix it.)
Well, it's an AP_DEBUG_ASSERT, so it only breaks in maintainer mode,
right? So IMO it's not worth
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
Ian was hesitant to bump to 2.0.32 because he was under the
impression that it was not permitted to bump so close to a previous
tag. He was the RM, so it was his call.
This argument has been had befor (ad naseum), but...
This is
Cliff Woolley wrote:
On Sun, 3 Feb 2002, Justin Erenkrantz wrote:
I hate asserts. I don't even know why I put it in there. This is
exactly why it is a bad idea to have debug asserts change code.
Seriously.
...but if totalread had been -1?
How about rolling .32 as the same as
According to Joshua Slive:
I'm not sure why Ralf did it that way. It seems that HTTPS should simply
be added to the safe list near the top of the file. The revised patch is
below.
+1
ciao...
--
Lars Eilebrecht- Cyberspace: ...the most potent technology
[EMAIL PROTECTED]
On Sun, 3 Feb 2002, Ian Holsman wrote:
While I'm not on the showstopper bandwagon, I'm wondering what the
chances are of getting some packaging issues* handled in a 2.0.32
before somebody destabilizes the codebase.
I was thinking about this. seeing how noone likes the idea of retagging
Sure, here is what I do to get php to compile from square zero:
rm -rf php4
cvs co php4
cd php4
cvs co Zend TSRM
./buildconf
./configure \
--with-apxs2=/usr/local/apache2/bin/apxs \
LDFLAGS=-L/usr/X11R6/lib -L/usr/local/lib -L/usr/local/ssl/lib \
CFLAGS=$CFLAGS -pipe -g -I/usr/local/include
On Sun, Feb 03, 2002 at 05:18:19PM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/02/03 09:18:19
Modified:modules/proxy proxy_ftp.c
Log:
Make sure we include time.h if it is there. (Other mojo may be needed for
other platforms.)
Should that code even be using time.h? If it
Ryan Bloom wrote:
Not long after the current tag/roll procedure was developed, we had this
same situation, and Roy himself agreed that rolling more than once a
week discouraged people from testing the tarballs.
Not sure what this Roy himself comment means... like it's some sort
of Voice
Cliff Woolley wrote:
Well, it's an AP_DEBUG_ASSERT, so it only breaks in maintainer mode,
right? So IMO it's not worth a rerelease just for that. If you're
willing to run in maintainer mode, it means you're willing to deal with
this sort of thing. Post a patch in the release notes, and
From: Jim Jagielski [mailto:[EMAIL PROTECTED]]
Ryan Bloom wrote:
Not long after the current tag/roll procedure was developed, we had
this
same situation, and Roy himself agreed that rolling more than once a
week discouraged people from testing the tarballs.
Not sure what this Roy
I've been using PHP 4.1.1 and things seem to be okay for me (on HPUX).. I'm
using PHP 4.1.1 with the following configure command :
configure --prefix=/opt/apache2/modules \
--enable-so --with-apache=/opt/apache2
--with-apxs2=/opt/apache2/bin/apxs
-Madhu
-Original Message-
From:
just a reminder. there were a couple of displays of interest in these
patches any comments?
sterling
On Thu, 31 Jan 2002 [EMAIL PROTECTED] wrote:
On Thu, 31 Jan 2002, William A. Rowe, Jr. wrote:
+1 ... offer patches !-)
okay... you and justin asked for it :) attached is a patch
I lost a machine today due to a fscked up flash update utility.
You are warned :)
From: Rodent of Unusual Size [EMAIL PROTECTED]
Sent: Sunday, February 03, 2002 9:10 AM
William A. Rowe, Jr. wrote:
It would be rather cool, however, to have and index.html
and full.html in one place, and
From: Ryan Bloom [EMAIL PROTECTED]
Sent: Sunday, February 03, 2002 1:12 PM
No that isn't what this is based on. It is based on the fact that
tagging the tree with two different versions within two days discourages
people from testing. If I roll a release every few days, why should
anybody
30 matches
Mail list logo