Multipart/mixed for many inline images (was Re: Toward Closure on HTML)

lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
Errors-To: listmaster@www0.cern.ch
Date: Fri, 8 Apr 1994 14:13:22 --100
Message-id: <94040813074442@cguv5.cgu.mcc.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Multipart/mixed for many inline images (was Re: Toward Closure on HTML)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2308
masinter@parc.xerox.com said:

>[I said:]

>> The browser can tell the difference by parsing the link.

>Did you get a reply to this?

Not really. The current stuff about the DTD seems to have somewhat swamped my 
suggestion.

>The browsers can't tell what type a URL is by parsing the link.

Could you elaborate? It seems to me that they can. If a link is of the form 

  http://site/path/blah.html     its an html file
  http://site/path/blah.tif      its an image, etc.

Sure if someone defined *.gif to be text/html in their servers list of mime 
types that might be a problem, but that would be perverse in the extreme. How 
many html pages are there on the web, and what percentage of them do not have a 
file type of .html or .htm (for broken DOS systems ;-0 )

All a browser would have to do is detect that the link it is about to follow is 
to an html file, switch on or off image types in the accept field as 
appropriate, then add multipart/mixed in the accept field.

Marc suggested that my suggestion wasted already cached images, which is true; 
but then if they are all retrieved in a block the inefficiency is not that 
great.

An alternative would be to have the browser construct a list of images in the 
current document that are not in the browsers cache; however extending the 
syntax of a GET to allow lists seems a bigger task. Could be the way to go, 
though.

Apart from that, and Marc's comment, the topic seems to have sunk without trace. 
A pity; it seemed such a simple, largely impact free optimisation, primarily 
using  existing technology.

Chris Lilley
+-----------------------------------------------------------------------------+
| Technical Author, ITTI Computer Graphics and Visualisation Training Project |
+-----------------------------------------------------------------------------+
| Computer Graphics Unit,        |  Internet: C.C.Lilley@mcc.ac.uk            |
| Manchester Computing Centre,   |     Janet: C.C.Lilley@uk.ac.mcc            |
| Oxford Road,                   |     Voice: +44 61 275 6045                 |
| Manchester, UK.  M13 9PL       |       Fax: +44 61 275 6040                 |
| <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">click here</A> | 
+-----------------------------------------------------------------------------+