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
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
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
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
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, the Mozilla animation
At 04:39 PM 4/1/2002, you 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
22 matches
Mail list logo
