On Tue, 2 Apr 2002, Doug MacEachern wrote:
this patch does not change anything that i can see, both the old version
and new do this:
The old version for me was giving a res-code of 200, not 500, because it
was sending the http request to port 8529, not 8530. Maybe it's related
to the version
On Tue, 2 Apr 2002, Cliff Woolley wrote:
The old version for me was giving a res-code of 200, not 500, because it
was sending the http request to port 8529, not 8530. Maybe it's related
to the version of LWP I'm using?
strange. i don't think it is lwp related. probably not worth spending
On 2 Apr 2002 [EMAIL PROTECTED] wrote:
jwoolley02/04/01 23:20:34
Modified:perl-framework/t/ssl http.t
Log:
Okay, well the test works now, but it still fails at the moment because
mod_ssl really is broken. :)
this patch does not change anything that i can see, both the old
If running in the foreground then ignore errors from apr_proc_detach()
(most likely setsid() failed because we're process group leader).
This is a simpler alternative to adding -DFOREGROUND and associated
apr_proc_detach() changes.
Index: server/mpm/prefork/prefork.c
+0.5
This is ok but I like -DFOREGROUND better. :) The reason I like it
is because I still want it to be a fatal error if setsid() failed
and they intended to run httpd under daemontools or the like.
-aaron
On Tue, Apr 02, 2002 at 10:28:22AM -0500, Jeff Trawick wrote:
If running in the
the test started failing at some point due to filter changes. i think i
heard it is not longer possible for a filter to remove itself? in any
case, mod_ssl already checks in the output filter already passes if its
ssl pointer is NULL (normally due to error). the input filter should
the test started failing at some point due to filter changes. i think
i
heard it is not longer possible for a filter to remove itself? in any
It is perfectly possible for a filter to remove itself. In fact, the
byterange filter relies on that ability to work correctly. While I
would be
On Tue, 2 Apr 2002, Ryan Bloom wrote:
It is perfectly possible for a filter to remove itself. In fact, the
byterange filter relies on that ability to work correctly. While I
would be interested to know what happened to make that case fail, if the
patch below works, then +1.
i was thinking
On Tue, 2 Apr 2002, Ryan Bloom wrote:
It is perfectly possible for a filter to remove itself. In fact,
the
byterange filter relies on that ability to work correctly. While I
would be interested to know what happened to make that case fail, if
the
patch below works, then +1.
i was
On Tue, 2 Apr 2002, Ryan Bloom wrote:
Nope, I fixed this. The problem was that we couldn't remove the first
filter in any of the three lists, because the previous filter structure
wouldn't be updated. The solution was to walk the filter list each time
we tried to remove a filter. This
Nope, I fixed this. The problem was that we couldn't remove the
first
filter in any of the three lists, because the previous filter
structure
wouldn't be updated. The solution was to walk the filter list each
time
we tried to remove a filter. This allows us to find the correct
filter
At 08:48 AM 4/2/2002, you wrote:
stoddard02/04/02 06:48:54
Modified:server/mpm/winnt mpm_winnt.c
Log:
Win32: tweak some messages
Revision ChangesPath
1.255 +2 -2 httpd-2.0/server/mpm/winnt/mpm_winnt.c
The NOTICE level reversion and message tweaks will
At 11:04 AM 4/2/2002, Ryan wrote:
there is still a problem. ssl is removed from c-output_filters, but
not
r-output_filters. mod_ssl does not have access to r-output_filters.
Damn. I thought I had fixed that. You're right though, I couldn't fix
that. The only solution looks to be
Hi all!
I´m having a little problem with server-status that it´s returning
me
forbidden every time i try it. Below you can see my configuration in
httpd.conf, and the error returned in the logs.
Location /server-status
SetHandler server-status
Order deny,allow
Deny
This looks really arcane to me though - there are very few HTTP/0.9
servers out there that I am aware of to start with, adding functionality
to specifically not support them seems like software bloat to me.
Is this a real problem in your installation?
This is really a problem of
Greg Ames [EMAIL PROTECTED] writes:
I noticed something weird on daedalus on the test build. It looks like we're
not autoindexing directories with HEADER.html or README.html files correctly.
You see the contents of HEADER.html and/or README.html, but not the other files
or subdirs in the
Jeff Trawick [EMAIL PROTECTED] writes:
Greg Ames [EMAIL PROTECTED] writes:
I noticed something weird on daedalus on the test build. It looks like we're
not autoindexing directories with HEADER.html or README.html files correctly.
You see the contents of HEADER.html and/or README.html,
Greg Ames wrote:
I noticed something weird on daedalus on the test build. It looks like we're
not autoindexing directories with HEADER.html or README.html files correctly.
You see the contents of HEADER.html and/or README.html, but not the other files
or subdirs in the directory. Often,
On Tue, Apr 02, 2002 at 04:28:31PM -0500, Jeff Trawick wrote:
maybe this helps... haven't tested yet
I believe we took that out specifically to ensure that any
requests that may be promoted to a real request do not have
the subreq filter. IIRC, if the subreq is being created with
a NULL parent
In handle_autoindex, we are working on the main request upon entry.
r-output_filters looks like:
old_write
byterange
content_length
http_header
core
When it sees that HEADER.html exists, it apparently fires off a
subrequest
(can't say for sure, I hit n in gdb rather than s at the
Jeff Trawick wrote:
Here's a backtrace while processing /dist/httpd/. Where is the
subrequest filter?
maybe this helps... haven't tested yet
Index: request.c
yep, this solves about half of the problem. With this on, I now see all the
data, it's just in the wrong order. I see the
Jeff Trawick wrote:
Here's a backtrace while processing /dist/httpd/. Where is the
subrequest filter?
maybe this helps... haven't tested yet
Index: request.c
yep, this solves about half of the problem. With this on, I now see
all
the
data, it's just in the wrong order.
Greg Ames wrote:
Jeff Trawick wrote:
Here's a backtrace while processing /dist/httpd/. Where is the
subrequest filter?
maybe this helps... haven't tested yet
Index: request.c
yep, this solves about half of the problem. With this on, I now see all the
data, it's just in
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Greg Ames
Sent: Tuesday, April 02, 2002 2:35 PM
To: [EMAIL PROTECTED]
Subject: Re: 2.0.34 - erratic behavior with autoindexes
Greg Ames wrote:
Jeff Trawick wrote:
Here's a backtrace while
On Tue, Apr 02, 2002 at 01:50:59PM -0800, Ryan Bloom wrote:
...
chain. Bill S. stuck his head in here and said something about a rule
that if old_write is ever used, it has to always be used.
If you read through mod_include, you will see that whenever we create a
sub-request, we send the
On Tue, Apr 02, 2002 at 02:27:17PM -0800, Ryan Bloom wrote:
...
So it looks like we have to do something about flushing the data that
old_write is hanging on to. I'd rather see the core figure out how to
do this, rather than mod_autoindex. Otherwise we are going to impact
1.3 modules
Everything below is true, assuming you are not talking about
sub-requests. According to the stack that Greg posted, the OLD_WRITE
filter was not found in the sub-request filter stack. That is to be
expected, because the OLD_WRITE filter is a RESOURCE filter. Since
RESOURCE filters are not
if the following tags in modules/ssl could be pushed:
/ssl_engine_config.c/1.66/Tue Apr 2 21:49:09 2002//
/ssl_engine_init.c/1.94/Tue Apr 2 21:46:22 2002//
/ssl_util_ssl.c/1.20/Tue Apr 2 22:04:16 2002//
minor fixes to get SSLProxyMachineCertificatePath working.
The core can't do anything about it. If you are creating a
sub-request,
you must flush the data.
Bing!
ANY filter inserted by the subreq could be holding content. The
subrequest
definitely MUST flush out its filter stack before going away.
Yes, old_write buffers, and if that is
Ryan Bloom wrote:
Did you try just http://httpd.apache.org:8092?
not until now. Thanks for the extra eyeballs.
It looks like that patch completely broke DirectoryIndex pages.
It's definitely hosed. But you and Justin both said something about subrequests
which get promoted. That's a
On Tue, Apr 02, 2002 at 02:56:33PM -0800, Ryan Bloom wrote:
Everything below is true, assuming you are not talking about
sub-requests. According to the stack that Greg posted, the OLD_WRITE
filter was not found in the sub-request filter stack. That is to be
expected, because the OLD_WRITE
The core can't do anything about it. If you are creating a
sub-request,
you must flush the data.
Bing!
ANY filter inserted by the subreq could be holding content. The
subrequest
definitely MUST flush out its filter stack before going away.
Yes, old_write buffers,
On Tue, Apr 02, 2002 at 03:30:07PM -0800, Ryan Bloom wrote:
...
We are talking about the main request flushing its
buffers before it runs the request.
Um. How'd the buffers get filled before running the request?
The problem is that the main request generates content, and that goes
We are talking about the main request flushing its
buffers before it runs the request.
Um. How'd the buffers get filled before running the request?
The problem is that the main request generates content, and that
goes
into the OLD_WRITE filter buffer. Then it creates a
At 05:17 PM 4/2/2002, you wrote:
Here are the revision numbers:
apr/build/apr_hints.m4, revision 1.39
apr/locks/unix/proc_mutex.c, revision 1.13
Now adopted by APACHE_2_0_34; thanks!
At 04:57 PM 4/2/2002, you wrote:
if the following tags in modules/ssl could be pushed:
/ssl_engine_config.c/1.66/Tue Apr 2 21:49:09 2002//
/ssl_engine_init.c/1.94/Tue Apr 2 21:46:22 2002//
/ssl_util_ssl.c/1.20/Tue Apr 2 22:04:16 2002//
minor fixes to get SSLProxyMachineCertificatePath
The core can't do anything about it. If you are creating a
sub-request,
you must flush the data. We could have the core always flush, but
that
would cause us to send flush buckets before any data has been
generated,
or in cases where a flush is not required. The module MUST be the
thing
this is not quite fixed. currently does return 400 Bad Request, but
reports:
Your browser sent a request that this server could not understand.
Request header field is missing colon separator.
with the patch below it properly reports:
Your browser sent a request that this server could not
Okay, I have had more time to investigate the problem. This is kind of
strange. First of all, I have included a patch with this post that is
absolutely 100% wrong. The only purpose of the patch is to show the
problem, and hopefully prove that I have isolated the problem correctly.
I wasn't
On Tue, 2 Apr 2002, Doug MacEachern wrote:
apr_bucket_immortal_create(HTTP_ON_HTTPS_PORT, \
- sizeof(HTTP_ON_HTTPS_PORT) - 1, \
+ sizeof(HTTP_ON_HTTPS_PORT), \
Mmmm... no. I don't know how that makes it work its way through,
On Tue, 2 Apr 2002, William A. Rowe, Jr. wrote:
minor fixes to get SSLProxyMachineCertificatePath working.
are now incorporated in the APACHE_2_0_34 tag... anyone interested
in testing SSL, feel free to cvs up -r APACHE_2_0_34
+1 ... works for me. I tested as much of the proxy stuff as I
41 matches
Mail list logo
