Re: Deploying new versions [Was: Versioning HTML at the

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Mon, 31 Oct 1994 05:00:34 +0100

Thus wrote: Brian Behlendorf
>Well, fine, servers serve HTML 2.0 docs as "text/html" and
>HTML 3.0 docs as "text/html; version=3.0". Browsers that implement all
>or part of HTML 3.0 should send an Accept field of "text.html;
>version=3.0", so servers can optionally be intelligent about what
>versions of documents they serve. The only missing link I see is how
>document authors tell servers their documents are HTML 3.0 - most servers
>base this on file extension (i.e., .html files are "text/html") so I
>don't see an easy way around defining a common file extension like .htm3
>or something.

Well, filename extension mappings are mostly a local problem. There
do need to be some additional suggestions.

One needed change is that the HTTP spec needs to at least hint at what
a server should do if a document is requested but the server cannot
deliver it in any of the Accept:ed formats. Return the document as
application/octet-stream? Return an error? Which one?

In any case, this also has problems with existing systems. Servers
could, in principle, assume that accepting "text/html" with no further
qualifiers means support for up to version 2.0, but handling "*/*" and
"*" (what the latter means is beyond me, but NetScape seems to
generate it) is much harder.

I don't think we're willing to declare that "When the client says it
will accept anything, it doesn't really mean *anything*" and require
every server implementation have complete historical knowledge of
client history. This is going to make it mighty difficult for servers
to allow the same document to be available in HTML 2.0 and HTML 3.0 in
a transparent fashion.

--
Marc VanHeyningen  <http://www.cs.indiana.edu/hyplan/mvanheyn.html>