Server Side Includes

Server Side Includes

[Ian Lance Taylor]

Currently we are processing Server Side Includes on many of the files
on the web site.  However, only a few files actually use them.  This
wastes httpd execution time looking for the include directives.

After some discussion with fche, I plan to turn on the XBitHack
directive, and turn off the default Server Side Include processing.  I
would first turn on the execution bit for any file I find which
requires Server Side Includes.

XBitHack will still be controlled by the Includes and IncludesNOEXEC
options which are set on a directory by directory basis.  For example,
we already turn off Includes for the mailing list archives.

Does anybody have any objections, concerns, or comments?

Ian

Re: Server Side Includes

[Jason Molenda]

On Mon, Feb 07, 2005 at 01:05:54PM -0500, Ian Lance Taylor wrote:

> Does anybody have any objections, concerns, or comments?


None from me.  SSI was used because we wanted to use html templates
to give the entire site (the sourceware side) a unified look and
feel.  Obviously this harks back to the time when the projects were
all externalizations of software Cygnus was working on, and marking
had their fingers in the site layout from time to time.

All of these old pages could have their templates substituted in
and there would be no real loss -- it's obvious no one is going to
change the site's overall look and feel.  If someone wanted to
change the top-level look and feel, it's less than a dozen pages;
it can be done by hand.

It's possible someone has done a clever hack on some project's
page that depends on SSI, but I doubt it.

I believe the project generates all their web pages (metahtml IIRC)
and installs static versions.

J

Re: Server Side Includes

[Christopher Faylor]

On Mon, Feb 07, 2005 at 01:05:54PM -0500, Ian Lance Taylor wrote:
>Currently we are processing Server Side Includes on many of the files
>on the web site.  However, only a few files actually use them.  This
>wastes httpd execution time looking for the include directives.
>
>After some discussion with fche, I plan to turn on the XBitHack
>directive, and turn off the default Server Side Include processing.  I
>would first turn on the execution bit for any file I find which
>requires Server Side Includes.
>
>XBitHack will still be controlled by the Includes and IncludesNOEXEC
>options which are set on a directory by directory basis.  For example,
>we already turn off Includes for the mailing list archives.
>
>Does anybody have any objections, concerns, or comments?

As long as SSI still works for the cygwin web pages, no complaints from
me.

cgf

Re: Server Side Includes

[Gerald Pfeifer]

On Mon, 7 Feb 2005, Jason Molenda wrote:
> I believe the project generates all their web pages (metahtml IIRC)
              ^^^
              GCC
> and installs static versions.

Yes, that's the case, and I just verified that we indeed do not seem
to have any SSIs left.  As far as I can see, I removed the last ones
in 2001 when integrating the Java pages more tightly.

As far as MetaHTML is concerned, that was/is a really nice tool, but
sadly it has been virtually killed by its maintainers who stopped to
show any interest but did not properly hand it over either.  In the
long term we'll need to look for some replacements.  I looked into WML
some time ago, which is a huge beast with one of its passes providing
the subset of MetaHTML we are using, but that one doesn't seem active
any longer as well. Sigh.

Gerald

Re: Server Side Includes

[Ian Lance Taylor]

Ian Lance Taylor <ian@airs.com> writes:

> After some discussion with fche, I plan to turn on the XBitHack
> directive, and turn off the default Server Side Include processing.  I
> would first turn on the execution bit for any file I find which
> requires Server Side Includes.

I have made this change.

If you want to use Server Side Includes, you must now turn on the
execution bit for the relevant file.  I have done for existing files,
both in the repository and in the checked out version.

Chris, there are some generated .html files in cygwin.com which use
Server Side Includes.  For example, packages/index.html.  Somebody
will have to make sure that when the files are regenerated, they
retain the execute bit.  I can do that if you tell me where they are
generated.

Ian

Re: Server Side Includes

[Christopher Faylor]

On Tue, Feb 08, 2005 at 11:27:51AM -0500, Ian Lance Taylor wrote:
>Ian Lance Taylor <ian@airs.com> writes:
>
>> After some discussion with fche, I plan to turn on the XBitHack
>> directive, and turn off the default Server Side Include processing.  I
>> would first turn on the execution bit for any file I find which
>> requires Server Side Includes.
>
>I have made this change.
>
>If you want to use Server Side Includes, you must now turn on the
>execution bit for the relevant file.  I have done for existing files,
>both in the repository and in the checked out version.
>
>Chris, there are some generated .html files in cygwin.com which use
>Server Side Includes.  For example, packages/index.html.  Somebody
>will have to make sure that when the files are regenerated, they
>retain the execute bit.  I can do that if you tell me where they are
>generated.

I think the code will preserve the x bit unless the file is completely
wiped out.

Changing the extension to shtml is the right long-term solution, right?

cgf

Re: Server Side Includes

[Per Bothner]

Christopher Faylor wrote:
> Changing the extension to shtml is the right long-term solution, right?

Only if the server remaps the url.  Server-side includes is an
implementation property, and so should never appear in user-visible
urls.  Thus .php .shtml .pl .cgi .jsp etc are banned as url extensions.

(Some would go so far as to also advise against extensions at all, 
including .html, since perhaps 20 years from now we might no longer
be using html.  Cfr the recent discussion on wiki urls.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Server Side Includes

[Ian Lance Taylor]

Christopher Faylor <me@cgf.cx> writes:

> Changing the extension to shtml is the right long-term solution, right?

Yes, though that is harder for the case of index.html files.

Ian

Re: Server Side Includes

[Ian Lance Taylor]

Christopher Faylor <me@cgf.cx> writes:

> On Tue, Feb 08, 2005 at 01:27:05PM -0500, Ian Lance Taylor wrote:
> >Christopher Faylor <me@cgf.cx> writes:
> >
> >> Changing the extension to shtml is the right long-term solution, right?
> >
> >Yes, though that is harder for the case of index.html files.
> 
> Except for the problem of external links pointing to
> http://cygwin.com/packages/index.html rather than just
> http://cygwin.com/packages/, why would this be a problem?
> Doesn't the server look for either .html or .shtml?

As far as I know, it does not.

But there is probably some way to fix it, so you're right that it's
not a concern.  I guess I would worry more about Per's comment.

Ian

Re: Server Side Includes

[Jonathan Larmour]

Per Bothner wrote:
> Christopher Faylor wrote:
> 
>> Changing the extension to shtml is the right long-term solution, right?
> 
> 
> Only if the server remaps the url.  Server-side includes is an
> implementation property, and so should never appear in user-visible
> urls.  Thus .php .shtml .pl .cgi .jsp etc are banned as url extensions.
> 
> (Some would go so far as to also advise against extensions at all, 
> including .html, since perhaps 20 years from now we might no longer
> be using html.  Cfr the recent discussion on wiki urls.)

Actually I think you've hit the nail on the head there - why should .html 
be any more significant than .shtml _really_. URLs, well URIs really, are 
pretty much just identifiers, i.e. data.[1] The mapping to files is not of 
the user's concern. It's not that they shouldn't appear in user-visible 
URLs... it's that whatever appears to the user should not actually matter. 
Nor is it the server's concern. It's up to whoever is managing the content 
and how they want to trade things off.

If whoever is providing the content wants to avoid that, then they should 
jump through the .htaccess hoops; or put each file in its own directory so 
extensions can be dropped completely; or (more likely) use some other 
content manager rather than the filesystem. That's nothing to do with the 
user nor the server configuration.

So .shtml seems to me to be no better nor worse than .html. Both make 
significant implementation assumptions.

I note that Savannah.gnu.org has plenty of .php extensions and similar.

Jifl
[1] cf. <http://www.w3.org/Addressing/URL/uri-spec.html> which indicates 
the only constraint really is that slashes imply a hierarchical structure.
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
Visit us at Embedded World 2005, Nürnberg, Germany, 22-24 Feb, Stand 11-124
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine