HTTP/1.1 Request/Response parsing about http HOT 10 CLOSED

I'm quite a 👎 here.

• It could only ever support HTTP/1, not 2. That would feel weird to me.
• Parsing is opinionated. We wouldn't want anyone to not use this crate because they felt the parsing was not done the way they wanted.
• Parsing should be out of scope for what a user wants. A user should use this crate because they want to define the ability to receive or make requests and responses. How a bucket of bytes becomes those things should be up to any implementation.
• As Carl mentions, any flaw in the parsing API would never be fixed at the expense of breaking backwards compatibility with everyone, when the main goal is to use the types.

from http.

Big 👍 here, right now I'm integrating httparse to do this, and it works okay, but it'd be nice to have it handled by the library. It also has some symmetry with Uri::parse.

from http.

IMO parsing is slightly out of scope for the crate, though it doesn't seem to hurt too much to add.

The main drawback that I see is that parsing could be a lot more opinionated and we will doubtfully ever trigger a breaking change release to fix parsing APIs. Aka, I would regard any parsing apis as "second class".

from http.

I worked on this but I doubt the implementation we would have here would be one any production crate would use. Here are the issues I found:

• If we don't want parsing to be intertwined with reading (and it can't be at this level because of the difference between blocking and nonblocking reads), users will need to be reading newlines to the end of the header. And this is setting aside the issue of reading the body (which requires figuring out which length header to use and then reading that much data).
• HTTP\1.1 is a "helpfully" flexible spec, making correct parsers very complex - we're supposed to support arbitrary linear whitespace, both \n and \r\n line separates, headers broken up over multiple lines, etc.

I decided if we're going to do this its definitely not an 0.1 blocker, and we should decide up front exactly what we're supporting.

We do parse each individual component of a message (though I think version validating was removed recently for reasons I didn't really understand), which should make it easier to implement a parser.

from http.

This definitely should not block 0.1.

from http.

@seanmonstar I can understand this perspective, and it makes sense. However, I'd argue that including URI parsing runs into basically the same issues, no?

To me, it's mostly weird that there's one kind of parser, but not another.

from http.

Uri parsing is a FromStr impl and is going to be much more common to use in end user apps than parsing from an h1 payload.

The httparse create could easily add support for parsing here.

from http.

It seems to me that the http crate is actually doing some parsing -- it looks quite optimised as well, for instance, URIs, Header Names and Http Methods.

At the moment it looks like two parsing stages are needed. One stage gets the parts ready for the http crate and then the work done in the http crate itself. To me, this seems like a waste when you consider the system as a whole.

One thing that would be nice for me is if the first parsing stage that I do myself is as easy as possible. This would be helped by having all parts consistently readable from a byte array e.g Http Version. At the moment Http Version must be parsed outside the http crate.

from http.

The crate should provide "unchecked" constructor variants that let HTTP implementations that have already performed parsing to just load the types. These should be added as needed when there is a measurable benefit.

The main reason there is parsing implemented for types like URI, headers, and method is that there is that those functions are useful for the end user (i.e. not HTTP client / server libs).

Again, I think it would be fine for httparse to provide all of the parsing as the recommended HTTP parser.

from http.

The conclusion here is that there will be no parsing added to the crate.

from http.