Re: Content negotiation

At 6:59 PM 11/7/95, George Phillips wrote:
>One of the big problems with the current scheme
>is that browsers and their helper apps can handle enough content types that
>it takes several KB just to list them.

This is not the most likely circumstance.  If you take all text but really
love HTML, send "text/html" with a higher q value than "text/*".  If you
have Super-Mega-Audio-App and you are confident that it knows all and hears
all, send "audio/*" and be done with it.  We're not talking about "several
KB" if the header is put together succinctly.  If a user wants to express
really precise preferences, that user will have a larger Accept header as a
result, but that's what you get for being picky.

I don't like "*/*" when it is done without a q value -- it should default
to the lowest quality and be read as, "beyond what I have already said,
I'll take anything so I can save it to disk (or whatever)."  UA's that are
just indexing HTML can then omit it to mean that they don't want anything
but HTML.  However, I _do_ like subtype globbing where appropriate.

[The last time I looked, which was admittedly quite a while ago, Bill Perry
was the _only_ one who had gotten anywhere near a reasonable
implementation.  If you want to see Accept done as well as it can be, look
at Emacs/w3.]

>I'd leave Accept: as is and let the browsers put in whatever is most
>likely (text/html, image/gif, imager/jpeg).  90% of time that is all (or more)
>than the server needed to know.

The browser can't know what what is "most likely" because the browser can't
tell the content-type of a document, nor possible variants, from its URL.
If I have a postscript version of <URL:http://www.server.dom/page.html>,
how are you supposed to know that this is one of those 10% cases where you
need to send "application/postscript" along with "text/html"?  If you're
like most people, you probably don't even have a helper app to display
postscript; but you very well might have access to a postscript printer.

Also, if the browser just sends whatever is most likely, and the Accept-URL
points to generic capabilities of the browser, how is the user supposed to
express preferences?  How is the server supposed to know whether you have
the RealAudio app installed?

Finally, if every browser sends a URL for some random server that describes
its capabilities, there would need to be some central registration of
"feature names."  Otherwise, everyone will just put "My browser does
tables" on their reference page, and convey little information.  If there
is a centralized server, at least there is some chance of having that
server deal with this in a reasonable manner (for instance:
        <table border= cellpadding= cellspacing= ...>
where each tag listed is recognized, and each "word=" is an attribute
recognized in that tag.  And that only works for HTML.  And that is not a
low-bandwidth solution.  And that still doesn't deal with the _values_ of
the attributes, which can vary [e.g. "width =(pixels|pct)"].
And....and...and...)

M. Hedlund <hedlund@best.com>

Received on Wednesday, 8 November 1995 14:04:15 UTC