:max_requests. This is a connection-level option signalizing how many requests can be performed on a connection. Although the HTTP/1 parser defined this well, in HTTP/2 this wasn’t very clear, so: by definition, the remote MAX_CONCURRENT_STREAMS setting will be used to define it, unless the user explicitly passed the option. You can also pass
:max_requests => Float::INFINITY if you know that the server allows more requests than that on a connection.
Although there was support for
expect: 100-continue header already when passed, this plugin can:
automatically set the header on requests with body;
execute the flow;
recover from 417 status errors (i.e. try again without it);
send body after X seconds if no 100 response came;
with_ methods for the session. As long as the suffix is a valid attribute, it’s just like that:
HTTPX.with_timeout(...).with_ssl(...) # same as: # HTTPX.with(timeout: ..., ssl: ...)
The following improvements make the
persistent plugin way more resilient:
Better balancing of HTTP/2 connections by distributing requests among X connections depending of how many requests they can process.
Exhausted connections can off-load to a new same-origin connection (such as, when the server negotiates less
MAX_CONCURRENT_STREAMSthan what’s expected).
(Timeouts will be one of the main improvements from the 0.7.x series)
:total_timeout is now a connection-level directive, which means that this feature will actually make more sense and account for all requests in a block at the same time, instead of one-by-one.
Option setters were being bypassed, therefore a lot of the type-checks defined there weren’t effectively being picked upon, which could have led to weird user errors.
push_promiseplugin integration (wasn’t working well since