HttpMuncher: Rust Streaming HTTP Parser

announcements
1

Hello,

I'd like to present you my very first Rust crate: https://github.com/nbaksalyar/rust-streaming-http-parser (http-muncher on crates.io).

It wraps Joyent's C library http-parse and allows you to parse HTTP requests in a safe and fast way. The original library itself is built upon the Nginx's HTTP parser which is famous for its speed and reliability.

It's my first Rust project, and a major part of its goal is to gather some feedback on the code quality, formatting, and the overall idea. But I'm planning to make it more interesting soon by using the library as a foundation for something of more value & production quality - a Metal I/O-based asynchronous WebSocket & HTTP/2 server for Rust projects. So, stay tuned! :slight_smile:

For now, I'd be happy to get some comments on this.

Thanks for reading!

2

This part looks a little weird to me:

Return Option as a result of each function call - either None for the "OK, go on" status, or Some(1) when you want to stop the parser after the function call is ended.

Can you say some more why these callbacks return an Option<u16> and not, say, a Result or Bool ?

2 Likes
3

The idea was to be more compatible with the underlying library that can use the special return value codes. And returning just u16 looks a bit too low-level and non-descriptive to me.

But you're right - I think most of the callbacks can be safely converted to return Bool, and edge cases can be handled separately.

Thanks!

4

If there are special values that can be returned, then maybe an Enum would be better?

#[repr(C)]
enum CallbackStatus {
  OK = 0,
  BAD_FOO = 128,
  BAD_BAR = 256
}

This way you might be able to easily convert from the enum to the i16, but at the same time prevent the rust user from supplying an invalue value.

(Sorry I haven't looked carefully at the Joyent docs, maybe they say something about what special return value codes they might have)

3 Likes