Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t

2004-10-28 Thread Cliff Woolley
On Thu, 28 Oct 2004, Geoffrey Young wrote:

 I get the following failures on 1.3.32 but not on 1.3.33.

 t/modules/rewrite.t  222   9.09%  18 20
 t/security/CAN-2004-0940.t11 100.00%  1
 t/security/CAN-2004-0958.t92  22.22%  1 3

 I think these are all recent additions from you.  should each of these
 failures be skipped unless something like

   ( have_apache(1)  have_min_apache_version(1.3.33) ) ||
   ( have_apache(2)  have_min_apache_version(2.0.XX) )

I don't think so -- it's detecting an actual legitimate failure.  It's not
that the test requires a new version to work right, it's that that
particular version was broken.  No sense obfuscating that fact.

--Cliff


Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes

2004-04-05 Thread Cliff Woolley
On Mon, 5 Apr 2004 [EMAIL PROTECTED] wrote:

 stas2004/04/04 21:35:21

   Modified:perl-framework/Apache-Test/lib/Apache TestRun.pm
 TestConfig.pm
perl-framework/Apache-Test Changes
   Log:
   Don't try to set ulimit unlimited for coredumps on Solaris, unless run
   as root
   Submitted by:   Rob Kinyon [EMAIL PROTECTED]

Um, wait, why is this?  I have ulimit -c unlimited in my non-root-user
.bashrc on Solaris 8 and it works fine (it worked on other versions as
well).

The only time it won't let you set it as a normal user that I was aware of
was when the system-wide login script has it set to something less than
unlimited explicitly ... a normal user can decrease the limit but not
increase it.

--Cliff


Re: apr_psprintf thread safe?

2004-01-09 Thread Cliff Woolley

Where does it say that?  httpd uses it extensively, so if it's not, I'd
tend to think we'd have noticed by now...

--Cliff


On Thu, 8 Jan 2004, Donald Doane wrote:

 Okay, will do that, but it's called in
 flood_easy_reports::easy_process_stats() and it seems APR
 documentation implies it is not thread safe.

 We use a modified version of flood_easy_reports and I'd like to
 confirm whether or not its use is truly thread safe.

 Geoffrey Young wrote:

 Donald Doane wrote:
 
 
 Can someone please confirm whether or not apr_psprintf is thread safe.
 
 Thank you.
 
 
 
 sorry, wrong list.  try [EMAIL PROTECTED]
 
 --Geoff
 
 
 
 




Re: apr_psprintf thread safe?

2004-01-09 Thread Cliff Woolley
On Thu, 8 Jan 2004, Donald Doane wrote:

 The following comment is from apr_lib.h:

  * apr_vformatter does not call out to any other code, it is entirely
  * self-contained.  This allows the callers to do things which are
  * otherwise unsafe.  For example, apr_psprintf uses the scratch
  * space at the unallocated end of a block, and doesn't actually
  * complete the allocation until apr_vformatter returns.  apr_psprintf
  * would be completely broken if apr_vformatter were to call anything
  * that used a apr_pool_t.  Similarly http_bprintf() uses the scratch
  * space at the end of its output buffer, and doesn't actually note
  * that the space is in use until it either has to flush the buffer
  * or until apr_vformatter returns.

That seems to say to me that apr_psprintf is in fact threadsafe after all.
:-)

--Cliff


Re: status of the perl-framework

2003-12-08 Thread Cliff Woolley
On Mon, 8 Dec 2003, Geoffrey Young wrote:

 Use of bare  to mean  is deprecated at modules/include.t line 120.
 
 which is probably new to 5.8.2.
 
 
  Interesting.  doesn't occur within include.t. So it happens within the
  framework?

 hmm, perhaps.  I was actually planning on getting down and dirty tomorrow :)
  but yes, it could be the framework or an interaction between them.

Sounds like a cvs conflict marker.

--Cliff


Re: status of the perl-framework

2003-12-08 Thread Cliff Woolley
On Mon, 8 Dec 2003, Geoffrey Young wrote:

  Sounds like a cvs conflict marker.
 duh.  that was it.  eesh.

I only knew that because it happens to me all the time.  ;)  nbd.

--JC


Re: Patch for cookie processing in Flood [...]

2003-10-25 Thread Cliff Woolley
On Thu, 23 Oct 2003, Jacek Prucia wrote:

 then prepare separate patch and post it here. You'll score extra points
 from our own style purist (Hello Justin ;)

...and hello me, too. ;)

--Cliff Style Police Woolley


Re: cvs commit: httpd-test/perl-framework/c-modules/echo_post_chunk mod_echo_post_chunk.c

2003-10-16 Thread Cliff Woolley
On Wed, 15 Oct 2003 [EMAIL PROTECTED] wrote:

   fix link error with apr 1.0

   -trailer_header = ap_table_get(r-headers_in, X-Chunk-Trailer);
   +trailer_header = apr_table_get(r-headers_in, X-Chunk-Trailer);

I fixed this in my local tree yesterday but then forgot about it.  It
actually needs an #ifdef since in Apache 1.3.x it really is ap_table_get.

I'll commit that.


Re: LIST

2003-10-02 Thread Cliff Woolley
On Thu, 2 Oct 2003, Jeffrey P. Toth wrote:

 Can someone tell me how to unsubscibe from this list. I have sent emails
 to all addresses and they are just returned. Thank you.

If you'd look in the headers of any message delivered to this list, you'd
see:

--
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
--

Ie, just send a message to [EMAIL PROTECTED] .

--Cliff


Re: cvs commit: httpd-test/flood config.h.in flood_round_robin.c

2003-09-08 Thread Cliff Woolley
On Sun, 7 Sep 2003 [EMAIL PROTECTED] wrote:

   +if (apr_procattr_create(procattr, rp-pool) != APR_SUCCESS) {
   +apr_file_printf(local_stderr,
   +apr_procattr_create failed for '%s'\n,
   +rp-url[rp-current_url].responsescript);
   +return APR_EGENERAL;
   +}

Why do all of these return APR_EGENERAL rather than catching the
apr_status_t from the function that was called (apr_procattr_create in
this case) and returning that?  Is this just a flood thing I don't know
about?

--Cliff


RE: cvs commit: httpd-test/flood config.h.in flood_round_robin.c

2003-09-08 Thread Cliff Woolley

 is a safe bet. If this looks really obscure considering APR concepts, then
 please feel free to commit a fix.

Fix commited.  Please test, since I didn't.  :)

PS: I also fixed a buglet or two.

--Cliff


Re: required changes for APR 1.0

2003-09-05 Thread Cliff Woolley
On Thu, 4 Sep 2003, Stas Bekman wrote:

 it probably doesn't make any difference if older releases won't work
 with it.

+1.  As long as the top-of-tree 1.3-dev, 2.0-dev, and 2.1-dev all build
and run, that's fine.  Older point releases are not an issue.


Re: [patch] have_apache_mpm()

2003-07-08 Thread Cliff Woolley
On Wed, 9 Jul 2003, Stas Bekman wrote:

 plan ..., have_apache2  have_apache_mpm('prefork');

I think this is probably the way to go.  If you call have_apache_mpm() and
it's apache 1.3, I might have it return an error of some kind, but I
wouldn't have it return 'prefork'.

--Cliff


Re: are perl-framework apache tests still used?

2003-02-07 Thread Cliff Woolley
On Fri, 7 Feb 2003, Stas Bekman wrote:

 I haven't seen any activity with maintaining tests in a while and I have a
 bunch of ssl tests failing. I remember Ryan working on a new test suite.
 What's the current status of things? Should Joe's new php tests be committed?

 These fail for me:

 ssl/basicauth.t31  33.33%  2
 ssl/http.t   255 65280 22 100.00%  1-2
 ssl/proxy.t  1695   2.96%  113-117
 ssl/varlookup.t   724   5.56%  38-39 52-53

Glad it's not just me.  :)  I'm not sure when they broke... there was a
big gap in there up until last week when I hadn't run the perl-framework
tests in a long time.  :-/

Anybody?

I'm CC:ing [EMAIL PROTECTED] on this to make sure it's on everyone's radar...
followups to test-dev, please.

--Cliff



Re: Crypt::SSLeay

2003-01-30 Thread Cliff Woolley

Figured it out.  It was a bug in Crypt::SSLeay ... not sure how it ever
even worked.  I'm sending them the following patch:

--- SSLeay.xs.orig  2002-08-01 17:43:22.0 -0400
+++ SSLeay.xs   2003-01-29 21:41:17.0 -0500
@@ -109,6 +109,7 @@
SSLeay_add_all_algorithms();
SSL_load_error_strings();
ERR_load_crypto_strings();
+   SSL_library_init();
   bNotFirstTime = 1;
 }
 RAND_seed(buf,sizeof buf);


Geeze.  Crypt:SSLeay's make test actually passes now, it's amazing.  ;)

--Cliff


Re: Crypt::SSLeay

2003-01-30 Thread Cliff Woolley
On Thu, 30 Jan 2003, William A. Rowe, Jr. wrote:

 That's actually sorta sad... are they missing CRYPTO_malloc_init as well?

[EMAIL PROTECTED]:../build/Crypt-SSLeay-0.45# grep -i CRYPTO_malloc_init *
[EMAIL PROTECTED]:../build/Crypt-SSLeay-0.45#

Looks that way, yeah...  :)

--Cliff


Crypt::SSLeay

2003-01-29 Thread Cliff Woolley

Has anybody out there managed to get Crypt::SSLeay to do anything but
segfault with recent OpenSSL's?  I sure can't.  As a result, every single
SSL test fails for me.

--Cliff


RE: Crypt::SSLeay

2003-01-29 Thread Cliff Woolley
On Wed, 29 Jan 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:

 PS : I'm using Perl 5.8 though (I'm not sure if it matters, but I can
 try on 5.6.1)

I'm using Linux, Slackware current, kernel 2.4.20, glibc 2.3.1, openssl
0.9.6h, perl 5.8.0, latest Crypt::SSLeay.

--Cliff


Re: [STATUS] (perl-framework) Wed Nov 6 23:45:56 EST 2002

2002-11-07 Thread Cliff Woolley
On Thu, 7 Nov 2002, William A. Rowe, Jr. wrote:

 Guys, some time in the {recent} past, TEST.pl was renamed TEST.

Umm it's actually been TEST for as long as I can remember.

Here's a partial directory listing of an old copy of httpd-test of mine:

-rwxr-xr-x1 jcw5qroot  424 Jun 28 17:14 REPORT
-rwxr-xr-x1 jcw5qroot  425 Jun 28 17:14 SMOKE
-rwxr-xr-x1 jcw5qroot  484 Jun 28 17:14 TEST

I don't recall them ever being TEST.pl, SMOKE.pl, etc.  Not that I would
mind them changing to *be* TEST.pl et al.

/me is confused...

--Cliff



Re: rewritemap breakage

2002-05-31 Thread Cliff Woolley
On Fri, 31 May 2002, Doug MacEachern wrote:

 seems that the test suite now requires httpd-2.0-cvs from
 HEAD?  server does not start with 1.3.x or 2.0.36:

 Syntax error on line 139 of .../t/conf/extra.conf RewriteMap: map file
 or program not found:/.../t/htdocs/modules/rewrite/append.pl foo

Hmph.  Well, it definitely won't work with 2.0.36... 2.0.36 was broken in
this regard.  :)  I thought this worked on 1.3.x though.  Oh well, no big
deal.  You can remove that test if you like.

--Cliff



inherit_documentroot breakage

2002-05-14 Thread Cliff Woolley

Anybody know why this just started happening within the last few days?

[EMAIL PROTECTED]:/root/apache/httpd-test/perl-framework$ t/TEST
configure() has failed:
invalid token: @inherit_documentroot@ in file
/root/apache/httpd-test-8/perl-framework/t/conf/extra.conf.in

forcing Apache::TestConfig object save
run 't/TEST -clean' to clean up before continuing


And yes, I've cvs up'ed, make clean'ed, and all that jazz.

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: inherit_documentroot breakage

2002-05-14 Thread Cliff Woolley
On Tue, 14 May 2002, Doug MacEachern wrote:

 i just backed out the change from yesterday that caused it, should be ok
 now.

Thanks.  I had noticed that commit, but thought maybe there would be some
way to fix it by just adjusting extra.conf.in rather than reverting.  Oh
well, whatever works.  :)

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




all the commits ;)

2002-05-09 Thread Cliff Woolley

Sorry about the flurry of commit messages... I'm just rearranging t/htdocs
a bit to get a more parallel directory structure to make it easier to add
other stuff without cluttering up the docroot.

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: mod_specweb99

2002-05-01 Thread Cliff Woolley
On Wed, 1 May 2002, Greg Ames wrote:

  If we need to arrange for people without httpd commit to get commit
  to just httpd-test, we can probably do so...  -- justin

 Do you mean Dirk and I automagically have httpd-test commit access by
 virtue of being httpd committers?  If so, great!

Yep!  It's a subproject.  All core httpd developers are already in avail
for httpd-test.

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: perl-framework: make test recompiles everything all the time

2002-04-16 Thread Cliff Woolley
On Tue, 16 Apr 2002, Stas Bekman wrote:

 one last question. Should the ssl certificates be recreated on t/TEST
 -clean (or 'make test')?

As they're currently done, they need to be recreated at least *once* in a
while, because they're set to expire.  That happened on me once when I
hadn't cleaned up in a while.  But in general, yes, I think they should be
cleaned up with t/TEST -clean... I like having a way to throw out all the
generated cruft and go back to what's basically the same as you get from
CVS.

That's just me, though.

--Cliff



Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestSmoke.pm

2002-04-12 Thread Cliff Woolley
On 11 Apr 2002 [EMAIL PROTECTED] wrote:

 stas02/04/11 08:02:26

   Modified:perl-framework/Apache-Test/lib/Apache TestSmoke.pm
   Log:
   - improved the generated smoke report

   +
   +== Summary ===
   +Completion  : $completion
   +Status  : $status
   +Tests run   : $self-{total_tests_run}
Random iterations made  : $self-{total_iterations}
   +EOM

make now reports this:

lib/Apache/TestSmoke.pm:373: Unknown command paragraph
= Summary
===


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA





Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

2002-04-06 Thread Cliff Woolley
On 6 Apr 2002 [EMAIL PROTECTED] wrote:

 dougm   02/04/05 18:39:31

   Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
   Log:
   try MP_AP_PREFIX in modperl build config for httpd location hint

Doug.  DOOD.  You're working too hard.  GO PARTY!  ;)

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: cvs commit: httpd-test/perl-framework/t/ssl http.t

2002-04-02 Thread Cliff Woolley
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 of LWP I'm using?

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: httpd-test negotiation failures.

2002-02-04 Thread Cliff Woolley
 for index.fu.html
# expected: 'index.de.html'
# received: 'index.fu.html'
not ok 72
# Failed test 72 in modules/negotiation.t at line 71 fail #4
# testing : Explicitly request fu/index.html.en
# expected: 200
# received: '200'
ok 73
# testing : Explicitly request fu/two/index.en.html
# expected: 200
# received: '200'
ok 74
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.html.en'
# received: 'index.html.en'
ok 75
# testing : Verify with a default language Accept-Language still obeyed 
(compression on)
# expected: 'index.html.en.gz'
# received: 'index.html.en.gz'
ok 76
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.en.html'
# received: 'index.en.html'
ok 77
# testing : Explicitly request fu/index.html.fr
# expected: 200
# received: '200'
ok 78
# testing : Explicitly request fu/two/index.fr.html
# expected: 200
# received: '200'
ok 79
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.html.fr'
# received: 'index.html.fr'
ok 80
# testing : Verify with a default language Accept-Language still obeyed 
(compression on)
# expected: 'index.html.fr.gz'
# received: 'index.html.fr.gz'
ok 81
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.fr.html'
# received: 'index.fr.html'
ok 82
# testing : Explicitly request fu/index.html.de
# expected: 200
# received: '200'
ok 83
# testing : Explicitly request fu/two/index.de.html
# expected: 200
# received: '200'
ok 84
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.html.de'
# received: 'index.html.de'
ok 85
# testing : Verify with a default language Accept-Language still obeyed 
(compression on)
# expected: 'index.html.de.gz'
# received: 'index.html.de.gz'
ok 86
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.de.html'
# received: 'index.de.html'
ok 87
# testing : Explicitly request fu/index.html.fu
# expected: 200
# received: '200'
ok 88
# testing : Explicitly request fu/two/index.fu.html
# expected: 200
# received: '200'
ok 89
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.html.fu'
# received: 'index.html.fu'
ok 90
# testing : Verify with a default language Accept-Language still obeyed 
(compression on)
# expected: 'index.html.fu.gz'
# received: 'index.html.fu.gz'
ok 91
# testing : Verify with a default language Accept-Language still obeyed
# expected: 'index.fu.html'
# received: 'index.fu.html'
ok 92
# testing : fu has a higher quality rating, so we expect fu
# expected: 'index.html.fu'
# received: 'index.html.fu'
ok 93
# testing : fu has a higher quality rating, so we expect fu
# expected: 'index.fu.html'
# received: 'index.fu.html'
ok 94
# testing : fu has a higher quality rating, so we expect fu
# expected: 'index.html.fu.gz'
# received: 'index.html.fu.gz'
ok 95
# testing : bu has the highest quality but is non-existant, so fr is next best
# expected: 'index.html.fr'
# received: 'index.html.fr'
ok 96
# testing : bu has the highest quality but is non-existant, so fr is next best
# expected: 'index.fr.html'
# received: 'index.fr.html'
ok 97
# testing : bu has the highest quality but is non-existant, so fr is next best
# expected: 'index.html.fr.gz'
# received: 'index.html.fr.gz'
ok 98
FAILED tests 1-3, 24-26, 70-72
Failed 9/98 tests, 90.82% okay
Failed Test   Status Wstat Total Fail  Failed  List of Failed

modules/negotiation.t 989   9.18%  1-3, 24-26, 70-72


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




getting t/SMOKE to work

2001-12-24 Thread Cliff Woolley
 and $old_pid == $self-pid) {
-warning old pid file ($old_pid) still exists;
+warning(old pid file ($old_pid) still exists);
 sleep 1;
 }


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




ssl/varlookup.t

2001-12-02 Thread Cliff Woolley

Is this really a bug in httpd, or is it a bug in the test?  I think it's a
bug in the test that only shows up days 1-9 of the month, but I just
thought I'd check before I went and 'fixed' the test.

# testing : TIME_YEAR
# expected: '2001'
# received: '2001'
ok 15
# testing : TIME_MON
# expected: '12'
# received: '12'
ok 16
# testing : TIME_DAY
# expected: 1
# received: '01'
not ok 17
# Failed test 17 in
/root/apache/httpd-test/perl-framework/blib/lib/Apache/Test.pm at line 46
fail #17
# testing : TIME_WDAY
# expected: 6
# received: '6'
ok 18


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: .htaccess on WIn2000

2001-11-12 Thread Cliff Woolley
On Mon, 12 Nov 2001, [iso-8859-1] ???  wrote:

 Filename in Win2000 cannot start with dot, so we can't create .htaccess.
 How to solve this problem?

Just use some name other than .htaccess in your AccessFileName directive,
one that doesn't start with a period.

BTW, this mailing list is for issues relating to development of the test
suite for Apache.  Please direct this type of question to one of the
support mailing lists in the future.

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA





Re: 2.0.28

2001-11-09 Thread Cliff Woolley
On Thu, 8 Nov 2001, Justin Erenkrantz wrote:

modules/cgi.t36   33  91.67%  1-4, 6, 8-27, 29-36
ssl/env.t22   16  72.73%  1-5, 12-22
   Do these look normal?  They've been failing for quite a while
   now and nobody else that I know of except Aaron seems to have
   noticed.

 Those two seem to be related to a stale httpd-test build.  Usually a
 fresh checkout seem to make it work.  But, I'll try to check again
 later this weekend.  -- justin

Ah, that's one thing I didn't try... I'll re-check-out and see what
happens.

--Cliff


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: Initial version of website up...

2001-09-17 Thread Cliff Woolley
On Mon, 17 Sep 2001, Justin Erenkrantz wrote:

  http://cvs.apache.org/viewcvs.cgi/modperl-docs/src/devel/writing_tests/writing_tests.pod

 I'm not familiar enough with perl, but is there a way to get a POD file
 as an HTML file?  -- justin

There's a utility called pod2html ... :-)

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: cvs commit: httpd-2.0/modules/filters mod_include.c mod_include.h

2001-09-02 Thread Cliff Woolley
On 2 Sep 2001 [EMAIL PROTECTED] wrote:

 jerenkrantz01/09/01 18:09:02

   Modified:.CHANGES
modules/filters mod_include.c mod_include.h
   Log:
   Make mod_include check for BYTE_COUNT_THRESHOLD on a per-bucket basis
   rather than on a per-character basis.  A significant amount of time
   was spent checking the limit.  A better place to check for the threshold
   is when we read the bucket in not as we read each character in the bucket.

   If a bucket manages to be 200MB, it is not this code's problem as it
   is a mere filter.

   I ran this with the mod_include stuff in httpd-test and it looks good
   from here.

The httpd-test mod_include tests are probably insufficient to test this
code.  They have lots of recursion and check just about all of the
imaginable flavors of tag types, but none of them have really BIG
content... not even close to big enough to warrant a brigade split.  Maybe
we should add a test that includes biggish data from the middle of a
biggish file?  Somewhere around 32k should be sufficient, I'd guess...

--Cliff


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA





new test request for mod_include

2001-08-31 Thread Cliff Woolley

Some subrequest URI fooness we're currently seeing at the HEAD of httpd
cannot be detected with the current tests in the framework.  They can be
seen if you add a test that does an include virtual or include file on a
file that's in some other directory than the current one using a relative
path.  So can someone please add a test or two to the mod_include tests,
sticking some file in a subdirectory of t/htdocs/modules/include and
trying to include that file from, say, big.shtml in the main directory?

Thanks,
Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA




Re: cvs commit: httpd-test/perl-framework/t/htdocs/modules/include/extra inc-bogus.shtml inc-extra1.shtml inc-extra2.shtml

2001-08-31 Thread Cliff Woolley
On 31 Aug 2001 [EMAIL PROTECTED] wrote:

   Index: inc-rfile.shtml
   ===
   !--#include file=extra/inc-extra1.shtml--
   inc-rfile.shtml body


Sweet.  I was just about to pester somebody to take care of this.  While
you're at it, can you throw in a test with an absolute path as well?

Thanks,
Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA