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