Opened 10 years ago

Closed 8 years ago

#81 closed design (fixed)

Content Negotiation for media types

Reported by: mnot@… Owned by:
Priority: normal Milestone: 09
Component: p3-payload Severity: Active WG Document
Keywords: Cc:

Description

HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out. The original theory of content negotiation was worked out when the idea of the web was that browsers would support a handful of media types (text, html, a couple of image types), and so it might be reasonable to send an 'accept:' header listing all of the types supported. But in practice as the web evolved, browsers would support hundreds of types of all varieties, and even automatically locate readers for content-types, so it wasn't practical to send an 'accept:' header for all of the types.

So content negotiation in practice doesn't use accept: headers except in limited circumstances; for the most part, the sites send some kind of 'active content' or content that autoselects for itself what else to download; e.g., a HTML page which contains Javascript code to detect the client's capabilities and figure out which other URLs to load. The most common kind of content negotiation uses the 'user agent' identification header, or some other 'x-...' extension headers to detect browser versions, among other things, to identify buggy implementations or proprietary extensions.

I think we should deprecate HTTP content negotiation, if only to make it clear to people reading the spec that it doesn't really work that way in practice.

Many people seem to use HTTP content negotiation as a motivation for adding 'version' parameters to MIME types or registering new MIME types, with the hopes that the MIME types or parameters would be useful in HTTP content negotiation, and we should warn them that it isn't really productive to do so. That's why it might be useful advice to add to the guidelines for registering MIME types, should those ever be updated.

This may also affect the text that describes the circumstances when a 406 may/must be sent.

Attachments (2)

i81.diff (6.7 KB) - added by julian.reschke@… 8 years ago.
proposed path for part 3
i81.2.diff (8.0 KB) - added by julian.reschke@… 8 years ago.
Proposed patch for part 3.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 10 years ago by mnot@…

  • Component set to auth
  • Owner set to LMM@…

Larry Masinter agreed to come up with a proposal for text in Vancouver.

comment:2 Changed 10 years ago by mnot@…

  • Milestone set to unassigned

comment:3 Changed 10 years ago by mnot@…

  • Component changed from auth to payload

comment:4 Changed 8 years ago by henrik@…

I disagree that content negotiation does not work in general. Sure it has limitations when it comes to wide range properties like Content-Type negotiation, but if one considers that clients in most cases MAY retry the request with a different Accept setting if the result they got the first time wasn't acceptable it still works out quite well even for Accept/Content?-Encoding. Remember that Accept can include negative selectors saying "I do NOT want this" (q=0) as well as positive ones of varying degrees (q>0).

comment:5 Changed 8 years ago by mnot@…

  • Owner LMM@… deleted
  • Priority set to normal

comment:6 Changed 8 years ago by mnot@…

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

Larry commented that he didn't feel this strongly any more, and couldn't come up with more specific text. No one else stepped forward to volunteer text.

comment:7 Changed 8 years ago by mnot@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:8 Changed 8 years ago by masinter@…

http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0792.html

Proposed rewording sent to mailing list, should be incorporated into draft.

comment:9 Changed 8 years ago by mnot@…

  • Milestone changed from unassigned to 08
  • Severity set to Active WG Document

comment:10 Changed 8 years ago by julian.reschke@…

  • Milestone changed from 08 to 09

comment:11 Changed 8 years ago by masinter@…

Update proposed rewording, and suggestions for leaving 4.1 and 4.2 but replacing 4.3 just with reference to TCN RFC:

see

http://lists.w3.org/Archives/Public/www-tag/2010Jan/0036.html

Changed 8 years ago by julian.reschke@…

proposed path for part 3

Changed 8 years ago by julian.reschke@…

Proposed patch for part 3.

comment:12 Changed 8 years ago by julian.reschke@…

From [745]:

Add new introduction about Content Negotiation, remove section about transparent conneg, instead just mention RFC 2295 (see #81)

comment:13 Changed 8 years ago by julian.reschke@…

Fixed with 09, pending review.

comment:14 Changed 8 years ago by mnot@…

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