Re: what type a URL is by parsing the link (was Re: Multipart/mixed for many inline images)

Steve Putz (
Fri, 8 Apr 1994 10:16:43 PDT

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

Chris Lilley wrote:
> 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 )

Wait a minute. URLs are not required to have an extension and (as you
pointed out) the extension is not significant with HTTP/1.0. I have
created servers that generate GIF images accessed via a URL like:


and respond with:

Content-type: image/gif

This is not perverse. It is just following the spec.

Now we should either require reliable type information in URLs or not.
But relying on URL extensions is a bad idea unless they are a well
defined part of the spec -- and they currently are not.

Specifically for inlined images the client might infer the type is some
kind of image because the URL appears within <IMG SRC="...">. But that
is different than using the URL extension.

-- Steve Putz