Apache SSI (Linux)

There is a slight inconsistency in the apache docs. On one hand, they
stress the importance of enabling (by x-bit or shtml extension) only
those pages that have SSI. On the other hand, they document a footer
include as an example, in which case one might as well enable .html
since it is a global approach.

I was thinking about SSI for our cascading menus.

Any suggestions?
--
Displayed Email Address is a SPAM TRAP
Eliminate Spam: http://www.TQMcube.com/spam_trap.htm
RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm
Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm

On Sun, 26 Jun 2005 19:31:32 GMT,
David Cary Hart <DavidHart@TQMcube.com> posted:

> There is a slight inconsistency in the apache docs. On one hand, they
> stress the importance of enabling (by x-bit or shtml extension) only
> those pages that have SSI. On the other hand, they document a footer
> include as an example, in which case one might as well enable .html
> since it is a global approach.

I wouldn't, as you can't easily tell Apache to not parse some HTML files
(which is time consuming, especially on big ones), and just serve them.

You might want to post a URI to the bit of the docs that you're concerned
about, you'll get more direct answers.

> I was thinking about SSI for our cascading menus.

I use SSI for inserting navigation menus, works fine for me.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

On Mon, 2005-06-27 at 23:42 +0930, Tim wrote:

> > I was thinking about SSI for our cascading menus.
>
> I use SSI for inserting navigation menus, works fine for me.
>
So that means that virtually every page will parse for SSI since
virtually every page will have a nav menu.

Let me re-phrase my question. Maintenance aside, strictly in terms of
performance, what are the consequences of using SSI to provide a fairly
global navigation menu?

Here's the document issue (/var/www/manual/howto/ssi.html.en):

"A brief comment about what not to do. You'll occasionally see
people recommending that you just tell Apache to parse all .html
files for SSI, . . . by doing this, you're requiring that
Apache read through every single file that it sends out to
clients, even if they don't contain any SSI directives. This can
slow things down quite a bit, and is "

That says to use SSI sparingly yet (in the same doc);

"Including a standard footer. If you are managing any site that
is more than a few pages, you may find that making changes to
all those pages can be a real pain, particularly if you are
trying to maintain some kind of standard look across all . . .
"

That suggests using SSI on every page across the site.

Is there something that, perhaps, I don't understand correctly?
--
Displayed Email Address is a SPAM TRAP
Eliminate Spam: http://www.TQMcube.com/spam_trap.htm
RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm
Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm

Unattributed authors wrote:

>>> I was thinking about SSI for our cascading menus.


Tim wrote:

>> I use SSI for inserting navigation menus, works fine for me.


David Cary Hart <MaiPhenLai@TQMcube.com> posted:

> So that means that virtually every page will parse for SSI since
> virtually every page will have a nav menu.

Almost... In my case I have a couple of really long pages that take a long
time to be served if Apache has to parse them looking for SSI instructions,
compared to being able to serve them in a flash because it knows it doesn't
have to. For those long pages, I've just written in a few basic addresses
that aren't going to change (e.g. "/", "./" & "../").

> Let me re-phrase my question. Maintenance aside, strictly in terms of
> performance, what are the consequences of using SSI to provide a fairly
> global navigation menu?

The server has to process the entire content of each and every HTML file
that it serves, rather than just pipe the file out. That can slow things
down, and on some hosting services get you in bother for causing more CPU
load than is really necessary (how some determine what is too intensive is
quite arbitrary).

As an aside, if you are going to make a server parse all .html files as
SSI, then don't use the .html suffix on anything that doesn't need parsing
(such as the stuff to be inserted).

> That says to use SSI sparingly yet (in the same doc);
>
> "Including a standard footer. If you are managing any site that
> is more than a few pages, you may find that making changes to
> all those pages can be a real pain, particularly if you are
> trying to maintain some kind of standard look across all . . .
> "
>
> That suggests using SSI on every page across the site.

There's an alternative: Have a common footer file that is placed below
your content, write your content without finishing the page, and let Apache
simply join them together (a far simpler, and less CPU intensive,
operation).

e.g. firstpage.html:

<html>
<head> ... </head>
<body>
page content...

footer.html:

... navigational links
</body>
</html>

The server joins firstpage.html+footer.html when requests
are made for the firstpage.html file, and serves out:

<html>
<head> ... </head>
<body>
page content...
... navigational links
</body>
</html>

Of course, you can use CSS to reposition the navigational footer content if
you don't want it to appear at the bottom of the page.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

On Tue, 2005-06-28 at 17:08 +0930, Tim wrote:

> e.g. firstpage.html:
>
> <html>
> <head> ... </head>
> <body>
> page content...
>
> footer.html:
>
> ... navigational links
> </body>
> </html>
>
> The server joins firstpage.html+footer.html when requests
> are made for the firstpage.html file, and serves out:
>
> <html>
> <head> ... </head>
> <body>
> page content...
> ... navigational links
> </body>
> </html>
>
> Of course, you can use CSS to reposition the navigational footer content if
> you don't want it to appear at the bottom of the page.
>
Thanks. That's very helpful.
--
Displayed Email Address is a SPAM TRAP
Eliminate Spam: http://www.TQMcube.com/spam_trap.htm
RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm
Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm