On 29 Feb 2008, at 16:33, Julian Reschke wrote:
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.
And guess what? Users don't like error messages. I want to know how to
deal with it without having to look elsewhere (from the spec).
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.
A page (<http://www.toledoblade.com/apps/pbcs.dll/section?Category=RSS01&mime=XML
>) that I came across recently had:
Content-Type: XML
Content-Type: text/XML
Using the first would break badly. I guess it seems to work because of
content-type sniffing on an unknown (and invalid) header (or, as many
feed readers do, totally ignoring it, with the exception of any
charset parameter). Without content-type sniffing, that HTML 5 now
allows, you need the last.
But as James says: how do I know that which behaviour I choose doesn't
matter until I reverse engineer browsers to discover that?
--
Geoffrey Sneddon
<http://gsnedders.com/>
