Opened 9 years ago

Closed 9 years ago

#519 closed design (wontfix)

Request that the WG reconsider section 3.4: Content Negotiation

Reported by: julian.reschke@… Owned by: draft-ietf-httpbis-p2-semantics@…
Priority: normal Milestone: 25
Component: p2-semantics Severity: In IETF LC
Keywords: Cc:


Henry S. Thompson:

It's my impression that content negotiation hasn't turned out to play the kind of significant role in Web Architecture in general, or in HTTP use in particular, that was expected for it.

I think the section on conneg in p2-semantics [1] is so out-of-step with actually deployment, usage and expectations that to publish it as it stands would be a serious mistake.

In particular, the discussion of the relative disadvantages of the newly (re-)named 'proactive' and 'reactive' variants are not only out-of-date, but also this discussion appears to at least this reader to amount to a recommendation for 'reactive' negotiation. Yet as far as I can tell no user agents _or_ servers actually support this approach today, as it's described here.

I was sufficiently concerned about this question to undertake a moderately extensive empirical investigation [2]. To summarise perhaps too briefly, I found _no_ evidence of the use of reactive conneg in over 75 million HTTP request/response exchanges.

I think 3.4 can and should be substantially simplified, with all the evaluative/speculative prose removed, focussing simply on the semantics of the Accept... headers and the 300 and 406 status codes, perhaps also making clear that 'proactive' conneg is the only form of conneg with any signficant degree of server-side support.

[2] discusses all this at more length -- I hope it will be helpful. I am of course aware that personal experience, backed up by one small study, may well be misleading, but I did look moderately hard to find any other relevant experimental results without success. It is less likely, but not impossible, that what I report in [2] about what is implemented in IIS, Apache and the major web browsers is also mistaken. On either count, I would welcome concrete evidence of where I've misunderstood or misrepresented the actual situation.


[1] [2]

Change History (5)

comment:1 Changed 9 years ago by fielding@…

I think this ticket is based on a fundamental misunderstanding of the protocol and the various ways of negotiating content. Perhaps it would help to actually read these sections of the spec, since reactive negotiation is not limited to 300 and 406 responses and is, in fact, the most common form of content selection on the Web (any site that provides links to different language variations is using manual reactive negotiation). Automated selection is used extensively within the content management industry, primarily using client-side javascript libraries. Apache has implemented both forms of content negotiation (in a multitude of modules) since 1995.

comment:2 Changed 9 years ago by fielding@…

  • Resolution set to wontfix
  • Status changed from new to closed

comment:3 Changed 9 years ago by fielding@…

  • Milestone changed from unassigned to 25

comment:4 Changed 9 years ago by fielding@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:5 Changed 9 years ago by mnot@…

  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.