mod_include and Last-Modified, take 45643

[Sönke Tesch <st...@kino-fahrplan.de>]

Hi,

the issue about SSI and the Last-Modified header (or the missing thereof)
seems to be as old as mod_include itself. There are still requests from
1996 in the bug database (gnats#38) and the newest seems to be the one
dated January 2003 I stumbled across yesterday (PR#15943).

Of course, there's XBitHack, but this is a rather unlovely solution. Sure
it works, but you have to deal with the group-x bit for every single file;
it's not possible to enable Last-Modified for "every page" in a directory
and you cannot set that file option the same way as the other SSI options
(i.e. within the file), you have to exit the editor and use chmod instead
- bad luck if you're a newbie using FTP on 150 pages.
You might also needlessly loose that information bit if you copy the file.

Easier access to Last-Modified
------------------------------

I think there is no need to make sending Last-Modified as complicated
as it is currently. No doubt, it is possible to run into problems if 
you only rely on the main document always having the newest file date.
However, shouldn't this decision be left to the page maintainers? Does
Apache really need to "hide" that option away? I don't think so.

1. Per directory setting:
Add a configuration directive SSISendLastModified, available on .htaccess
level. If enabled, any SSI page in that directory will get a Last-Modified
header. 
It's the same as 'XBitHack & chmod g+x *', just that you don't have to take
care of it everytime you move or add files.

2. Per file setting:
Would it be possible to put some <!--#config lastmodified="on" --> at the 
very first byte of an SSI page to get mod_include sending the Last-Modified
header? Or is even that too late?
This option would join the Last-Modified option with everything else,
within the file, not outside.


The real thing
--------------

As I had to experience two weeks ago, it seems to be quite easy to get
the correct Last-Modified dates of all objects up to the main request.
Unfortunatly I also had to experience that it's getting there too late :]

There are only two solutions for this: Caching the output or parsing
the document twice. It's a waste of time to do the same thing twice,
so: Is it currently possible to cache/delay the output of a request,
maybe by creating a "fake" brigade? I saw some set-brigade-aside
function somewhere, could that work?
Or is it possible to implement some "output inhibit"? (No, I have no
idea of that brigade and bucket stuff, that's why I ask :)

Some developers noted earlier that Apache will need more resources. But
that's only half of the story, since as memory usage goes up because of
the caching, bandwidth usage will go down because more sites will just
receive a "Not modified" answer instead of the full page every time.
RAM and CPU has to be paid only once, bandwidth constantly. Second,
hardware is getting cheaper and cheaper, the performance issue might
have been a serious, widespread one in 1996, but today? And how big
are pages anyway, compared to current servers' RAM?

Again, the decision should be left to site/server maintainer, this time
wether he wants to pay less for bandwidth or less for hardware.


Looking forward to your comments.

Kind regards,
  soenk.e (volunteering for all of the above, with some external help
           on the brigade caching magic).