W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Connection Header

From: John Franks <john@math.nwu.edu>
Date: Sun, 18 Dec 1994 23:52:58 -0600 (CST)
Message-Id: <9412190552.AA02631@hopf.math.nwu.edu>
To: Rob McCool <robm@neon.mcom.com>
Cc: john@math.nwu.edu, frystyk@www0.cern.ch, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
According to Rob McCool:
> 
> ... why not modify either Connection or Allow:MGET so
> they are ignored when a client is talking to a proxy? That is, if I'm
> a Connection or Allow:MGET aware client, I ignore these headers unless
> I also get Proxy-connection or Proxy-allow:MGET?
> 

Of course you are right.  This is a much better solution.

> 
>  * Any proposal
>  * that can't at least match the user's perceived performance which
>  * Netscape obtains with multiple connections is not viable. It's a
>  * competitive world out there and browser writers will have to go
>  * with multiple connections if nothing else matches their
>  * performance.  Any proposed standard, MGET or stay-open, which can't
>  * measure up to multiple connection performance just won't be
>  * implemented.
>  */
> 
> Yes, and to that end we have to keep in mind that while <img width=N
> height=M> is useful, it means that in order to see that performance
> win, everyone has to edit their HTML. That will take time, and
> Netscape's perceived performance works everywhere without having to
> edit (or parse) every single HTML doc on a server...
> 

This is a very important point and one that I hadn't fully considered.
Since the WN server keeps information about files in a data base and
parses the header of an HTML doc when it is entered in the data base
(to extract title and <meta> information like Keywords and Expires) I
had in mind parsing the whole doc at that time for information about
images.  But, but I am not sure how NCSA and CERN httpd would handle
this.  Since the vast majority of HTML docs served on the Web are
served by NCSA and CERN httpds we need something that can easily be
made to work with them.  I don't think it is reasonable to expect
authors to add the height and width.  Well, it may be reasonable, but
it is not realistic.

Also Mark VanHeyningen rightly points out that maybe headers devoted to
a single content-type (HTML) aren't really appropriate.  Maybe the
inlined file sizes could be put in the HTML header with some 
kind of <META> tag.  I would be easy to write utilities to insert these
headers for new or existing HTML documents, but getting people to use
the utilities is another issue.

I think this problem of communicatin inline image sizes before the
images themselves are downloaded is really central.  If an MGET or
SESSION methnod can't deal with this issue then there isn't much point
in implementing such a method in HTTP1.1.  Browsers won't use it but
will opt for multiple connections instead.


John Franks
Received on Sunday, 18 December 1994 21:54:08 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:10 EDT