freakerz asked an interesting question on the habari issues tracker.

How should we handle this kind of behavior? If the client does not use the APP properly, should we prevent the loss of information by catching/handling bad requests?
Of course, this is time to mention Postel's law, "be conservative in what you do, be liberal in what you accept from others." Again, of course, this solves nothing because there is an enormous amount of argument about what that means for implementors. There's already been a lot of discussion of this in relation to how aggregators should handle broken feeds.

The AtomPub spec does have something to say about how consumers should behave when they receive non-conforming content.
The Atom Protocol imposes few restrictions on the actions of servers. Unless a constraint is specified here, servers can be expected to vary in behavior, in particular around the manipulation of Atom Entries sent by clients. [...] Servers can choose to accept, reject, delay, moderate, censor, reformat, translate, relocate or re-categorize the content submitted to them. [...] The same series of requests to two different publishing sites can result in a different series of HTTP responses, different resulting feeds or different entry contents.

Aside: The anchor to this section is named "lark's vomit." Those wacky spec authors, I did but chuckle.

This doesn't answer the question at all for server implementers. It simply says you can do whatever you like when you receive stuff. The end user doesn't care, but they don't want to have their content rejected. This is a competitive business, and you don't want to lose clients, and you will if a competitor accepts something that you don't. People will switch.

Well-formedness is a minimum, so stuff that's not well-formed should stop processing. But in a nice way, that upsets the user as little as possible. So, we're really talking about invalid entries. Should there be specific code for producers that are known to create borked entries? More usefully, like testing for browser behaviour rather than a specific user agent, consumers should do their best to catch classes of errors and deal with them appropriately.

The server should accept all content and fail gracefully when it can't be consumed properly. When broken content is received server implementers have a responsibility to do everything they possibly can to work with the producer's builder to fix the problem, but in the meantime they should try to handle the broken content.