Re: client-side include

> It is inelegant and breaks many useful properties of HTML. The external
> files referenced by such a tag would not be valid HTML (since they could

More importantly, it would not make sense as SGML, especially as SGML has
a perfectly good way of doing this, even if HTML doesn't allow its use.

> There are also extreme security risks, if one site can include arbitrary

Those risks would seem to apply to a validating XHTML parser, already.
(Although there maybe are none that also support scripting.)  In my view,
the real problem is with scripts in general.

> Use server-side includes.
> 
> Why should the client browser be expected to do your work for you?

Because it uses much less bandwidth, if standard sub-components of the
page are cacheable.  As well as requiring the whole page to prime the
browser cache, not just the unique-to-page part, as typically implemented,
server side inclusion tends to inhibit caching completely.  Cacheability may
be significant to Jonathon as he works in a low budget charitable/
public sector area.  (Many server side include applications do have
well defined overall modification dates or could have stable ETags, but
the possibility of more dynamic elements tend to mean that no cache
correlator is sent.)

I know Jonathon has proper server access, but server side includes are
not available to many people working on a budget; unfortunately ISPs tend
to see some basic server functions (I'm thinking more of cache-control)
as premium services.

Received on Tuesday, 7 January 2003 01:51:50 UTC