Would using Rust have prevented this?
Isn't this already Rust?
That was obviously a joke question, pointing that Rust isn't the solution for everything.
We found a bug in the hyper HTTP library
31–40 of 97 posts
Re: We found a bug in the hyper HTTP library
#32Re: We found a bug in the hyper HTTP library
#33So “fearless concurrency” still only happens when one just decides to not be afraid… :)
Re: We found a bug in the hyper HTTP library
#34So “fearless concurrency” still only happens when one just decides to not be afraid… :)
This does not appear to be a concurrency bug though?
Re: We found a bug in the hyper HTTP library
#35This would have been flagged by Clippy lints `let_underscore_untyped` or `let_underscore_must_use`, which sadly are not enabled by default.
Ehh, easy fix
#[allow(clippy::let_underscore_untyped,clippy::let_underscore_must_use)]
let _ = self.poll_flush(cx)?;Re: We found a bug in the hyper HTTP library
#36Earlier quoted context omitted.
You're missing how rust works. The function is explicitly allowed to fail, which is why it returns a Result . They're using the function calls within for their side effects. The ? at the end of each line signals that the function will short-circuit return with an error if the function call fails, and only if it is successful it returns the actual value: they just don't care about this value, hence the let _ =. Basica…
What I am saying, is make another version of the function, which is explicitly not allowed to fail, if you want to use it in the loop.
[deleted]
Re: We found a bug in the hyper HTTP library
#37Nice writeup, but I don't understand how `curl` didn't trigger bug for them (or any other hyper HTTP server out there), given the explanation in the article.
`curl --http1.1` sends `Connection: Close` so sender (hyper) must attempt to shutdown connection after sending whole body. Surely any network is slower than memory copy into socket kernel buffers, so it must reliably trigger condition "buffer flush can't be done in one go" and thus trigger early TCP shutdown.
Re: We found a bug in the hyper HTTP library
#38This would have been flagged by Clippy lints `let_underscore_untyped` or `let_underscore_must_use`, which sadly are not enabled by default.
Ehh, easy fix #[allow(clippy::let_underscore_untyped,clippy::let_underscore_must_use)] let _ = self.poll_flush(cx)?;
Yeah, but you must know about them and the possible bug first in order to allow them...
Re: We found a bug in the hyper HTTP library
#39This would have been flagged by Clippy lints `let_underscore_untyped` or `let_underscore_must_use`, which sadly are not enabled by default.
Ehh, easy fix #[allow(clippy::let_underscore_untyped,clippy::let_underscore_must_use)] let _ = self.poll_flush(cx)?;
You can set the lints to `forbid` instead of `deny`, which means they can't be `allowed` like that.
Re: We found a bug in the hyper HTTP library
#40Earlier quoted context omitted.
Ehh, easy fix #[allow(clippy::let_underscore_untyped,clippy::let_underscore_must_use)] let _ = self.poll_flush(cx)?;
Yeah, but you must know about them and the possible bug first in order to allow them...
At which point you wouldn't have written this bug in the first place; or the warnings would trigger immediately, you'd change _ to an actual variable and then remove the warning pragmas because now you don't assign to _.