Preemptive and reactive content negotiation

Roy Fielding:
>There are two ways to do content negotiation: preemptive or reactive.
>I think preemptive content negotiation is doomed to failure in the
>long term, which is why I added the 300 response code.  When the
>day comes that preemptive content negotiation (Accept* headers) are
>more costly than reactive (an extra round-trip carrying a URC),
>then browsers and server can switch without changing the protocol.

I think preemptive content negotiation on *all* types a browser
supports is too costly already.

If my browser supports image/potrzbie (probably through an external
viewer), I don't want to put this in every accept header I send out,
just because 0.001% of all URI's on the web have an image/potrzbie and
an image/gif, with image/potrzbie having the better quality.

I thought 300 responses were invented for this, the 0.001% could, on
only finding image/gif in my Accept header, send a 300 response.  You
talking about `in the long term' has led me to doubt this.

My question is this: can I construct an Accept header of a few 100
bytes long, without image/potrzbie, for which it is guaranteed that
the 0.001% sends me a 300 response allowing reactive negotiation
whenever image/potrzbie may have a higher quality than the image/gif
that is in my Accept header?

If the answer is no, than I propose that the spec be extended to make
such an Accept header possible.  Without this being possible, there
would be considerable pressure on Accept headers to grow very large,
which would be a bad thing.

> ....Roy T. Fielding Department of ICS, University of California, Irvine USA

Koen.

Received on Wednesday, 6 September 1995 14:49:41 UTC