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

Daniel DuBois:
>[Koen Holtman:]
>> Accept: text/html, image/gif, image/jpeg;q=0.7, */*;q=0.9
>>[...]
>>this would make the server send me text/x-tex, and my browser
>>can't even handle text/x-tex!!
>
>Well, you DID say */*;q=.9.... Try */*;q=.01.... 

*/*;q=.01 is almost the same as not using any * in the Accept header.
See the discussion of the second case in my original message for the
disadvantages of that.

>And I don't think the case
>of a server trying really hard to force a particular MIME type down a user
>agent's throats is going to be a frequent one.

The case I discussed was the case of the mime type with the best
_source_ quality not being listed in the Accept header.  This is a
frequent one.  With short enough Accept headers, it occurs whenever a
document not written in HTML (but in tex, latex, word, wordperfect,
...) is published, both in the original form and in a (much less
attractive) HTML form, on the web.

>  Negotiation is going to come
>into play mostly for deciding whether to send a GIF or a JPG, and servers
>will generally trust the UA's preferences when it comes to
>negotiation.

Trust has nothing to do with it.  This is not about the UA's q values,
it is about qs, source quality values.

[...]
>>- send small Accept with *: risk getting responses with mime types you
>>  can't handle
>
>A UA can always "Save As".
>
>>- 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!

You Have Greatly Misunderstood The Purpose Of Content Negotiation.

Negotiation is _not_ about making the client software `happy' because
it gets a format that can be displayed internally.  

It is about making the _user_ happy by making the client retrieve and
display the format that has the highest overall quality.

The user will not be happy if the client does a `save as' for a format
the user likely has no viewer for anyway, nor if the client displays a
crappy html version of a tex document while a much better dvi version
could have been displayed.

[...]
>  I am not willing to call it
>a problem however, because I am not willing to say there is a fix.

Problems without a fix are not problems?

Anyway, there is a fix, and I described it in my previous message.
The fix will occasionally lead to a 300 response, but not always.

I was not suggesting that there could be a fix that would eliminate
all reactive (300 and 406) negotiation _and_ use short Accept headers
too.  My fix would however lead to reactive negotiation on only a
small percentage of all URI's.

[...]
>Maybe something like:
>A.  if ( (q[maxQitem] != maxq) || (qs[maxQitem] != maxqs) )
>        then send 300
>would appease you?

I already gave the rule that would appease me:

     if ( every maxQitem was derived from a media _range_ (something
          with *) in the Accept header )
        then you should send a 300.

[...]
>PS: With keepalives, reactive negotiation becomes alot cheaper.  Maybe 300's
>should be sent under a greater number of circumstances on a keepalive
>connection?

No.  With keepalives, round trip times for reactive negotiation do not
go away, but the overhead of a long Accept header does diminish,
because the Accept header only needs to be sent once and can then
apply also to all future requests.  So it is the preemptive
negotiation that gets cheaper.

>  Did I just make an evil statement?

You just made a wrong statement.

>Dan DuBois, Software Animal                          ddubois@spyglass.com

Koen.

Received on Saturday, 9 September 1995 14:21:32 UTC