httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: PLEASE READ: Filter I/O
Date Fri, 23 Jun 2000 06:17:13 GMT

In a message dated 00-06-22 22:35:39 EDT, Greg Stein writes...

> I believe Kevin's point is simply that many browsers (in use!) do not
>  support HTTP/1.1 and chunking.

...and even if they do say they support certain things they don't 
even work half the time.
Example: Early versions of MSIE ( 3.late and 4.early ) still put out 
the 'Accept-encoding: gzip,compress' field but if you send ANY
compressed data to those browsers you better hope the user has
a backup of their hard drive because they are going to get the
'blue screen of death'.

...and on the other end of the spectrum... the newest version of Netscape
suddenly NO LONGER 'says' it supports Content-Encoding when, in
fact, it really does. Go figure.

>  From a performance standpoint, this is a problem since it means HTTP/1.0
>  streams will need to close the connection. 

Exactly... and HTTP 1.1 streams too if the filtering scheme isn't done right. 

Bottom line: You can't do Keep-Alive unless Content-Length is always
100% accurate and this is where multi-layered filtering can fall down.

See other message to Jeff Trawick regarding 'real world examples'.

The Web has changed a lot since Keep-Alive came along and most sites
now DEPEND on it happening or the results are miserable.

>  I don't see any problems. All browsers that I know of can deal
>  with the "no content-length, so wait for connection close" approach.

See above. Of course they can 'deal with it'... but people in 
Africa have gotten used to malaria as well because they had to
but that doesn't mean they are happy about it.

Why create more malaria when all it takes is a little 
preventive medicine to avoid another outbreak?

Kevin Kiley...
CTO, Remote Communications, Inc. - Online Internet Content Compression Server

View raw message