3 ms·
This is not a correct interpretation of the spec, as far as I can tell. I did some more research on this + primary sources on my blog if you're interested in wh
by treve 2y ago
This is not a correct interpretation of the spec, as far as I can tell. I did some more research on this + primary sources on my blog if you're interested in why and why people are confused about this:
https://evertpot.com/get-request-bodies/ https://evertpot.com/get-request-bodies/
- BugsJustFindMe 2y agoYour post puts a tremendous amount of weight on how you personally feel about using it across load balancers that you don't control and whatnot, but you also still acknowledge that it doesn't violate the spec. > It’s true that undefined behavior means that you as a server developer can define it Good. Agreed. Done. Someone else complying with the spec in an incompatible way doesn't make your compliance wrong. It just reduces the circumstances where it will work. But those circumstances are...well... circumstantial. And I think it's important to establish that there's a meaningful difference between "won't work as expected in certain common but not universal circumstances" and "not allowed to at all".
- treve 2y agoYou either didn't read what I wrote, or are homing in on the things that are ambiguous vs the things that aren't. (or I'm just a bad writer). One thing is not ambiguous: The intent, as stated by one of the primary authors of the HTTP specification has "no semantic meaning" and "is never useful to do so". You can do something different and assign meaning to the body, but it's no longer HTTP. So you are correct, it's not disallowed, just pointless. I'd also recommend you read the latest version of the HTTP spec. It's a bit more direct about this. You can disagree with the authors of the HTTP spec of course, but I'm not interested in having that argument with you.
- deleted 2y ago[deleted]