HTTP requests are not things that humans discovered in nature. They are abstractions, created entirely by specification. In some sense, an HTTP request is exactly that which conforms to the specification.
> HTTP requests are not things that humans discovered in nature. They are abstractions, created entirely by specification.
They're created by something, but that something has more to do with a million blog posts and hallway conversations than it does with the formal RFC process. Certainly for most specifications of this kind, the working code came first and the specification was based largely on discovering what existing implementations did. If what the specification says is different from what HTTP clients send and HTTP servers understand, so much the worse for the specification.
You don't have to run an HTTP server very long on the internet to start discovering HTTP requests (including malformed HTTP requests, which are also a kind of HTTP request), 'in nature'.
If you can completely ignore HTTP request data that happens to not perfectly meet the RFC at your work (or, more specifically for us, Modbus RTU responses), I salute you. Sadly, I can’t, we get some wild stuff that we still need to attempt to handle. Both HTTP and Modbus!
To be less snarky, the RFC defines what a well-formed HTTP request is. In the wild there are a lot of malformed HTTP requests that business cases may require handling.
I suppose the “parse don’t validate” philosophy would recommend first transforming the I’ll formed request into a data structure that only models well formed requests, before it’s processed by any other part of the program.
Which I agree, is a poor design choice. A type modeling an HTTP request should model the RFC definition as closely as possible.