Bug 20945 - Mod_ext_filter mangles SSI
Summary: Mod_ext_filter mangles SSI
Status: RESOLVED DUPLICATE of bug 17629
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ext_filter (show other bugs)
Version: 2.0.46
Hardware: PC Linux
: P3 minor (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-20 10:32 UTC by Neil Fraser
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Neil Fraser 2003-06-20 10:32:52 UTC
The apache docs describe a trivial 'slowdown' filter here:
  http://httpd.apache.org/docs-2.0/mod/mod_ext_filter.html
This filter rearranges the order of SHTML includes.

When both mod_ext_filter and mod_includes target the same document,
mod_ext_filter is called once for each piece (which is very annoying, but that's
another bug).  If the shtml document is large, and the include is small, the
small include will be printed first, causing major errors in the resulting web page.
Comment 1 Jeff Trawick 2003-06-21 00:48:58 UTC
Regarding the scenario where the example "slowdown" filter breaks SSI: Please
submit a sample configuration that shows this problem so we can recreate/debug.
 Also, was anything written to the error log at the time?

I don't know what you mean by a problem with a filter being "called for each
piece" though.  mod_ext_filter will write data to the external filter as it
receives it, so if the content generator or another filter sends it down in
relatively small pieces, mod_ext_filter will write it to the external filter in
the same relatively small pieces.  The amount of data received by the external
filter in one piece is also limited by the amount of data the kernel will buffer
for a pipe.
Comment 2 Neil Fraser 2003-06-21 20:27:38 UTC
> Regarding the scenario where the example "slowdown"
> filter breaks SSI: Please submit a sample configuration
> that shows this problem so we can recreate/debug.

Ok:
1. Copy and paste the 'slowdown' filter from
  http://httpd.apache.org/docs-2.0/mod/mod_ext_filter.html
  (or any other filter, as far as I can tell)
2. Create the following SHTML file called test.shtml:
  <HTML><HEAD><TITLE>Title</TITLE></HEAD><BODY>
  <H1>Start</H1>
  <H3>[<!--#include virtual="sub"-->]</H3>
  <H1>End</H1>
  </BODY></HTML>
3. Create the following include file called sub.html:
  This is the include.

The catch (which stumped me for quite a while) is that the include statement is
looking for "sub", but the file is actually called "sub.html".  Apache fills in
the missing extention, but the presence of mod_ext_filter causes the include to
be printed before the <HTML> tag, not in the <H3>.  With the full extention
listed, the include is printed in the correct place.  This is 100% repeatable.

Downgrading this bug from 'Major' to 'Minor' now that I see that this only
affects server-side includes which have partially broken references.

> Also, was anything written to the error log at the time?

No, the error log is clean.

(I'll respond to part 2 of your comment as soon as I generate some supporting data.)
Comment 3 Neil Fraser 2003-06-21 20:52:02 UTC
> I don't know what you mean by a problem with a filter being
> "called for each piece" though.  mod_ext_filter will write data
> to the external filter as it receives it, so if the content
> generator or another filter sends it down in relatively small pieces,
> mod_ext_filter will write it to the external filter in the same
> relatively small pieces.  The amount of data received by the external
> filter in one piece is also limited by the amount of data the kernel
> will buffer for a pipe.

Tweak the slowdown filter so that it calls "cat -n" once on all files.  This
adds line numbers to Apache's output.  The config is:
  ExtFilterDefine slowdown mode=output cmd="/bin/cat -n" preservescontentlength
  <Location />
  SetOutputFilter slowdown
  </Location>

Next, view source on the test.shtml page as described above (though with the
include expanded to "sub.html" so that it works correctly).  The source looks
like this:

     1	<html><head><title>Title</title></head><body>
     2	<h1>Start</h1>
     3	<h3>[     1	This is the include.  <== NOTE THE "1" LINE NUMBER
     4	]</h3>
     5	<h1>End</h1>
     6	</body></html>

As you can see from the line numbers created by "cat -n", the filter was run
twice; once on each peice of the page.  Then the two peices were spliced
together my mod_include.  In bug 20946 I argue that the SSI splicing should
occur before the filter.  That way the filter would only be run once and would
be able to see the whole page in context.

I hope these two posts answer your questions.  Let me know if I can provide any
more information.
Comment 4 André Malo 2003-06-21 22:50:03 UTC
Do I understand you correctly, that if you use include virtual="sub.html" (full
name) then it works as expected? Then it's a dupe of Bug 17629 and has nothing
to do with mod_ext_filter or mod_include. It's a core design flaw (which still
has to be resolved ...)
Comment 5 Neil Fraser 2003-06-22 10:02:49 UTC
> Do I understand you correctly, that if you use include
> virtual="sub.html" (full name) then it works as expected?

Correct.  When I posted this bug, I thought it applied to all includes.  But
further investigation showed it only affects redirected includes.

> Then it's a dupe of Bug 17629 and has nothing to do with
> mod_ext_filter or mod_include. It's a core design flaw
> (which still has to be resolved ...)

Good catch!  Totally different symptoms of what looks like the same bug. 
Marking as duplicate.

*** This bug has been marked as a duplicate of 17629 ***