Mailing List Archive

At 11:19 PM 8/8/95, Andrew Wilson wrote:

> Uuuh, try making BOTH files u+x:
>
> chmod u+x the_file.html
> chmod u+x DocumentRoot/lastmod.inc
>
> that's if you're using the -DXBITHACK mods to indicate that the files
> are to be parsed.
>
> The alternative is to add the directive
>
> XBitHack Full
>
> to the .htaccess governing these pages, or more globally

The above does work...

> XBitHack Full
>
> in the conf/access.conf

I assume that one would too...

> Then again you could tell the server that .inc files are really like
> .shtml files (I don't use this notation but it's a directive to indicate
> that the server should parse these files) in srm.conf
>
> AddType text/x-server-parsed-html .shtml

And this _was_ just about what I had done... though previous versions
allowed one to specify:

AddType text/x-server-parsed-html lastmod.inc

But this version requires:

AddType text/x-server-parsed-html .inc

In other words, you can't specify just one specific filename to get parsed
in a directory, it has to be an extension...

> As ever:
>
> #ifdef ANDY_ISNT_TALKING_CACK
>
> which on current form is very unlikely.

"CACK"? Is there a missing "R" in the sentence and and extra "L"? Just kidding.

Thanks,

-ech

______________________________________________________
Eric Hagberg Phone: 212-746-6387
User Services Manager, CUMC/OAC Fax: 212-746-8161

At 6:41 PM 8/8/95, I wrote:

> And this _was_ just about what I had done... though previous versions
> allowed one to specify:
>
> AddType text/x-server-parsed-html lastmod.inc
>
> But this version requires:
>
> AddType text/x-server-parsed-html .inc
>
> In other words, you can't specify just one specific filename to get parsed
> in a directory, it has to be an extension...

Even worse than that, previous versions evaluated the variables like
"LAST_MODIFIED" in relation to the file that the nested #include was called
from... and apache_0.8.8 evaluates the variable wrt the file that the
variable evaluation is actually in.

Now all my pages have the same last-modified date :-(

This certainly seems to be broken behavior; correct me if I'm wrong.

Thanks,
-ech

______________________________________________________
Eric Hagberg Phone: 212-746-6387
User Services Manager, CUMC/OAC Fax: 212-746-8161

Date: Tue, 8 Aug 1995 18:57:38 -0400
From: hagberg@mail.med.cornell.edu (Eric Hagberg)

Even worse than that, previous versions evaluated the variables like
"LAST_MODIFIED" in relation to the file that the nested #include was called
from... and apache_0.8.8 evaluates the variable wrt the file that the
variable evaluation is actually in.

Now all my pages have the same last-modified date :-(

This certainly seems to be broken behavior; correct me if I'm wrong.

Well, it's certainly not what *I* would have expected, but if it's
desirable for back-compatibility reasons, it could be obtained, at
the price of hairing up the code a bit... (tossing an

if (r->main) r->subprocess_env = r->main->subprocess_env;

at the right spot should do most of the job, but you have to be sure
that the LAST_MODIFIED time gets reset to the correct value if the
time format changes. I *think* that's everything...).

rst

On Wed, 9 Aug 1995, Andrew Wilson wrote:
> > Even worse than that, previous versions evaluated the variables like
> > "LAST_MODIFIED" in relation to the file that the nested #include was called
> > from... and apache_0.8.8 evaluates the variable wrt the file that the
> > variable evaluation is actually in.
> >
> > Now all my pages have the same last-modified date :-(
> >
> > This certainly seems to be broken behavior; correct me if I'm wrong.
>
> You're right, it's r0ng. That was the whole pointed of allowing nested
> includes in the first place!

Hmm... I'm not sure I would consider that wrong. Different, yes, but how
would I then get the last modified bit of the included file, if I wanted
it? (or any other relevant data). Do #included files get the extra CGI
variables with the REDIRECTED_ prefix, i.e would

<!--#echo var="REDIRECTED_LAST_MODIFIED" -->

be an acceptible solution?

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

On Tue, 8 Aug 1995, Brian Behlendorf wrote:

> On Wed, 9 Aug 1995, Andrew Wilson wrote:
> > > Even worse than that, previous versions evaluated the variables like
> > > "LAST_MODIFIED" in relation to the file that the nested #include was called
> > > from... and apache_0.8.8 evaluates the variable wrt the file that the
> > > variable evaluation is actually in.
> > >
> > > Now all my pages have the same last-modified date :-(
> > >
> > > This certainly seems to be broken behavior; correct me if I'm wrong.
> >
> > You're right, it's r0ng. That was the whole pointed of allowing nested
> > includes in the first place!
>
> Hmm... I'm not sure I would consider that wrong. Different, yes, but how
> would I then get the last modified bit of the included file, if I wanted
> it? (or any other relevant data). Do #included files get the extra CGI
> variables with the REDIRECTED_ prefix, i.e would
>
> <!--#echo var="REDIRECTED_LAST_MODIFIED" -->
>
> be an acceptible solution?

It would be acceptable to me... but I'd worry about all those people out
there who expect the earlier behavior to continue to work... In any case,
neither the earlier way or the "REDIRECTED_" way work at present.

-ech

> I have a file with nested includes in it and the file is definitely being
> read, and is not having the directives evaluated... are nested includes
> broken intentionally in apache 0.8.8 :-( ? Or is it just me?
>
> The file that contains the nest has:
>
> <!--#include virtual="/lastmod.inc" -->
>
> and DocumentRoot/lastmod.inc has:
>
> <!--#config timefmt="%h %d, 19%y at %T" -->
> <cite>Last modified:
> <!--#echo var="LAST_MODIFIED" -->.</cite><p>
>
> And there are .htaccess files specifying that .inc (in the document root)
> and the file containing the "#include" are to be parsed for includes.
>
> And the setup works fine with apache_0.7.3k, but with apache_0.8.8 the
> lastmod.inc file _is_ read, but not parsed... or at least I get no date
> info out of it... of course, if I just paste the contents of lastmod.inc
> into the file where I want the timestamp, it works... but that still leaves
> me wondering why the included file isn't parsed.
>
> Hope I haven't just made some stupid error, but the 0.7.3k version of
> apache handles this, so I don't think so.
>
> Ideas? Thanks,

Uuuh, try making BOTH files u+x:

chmod u+x the_file.html
chmod u+x DocumentRoot/lastmod.inc

that's if you're using the -DXBITHACK mods to indicate that the files
are to be parsed.

The alternative is to add the directive

XBitHack Full

to the .htaccess governing these pages, or more globally

XBitHack Full

in the conf/access.conf

Then again you could tell the server that .inc files are really like
.shtml files (I don't use this notation but it's a directive to indicate
that the server should parse these files) in srm.conf

AddType text/x-server-parsed-html .shtml

As ever:

#ifdef ANDY_ISNT_TALKING_CACK

which on current form is very unlikely.


You know, this could probably be the start of another compatibility note,
Brian?

Cheers,
Ay

> -ech
>
> ______________________________________________________
> Eric Hagberg Phone: 212-746-6387
> User Services Manager, CUMC/OAC Fax: 212-746-8161

> Even worse than that, previous versions evaluated the variables like
> "LAST_MODIFIED" in relation to the file that the nested #include was called
> from... and apache_0.8.8 evaluates the variable wrt the file that the
> variable evaluation is actually in.
>
> Now all my pages have the same last-modified date :-(
>
> This certainly seems to be broken behavior; correct me if I'm wrong.

You're right, it's r0ng. That was the whole pointed of allowing nested
includes in the first place!

Ew.

> Thanks,
> -ech

At 9:44 AM 8/9/95, Robert S. Thau wrote:

> Actually, to solve the timefmt issue, make that...
>
> if (r->main) {
> /* Kludge --- for nested includes, we want to keep the
> * subprocess environment of the base document (for compatibility);
> * that means torquing our own last_modified date as well so that
> * the LAST_MODIFIED variable gets reset to the proper value if
> * the nested document resets <!--#config timefmt-->
> */
> r->subprocess_env = r->main->subprocess_env;
> r->finfo.st_lastmod = r->main->finfo.st_lastmod;
> }

I put that chunk (with "st_lastmod" replaced by "st_mtime") in the
mod_include.c, as follows:

void add_include_vars(request_rec *r, char *timefmt)
{
table *e = r->subprocess_env;
char *t;
time_t date = time(NULL);

if (r->main) {
/* Kludge --- for nested includes, we want to keep the
(...snip...)

This works for me... does it break things for others?

-ech

From: rst@ai.mit.edu (Robert S. Thau)
Date: Tue, 8 Aug 95 19:29:16 EDT

Well, it's certainly not what *I* would have expected, but if it's
desirable for back-compatibility reasons, it could be obtained, at
the price of hairing up the code a bit... (tossing an

if (r->main) r->subprocess_env = r->main->subprocess_env;

at the right spot should do most of the job, but you have to be sure
that the LAST_MODIFIED time gets reset to the correct value if the
time format changes. I *think* that's everything...).

Actually, to solve the timefmt issue, make that...

if (r->main) {
/* Kludge --- for nested includes, we want to keep the
* subprocess environment of the base document (for compatibility);
* that means torquing our own last_modified date as well so that
* the LAST_MODIFIED variable gets reset to the proper value if
* the nested document resets <!--#config timefmt-->
*/
r->subprocess_env = r->main->subprocess_env;
r->finfo.st_lastmod = r->main->finfo.st_lastmod;
}

I *think*. NB in response to Brian, I'm not exactly fond of this
behavior, but as far as I'm concerned, there's a serious enough
compatibility issue here to make it be worth emulating. If someone
gets this code to work, it'll have a +1 from me...

rst

At 11:42 AM 8/9/95, Robert S. Thau wrote:

> Hmmm... I'd actually thought of having that code in send_parsed_file,
> and putting the add_common_vars and add_include_vars which are already
> there in an else clause to the if statement I suggested adding. The
> major effect of putting it into add_include_vars instead is that
> DOCUMENT_NAME gets reset (and it probably *stays* reset even after you
> are back in the top-level document --- arguably undesirable).

Yep, you are right... (I did have an include that got barfed-on because I
added it in the wrong place, and now it works correctly for me, when added
as you specify above.

-ech

______________________________________________________
Eric Hagberg Phone: 212-746-6387
User Services Manager, CUMC/OAC Fax: 212-746-8161

Hmmm... I'd actually thought of having that code in send_parsed_file,
and putting the add_common_vars and add_include_vars which are already
there in an else clause to the if statement I suggested adding. The
major effect of putting it into add_include_vars instead is that
DOCUMENT_NAME gets reset (and it probably *stays* reset even after you
are back in the top-level document --- arguably undesirable).

rst

Guess I should have been more specific...

Eric --- as long as you've got it working, have a patch? ;-).

(Shoulda done it myself, I know...).

rst