HTTP/2: check window sizes, implement streaming #158

the-mikedavis · 2021-10-29T14:44:44Z

closes #88

HTTP/2 streaming is quite a different beast from HTTP/1. The main catch is the control-flow, which is really a backpressure mechanism in which the server limits the number of bytes you can send on a per-connection and per-request-stream level. Once the window has been consumed, the server will replenish the window with a SETTINGS frame, allowing the client to send more data.

The approach we take here is to follow the Mint documentation's recommendation of switch from doing

Mint.HTTP2.request(conn, method, path, headers, body)

to

Mint.HTTP2.request(conn, method, path, headers, :stream)

for all non-nil bodys. Then we use an t:Enumerable.continuation/0 to gradually unroll the input stream and send chunks with Mint.HTTP2.stream_request_body/3, suspending when window needs to be replenished. When we receive a message from the server (with Mint.HTTP2.stream/2), it's possible that the window has been replenished for any active requests, so we continue the Enumerable.reduce/3, repeating until the stream is complete. Finally we send the Mint.HTTP2.stream_request_body(conn, ref, :eof).

There are really two things being solved here: checking window sizes and implementing {:stream, stream} bodies for HTTP/2. They're very similar implementation-wise so I thought I'd try to knock out two birds with one stone in this PR.

Any feedback is welcome (especially on the control flow parts if/with/case/etc) 🙂

sneako · 2021-10-29T17:37:38Z

Thank you @the-mikedavis ! I've really wanted to get #88 tackled and the fact that we get request body streaming as a bonus is great! I'll need a few days, but I'll give this a proper review and also do some load testing so we can see how much better things are after this.

sneako · 2021-11-08T19:27:33Z

Hey @the-mikedavis! Sorry for the delay, I've had a very busy week, but I have been able to spend short periods of time here and there testing this out. I had a few huge tasks on my plate that have now been completed, so I should have a bit more free time going forward.

So far, I have seen some noticeable improvements, for example I put together this script:

destructure [finch_version_input, body_size_input], System.argv()

finch_dep =
  case finch_version_input do
    "pr" ->
      {:finch, github: "the-mikedavis/finch", ref: "window-sizes-and-streaming"}

    _ ->
      :finch
  end

body_size = if body_size_input, do: String.to_integer(body_size_input), else: 1_000
body = String.duplicate("x", body_size)

Mix.install([finch_dep])

Finch.start_link(name: MyFinch, pools: %{default: [protocol: :http2]})

req = Finch.build(:post, "https://nghttp2.org/httpbin/post", [], body)

Finch.request(req, MyFinch)
|> IO.inspect(label: :output)

It takes 2 args. If you pass "pr" as the first arg, this branch will be used, otherwise the hex version of Finch will be used. The second arg is the body size.

We can clearly demonstrate the improvement of this PR by sending 1 byte more than the window size.

Here is with hex Finch:

$ check_window_size.exs main 1048577
output: {:error,
 %Mint.HTTPError{
   module: Mint.HTTP2,
   reason: {:exceeds_window_size, :request, 1048576}
 }}

And here is with this PR:

$ elixir check_window_size.exs pr 1048577  
output: {:ok,
 %Finch.Response{
   body: "{\n  \"args\": {}, \n  \"data\": \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" <> ...,
   headers: [
     {"date", "Mon, 08 Nov 2021 19:14:29 GMT"},
     {"content-type", "application/json"},
     {"content-length", "1048849"},
     {"access-control-allow-origin", "*"},
     {"access-control-allow-credentials", "true"},
     {"x-backend-header-rtt", "3.783022"},
     {"strict-transport-security", "max-age=31536000"},
     {"server", "nghttpx"},
     {"alt-svc", "h3=\":443\"; ma=3600, h3-29=\":443\"; ma=3600"},
     {"via", "1.1 nghttpx"},
     {"x-frame-options", "SAMEORIGIN"},
     {"x-xss-protection", "1; mode=block"},
     {"x-content-type-options", "nosniff"}
   ],
   status: 200
 }}

This is already a huge win!

I have another test is more of a benchmark style test that sends many concurrent requests. I will clean it up and share that with you ASAP. In this test, it seems that Finch gets into some kind of endless loop with this PR, whereas the hex version simply has a high error rate (also not ideal 😬) It could be a problem with my setup or the test itself (I have used it exclusively with http1 in the past and had to add http2 support to test this), so I would like to try to figure out more about what is happening before I send you on a wild goose chase.

I'll get back to you soon, but I did not want to leave you hanging for much longer so here is my update. Thank you for your patience!

the-mikedavis · 2021-11-09T00:43:36Z

Awesome! No rush, I'm actually on vacation this week away from a computer so it'll take me a bit to dig in for bugs+changes. I'm not really in a big rush with this pr anyways so no pressure!

W.r.t. the infinite looping, I have some ideas what might be causing behavior like that but I'll await your stress test to be sure. Sounds like a fun bug to hunt down and squash :)

sneako · 2021-11-25T09:49:43Z

Hey @the-mikedavis sorry for the delay! I had a huge task to finish up at my day job and then had family visiting from overseas for the past week. They are still here for a few more days but I found some time to get this together.

I just pushed https://github.com/sneako/httpc_bench/tree/h2 and added some instructions to the readme. You can toggle between Finch versions by commenting and uncommenting in mix.exs. Finch main is able to complete the test with a high error rate while this PR seems to get stuck somewhere.

Please let me know if you have any questions or are struggling to get this running and/or reproducing the issue!

the-mikedavis · 2021-11-26T16:48:20Z

Ok I've got it running locally.

example outputs...

main:

Client,Pool Count,Pool Size,Concurrency,Req/sec,Error %, Total Processes
Finch,128,1,1024,11163,0.1,128
Finch,64,1,1024,4409,34.2,64
Finch,32,1,1024,2574,65.0,32
Finch,24,1,1024,2117,72.1,24
Finch,12,1,1024,1044,87.0,12
Finch,128,1,512,12020,1.9,128
Finch,64,1,512,4209,35.2,64
Finch,32,1,512,2380,67.2,32
Finch,24,1,512,1783,76.0,24
Finch,12,1,512,1092,85.6,12
Finch,128,1,256,10559,0.0,128
Finch,64,1,256,3904,36.3,64
Finch,32,1,256,2066,68.3,32
Finch,24,1,256,1702,75.0,24
Finch,12,1,256,937,86.2,12
Finch,128,1,128,7521,0.0,128
Finch,64,1,128,3117,35.5,64
Finch,32,1,128,7518,68.4,32
Finch,24,1,128,1386,73.3,24
Finch,12,1,128,971,80.8,12
Finch,128,1,64,4374,0.0,128
Finch,64,1,64,2184,35.2,64
Finch,32,1,64,1187,65.2,32
Finch,24,1,64,977,72.0,24
Finch,12,1,64,622,76.9,12

this pr

Client,Pool Count,Pool Size,Concurrency,Req/sec,Error %, Total Processes
Finch,128,1,1024,8246,0.0,128
Finch,64,1,1024,10574,31.2,64       # seems to hang on the next iteration
^C

This is pretty curious! I'll dig in a bit and see what I can find

sneako · 2021-11-26T17:06:30Z

Great! Those results match what I was seeing as well.

the-mikedavis · 2021-11-29T05:04:20Z

Ok so I think I spent most of the time so far looking at the wrong bug but I think I may have found a (partial?) fix for #120 in elixir-mint/mint#339.

The openresty h2 server has a kinda odd behavior where it's sending a GOAWAY after every 100th requests. Iirc the spec allows that but it seems to be inflating the error rate for the benchmark tests because the connection will go connected->read-only->disconnected->(wait)->connected every 100 successful requests. As far as I can tell so far, that seems to be what's provoking the connections to get into a wonky state and seem to hang.

Still digging in! 🕵️

sneako · 2021-11-29T11:51:39Z

Great find @the-mikedavis! It looks like this behaviour is caused by this setting http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests and "Prior to version 1.19.10, the default value was 100."

I just tried increasing the value to 10,000 and the error rate looks much better, and neither version of Finch gets stuck anymore.

Here are the results I get with this PR:

config: [
  pipelining: 1024,
  concurrencies: [1024, 512, 256, 128, 64],
  test_function: :post,
  output: :csv,
  pool_sizes: [1],
  host: "localhost",
  port: 8443,
  path: "/wait/10",
  clients: [HttpcBench.Client.Finch],
  timeout: 1000,
  iterations: 10000,
  headers: [{"connection", "keep-alive"}],
  pool_counts: [128, 64, 32, 24, 12]
]
Client,Pool Count,Pool Size,Concurrency,Req/sec,Error %, Total Processes
Finch,128,1,1024,5211,0.0,128
Finch,64,1,1024,6717,0.0,64
Finch,32,1,1024,8009,0.6,32
Finch,24,1,1024,8426,1.2,24
Finch,12,1,1024,9116,5.0,12
Finch,128,1,512,5293,0.0,128
Finch,64,1,512,6731,0.0,64
Finch,32,1,512,7885,0.0,32
Finch,24,1,512,8312,0.0,24
Finch,12,1,512,8895,0.0,12
Finch,128,1,256,5055,0.0,128
Finch,64,1,256,6575,0.0,64
Finch,32,1,256,7463,0.0,32
Finch,24,1,256,8014,0.0,24
Finch,12,1,256,8790,0.0,12
Finch,128,1,128,4719,0.0,128
Finch,64,1,128,5818,0.0,64
Finch,32,1,128,6824,0.0,32
Finch,24,1,128,7184,0.0,24
Finch,12,1,128,7887,0.0,12
Finch,128,1,64,4008,0.0,128
Finch,64,1,64,4644,0.0,64
Finch,32,1,64,5047,0.0,32
Finch,24,1,64,5125,0.0,24
Finch,12,1,64,5375,0.0,12

I think you are really on to something with elixir-mint/mint#339

the-mikedavis · 2021-11-29T16:04:14Z

Sweet, nice find! I'll keep poking around with the keepalive_requests set low to see if I can figure out why it's hanging. There must be something about the closed-for-writing state that's getting some requests stuck and the connection processes looping 🤔

the-mikedavis · 2021-12-05T22:19:20Z

Ok so I did a bit more stress testing, now against the keepalive 10000 setting, and I see just about the same results when running in mix test. I tried running the test in Mix.env() == :dev too where I have a config like so:

config: [
  timeout: 1000,
  path: "/wait/10",
  pool_sizes: [256, 192, 128, 96, 64, 32],
  concurrencies: [4096, 3064, 2048, 1024],
  output: :csv,
  port: 443,
  iterations: 500000,
  headers: [{"connection", "keep-alive"}],
  host: "openresty",
  clients: [HttpcBench.Client.Finch],
  pool_counts: [32, 16, 8, 4],
  pipelining: 1024,
  test_function: :post
]

where the notable difference is the iterations: 500_000. With that configuration the test suite takes a while and ends up with a much higher error rate. With an IO.inspect/1 in the right place I see that many of the requests are failing with

{:error, %Mint.HTTPError{module: Mint.HTTP2, reason: :too_many_concurrent_requests}}

which makes sense with some help from wireshark: it looks like the server is requesting :max_concurrent_streams of 128. That makes sense given the configuration and where we see the error rate jumping up in Mix.env() == :test: in the cases with concurrency set to 1024.

I don't really know anything about NimblePool or pooling in general (😅) but maybe this is something that can be solved by the pool setup? In any case it seems to also be present when using finch on main so I'd like to separate out that work from this PR if possible. Should I spin up an issue?

There's one more thing that I'd really like to test out before I feel happy about this PR: POSTing bodies double, +1, and -1 byte the size of the smallest window, just to make sure I have the edge cases correct. I'll see if I can knock that out right now! (edit: done! and I found an off-by-one 🎉)

testing against the exact connection-level window size, I see on the last commit: | bytes to send | number of DATA frames | sizes of each frame | |----------------|-----------------------|---------------------| | 65_536 | 2 | 65_536, 0 | | 65_536 - 1 | 1 | 65_535 | | 65_536 + 1 | 3 | 65_535, 2, 0 | | 2 * 65_536 | 3 | 65_535, 65_537, 0 | | 2 * 65_536 - 1 | 3 | 65_535, 65_536, 0 | | 2 * 65_536 + 1 | 3 | 65_535, 65_538, 0 | this looks like the formula for how many bytes to fit when overloaded is off-by-one. after applying the change in this commit, the numbers work out perfectly: | bytes to send | number of DATA frames | sizes of each frame | |----------------|-----------------------|---------------------| | 65_536 | 2 | 65_536, 0 | | 65_536 - 1 | 1 | 65_535 | | 65_536 + 1 | 3 | 65_536, 1, 0 | | 2 * 65_536 | 3 | 65_536, 65_536, 0 | | 2 * 65_536 - 1 | 3 | 65_536, 65_535, 0 | | 2 * 65_536 + 1 | 3 | 65_536, 65_537, 0 |

sneako · 2021-12-06T10:28:35Z

Amazing! I really appreciate your work here @the-mikedavis.

I agree that this :too_many_concurrent_requests is a separate issue, so please do spin up that issue when you have a chance.

RE: pooling, NimblePool is only used for HTTP/1 connections. For HTTP/2, we are treating each individual connection as a 'pool' and not using NimblePool at all.

It sounds like we need to store :max_concurrent_streams and a counter that is tracking the number of concurrent requests in order to avoid exceeding this limit. It might also be time to finish up my work on #45 (RoundRobin pool selection). I kind of left it where it is because I did see significant improvements on the HTTP/1 side of things, but that should help use avoid exceeding this limit on the H/2 side.

I'll do a final round of testing on this PR ASAP so that we can get this great work merged and released!

lib/finch/http2/request_stream.ex

lib/finch/http2/pool.ex

sneako · 2021-12-12T08:32:13Z

Thank you @the-mikedavis! This is a huge improvement to our H2 support ❤️

sneako · 2021-12-13T09:33:20Z

Released in v0.10.0!

ruslandoga · 2021-12-24T12:59:27Z

I've added a failing test in #165

the-mikedavis · 2021-12-24T13:36:41Z

Ah good catch. I see the problem, I'll push up a PR to fix

the-mikedavis added 2 commits October 29, 2021 09:15

HTTP/2: check window sizes

016d7ea

document passing a stream body for HTTP/2

3b11fcf

the-mikedavis added 3 commits November 29, 2021 21:21

use macro-form put_in/2 consistently

2eae2ec

only continue streaming when the connection is open for writing

336e638

discard streaming requests when closed for writing

c49ea5d

sneako reviewed Dec 6, 2021

View reviewed changes

lib/finch/http2/request_stream.ex Outdated Show resolved Hide resolved

sneako reviewed Dec 6, 2021

View reviewed changes

lib/finch/http2/pool.ex Outdated Show resolved Hide resolved

the-mikedavis added 2 commits December 6, 2021 09:50

combine Enum.filter/2 and Enum.reduce/3 calls

11dd75e

don't call IO.iodata_to_binary/1 on binary input

466bf4b

the-mikedavis mentioned this pull request Dec 6, 2021

HTTP/2: check max-concurrent-streams setting #164

Open

sneako merged commit c4484c7 into sneako:main Dec 12, 2021

the-mikedavis deleted the window-sizes-and-streaming branch December 15, 2021 17:22

ruslandoga mentioned this pull request Dec 24, 2021

add failing test with iolist > window #165

Merged

the-mikedavis mentioned this pull request Feb 21, 2023

[Question] About Gun NFIBrokerage/spear#66

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HTTP/2: check window sizes, implement streaming #158

HTTP/2: check window sizes, implement streaming #158

the-mikedavis commented Oct 29, 2021

sneako commented Oct 29, 2021

sneako commented Nov 8, 2021 •

edited

Loading

the-mikedavis commented Nov 9, 2021

sneako commented Nov 25, 2021

the-mikedavis commented Nov 26, 2021

sneako commented Nov 26, 2021

the-mikedavis commented Nov 29, 2021

sneako commented Nov 29, 2021 •

edited

Loading

the-mikedavis commented Nov 29, 2021

the-mikedavis commented Dec 5, 2021 •

edited

Loading

sneako commented Dec 6, 2021

sneako commented Dec 12, 2021

sneako commented Dec 13, 2021

ruslandoga commented Dec 24, 2021

the-mikedavis commented Dec 24, 2021

HTTP/2: check window sizes, implement streaming #158

HTTP/2: check window sizes, implement streaming #158

Conversation

the-mikedavis commented Oct 29, 2021

sneako commented Oct 29, 2021

sneako commented Nov 8, 2021 • edited Loading

the-mikedavis commented Nov 9, 2021

sneako commented Nov 25, 2021

the-mikedavis commented Nov 26, 2021

sneako commented Nov 26, 2021

the-mikedavis commented Nov 29, 2021

sneako commented Nov 29, 2021 • edited Loading

the-mikedavis commented Nov 29, 2021

the-mikedavis commented Dec 5, 2021 • edited Loading

sneako commented Dec 6, 2021

sneako commented Dec 12, 2021

sneako commented Dec 13, 2021

ruslandoga commented Dec 24, 2021

the-mikedavis commented Dec 24, 2021

sneako commented Nov 8, 2021 •

edited

Loading

sneako commented Nov 29, 2021 •

edited

Loading

the-mikedavis commented Dec 5, 2021 •

edited

Loading