- From: Larry Masinter <masinter@adobe.com>
- Date: Tue, 1 Feb 2011 07:43:32 -0800
- To: Yves Lafon <ylafon@w3.org>, "Eric J. Bowman" <eric@bisonsystems.net>
- CC: "nathan@webr3.org" <nathan@webr3.org>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, Jonathan Rees <jar@creativecommons.org>, Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org" <www-tag@w3.org>
Wasn't there a proposed (or implemented) "I really mean the content-type header please don't sniff" HTTP header? Larry -- http://larry.masinter.net -----Original Message----- From: Yves Lafon [mailto:ylafon@w3.org] Sent: Tuesday, February 01, 2011 6:50 AM To: Eric J. Bowman Cc: nathan@webr3.org; ashok.malhotra@oracle.com; Jonathan Rees; Larry Masinter; Noah Mendelsohn; www-tag@w3.org Subject: Re: ACTION-472: New Mime-web-info draft On Mon, 31 Jan 2011, Eric J. Bowman wrote: > Nathan wrote: >> >> Aye, and I guess classing some URIs as "media types" based on the >> first x chars of the lexical form of the URI would not be a good idea >> (Opacity and all). >> > > It's a fine debate to have on rest-discuss, where we can talk about the > various philosophies of how self-descriptive messaging might function, > without limiting ourselves to the constraints imposed by HTTP. The > HTTP WG would be the right forum to suggest, in the absence of a > Content-Type header, falling back to some other header which allows > URIs as tokens -- without having anything to do with media types. Here, > though, we should treat decisions like the registry being targeted at > humans or not being URI-extensible (or existing at all), as having > already been made, IMO. The current fallback is sniffing, not another header. Adding a new header won't solve the issues outlined by Larry's document. That said, minting URIs to query a registry might be helpful. -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Tuesday, 1 February 2011 15:44:13 UTC