We attempt to minimize connection and reconnection work, but in this case we
were overly aggressive about retaining the same connection. In some deployments
services will share certificates but not DNS addresses; when redirecting
between such services we were incorrectly attempting to reuse the connection.
This would have resulted in 404s and other misdirected requests.
Closes: https://github.com/square/okhttp/issues/5859
* Allow for users who have disabled certificate checks in dev.
* Avoid repeated calls
* typo
* Lock is assumed at this point
* Stay safe
* rework
* spotless
* Fix
* Handle one more case
* Capture the exception
* Add test
* Comment
Previously we didn't do any health checks at all until a
connection completed a single exchange. This was awkward
for HTTP/2, which could have multiple exchanges in-flight
before any were health checked.
We were also doing the awkward and expensive read timeout
check on all non-GET requests on pooled connections. Now
we only perform these checks if the connection was idle
for 10 seconds or more.
Closes: https://github.com/square/okhttp/issues/5547
We originally had a bug where Call.cancel() would incorrectly
cause HTTP/2 connections to be closed.
The fix was to not consider HTTP/2 connections to be degraded
when a CANCEL error is received:
https://github.com/square/okhttp/pull/4052
This closes the loop to make sure that we only treat CANCEL as
expected when the call was actually canceled.
Closes: https://github.com/square/okhttp/issues/5726
I prefer the old code esthetically, but this has the behavior I want. The
core problem is we're deciding about nextRouteToTry too early, before a
failure makes that route ineligible.
Closes: https://github.com/square/okhttp/issues/5791
We limit per-connection retries but not per-call retries, so this was
creating large numbers of connections each of which called the server
and accepted yet another REFUSED_STREAM.
Instead we fail sooner with a StreamResetException.
This shows that the ExchangeFinder interface is still somewhat inadequate
to support all of the use cases we have.
There's four useful events:
1. When we're ready to call network interceptors. At this point
we expect an exchange to exist, as a handle to the connection
we've chosen for the network call
2. When we hold an exchange that must later be released.
3. When we release the exchange
4. When we're done calling network interceptors. Only at this point
do we no longer need to remember what the exchange was and what
connection it used.
In practice 1 and 2 happen mostly at the same time. Right now 1 is
in RetryAndFollowUpInterceptor and 2 is in ConnectInterceptor, but
we should be able to move those around without pain.
But we have a problem with 3 and 4. If the response has no response
body, then 3 will precede 4. We will release the exchange as soon as
we know there's no streams held. This means that network interceptors,
including our own RetryAndFollowUpInterceptor, do not consistently
have an exchange after they've called proceed(). This is problematic
if they want to make decisions based on what connection was used.
I've added a new member, 'interceptorScopedExchange' that holds the
exchange from 1 and 2 through 4, regardless of when 3 happens.
This is all working towards a solution to handling HTTP 421s on
coalesced connections.
https://github.com/square/okhttp/issues/5424
I've attempted to put RealCall's methods into a logical order; it's approximately
the order the methods get called in for a successful call.
For RealInterceptorChain I've created a copy() method inspired-by data classes.
This has the added benefit of shrinking the call stack everywhere.
These two were 1:1 with each other and there were a few places in the code
where we had both. Putting them into the same class creates a class that
does has a lot of responsibilities, but I believe it's simpler overall than
having two classes.
* Updated bug bounty
* Fix the bugcrowd URL
* Fix the bugcrowd URL
* Restore the https:// in the bugcrowd URL
Co-authored-by: Jesse Wilson <jesse@swank.ca>
