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

Alan Emtage (bajan@bunyip.com)
Sun, 10 Apr 1994 23:40:16 -0400


[lilley@v5.cgu.mcc.ac.uk says:]
> >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 )

Just to reiterate what others have said, I would mention that URLs (as
currently defined) don't include typing information unless specifically
required to enable you to access the object.

There is a logic beind this: typing information can be complex. It
actually can be very complex (one level up :-). As a result the general
consensus in the URI group of the IETF decided that it would be left out
of the URL (which after all is a Locator) and put it into some other
beastie. People have complained about this in the past, and I'm sure will
continue to do so. However, my gut feeling is that it was the right
decision. We'll have to wait for the next construct (URCs) to come along
to get all that nifty typing information as well as copyrights, author
names and the like. It is dangerous to use filename extensions to
determine file types.

-- 
-Alan

------------------------------------------------------------------------------ Alan Emtage, "The Left in Canada is more gauche Bunyip Information Systems, than sinister" Montreal, CANADA -The Economist

bajan@bunyip.com Voice: +1 (514) 875-8611 Fax: +1 (514) 875-8134