Rather than getting the content length from a header on demand, this gets it
at the time that the RealResponseBody is created. This means that HEAD requests
can have a non-zero Content-Length header while their bodies have no content.
Closes: https://github.com/square/okhttp/issues/3365
We were assuming on a client failure the server wouldn't have any
further events. But it will get a failure if we give it a moment.
This was causing some test flakiness.
Currently our implementation acquires the connection early so that we have
something to close if the call is canceled. Event listeners are simpler if
they only get a connectionAcquired event once the connection has been
actually established.
This is an edge case that can occur with HTTP/2. Since multiple requests
use the same connection, it's possible for one request to restrict the
connection from creating new streams during a follow-up request.
https://github.com/square/okhttp/issues/3521
* Lookup the FQDN given the MockWebServer hostname to compare with the HttpUrl hostname. Issue #3546.
* Update MockWebServer to use the FQDN for its host name. Issue #3546.
* API in place, some tests, but some -1 sent
* typo
* header length and temporarily the request length if known
* reformat
* fix TODOs
* missing re-throw
* remove todo
* count request body bytes
* rename l -> value
* Allow using an encoding other than UTF-8 for creating urlencoded request form bodies.
This is useful when accessing a web server you don't control which receives form data
encoded in a charset other than UTF-8 (e.g. ISO-8859-1).
To use this you pass an encoding to FormBody.Builder constructor. The constructor is used so
it's clear you shouldn't switch encodings in the middle of building a form body.
The result is undefined is a character cannot be encoded in the specified charset (as the
result of Java's String.getBytes(charset) is also undefined in that case.
* Update HttpUrl.java
* Improve variable name in RouteSelector.
* Honor retryOnConnectionFailure on a client request timeout.
Also limit the number of retry attempts. This functionality is
consistent with how Chrome handles 408's presently.
Closes: https://github.com/square/okhttp/issues/3483
* Fill out documentation for EventListener
* rename connectionFound
* tests for connectionFound updated
* cleanup
* address comment on body calls
* Update EventListener.java
* connect end event added a Proxy to match against start event
Previously we'd only look at one route at a time. If DNS returned
results in random order it would lower our chances of finding a
coalesced connection. Now we consider all routes at once which hopefully
improves our chances.
Loading the resource using a path relative to the class prevents conflicts
when the okhttp classes are relocated (shaded) by allowing multiple
private copies of the database.
