This tactic seems to betray a certain amount of naivety with regard to how closely most real-world HTTP implementations follow the specifications. (Hint: they d

This tactic seems to betray a certain amount of naivety with regard to how closely most real-world HTTP implementations follow the specifications. (Hint: they don't follow the specifications.) Remember Postel's law: "Be conservative in what you do, be liberal in what you accept from others." Unfortunately, you will have to return URLs to your users that are invalid. You will have to parse slightly malformed dates. Your clients will expect to be able to pass through malformed values from bad endpoints and not introduce a point of failure in your library. (Do you know about the "Cneonction: close" trick, for instance? All real-world proxies do all sorts of batshit-crazy HTTP header munging.) If your library can't accept and pass through arbitrary strings for arbitrary headers, and return them to users, and then accept them back again, then it is unlikely to be successful in any sufficiently complex and robust HTTP service.