The underlying idea is not new, but applying it to SSI
(a very specific *serverside* hack) doesn't make sense.  Javascript
has browser support, or if you're looking to something more SSI-like,
consider XML techniques that browsers might sometime support.

I don't think it makes sense to have a tag, SSI directive, or any such thing, be ineffectual just because a file is served compressed. Compression of a webpage should be transparent to a visitor, and a web developer shouldn't have to worry about whether SSI is used in any files that he wants to compress. He might have hundreds or thousands of files, and compression might not be practical if they use SSI. There's not even a "cannot process this directive" error when a compressed webpage using SSI is rendered, but that's mainly the browser's fault.

Javascript isn't as powerful as C or Perl or other languages that a developer would probably have access to on the server. The client would have to have Javascript turned on. If the script is time dependant, the client's clock has to be set correctly. The client's computer might be slow. The client's connection might be slow, creating slow loading of webpages that include long Javascript scripts. The script's author might not want it published.

Well, that's two things I've done in there.  One was to add an
uncompression output filter in mod_deflate; the other was the smart
filter architecture (mod_filter).  That's what the OP described as a
server-intensive solution...

My web host's CTO described it as "a tad bit excessive, even if it could be done, since compression algorithms aren't exactly cheap."

...and supports serverside processing of
compressed or otherwise encoded contents in a proxy situation
where you have absolutely no control of the incoming contents.

That was only one of my ideas, to make it unnecessary to store, separately from the compressed webpage, SSI directives and the files they're associated with. My client-as-proxy idea isn't necessary, but it would be a secure option in some cases.


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 7/19/2005

Reply via email to