[email protected] (Kevin Altis) writes:
> Yeah, yeah, yeah, we know all that, what's your point. Well, a couple of things.
> I think we might be better off making <IMG SRC...> and <INC SRV...> into a
> single "inclusion" tag with a modified syntax to support an arbitrary set
> of inclusion types. What I have in mind is to put the MIME types into the
> tag syntax so you might do <INC text/html="..."> or <INC image/gif="...">
> or <INC sound/wav> or <INC x-command/. This simplifies the syntax and at
> the same time allows a lot more flexibility than we currently have. The
<INC> isn't part of HTML. It's a hack in the NCSA server. It's a
simple macro expansion. It has nothing to do with HTML or <IMG>,
nor should it.
[ My personal problem with <INC> is just that it tends to generate email
for me since people don't understand why foo.html doesn't work anymore
when they switch servers. If, for example, the NCSA server required
the files to be called foo.ncsa before <INC> worked I wouldn't care.
I understand *why* they did this (because some naughty HTTP0 browsers
look at the URL) but that doesn't mean I have to like the email :-)
]
You are confused about the file extension issue. I'll not explain it here
for fear of further confusion. Suffice it to say that this is a non-issue,
HTTP/1.0 objects are self-typing, no file extensions are looked at.
On moving this type of functionality into HTML (call it <IMG> <EXTERN>
<EMBED> or whatever), my basic argument still stands, one does not want
to type the reference to an object (HREF).
For example, a particular instantiation of the object:
<A HREF="http://www.bsdi.com/setext/usenet-email.etx">
might look like this (this is an actual example, try it):
HTTP/1.0 200 Document follows
Last-modified: Monday, 28-Jun-93 16:27:47 GMT
Date: Wednesday, 06-Oct-93 22:53:02 GMT
Server: plexus/3.0i
MIME-version: 1.0
Content-type: text/html
<TITLE>Usenet and Email Hypertext</TITLE>
...html document here...
Note the content-type. This does *not* depend on the file extension, it
only depends on the object. This object happened to begin it's life as
text/x-setext and got converted on the fly to text/html because the browser
doesn't support text/x-setext. If you had typed the link and the browser
didn't support text/x-setext you wouldn't be able to read that document.
To see the "source" try: http://www.bsdi.com/setext/usenet-email.etx.txt
--sanders