- From: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
- Date: Fri, 25 Jan 2008 23:22:15 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf-http-wg@w3.org
On Fri, Jan 25, 2008 at 01:00:47PM +0100, Julian Reschke wrote: > Frank Ellermann wrote: > >Julian Reschke wrote: > > > >>So, please have a look at > >> <http://www.hixie.ch/tests/adhoc/http/content-type/sniffing/> > >>and supply feedback on the expected results > > > >I don't understand test case 11, I'd expect the same outcome as > >for cases 9 and 10. > > That's because HTML5 tries to restrict content sniffing to precisely > three content type header values, see > <http://www.w3.org/TR/2008/WD-html5-20080122/#content-type-sniffing>. That's the best: html5 rules over what "text/plain" really means. Apart from that, I would like to ask you all: a) Which Content-Type makes pretty clear that the entity should be shown "as-is" in a specified encoding? (Meaning: show anything as something character like, exception: make line breaks (where? In case of doubt, make one)) [my "as-is" is what browsers do when showing "text without interpretation"] b) I request that any browser offers a possibility to show whatever it receives "as-is" (as described in a)), the same way a browser can be made to save whatever it receives in a file. Having a browser like that: what is the difference in "text/plain" being interpreted as "text/plain" or "application/octet-stream"? [see html5 content sniffing to know why I care] The only difference I see is wheter I get the "save as" dialog automatically or not... c) Knowing that it is easy to make a browser treat something as "application/octet-stream", but that it is not easy to make it handle content as "text/plain" (or "as-is"): Is it desirable to make a browser treat "text/plain" labled stuff as "application/octet-stream"? Robert
Received on Friday, 25 January 2008 22:21:59 UTC