Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We found a bug in the hyper HTTP library

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 97 posts

Re: We found a bug in the hyper HTTP library

#71

Post by throw_await »

logicchains wrote: post #41
fwlr wrote: post #10

Earlier quoted context omitted.

let _ = …? This is the Rust idiom for “I am intentionally ignoring this return value”. The linter would have caught self.poll_read()?; and in fact one of the options the linter itself suggests in this case is exactly this “let underscore equals” idiom. (Arguably, this code exists because of the linter, not due to its absence!) In any case, the return value is being “handled” - the question mark examines the result an…

>This is the Rust idiom for “I am intentionally ignoring this return value”. That doesn't make the code any less awful, it just makes idiomatic Rust sound awful. Discarding a return value without even a comment to explain why shouldn't be allowed in any critical project, and the linter should be perfectly capable of ensuring that a comment accompanies the discard and complaining loudly when it doesn't.

As the top comment states, there is a lint rule, but you have to turn it on.

Re: We found a bug in the hyper HTTP library

#72

Post by testdelacc1 »

microgpt wrote: post #20

Would using Rust have prevented this?

I get that it’s fun to dunk on Rust when a Rust bug surfaces. But is it a bit petty to bring this out when there’s any type of bug of any severity in any Rust software?

In this case a small minority of requests were getting truncated responses.

No one said Rust software is bug free. If someone thinks that they’ve been seriously misled.

Re: We found a bug in the hyper HTTP library

#73

Post by gmueckl »

worldsavior wrote: post #18

> We spent six weeks chasing a nearly invisible bug — a race condition that occurred only under specific conditions — in the hyper library that impacted how the Images binding returned processed image data back to the client. In the end, it took four lines of code to fix it. That's a long time, must be frustrating.

It is a long time and it gets frustrating when there is significant time where there is flailing with no visible progress.

I have had long bug hunts (~a month each) and witnessed ones that took much, much longer. But the longest one I witnessed was drawn out because reproduction was initially unreliable and could take weeks to months. Thankfully, reproduction was by letting a box sit in a corner while tje people involved moved on to other tasks. This kept everybody sane.

Re: We found a bug in the hyper HTTP library

#74

Post by moralestapia »

100ms wrote: post #12

> The failure was caused by a timing-dependent race condition in hyper’s HTTP/1 connection handling. When the reader was slower and the socket buffer filled, poll_flush returned Poll::Pending, but the dispatch loop discarded that result. Hyper then treated the response as complete and shut down the socket while data remained buffered internally, causing the client to receive an EOF before the full body arrived. https…

Hey, you have to justify three engineers full time's worth of salary.

Re: We found a bug in the hyper HTTP library

#75

Post by inexcf »

microgpt wrote: post #51
c0balt wrote: post #34

Earlier quoted context omitted.

This does not appear to be a concurrency bug though?

Of course it's a concurrency bug. It races sending data to the kernel against the kernel sending data to the network. If the wrong one wins the bug occurs.

Isn't that like saying there can never be a language with safe concurrency since the code could interact with C code that segfaults? I dunno this kinda reminds me of the 10/10 Rust CVE that turned out to be cmd.exe on Windows not sanitizing inputs and languages like Java just labeled it "won't fix".

Re: We found a bug in the hyper HTTP library

#76

Post by tetha »

microgpt wrote: post #51
c0balt wrote: post #34

Earlier quoted context omitted.

This does not appear to be a concurrency bug though?

Of course it's a concurrency bug. It races sending data to the kernel against the kernel sending data to the network. If the wrong one wins the bug occurs.

But it did not take 2 threads within the same application to interact in a bad way on data the system controlled to cause this problem.

This reads more like an overly broad transition in a deterministic state machine. The fix was to split up a bad transition to shutdown.

Re: We found a bug in the hyper HTTP library

#77

Post by microgpt »

tetha wrote: post #76
microgpt wrote: post #51

Earlier quoted context omitted.

Of course it's a concurrency bug. It races sending data to the kernel against the kernel sending data to the network. If the wrong one wins the bug occurs.

But it did not take 2 threads within the same application to interact in a bad way on data the system controlled to cause this problem. This reads more like an overly broad transition in a deterministic state machine. The fix was to split up a bad transition to shutdown.

Concurrency bugs don't have to be within a single process.

Re: We found a bug in the hyper HTTP library

#78

Post by microgpt »

inexcf wrote: post #75
microgpt wrote: post #51

Earlier quoted context omitted.

Of course it's a concurrency bug. It races sending data to the kernel against the kernel sending data to the network. If the wrong one wins the bug occurs.

Isn't that like saying there can never be a language with safe concurrency since the code could interact with C code that segfaults? I dunno this kinda reminds me of the 10/10 Rust CVE that turned out to be cmd.exe on Windows not sanitizing inputs and languages like Java just labeled it "won't fix".

You mean the one where Windows doesn't have argv the way Unix does, and instead just has a single string that is interpreted slightly differently by each executable? That is a language making false assertions about how the underlying platform works, causing an impedance mismatch that is impossible to fix.

Re: We found a bug in the hyper HTTP library

#79

Post by microgpt »

edelbitter wrote: post #22
microgpt wrote: post #21

Earlier quoted context omitted.

That's not even a bug. That's how TCP works. If you keep sending data to a socket the other side has closed, you get RST.

In case of plain HTTP over TCP, there is even a hint in the spec about why and how a server might want to avoid fully closing prematurely. https://datatracker.ietf.org/doc/html/rfc9112#section-9.6 (this was already in https://datatracker.ietf.org/doc/html/rfc7230#section-6.6 )

This is relevant if the client sends multiple requests but the server decides to close the connection after one of them. The server should discard the additional requests until the client signals no more requests are coming.

Re: We found a bug in the hyper HTTP library

#80

Post by microgpt »

NooneAtAll3 wrote: post #52
microgpt wrote: post #21

Earlier quoted context omitted.

That's not even a bug. That's how TCP works. If you keep sending data to a socket the other side has closed, you get RST.

what is RST?

connection reset - TCP says "this connection is too messed up, abort, abort!"

The relevant condition here is where one side closed its socket but the other side didn't and keeps sending data to the closed socket. That's obviously an improper way to end a connection. A graceful shutdown does not send RST and ensures all data is received on both sides.

Post reply on HN