Is there any Rust web framework that does not have problem with Slow-Loris ? https://github.com/SergioBenitez/Rocket/issues/1405
The Serde Rust Framework
11–20 of 159 posts
Re: The Serde Rust Framework
#12serde is one of the best things about Rust in practice. It is more convenient to use serde to serialize/deserialize to some standard format like JSON or YAML than it is to write your own half-baked format and serialization/deserialization code --- even for the simplest tasks --- so you just stop doing the latter. This is a fundamental shift, and very good for your software. "Convenience" here actually covers a lot of…
I think in most ecosystems it's easier to use a prebuilt serializer/deserializer than your own format.
A generic JSON decoder would give you a dynamic structure that can contain anything, and then you'd have to pick it apart.
Re: The Serde Rust Framework
#13Missing fields default to some kind of default “zero value” - for any type, even full blown structs. You can’t tell the difference of a missing field or the field having the default value.
So if a field has a validation of “must be greater than zero”, you can’t really give a proper error message. If user puts in “0” or omits the field, you always get a value of “0”.
Re: The Serde Rust Framework
#14Is there any Rust web framework that does not have problem with Slow-Loris ? https://github.com/SergioBenitez/Rocket/issues/1405
This is interesting, and news to me. Your comment suggests something about Rust imposes this problem on all web frameworks, is that true? If so could you share the root cause?
Re: The Serde Rust Framework
#15serde is one of the best things about Rust in practice. It is more convenient to use serde to serialize/deserialize to some standard format like JSON or YAML than it is to write your own half-baked format and serialization/deserialization code --- even for the simplest tasks --- so you just stop doing the latter. This is a fundamental shift, and very good for your software. "Convenience" here actually covers a lot of…
I've done some benchmarking on JSON -> in-memory borrow structs and it was pretty darn impressive while being fairly ergonomic to use compared to a streaming parser.
Re: The Serde Rust Framework
#16Earlier quoted context omitted.
I think in most ecosystems it's easier to use a prebuilt serializer/deserializer than your own format.
Fair enough. I have not found that to be true in C/C++, which is my main point of comparison. For very simple cases it's generally easier to write a few lines to a text file, maybe with some whitespace separators in the lines, than to use an "real" format. For JS and Python, JSON.stringify/parse and json.loads/dumps are a step up, but you still end up with an untyped mess with no schema validation, which makes them o…
Re: The Serde Rust Framework
#17Re: The Serde Rust Framework
#18Earlier quoted context omitted.
This is interesting, and news to me. Your comment suggests something about Rust imposes this problem on all web frameworks, is that true? If so could you share the root cause?
I'm just newbie in Rust. Does some web framework not use hyper? I'm trying to find web framework that does not have problem with Slow-Loris.
Re: The Serde Rust Framework
#19Earlier quoted context omitted.
I think in most ecosystems it's easier to use a prebuilt serializer/deserializer than your own format.
The trick with Serde is that it decodes straight into a native Rust struct. You get most of validation for free (it also nicely takes advantage of Rust enums with data), and struct access is maximally fast. A generic JSON decoder would give you a dynamic structure that can contain anything, and then you'd have to pick it apart.
Serde just doesn't use reflection to do it.
Re: The Serde Rust Framework
#20serde is one of the best things about Rust in practice. It is more convenient to use serde to serialize/deserialize to some standard format like JSON or YAML than it is to write your own half-baked format and serialization/deserialization code --- even for the simplest tasks --- so you just stop doing the latter. This is a fundamental shift, and very good for your software. "Convenience" here actually covers a lot of…
Serde generates heaps and heaps of generic code. This all gets optimized away to be very efficient, but only once it reaches LLVM.
Ever tried working on a crate with hundreds or thousands of de/serializable types? Compile times shoot through the roof really quickly, and serde is often the culprit.
The maintainer of serde also created `miniserde` [1] to tackle this problem, which uses dynamic dispatch instead of generics and can have 4x compile time improvements.
Due to Rusts lack of orphan instances you really depend on a pervasive standard for serialization, though, so the ecosystem is pretty locked in to serde.