- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 29 Feb 2008 17:33:13 +0100
- To: Geoffrey Sneddon <foolistbar@googlemail.com>
- 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>
Geoffrey Sneddon wrote: >>> 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. > ... Doesn't seem to apply to this case. A duplicate Content-Type header response indicates that the response is invalid. Apparently, most browsers accept the response anyway, some of which picking the first value, others the second. Both behaviors seem to be acceptable to users. So there's nothing you *need* to reverse engineer in this case. BR, Julian
Received on Friday, 29 February 2008 16:33:39 UTC