You’re probably familiar with the robustness principle which is usually stated as:
Be liberal in what you accept, and conservative in what you send.
When it comes to standards, I’d like to offer a corollary:
Be precise in your description and flexible in your interpretation.
An example of where this corollary could be applied is in some browser developers’ handling of HTTP’s 301 Moved Permanently responses. According to RFC 2616, section 10.3.2 301 Moved Permanently:
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
That’s all well and good but permanence is an elusive thing on the web. Websites and applications tend to change quite a lot, especially during development. And when aren’t they under development? Even if mistakes were never made, the ownership of domains (and therefore URIs) is subject to change.
None of that would pose a problem in this instance if it weren’t for browser developers who cache 301 responses for a resource indefinitely and use one of the returned URIs for all future references to that resource.
But, but, but! . . . That’s what the RFC says they SHOULD do, right? And isn’t a good thing that they want to be called unconditionally compliant?
Yes. But that misses the point. The phrase any future references to this resource can be quite flexibly interpreted. Any future references handled by what exactly? Some browser developers have decided it should mean any future references handled by an installation of their browser. It would be a lot more reasonable, especially from the perspective of web developers, if the browser developers simply interpreted it to mean an instance instead, at least, in the absence of specific caching instructions.