3 ms·
HTTP 413 Payload Too Large is the appropriate response, not silently truncating content because you wanted to be ‘optimistic’ in your replies to clients.
by xctr94 3y ago
HTTP 413 Payload Too Large is the appropriate response, not silently truncating content because you wanted to be ‘optimistic’ in your replies to clients.
- madsbuch 3y ago> Pushover's API might be unusual in that it is used by a wide range of devices (embedded IoT things ... If you did that, and no error handling was implemented in the IoT device, it would merely result in a non-event that no one knows about. In this specific instance, the author is doing the right thing. The developer will see truncated messages running through. In the end it is a question on desired semantics. The semantics of the operation in question is obviously to truncate and process rather than fail.
- flir 3y agoPostel's Law? (I actually agree with you, I think it's a bad rule of thumb. I prefer Fail Fast (and loudly)).
- JimDabell 3y agoPostel’s Law is bad and has been the cause of countless bugs, including many security vulnerabilities. Some discussion here: https://news.ycombinator.com/item?id=9824638 https://news.ycombinator.com/item?id=9824638
- kiitos 3y agoThe message in question is being delivered to an end-user device, and is not expected to serve any purpose other than being displayed on a screen. In this context, it seems totally reasonable to truncate overly-long messages.
- lijok 3y agoCertain types of messages have legal and regulatory requirements about their contents. Assuming no such messages traverse your API and truncating them silently is a recipe for disaster.
- deleted 3y ago[deleted]
- kiitos 3y agoYes, that's true. What makes you think that the API described in this post would be subject to those kinds of legal and/or regulatory requirements? Could it be the case that the author knows prima facie that no such requirements exist for their service?
- lijok 3y agoThe API described is not subject to those kind of legal/regulatory requirements. The users of the API may be.
- kiitos 3y agoUsers don't dictate terms, though. How my API works is up to me. If I target use cases that prefer truncation of messages to errors, then surely it's acceptable for me to build it that way, right? I'm not saying it's a good idea in general. I'm saying it can be acceptable in the appropriate context.