You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/04/12 03:53:27 UTC
PR 7966
C-L invalid when using SSI DirectoryIndex:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7966
We've got three people on Bugzilla who are seeing this bug. Is
anyone available to look at this? This seems related to the
issues that were being addressed right as we shipped. I wonder
if this snuck in or something. -- justin
Re: PR 7966
Posted by Greg Ames <gr...@remulak.net>.
Justin Erenkrantz wrote:
>
> C-L invalid when using SSI DirectoryIndex:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7966
>
> We've got three people on Bugzilla who are seeing this bug. Is
> anyone available to look at this? This seems related to the
> issues that were being addressed right as we shipped. I wonder
> if this snuck in or something. -- justin
hmmm, that puzzles me. I see very accurate C-L headers on normal SSIs (but
bogus Content-Range headers). I haven't tried SSIs on DirectoryIndexes, but
don't know why that should confuse it. There isn't a C-L header when I do
autoindexes.
Greg
[gregames@gandalf netcat]$ cat cyg.br0
HEAD /docs/cygwin.html HTTP/1.1
Host: httpd.apache.org
Range: bytes=0-
[gregames@gandalf netcat]$ nc apache.org 80 < cyg.br0
HTTP/1.1 206 Partial Content
Date: Fri, 12 Apr 2002 13:44:23 GMT
Server: Apache/2.0.35 (Unix)
Accept-Ranges: bytes
Content-Range: bytes 0-20418/20419
Content-Type: text/html
Content-Length: 20603
[gregames@daedalus docs]$ ls -l cygwin* header* footer*
-rw-r--r-- 1 rbowen httpd 20419 Oct 7 2001 cygwin.html
-rw-r--r-- 1 rbowen httpd 123 Oct 7 2001 footer.html
-rw-r--r-- 1 rbowen httpd 137 Oct 7 2001 header.html
the two #include virtual tags are 38 bytes long each.
Re: PR 7966
Posted by "Paul J. Reder" <re...@remulak.net>.
Um, mod_include *always* unsets the content length. What am I missing?
Ryan Bloom wrote:
>>From: Greg Marr [mailto:gregm@alum.wpi.edu]
>>
>>At 10:10 PM 04/11/2002, Ryan Bloom wrote:
>>
>>>>From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
>>>>On Thu, Apr 11, 2002 at 07:02:48PM -0700, Ryan Bloom wrote:
>>>>
>>>>>Dollars to Donuts, the problem is that the C-L filter isn't
>>>>>
>>>removing the
>>>
>>>>>C-L header from the request. I won't have time to look at this
>>>>>
>>>for a
>>>
>>>>>few weeks though.
>>>>>
>>>>The request? Don't you mean the file?
>>>>
>>>>Taking a quick look at default_handler:
>>>>
>>>>server/core.c line 3208:
>>>>ap_set_content_length(r, r->finfo.size);
>>>>
>>>>Isn't that call bogus? Why just not let the C-L filter handle it?
>>>>
>>>No, it isn't bogus. If the file isn't changed, then the call is
>>>correct. It is only bogus if the content is changed, as it is with
>>>SSI requests. If the C-L filter can't verify the C-L, it should be
>>>removing it from the request. If it doesn't, that is the bug.
>>>
>>Isn't the filter that changes the content responsible for removing
>>the C-L? Otherwise, the C-L filter would either remove the C-L every
>>time, or have to buffer the entire thing.
>>
>
> There are people who believe that the filter that modifies the content
> should be responsible for removing the C-L (I happen to be one of them),
> but that is not the current design.
>
> Ryan
>
>
>
>
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
RE: PR 7966
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Greg Marr [mailto:gregm@alum.wpi.edu]
>
> At 10:10 PM 04/11/2002, Ryan Bloom wrote:
> > > From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> > > On Thu, Apr 11, 2002 at 07:02:48PM -0700, Ryan Bloom wrote:
> > > > Dollars to Donuts, the problem is that the C-L filter isn't
> > removing the
> > > > C-L header from the request. I won't have time to look at this
> > for a
> > > > few weeks though.
> > >
> > > The request? Don't you mean the file?
> > >
> > > Taking a quick look at default_handler:
> > >
> > > server/core.c line 3208:
> > > ap_set_content_length(r, r->finfo.size);
> > >
> > > Isn't that call bogus? Why just not let the C-L filter handle it?
> >
> >No, it isn't bogus. If the file isn't changed, then the call is
> >correct. It is only bogus if the content is changed, as it is with
> >SSI requests. If the C-L filter can't verify the C-L, it should be
> >removing it from the request. If it doesn't, that is the bug.
>
> Isn't the filter that changes the content responsible for removing
> the C-L? Otherwise, the C-L filter would either remove the C-L every
> time, or have to buffer the entire thing.
There are people who believe that the filter that modifies the content
should be responsible for removing the C-L (I happen to be one of them),
but that is not the current design.
Ryan
RE: PR 7966
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 10:10 PM 04/11/2002, Ryan Bloom wrote:
> > From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> > On Thu, Apr 11, 2002 at 07:02:48PM -0700, Ryan Bloom wrote:
> > > Dollars to Donuts, the problem is that the C-L filter isn't
> removing the
> > > C-L header from the request. I won't have time to look at this
> for a
> > > few weeks though.
> >
> > The request? Don't you mean the file?
> >
> > Taking a quick look at default_handler:
> >
> > server/core.c line 3208:
> > ap_set_content_length(r, r->finfo.size);
> >
> > Isn't that call bogus? Why just not let the C-L filter handle it?
>
>No, it isn't bogus. If the file isn't changed, then the call is
>correct. It is only bogus if the content is changed, as it is with
>SSI requests. If the C-L filter can't verify the C-L, it should be
>removing it from the request. If it doesn't, that is the bug.
Isn't the filter that changes the content responsible for removing
the C-L? Otherwise, the C-L filter would either remove the C-L every
time, or have to buffer the entire thing.
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
RE: PR 7966
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
>
> On Thu, Apr 11, 2002 at 07:02:48PM -0700, Ryan Bloom wrote:
> > Dollars to Donuts, the problem is that the C-L filter isn't removing
the
> > C-L header from the request. I won't have time to look at this for
a
> > few weeks though.
>
> The request? Don't you mean the file?
>
> Taking a quick look at default_handler:
>
> server/core.c line 3208:
> ap_set_content_length(r, r->finfo.size);
>
> Isn't that call bogus? Why just not let the C-L filter handle it?
No, it isn't bogus. If the file isn't changed, then the call is
correct. It is only bogus if the content is changed, as it is with SSI
requests. If the C-L filter can't verify the C-L, it should be removing
it from the request. If it doesn't, that is the bug.
Ryan
Re: PR 7966
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Apr 11, 2002 at 07:02:48PM -0700, Ryan Bloom wrote:
> Dollars to Donuts, the problem is that the C-L filter isn't removing the
> C-L header from the request. I won't have time to look at this for a
> few weeks though.
The request? Don't you mean the file?
Taking a quick look at default_handler:
server/core.c line 3208:
ap_set_content_length(r, r->finfo.size);
Isn't that call bogus? Why just not let the C-L filter handle it?
-- justin
RE: PR 7966
Posted by Ryan Bloom <rb...@covalent.net>.
Dollars to Donuts, the problem is that the C-L filter isn't removing the
C-L header from the request. I won't have time to look at this for a
few weeks though.
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: Thursday, April 11, 2002 6:53 PM
> To: dev@httpd.apache.org
> Subject: PR 7966
>
> C-L invalid when using SSI DirectoryIndex:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7966
>
> We've got three people on Bugzilla who are seeing this bug. Is
> anyone available to look at this? This seems related to the
> issues that were being addressed right as we shipped. I wonder
> if this snuck in or something. -- justin
Re: PR 7966 C-L invalid when using SSI DirectoryIndex:
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:53 PM 4/11/2002, you wrote:
>C-L invalid when using SSI DirectoryIndex:
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7966
>
>We've got three people on Bugzilla who are seeing this bug. Is
>anyone available to look at this? This seems related to the
>issues that were being addressed right as we shipped. I wonder
>if this snuck in or something. -- justin
Perhaps this is the code change that causes redirects to update
all f->r members in the filter stack when the redirect is invoked.
I'll look tomorrow perhaps... after the CGI issues folks are reporting
are all fixed. But more likely I won't have time till next week. If anyone
wants to take a peek, keep an eye on the f->r member processed by
the HTTP_HEADER_FILTER.
Bill