4 ms·

I can't seem to find a parser for HTTP requests in the repo. I assume this is out of scope for the crate?

• connorcpu 9y ago
  Looks like this crate is merely trying to provide a standard set of types used in an HTTP pipeline to make different crates that want to have a part in that pipeline able to be combined together, without having to convert your types all over the place
• ivanbakel 9y ago
  To quote the announcement: >It does not cover transport, but is rather intended for use in libraries like Hyper, and to support an ecosystem of crates that can share HTTP-related types. So I don't think they added any implementation details to the crate itself, to avoid people taking issue with something being too bloat-ey or not to their need, and rejecting the common types, which seem to be the real goal. It does seem like something you'd always need, though - I can only imagine that a proper parser would be pretty large, and they didn't want people to complain about it.
  • JoshTriplett 9y ago
    I wouldn't be surprised if an "http-parser" crate pops up on top of this. But unlike the http crate, an http-parser crate would have to make at least one potentially controversial choice, namely "which parsing library".
    • steveklabnik 9y ago
      I've been working with this crate for a while, and use https://crates.io/crates/httparse https://crates.io/crates/httparse with it, it works pretty well.
• tatterdemalion 9y ago
  Parsing would get into policy choices this crate doesn't want to make, like DoS protection (max request size, mid-request timeouts, etc), and often is intertwined with reading data from IO, which this crate definitely doesn't want to get involved in.