Re: content-type preferences

Daniel W. Connolly (connolly@hal.com)
Mon, 6 Feb 95 14:40:55 EST

In message <9502061834.AA23493@dragget.hpl.hp.com>, "Dave Raggett" writes:
>> As I pointed out earlier, Dan's idea does have one drawback by not
>> accomodating multiple formats - and I do wish someone would explain in 25
>> words or less how an html author provides input into how http "negotiates"
>> with clients about content type -- but a content type attribute clearly
>> beats hardwiring content type based on file extension. For one thing, an
>> attribute is easier to parse than a URL/filename.
>
>The solution is to create a URC entry that describes the resource and
>to get HTTP servers to use these entries to construct the content type
>and other attributes. We need to get URCs underway and soon ...

Hmmm... "the solution"?

As long as you're just talking about an interaction between one client
and one server that has multiple representations of an object, the
current HTTP protocol is sufficient. Deployment of some shared
metainformation in the form of URCs or whatever is only necessary for
distributed indexing in the spirit of harvest, Dienst, whois++, SOLO,
or one of those.

_A_ solution is to use the existing support in, for the example, the
CERN HTTPD server. The information provider (aka "html author")
creates a .multi file describing the various representations of the
object. The server uses the .multi info and the client's Accept:
headers to choose which representation to return.

This feature doesn't seem to be explicitly documented, but I know it's
in there.

It's clearly not used very much. See also: an earlier discussion on
on "Format Negociation in Practice"[1].

Dan

[1] "Format Negociation in Practice [Was:Versioning HTML at the server]"
Daniel W. Connolly (connolly@hal.com)
Tue, 18 Oct 1994 19:10:46 +0100
http://gummo.stanford.edu/html/hypermail/www-talk-1994q4/0255.html