You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rob Hartill <ro...@imdb.com> on 1997/05/19 11:18:27 UTC

Re: Apache deflation option

On Mon, 19 May 1997, Dan Shearer wrote:

> Dear (responsive) Apache team,
> 
> This should be a very simple thing for an accomplished apache hacker to
> add, and one that would likely grab attention for version 2.0. I thought
> of it when looking at all the whitespace my nicely formatted #if XSSI
> include statements generate. 
> 
> Consider how much whitespace there is sent to a browser, for any HTML
> page. It would be very easy to just send the HTML markup, with either no
> whitespace or an enforced minimal-whitespace policy.

whitespace is often critical to the HTML rendering, e.g inside <PRE>

> Comments could be
> stripped.  This could be a big save for some sites at the very top and the
> very bottom of the web provision tree, those that take millions of hits a
> day and those that are on the end of 28.8k modems. The HTML code would
> still be just as compliant, and the overall load would be less. A cleverer
> implementation might optimise the HTML to do the same things in the most
> efficient way (a simple example might be removing </P> tags, if that is 
> considered universally acceptable.)

Yuck. Stripping HTML tags and making the results non-compliant HTML
just for the sake of a few bytes is a real bad idea.

> Potential problems:
> 
> 1. HTML authors (as opposed to users of Front Page, Pagemill etc) expect
> their code to served as-is, not rearranged by some facist web server! 
> 
> 2. This goes against the situation on the web today where if you want to
> see how something is done you just download the source and expect it to be
> fairly readable. However an HTML formatting program would soon inflate it
> again. 
> 
> So for now you could implement this as a configuration option, or even a
> skeletal module. I say skeletal because all it would need to do for
> version 2.0 is strip whitespace, and in the future smart HTML optimising
> algorithms could be added. 
> 
> Ultimately this could become part of the HTTP specification as a client 
> negotiation option. This is much more likely to happen if the most popular 
> server has been offering it as a module for some time :-)

HTTP and HTML are separate entities, you don't want HTTP dropping HTML
information that it can't regenerate at the other end. If you want to
reduce bandwidth compression is a much better option. HTTP has supported
compression for a long time, but the browser developers haven't
universally supported it despite some of us pleading with them for
years :-(

> Regards,
> 
> --
>  Dan Shearer                            email: Dan.Shearer@UniSA.edu.au

--
Rob Hartill                              Internet Movie Database (Ltd)
http://us.imdb.com/tour   .. a site for sore eyes.