Re: what type a URL is by parsing the link (was Re: Multipart/mixed for many inline images)
Steve Putz <putz@parc.xerox.com>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 8 Apr 1994 19:22:05 --100
Message-id: <94Apr8.101650pdt.2445@spoggles.parc.xerox.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: putz@parc.xerox.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Steve Putz <putz@parc.xerox.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: what type a URL is by parsing the link (was Re: Multipart/mixed for many inline images)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1357
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:
http://site/myurlformatisnoneofyourbusiness
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