httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the DocumentRoot (e.g.,
flood STATUS: -*-text-*-
Last modified at [$Date: 2002/01/17 01:09:45 $]
Release:
milestone-04: In development
milestone-03: Tagged January 16, 2002
ASF-transfer: Released July 17, 2001
milestone-02: Tagged August 13, 2001
On Thu, May 30, 2002 at 07:34:00AM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/05/30 00:34:00
Modified:.CHANGES
modules/proxy mod_proxy.c proxy_http.c
Log:
Switch mod_proxy to using the brigade/filter calls directly rather than
the *_client_block
On Thu, May 30, 2002 at 11:03:05AM +0530, Vinod Panicker wrote:
I need the actual socket that apache uses to communicate with the client
in the php module. Is it available somewhere in the request_rec
structure?
You've already found it in r-connection-client-fd.
Tony.
--
f.a.n.finch
From: Tony Finch [mailto:[EMAIL PROTECTED]]On Behalf Of 'Tony
Finch'
Sent: 30 May 2002 11:01
On Thu, May 30, 2002 at 11:03:05AM +0530, Vinod Panicker wrote:
I need the actual socket that apache uses to communicate with the client
in the php module. Is it available somewhere in the
I feel like kicking myself! Forgot all that I had learnt abt sockets!
What I actually wanted was the ability to use the socket from another
process. I obviously cant do that in this case since the socket that
has been opened is local to the process (DUH!)
Now I want to pass this socket to
* Sander Striker ([EMAIL PROTECTED]) wrote :
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
Sent: 30 May 2002 02:41
[...]
Log:
Catch up with the apr_allocator_set_owner - apr_allocator_owner_set renames
in APR.
This requires an MMN bump (which is fine with me, since
On Thu, May 30, 2002 at 05:57:33AM -, [EMAIL PROTECTED] wrote:
jwoolley02/05/29 22:57:33
Modified:include ap_mmn.h
Log:
Imagine the horror. I go to try compiling PHP4, and it bombs out on
r-boundary. BUT WAIT, I say, we have a test in there for that:
#if
Martin Kraemer wrote:
About the X-Forwarded-* stuff: It's non-standard anyway (you can add
any X-whatever header and still be RFC2616 compliant) so I'd rather
not see it in 1.3 now (maybe in the next release ;-)
I've seen proxies like squid hang because of nonstandard headers
Jeff Trawick [EMAIL PROTECTED] writes:
okay, do try it, but (unlike somebody last night) don't try it on daedalus
GET / HTTP/1.1
Accept: */*
Host: test
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
AAA
Is this test (with cr-lf added where
I'm running Apache 2.0.36-dev on Win2K, with SSL enabled. Most clients
are Win2K systems using either Netscape 6.x, IE5.5 or Mozilla RC1, and
they connect and browse without problems.
One client is a Mac OS X using IE5.0. It is constantly receiving 'Data
Encryption Errors'. On pages where
Justin Erenkrantz wrote:
On Thu, May 30, 2002 at 07:34:00AM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/05/30 00:34:00
Modified:.CHANGES
modules/proxy mod_proxy.c proxy_http.c
Log:
Switch mod_proxy to using the brigade/filter calls directly
A small wish from the field:
Will Justin's stuff be included with the RC3 of 2.0.37?
--
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.:
Jeff Trawick [EMAIL PROTECTED] writes:
Jeff Trawick [EMAIL PROTECTED] writes:
okay, do try it, but (unlike somebody last night) don't try it on daedalus
GET / HTTP/1.1
Accept: */*
Host: test
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
On Thu, May 30, 2002 at 03:00:21PM +0530, Vinod Panicker wrote:
I feel like kicking myself! Forgot all that I had learnt abt sockets!
What I actually wanted was the ability to use the socket from another
process. I obviously cant do that in this case since the socket that
has been opened
On Thu, 2002-05-30 at 01:23, Justin Erenkrantz wrote:
- As a side effect, a lot of 8k static buffer allocations have
been removed. (I can hear the Netware guys cheering from here.)
- This should also greatly reduce the number of copies that the
input data should have to go through as it
At 01:07 AM 5/30/2002, you wrote:
On Thu, 30 May 2002, William A. Rowe, Jr. wrote:
is modules/ssl/README even valuable anymore?
yes. fine to remove the stale stuff, but not the whole damn thing. there
was a useful roadmap of the source in there ...
Then I'll ask a simple question before I
Which module would be a good example for someone who wants to rewrite an
existing
ap_*_client_block
based module?
Tks
Brian Pane wrote:
On Thu, 2002-05-30 at 01:23, Justin Erenkrantz wrote:
- As a side effect, a lot of 8k static buffer allocations have
been removed. (I can hear the
On Thu, May 30, 2002 at 10:43:54AM -0500, William A. Rowe, Jr. wrote:
Then I'll ask a simple question before I resurrect ... Do we want individual
READMEs or LAYOUTs that describe all the files throughout each Apache
source tree directory, only one top-level LAYOUT that describes the entire
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
Sent: 30 May 2002 18:38
On Thu, May 30, 2002 at 10:43:54AM -0500, William A. Rowe, Jr. wrote:
Then I'll ask a simple question before I resurrect ... Do we want individual
READMEs or LAYOUTs that describe all the files throughout each
jerenkrantz02/05/29 22:42:46
Modified:modules/generators mod_cgid.c
Log:
Apply same patch to mod_cgid that was applied to mod_cgi so that it
bypasses the *_client_block calls in favor of using the input filters
and brigades directly.
Revision ChangesPath
On Thu, May 30, 2002 at 12:54:39PM -0400, Bill Stoddard wrote:
The above section of code looks like a potential endless loop if the brigade does not
contain an EOS bucket. Should the check for child_stopped_reading occur after the
apr_bucket_read below?
An EOS should be returned at some point
i see value the old modules/ssl/README. it has been very handy in the
past, and i would expect it to be for anybody coming from mod_ssl 1.3
based sources to contribute to 2.0 or even just being brand new to the 2.0
source. now they have lost the source roadmap, summary of major changes,
On Thu, 30 May 2002, Eli Marmor wrote:
A small wish from the field:
Will Justin's stuff be included with the RC3 of 2.0.37?
I'm still procrastinating on tagging RC2. Most of Justin's stuff is
already in, but I'm considering backing it out and waiting until RC3 since
some questions have
At 12:02 PM 5/30/2002, you wrote:
i see value the old modules/ssl/README. it has been very handy in the
past, and i would expect it to be for anybody coming from mod_ssl 1.3
based sources to contribute to 2.0 or even just being brand new to the 2.0
source. now they have lost the source roadmap,
On Thu, 30 May 2002, William A. Rowe, Jr. wrote:
Perhaps we could resurrect the porting history [although I believe it's
horribly
incomplete] as modules/ssl/HISTORY? OTOH, those parts that are correct
aught to have been committed to CHANGES if they were not in the first place.
they are in
On Thu, May 30, 2002 at 08:20:30PM -, [EMAIL PROTECTED] wrote:
+ 2) edit the path to LIBTOOL in config_vars.mk to reflect the
+ place where it was actually installed
In this case, I think it would be best if it used apr-config's
--apr-libtool option.
%
On Thu, May 30, 2002 at 11:02:09AM -0400, Jeff Trawick wrote:
Running HEAD, we get a segfault when the bogus request is for a
resource for which we aren't authorized. Here is the traceback:
Oh, that's not good. Something broke after I initially fixed it.
I'm trying to chase down what
On Thu, May 30, 2002 at 01:33:45PM -0700, Justin Erenkrantz wrote:
On Thu, May 30, 2002 at 11:02:09AM -0400, Jeff Trawick wrote:
Running HEAD, we get a segfault when the bogus request is for a
resource for which we aren't authorized. Here is the traceback:
Oh, that's not good. Something
Hi,
just reposting this patch.
Cheers,
-Thom
--
Thom May - [EMAIL PROTECTED]
Gman hum, I wonder if the cargo bar is looking for staff?
thom gman: cargo bar sydney has an insane staff turn over rate :)
jdub yeah, for turning over in the morning and seeing what you've woken up with.
hadess jdub
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
On Thu, May 30, 2002 at 02:43:05PM -0700, Ryan Bloom wrote:
This doesn't fix the underlying problem. Mod_bucketeer needs to be
smart enough to copy buckets if it doesn't recognize their type. If
the
bucket can't be copied, then the
On Thu, 30 May 2002, Justin Erenkrantz wrote:
The fact here is that not all buckets can be read such as EOS,
flush, and error.
Sure they can. They just contain zero data bytes.
Perhaps these buckets should return an error
if they are read? Then, if a filter sees APR_ENOTIMPL, it can
On Thu, 30 May 2002, Ryan Bloom wrote:
True, but I thought part of the idea behind buckets is so that the
backing type doesn't have to be known.
Exactly!
Exactly. All you really need to test here is length. If the bucket is
zero bytes, that's all you need to know. That gets you all
On Thu, May 30, 2002 at 05:50:45PM -0400, Cliff Woolley wrote:
On Thu, 30 May 2002, Justin Erenkrantz wrote:
The fact here is that not all buckets can be read such as EOS,
flush, and error.
Sure they can. They just contain zero data bytes.
Right, but the problem is how are these
Every bucket can be read. That is a mandatory function that all
buckets
must implement. If the back-end bucket-type isn't know, the filter
can
ALWAYS do a read/apr_bucket_make_heap.
True. Though we've specified the additional semantics that
apr_bucket_read() causes the bucket to
On Thu, 30 May 2002, Ryan Bloom wrote:
I didn't think it _had_ to auto-morph. My understanding is that the
default buckets do, because we assume the performance will be better if
they do. That makes sense, because a file_bucket is likely to be read
multiple times, so it makes sense to
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
On Thu, May 30, 2002 at 05:50:45PM -0400, Cliff Woolley wrote:
On Thu, 30 May 2002, Justin Erenkrantz wrote:
The fact here is that not all buckets can be read such as EOS,
flush, and error.
Sure they can. They just contain zero
On 30 May 2002 [EMAIL PROTECTED] wrote:
jwoolley02/05/30 15:39:08
Modified:modules/ssl ssl_engine_pphrase.c
Log:
This definitely gets the award for least useful error message of the month.
Index: ssl_engine_pphrase.c
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
On Thu, 30 May 2002, Ryan Bloom wrote:
I didn't think it _had_ to auto-morph. My understanding is that the
default buckets do, because we assume the performance will be better
if
they do. That makes sense, because a file_bucket is
On Thu, 30 May 2002, Ryan Bloom wrote:
Agreed, but I can think of one case. (a bit of hand-waving, but a
possibility, nonetheless) :-) If I write two filters that work in
tandem to solve a problem, I may want to use a special bucket type to
facilitate them working together.
Fair enough.
On 30 May 2002 [EMAIL PROTECTED] wrote:
+
+* 413 (invalid chunk size) followed by another request segfaults.
+ Message-ID: [EMAIL PROTECTED]
+ Status: Justin is completely confounded by this. It looks like a
+ bucket lifetime bug, but somehow an
On Sun, May 26, 2002 at 11:24:49AM -0700, Brian Pane wrote:
...
I didn't yet cast a vote. So,
-0 for including the pool fix in 2.0.37
+1 for including it in 2.0.38.
Note: the real procedure here is that Sander gets to just check the stuff in
whenever he would like. (which, I believe he
On Thu, May 30, 2002 at 07:26:02PM -0400, Cliff Woolley wrote:
On 30 May 2002 [EMAIL PROTECTED] wrote:
+
+* 413 (invalid chunk size) followed by another request segfaults.
+ Message-ID: [EMAIL PROTECTED]
+ Status: Justin is completely confounded by this. It looks
On Thu, 30 May 2002, Greg Stein wrote:
Personally, I'm finding that it seems we're getting back to the old, slow
it takes a lot of pain to make a release process. Rather than a nice,
easy, snap and release. Remember: even though we're GA, we can still snap
new releases, test them, and *then*
On Wed, May 29, 2002 at 08:40:55PM -0400, Cliff Woolley wrote:
On 30 May 2002 [EMAIL PROTECTED] wrote:
striker 02/05/29 17:21:27
Modified:server/mpm/beos beos.c
server/mpm/experimental/leader leader.c
server/mpm/experimental/threadpool
On Thu, May 30, 2002 at 11:17:23PM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/05/30 16:17:23
Modified:.STATUS
Log:
showstoppers++; (groan)
...
RELEASE SHOWSTOPPERS:
+
+* 413 (invalid chunk size) followed by another request segfaults.
+
On Thu, May 30, 2002 at 11:02:09AM -0400, Jeff Trawick wrote:
Running HEAD, we get a segfault when the bogus request is for a
resource for which we aren't authorized. Here is the traceback:
In particular, this problem is related to the fact that we have
two errors on this request: 401 and
On Thu, May 30, 2002 at 11:17:23PM -, Justin Erenkrantz wrote:
+* 413 (invalid chunk size) followed by another request segfaults.
+ Message-ID: [EMAIL PROTECTED]
+ Status: Justin is completely confounded by this. It looks like a
+ bucket lifetime bug,
On Thu, May 30, 2002 at 05:29:26PM -0700, Justin Erenkrantz wrote:
Per my earlier message, I believe this is the wrong way to do this.
If we get a neg chunk length, we shouldn't *ever* get back into
ap_http_filter (HTTP_IN). The whole point of the 413 error is
that we refuse to read the
On Thu, May 30, 2002 at 11:17:23PM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/05/30 16:17:23
Modified:.STATUS
Log:
showstoppers++; (groan)
...
RELEASE SHOWSTOPPERS:
+
+* 413 (invalid chunk size) followed by another request segfaults.
+
Hi Ronald,
Let me preface this by noting that I agree with your goals, however I
believe that you may not have considered the nature of the problem in
sufficient depth.
On Thu, May 30, 2002 at 07:45:42PM -0700, Ronald F. Guilmette wrote:
Most sites and web hosting companies _do_ want to
At 09:45 PM 5/30/2002, you wrote:
I am directing this message to the developer's list because I strongly
suspect that it may require some new development.
...
The first step in finding all such scripts however may often be the most
difficult one. That first step consists of simply gathering
On Thu, May 30, 2002 at 09:49:26PM -0400, Bill Stoddard wrote:
And all that child's threads? If we are voting, I vote this is a showstopper. A
segfaulting process can leave an awful lot of cruft laying around.
I would tend to agree, but as far as I know the segv has been fixed (and
the other
53 matches
Mail list logo
