Should the validator not provide a warning (at the very
least) when the HTTP content-type header for an Atom
feed is something other than application/atom+xml?
According to the spec (section 2): Atom documents are
[...] identified with the "application/atom+xml" media
type.
I don't know if that's enough to justify an error, but
unless something is said about it, we're never going to
get one-click subscription working.
Logged In: YES
user_id=847250
Current behaviour is to accept the Atom media type or either
of the generic XML types. For interoperability
(specifically, at least, viewing in Mozilla browsers), there
are good reasons for using the more generic types until a
fix for
<https://bugzilla.mozilla.org/show_bug.cgi?id=155730> is
implemented and widely deployed.
It's a pragmatic decision, certainly, so there's room for
debate.Does this seem reasonable?
Logged In: YES
user_id=1371743
Assuming Phil is right in comment #33, I don't see what the
big deal is about that "bug". If the user has as an Atom
aggregator installed there isn't a problem at all. And if they
don't, well then I'm not really sure how seeing a page full of
incomprehensible XML is going to be any more useful to your
average end user than a save dialog. It looks like a geek
feature request to me.
Either way, I don't see what this has to do with the feed
validator. Either this is a violation of the Atom spec or it isn't.
Bugs in other people's software shouldn't come into it at all. If
it's wrong there should be an error or warning. Many servers
have problems serving the correct charset and most
aggregators simply ignore it, but that doesn't stop the
validator pointing out charset errors when they occur.