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.