Re: Problems with content negotiation (was: Re: Preemptive and

At 11:10 AM 9/9/95 -0500, John Franks wrote:
>According to Daniel DuBois:
>> 
>> >- send small Accept without *: risk getting responses with inferior quality
>> 
>> Inferior according to the server, maybe.  Not inferior according to the
>> client.  The client is perfectly happy with what they got, because they
>> asked for it!
>> 
>
>Maybe you didn't understand the point. It is very expensive for the client
>to fully ask for what it wants.  If it asks less than fully there is a
>good chance the client will not be happy with what it gets.  This is
>a problem and "Live with it" is not the solution.

Harumph!  I understand the point perfectly.  Don't confuse the different
circumstances.  Look back again at the exact circumstance I was replying to.
It is impossible for a client to get something it's "not happy with" with an
Accept: header that has no wildcard specifications.  Everything in it's list
are the types is presumably thinks are most important.

[Explanation lest you again insult my understanding of the subject:
Otherwise it gets a 406, and at that point can worry about accepting "lesser
variants" ("What?! 406?! Shucks, now I'll have to go to an external viewer
or do a save as, depending on the body of this 406").  Presumably a client
would have 1) internally supported MIME types, 2) externally supported MIME
types, and 3) everything else.  Also conceivably it would like q=1 for #1,
q=.5 for #2, and q=.01 for #3.  Lastly a UA could decide to send an Accept:
header that lists its #1s, and doesn't do a */*.  Then upon forced reactive
negotiation, it could pick and choose from the remaining variants to
hopefully get something that's in the #2 list, or let the user decide.  If
it gets 200 OK on the original request, it most definately IS "happy with
what it got".  The server might not be thrilled that it had to send out it's
crappy rtf2html version, but client is ignorantly bliss.]

>I think that the ultimate answer has to be something like always use
>reactive negotiation if there are muliple variants of a document.  There

Reactive negotiation necessitates a 2nd request.  This is exactly the
negative aspect Koen was complaining about, and I was trying to reiterate
with my "live with it/have your cake and eat it to" statement.  You simply
can't have it both ways. [Both ways = easy, one-trip, fully-specified
preemptive negotiation.]
-----
Dan DuBois, Software Animal                          ddubois@spyglass.com
(708) 505-1010 x532                     http://www.spyglass.com/~ddubois/

Received on Saturday, 9 September 1995 10:00:56 UTC