Re: RDF Update Feeds + URI time travel on HTTP-level

2009/11/25 Michael Nelson <mln@cs.odu.edu>:
> In practice, agent-driven CN is rarely done (I can only guess as to why). In
> practice, you get either server-driven (as defined in RFC 2616) or
> transparent CN (introduced in RFC 2616 (well, RFC 2068 actually), but really
> defined in RFCs 2295 & 2296).  See:
> http://httpd.apache.org/docs/2.3/content-negotiation.html

My guess is that it relies on users making decisions that they aren't
generally qualified, or concerned enough, to make. Considering
language is basically a constant from the users operating system
configuration, and format differences do not affect users enough to
warrant giving them a choice between XHTML and HTML, or JPG and PNG,
for example. I think browser designers see CN as a good thing for
them, but basically irrelevant to users, and hence they decide it is
easiest to just automate the process using server or transparent
negotiation.

Similar reasoning about why Apache goes so far to try to break down,
what are likely unintentional mix-ups with equal q/qs value
combinations, as it reduces confusion the user. The fact that the
server and transparent CN processes rely on servers for part of the
decision (qs), makes it perfectly fine for them to make the tie
breaker decision in my opinion. There is basically no reason why the
choice the server makes will be inconvienient for users as they
already said that both formats or languages were acceptable in some
way through the Accept- headers. Combined with the servers knowledge,
the tie breaker will only choose one slightly better format compared
to another decent format, resulting in a win-win scenario according to
the users declared preferences. As long as the server sends back the
real Content-Type it chose I am happy.

Cheers,

Peter

Received on Wednesday, 25 November 2009 07:02:42 UTC