- From: Geoffrey Sneddon <foolistbar@googlemail.com>
- Date: Fri, 29 Feb 2008 16:22:51 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Ian Hickson <ian@hixie.ch>, Sam Ruby <rubys@intertwingly.net>, Robert Sayre <sayrer@gmail.com>, Anne van Kesteren <annevk@opera.com>, Sander Tekelenburg <st@isoc.nl>, ryan <ryan@theryanking.com>, Hugh Winkler <hughw@wellstorm.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Maciej Stachowiak <mjs@apple.com>, WHATWG <whatwg@whatwg.org>, "public-html@w3.org" <public-html@w3.org>
On 29 Feb 2008, at 10:54, Julian Reschke wrote: > Ian Hickson wrote: >> On Mon, 19 Nov 2007, Boris Zbarsky wrote: >>> Julian Reschke wrote: >>>> Multiple media-type values? What would that be good for? >>> Rendering the web? In particular, it's not uncommon for servers >>> (esp. when CGIs are involved) to produce things like: >>> >>> Content-Type: text/html; charset=ISO-8859-1 >>> Content-Type: text/plain >>> >>> which then get normalized to: >>> >>> Content-Type: text/html; charset=ISO-8859-1, text/plain >>> >>> Not sure where that normalization happens offhand (server end or >>> Gecko end). >> It seems like the HTTP spec should define how to handle that, but >> the HTTP working group has indicated a desire to not specify error >> handling behaviour, so I guess it's up to us. >> IE and Safari use the first one, Firefox and Opera use the last >> one. I guess we'll use the first one. > > Isn't the fact that FF and IE disagree here an indication that this > doesn't need to be specified? Things aren't specified well enough until I can write an HTTP UA that can work in the real world (which, as someone dealing with feeds, I can tell you need without question support for content-type sniffing) from reading specifications without having to reverse-engineer anything. -- Geoffrey Sneddon <http://gsnedders.com/>
Received on Friday, 29 February 2008 16:23:10 UTC