W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1996

Re: Improve the traffic condition on the Internet (fwd)

From: Mirsad Todorovac <tm@rasips2.rasip.etf.hr>
Date: Fri, 22 Mar 1996 10:53:26 +0100 (MET)
Message-Id: <199603220953.KAA05828@rasips2.rasip.etf.hr>
To: hammond@csc.albany.edu (William F. Hammond)
Cc: megazone@livingston.com, www-talk@w3.org
> 
> It was just said:
> 
> >  . . .  Monitoring even small sites shows that nearly all users still
> > download the graphics and text is *not* the majority.   . . .
> 
> If the "monitoring" is just counting bytes, then that is probably true.
> 
> But I suspect that most of the useful information delivered through
> http is either text/plain or text/html.  Unfortunately, it's common
> for 10 KB of useful text/html to travel with 30 KB of IMG baggage.
> 
>                                    -- Bill

This compression issue has been solved in HTTP protocol, via Accept-Encoding/
Content-Encoding headers.  However, not all browsers support this, and those
who do so, they do not indicate it via e.g.

	Accept-Encoding: x-gzip, x-compress

Then server could compress the information (text or html) via best available
method (or use cached result of previous information), with drastic _INCREASE
OF SPEED OF TRANSFER_.  This means simply that you have to wait less for
the same page [even on the local server it's faster, not speaking about
backbones]. When you talk about something like _common good_ etc., you will
not gain too much attraction, but this is the benefit of the individual user.

Now, Mosaic and Netscape support this for long time, and it's not "another
layer" or "big task" ... It's there ready and waiting.  However, two things
are missing:

	o	browsers do not indicate that they are capable to decompress
		on-the-fly (solution: list of browsers/versions + content of
		User-Agent: header field)

	o	servers do not compress on-the-fly.  Now, that's very simple
		to change -- just spawn gzip, it's PD.

Actually, we see that all of this work can be done on server.  Browsers are
ready.

Server needs to:

	a)	check if browsers supplied Accept-Encoding: header.
		if it did, compress via best available method.

	b)	if not, then the server needs to check given User-Agent: header
		field against a bultin list of browsers/their-capabilities and
		this way determine if the browser can accept
		e.g. Content-Encoding: x-gzip or some other and send by
		best available means of compression.

Server process can easily decide whether and by which method to compress
information by media type list:

	 (eg.
	text/plain: x-gzip, x-compress
	text/html: x-gzip, x-compress
	image/gif:
	audio/basic: x-adpcm, x-gsm
	... etc ...).

	c)	Server indicates with Content-Encoding: header field whether
		and which compression method was used. [If the field is
		ommited, browser implies no compression is used other than
		implied by media type (gif is already compressed etc.)]

You might object that this increases load on server, but actually HTTP server
process lays around for shorter time for transmission so it's maybe not that
critical. [Some comments on this?].

> 
> 


-- 
    | Mirsad Todorovac					|
    | Faculty of Electrical Engineering and Computing	|
    | University of Zagreb				|
    | Unska 3, Zagreb, Croatia 10000			|
    |							|
    | e-mail: mirsad.todorovac@fer.hr			|
Received on Friday, 22 March 1996 05:01:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:19 GMT