Use upstream reqwest
instead of vendored one
#952
No reviewers
Labels
No labels
Android
CS::needs customer feedback
CS::needs follow up
CS::needs on prem installation
CS::waiting
Chrome
Design:: Ready
Design:: in progress
Design::UX
E2EE
Edge
Firefox
GDPR
Iteration 13 IM
Linux
MacOS
Need::Discussion
Need::Steps to reproduce
Need::Upstream fix
Needs:: Planning
Needs::Dev-Team
Needs::More information
Needs::Priority
Needs::Product
Needs::Refinement
Needs::Severity
Priority::1-Critical
Priority::2-Max
Priority::3-Impending
Priority::4-High
Priority::5-Medium
Priority::6-Low
Priority::7-None
Progress::Backlog
Progress::Review
Progress::Started
Progress::Testing
Progress::Triage
Progress::Waiting
Reporter::Sentry
Safari
Target::Community
Target::Customer
Target::Internal
Target::PoC
Target::Security
Team:Customer-Success
Team:Design
Team:Infrastructure
Team:Instant-Messaging
Team:Product
Team:Workflows
Type::Bug
Type::Design
Type::Documentation
Type::Feature
Type::Improvement
Type::Support
Type::Tests
Windows
blocked
blocked-by-spec
cla-signed
conduit
contribution::advanced
contribution::easy
contribution::help needed
from::review
iOS
p::ti-tenant
performance
product::triage
proposal
refactor
release-blocker
s: dart_openapi_codegen
s::Famedly-Patient
s::Org-Directory
s::Passport-Generator
s::Requeuest
s:CRM
s:Famedly-App
s:Famedly-Web
s:Fhiroxide
s:Fhiroxide-cli
s:Fhiroxide-client
s:Fhirs
s:Hedwig
s:LISA
s:Matrix-Dart-SDK
s:Role-Manager
s:Synapse
s:User-Directory
s:WFS-Matrix
s:Workflow Engine
s:dtls
s:famedly-error
s:fcm-shared-isolate
s:matrix-api-lite
s:multiple-tab-detector
s:native-imaging
severity::1
severity::2
severity::3
severity::4
technical-debt
voip
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Matthias/conduit#952
Loading…
Reference in a new issue
No description provided.
Delete branch "pr_upstream_reqwest"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This uses the
ClientBuilder::dns_resolver
function that was added in reqwest 0.11.13, instead of the homebrewClientBuilder::resolve_fn
.What upgrade path do you have in mind for Hyper 1.0 when
hyper::client::connect
gets moved into the less stablehyper-util
?Probably referring to the following in hyper's CHANGELOG.md:
From the text, it sounds like depending on hyper-util in addition to hyper will work.
Thanks! I agree that’ll work. If people are comfortable about depending on
hyper-util
, we could start moving over when it’s released: https://github.com/hyperium/hyper-util/blob/master/src/client/connect/dns.rsIt doesn't look like you need to wait until
hyper-util
is released. The changes work withhyper 0.14
and it'll also be possible to make them work oncehyper 1.0
is released.mentioned in issue #343
I have been using this for a month or two, and it works well for me. It stopped an observed crash with malformed well-known file.
Given the positive responses, I will merge this, but we will have to think about upgrading the dependencies soon, the GaiResolver was moved into hyper-util and marked as
legacy
added 69 commits
famedly:next
69d00032
- Use upstream `reqwest` instead of vendored oneCompare with previous version
mentioned in commit
c86f9a5c5b
mentioned in issue #327