Handle poorly-behaved callbacks more reliably #636
Conversation
If `startwrite()` is never called during a server callback, the client may be left waiting for a response and never get one. This can cause lockups and general misery, especially when connections are proxied through an intermediary (such as `nginx`) with a finite connection limit. This PR detects a server callback that never calls `startwrite(http)` and throws an error, triggering the HTTP 500 mechanism. It also adds a `closewrite(http)` onto that branch as without it, it appears that the final chunk in the `Transfer-Encoding: Chunked` response may not appear.
|
@quinnj is this the best way to detect a lack of Also, I found that I needed to add a |
|
Closes #631 |
Codecov Report
@@ Coverage Diff @@
## master #636 +/- ##
==========================================
- Coverage 77.46% 75.47% -2.00%
==========================================
Files 36 36
Lines 2299 2145 -154
==========================================
- Hits 1781 1619 -162
- Misses 518 526 +8
Continue to review full report at Codecov.
|
|
Nightly failures look unrelated; some Pkg error. This looks great to me; can I make one small request? Would you mind adding a big |
If
startwrite()is never called during a server callback, the clientmay be left waiting for a response and never get one. This can cause
lockups and general misery, especially when connections are proxied
through an intermediary (such as
nginx) with a finite connectionlimit.
This PR detects a server callback that never calls
startwrite(http)and throws an error, triggering the HTTP 500 mechanism. It also adds a
closewrite(http)onto that branch as without it, it appears that thefinal chunk in the
Transfer-Encoding: Chunkedresponse may not appear.