A rule for Internet software
Here is one of the general rules for Internet software:
You cannot count on other people not screwing up.
(You can barely count on you not screwing up.)
Any time you talk to the Internet, you have to assume that someday, the other end will do something that it isn't supposed to by the specification. People are endlessly creative, which means that sooner or later someone will get pretty much anything wrong that it's possible to get wrong; for example, they will use permanent HTTP redirects for temporary situations.
Internet software that counts on the other end always getting it right is not robust software. Conversely, part of writing robust Internet software is asking yourself how the other end could get something wrong, what would happen to your software, and how you can make it still do what the user would like and expect. Features should be designed with this in mind, and you may find that they require more complicated implementations than you expected; the classical example of this is parsing syndication feeds, which in theory are perfectly formed XML.
(As a direct corollary, this applies to specifications too; any 'you MUST do alarming thing X if the other end says Y' language is at least potentially dangerous. Consider the merits of using SHOULD instead, especially since smart implementors are going to ignore your MUST anyways.)