When acting as a client, processing HTTP/1.0 responses fails

[vulpyne]

It seems like this line is the issue:

async-h1/src/client/decode.rs

Line 65 in a1448c3

ensure_eq!(version, 1, "Unsupported HTTP version");

It is my understanding there shouldn't be a meaningful difference parsing a HTTP/1.0 with a 1.1 parser since the only differences are some extra headers and possible result codes which wouldn't exist in the 1.0 response.

httparse_res.version will be 0 in the case of a HTTP/1.0 response. Perhaps that code is attempting to match on the major version number, however httparse uses that field for the minor one which is a bit unintuitive.

[jbr]

async-h1 is currently an http/1.1 library and does not yet support http/1.0. you're right that the differences are minor, but as of the current release of http-types and async-h1, it is exclusively http/1.1

[vulpyne]

Is there anything in a HTTP/1.0 response that would cause issues with a HTTP/1.1 parser? If not, what is the benefit of explicitly refusing to handle a HTTP/1.0 response?

[jbr]

It's not that we couldn't add support for 1.0 at some point (and I've started in on that in the v3 branch) but that the current version of async-h1 is intended to be an async http/1.1 client and server. I believe you're right that http/1.0 would be trivial to support on the client side

[vulpyne]

Trivial or not, I would expect someone else to do it for me. Would you accept a pull request that just changed the conditional to not explicitly error out on a HTTP/1.0 response? i.e. change it to ensure!(version < 2, "Unsupported HTTP version");

If you wanted to be super-safe I guess there could even be a feature flag that allowed rejecting those responses as before, although I personally don't really see the advantage.