Server::run abruptly returns when a response payload is too large
jasta opened this issue · 4 comments
I recently hit a case where I had too large of a response payload which resulted in a quite confusing error as it returned from server.run() only to panic based on server.run(...).await.unwrap():
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidData, error: "CoAP error: invalid packet length" }', src/main.rs:69:14
I understand we don't have Block1/2 (RFC 7959) support, however we should be able to do better than "crash" the server in this case. At a minimum I think we want to make sure I/O errors during server.run() don't return for every customer since that would easily allow for a DoS attack. Maybe just isolate self.server.send(...) errors and log them instead of returning?
Out of curiosity as well, what would it take to actually implement RFC 7959 support? It seems like we'd need to do some kind of caching by (Token,Endpoint) for some period of time and then add some request/response handling to add/interpret Block2 options accordingly when serving our cached result. Shouldn't be too bad though, right? I might take a crack at a generic implementation downstream of coap-rs and see if it can't be ported back into the core if there's interest.
Awesome thanks for the pointer, I'll take a look and see if this can be done cleanly on the latest codebase.
I've got the block support working but realized that it might be better to merge the lower level part I built into coap-lite instead, then a separate smaller PR here to integrate it automatically. See martindisch/coap-lite#21
Unfortunately after trying pretty hard to make this and Observe support integration work I've decided I need to go a different direction and start a new project with a higher level API goal for cleaner integration: https://github.com/jasta/coap-server-rs. While coap-rs has been extremely useful in getting me started there are some pretty significant architectural challenges that would need to be overcome for good generic support for more advanced features and that would end up taking the project in a very different direction with potentially a lot of disruption to current users. For now I'm choosing to incubate a more experimental but convenient approach in the linked repo above (which does have transparent Observe and Block-wise support)