Support Net::HTTP::Persistent.write_timeout #586
Conversation
|
@maurycy Thank you for submitting this! Looks good, but I'd like to make some time to do a deeper dive on the timeouts (the test coverage seems pretty thin for |
|
@flavorjones Thank you as well! That's true. I had to manually |
|
@flavorjones While we're at it, what do you think about covering ssl_timeout as well? It's well supported by net-http-persistent. I can handle this. Net::HTTP.keep_alive_timeout is shadowed by Net::HTTP::Persistent.idle_timeout, so not much we can do. Net::HTTP.continue_timeout is not supported by net-http-persistent. |
updates Linux Firefox user-agent to rev94
…se-psych-safe-load use safe_load when using Psych >= 3.1
…pdate-ci-to-ruby31 ci: update to cover Ruby 3.1
Note that in this case we treat cookies differently from credentials per RFC 6265 section 8.5: https://datatracker.ietf.org/doc/html/rfc6265#section-8.5 > Cookies do not provide isolation by port. If a cookie is readable > by a service running on one port, the cookie is also readable by a > service running on another port of the same server. If a cookie is > writable by a service on one port, the cookie is also writable by a > service running on another port of the same server. For this > reason, servers SHOULD NOT both run mutually distrusting services on > different ports of the same host and use cookies to store security- > sensitive information.
…edirect-headers fix: clear credentials when redirecting to a different port
|
@maurycy Since you emailed me directly let me respond here. Would you be willing to add test coverage to this PR that exercises the write timeout, either using the test server or via a mock? That would help me be confident in supporting it as a feature going forward. |
This seems to be common with Ruby 3.1+ (OpenSSL 3.0+).
until jruby/jruby#7481 is in a release
…pdate-ci-with-3.2 ci: include ruby 3.2, get back to green
jruby/jruby#7481 is fixed in 9.4.1.0
ruby 2.5 just started failing
…ix-ci-ruby-2.5 ci: use latest bundler
because the work to get CI to build properly is not worth it, IMHO context: ruby 2.5 CI started failing again, https://github.com/sparklemotion/mechanize/actions/runs/4382526288/jobs/7741821736#step:3:346
…nother-ruby25-ci-fix drop ruby 2.5 support
which allows us to handle frozen strings
…rop-force-encoding fix: stop force_encoding the page body
[skip ci]
to quash the node 12 warnings
…pdate-ci-actions ci: update actions/checkout version
…h-latest-user-agents Update user agent strings for agent aliases
versions 2.11.0..2.11.4 do not recover from encoding errors. upcoming release will change the encoding of the resulting doc as a result of recovery changes in libxml2. See https://gitlab.gnome.org/GNOME/libxml2/-/issues/543 for more context.
…sts-for-libxml2-encoding-changes test: work around libxml2 encoding changes
Related to 762df0c, we're seeing the upstream fixes did not ship in v2.11.5 so let's change the version test to assume it won't land until v2.12.0.
test: work around libxml2 encoding changes
…ix-require-order ci: test_mechanize_page_link requires nokogiri before using it
Net::HTTP::Persistent.write_timeoutnow exposes Net::HTTP.write_timeout since drbrain/net-http-persistent#99