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

WIDTH and HEIGHT

From: John Franks <john@math.nwu.edu>
Date: Fri, 16 Dec 1994 16:15:45 -0600 (CST)
Message-Id: <9412162215.AA13404@hopf.math.nwu.edu>
To: "Eric W. Sink" <eric@spyglass.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
According to Eric W. Sink:
> --
> 
> I've heard another option suggested:  Have the inline image sizes returned
> by the HTTP server as headers when the base document is retrieved.  These
> hints could look something like this:
> 
> Image size: myfile.gif  image/gif  400x300  49152
> 
> Where the four components on the line are the [partial] URL, the MIME type,
> the image dimensions, and the size of the image file in bytes.  Current
> browsers could ignore them.  Browsers who make use of them will have to be
> able to cope with their absence.  Cool servers will keep a database of this
> information around so that it doesn't have to be looked up on the fly.
> 
> 

This is a very good suggestion.  A simple MGET proposal which included 
headers like this would be easy from the server side.  I'm not a client
writer, but I think it should not be too difficult there either.  One
could probably get user perceived performance similar to that of Netscape.
I think it would be cleaner than multiple connections and would it should
decrease bandwidth use slightly.  What Netscape has that this wouldn't
provide is the ability to draw all the images simultaneously rather than
sequentially, but I am not sure how important that is.

This proposal removes the onus of getting the image size from the author
and puts it on the server which is probably a good thing.

John Franks
Received on Friday, 16 December 1994 14:18:53 EST

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