SSI for gzipped files

[- Barry - <ma...@polisource.com>]

I have an idea for someone to implement and give me credit for. I recently 
needed to have my SSI work from a gz file. The server-intensive way to make 
that work is to decompress the file to read the SSI, make the changes, then 
optionally compress it again before sending it to the client. There's are 
better ways, which browsers would have to be developed to support, in some 
cases with no change to the servers. Since the www-html list has been giving 
me trouble, I'm posting the idea to this list. The best solution requires 
server support anyway.

Have the server store SSI directives and the names of the files that contain 
them separately from the files when the files are compressed on the server. 
If the files were uploaded already compressed, then any SSI and file names 
should be uploaded separately, uncompressed. When a compressed shtml file 
(with SSI) is requested by a browser, the server would process the SSI 
without having to decompress the file that contains it, and would send a 
supporting browser the processed SSI in addition to the main file for the 
browser to combine after decompression. This could also be a security 
feature because the file name could be omitted from a virtual-include 
directive, and the text "virtual-include" alone could be the marker for 
where the markup gets inserted, so even if the browser can't include the 
markup from the SSI directive, the URL from the include won't be visible.

If the server doesn't support that and the browser receives a gzipped file 
with SSI in it, the browser should check for alternative support for gzipped 
SSI, which would be for the server to send an ID code with the gzipped file, 
which the browser would send back to the server along with the uncompressed 
SSI directive, so if the ID is correct, the server would process the SSI and 
send it to the browser to be combined with the webpage.

The final backup method would require no special server support at all. The 
browser would just decompress the file, request the page at the URL that's 
in the SSI directive, and if HTML is served, the browser would insert it 
into the webpage.

Barry 



-- 
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

Re: SSI for gzipped files

[- Barry - <ma...@polisource.com>]

> 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

Re: SSI for gzipped files

[Nick Kew <ni...@webthing.com>]

On Fri, 22 Jul 2005, William A. Rowe, Jr. wrote:

> At 04:17 PM 7/22/2005, Jem Berkes wrote:
> >> I have an idea for someone to implement and give me credit for. I
> >> recently needed to have my SSI work from a gz file. The server-intensive
> >> way to make
> >
> >Interesting, I've wanted to accomplish the same thing but couldn't figure
> >out a good way to do it. Maybe there are a lot of people who need this?
>
> I think we need a slightly more intellegent hook insertion
> schema; something that a hook can identify what C-L/C-T/T-E that
> it can grok (SSI would play stupid, of course) and httpd would
> inject appropriately registered filters in front, and afterwards.

Indeed.  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.

> The exact schema and syntax escapes me at the moment, but this is
> something that interested Nick Kew, refactoring our filter ordering
> and registration schema.  You raise a good point for the crowd to
> consider.

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, and supports serverside processing of
compressed or otherwise encoded contents in a proxy situation
where you have absolutely no control of the incoming contents.

-- 
Nick Kew

Re: SSI for gzipped files

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 04:17 PM 7/22/2005, Jem Berkes wrote:
>> I have an idea for someone to implement and give me credit for. I
>> recently needed to have my SSI work from a gz file. The server-intensive
>> way to make
>
>Interesting, I've wanted to accomplish the same thing but couldn't figure 
>out a good way to do it. Maybe there are a lot of people who need this?

I think we need a slightly more intellegent hook insertion
schema; something that a hook can identify what C-L/C-T/T-E that
it can grok (SSI would play stupid, of course) and httpd would
inject appropriately registered filters in front, and afterwards.

The exact schema and syntax escapes me at the moment, but this is
something that interested Nick Kew, refactoring our filter ordering
and registration schema.  You raise a good point for the crowd to
consider.

Bill 

Re: SSI for gzipped files

[Jem Berkes <jb...@users.pc9.org>]

> I have an idea for someone to implement and give me credit for. I
> recently needed to have my SSI work from a gz file. The server-intensive
> way to make

Interesting, I've wanted to accomplish the same thing but couldn't figure 
out a good way to do it. Maybe there are a lot of people who need this?