Then the browser sends the request with the list of acceptable formats:
GET ... HTTP/1.0
Date: Sunday, 03-Oct-93 19:37:52 GMT
Accept: text/plain; text/html; image/gif; image/x-xbitmap
Then the server responds:
HTTP/1.0 200 Document follows
MIME-version: 1.0
Content-type: image/gif
...
Oh BTW. While we are talking about this part of the protocol I just want
to remind everyone that something like <EXTERN HREF="..." ISMAP> is *NOT*
needed. This information should be part of the returned object. The
reason I made <IMG ISMAP> is because at that time we only had HTTP0 clients
and servers. Since all the browsers will soon support HTTP/1.0 ISMAP is
depreciated in favor of server responses like this:
HTTP/1.0 200 Document follows
Public: GET HEAD SPACEJUMP
MIME-version: 1.0
Content-type: image/gif
...
The "Public: SPACEJUMP" is the trick (btw it might also be "Allowed: SPACEJUMP"
browsers must check in both locations). This means that the current
document can be manipulated in the curious way we happen to support
spatial indexing (the same way as ISMAP currently where the browser
sends the offsets in a query). All future extensions should be along
these lines. If you need an object to have attributes don't put them
in HTML, return them with the object. Remember those same objects
might be used by some other system than WWW in the future.
> the same time allows a lot more flexibility than we currently have. The
> biggest win comes when the client software has MIME to application mappings
It's the wrong approach.
> Inlined should always behave like characters, otherwise you can't do tiling
> and other important layout things.
Shame on you for mentioning "layout" :-)
> My other problem with <IMG SRC...> and <INC SRV...> is that they do
> different things depending on whether you're fetching via an HTTP server or
> a client. I don't have any easy answers right now, but I forsee major user
> confusion when people put together documents and test them locally, only to
> find out they don't work off a server because of access privs. relative
> pathing, etc. Any ideas?
I think hacking <INC> into the server is a bad idea. I've mentioned this
before. If you do that then you have really created a new type and it
should be filename.hacked-html instead of filename.html to make it
clear that it's not HTML. Then format negotiation would convert
text/x-hacked-html to text/html if required (and when browsers start
support <INC> They will just Accept: text/x-hacked-html).
--sanders