* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #81 (closed design: fixed)

Opened 7 years ago

Last modified 5 years ago

Content Negotiation for media types

Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: 09
Component: p3-payload Severity: Active WG Document
Keywords: Cc:
Origin: http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html

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

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

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

  • Owner set to LMM@acm.org
  • Component set to auth

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

comment:2 Changed 7 years ago by mnot@pobox.com

  • Milestone set to unassigned

comment:3 Changed 7 years ago by mnot@pobox.com

  • Component changed from auth to payload

comment:4 Changed 5 years ago by henrik@henriknordstrom.net

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 5 years ago by mnot@pobox.com

  • Owner LMM@acm.org deleted
  • Priority set to normal

comment:6 Changed 5 years ago by mnot@pobox.com

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

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 5 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution wontfix deleted

comment:8 Changed 5 years ago by masinter@adobe.com

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 5 years ago by mnot@pobox.com

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

comment:10 Changed 5 years ago by julian.reschke@gmx.de

  • Milestone changed from 08 to 09

comment:11 Changed 5 years ago by masinter@adobe.com

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 5 years ago by julian.reschke@gmx.de

proposed path for part 3

Changed 5 years ago by julian.reschke@gmx.de

Proposed patch for part 3.

comment:12 Changed 5 years ago by julian.reschke@gmx.de

From [745]:

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

comment:13 Changed 5 years ago by julian.reschke@gmx.de

Fixed with 09, pending review.

comment:14 Changed 5 years ago by mnot@pobox.com

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