* Replace SocketPolicy with a new type, SocketEffect
SocketPolicy encapsulated two things:
- a trigger (request start, response body, etc)
- an effect (close the socket, close the stream, stall, etc.)
It also had some special cases for effects like
failing the TLS handshake.
With this PR there's a new class, SocketEffect, that determines
what to do. It's assigned to one of 5 fields for different
triggers.
# Conflicts:
# mockwebserver/src/main/kotlin/mockwebserver3/MockWebServer.kt
* apiDump
* Track API change
* Track more API changes
* Spotless
---------
Co-authored-by: Jesse Wilson <jwilson@squareup.com>
Also rename 'sequenceNumber' to 'exchangeIndex'.
This may be useful to test features like connection
reuse.
Co-authored-by: Jesse Wilson <jwilson@squareup.com>
* Change some MockWebServer ergonomics
Now calling MockWebServer.port and similar functions will
not implicity start the server. It is instead necessary to
explicitly call the start() function.
The problem with the old behavior was that reading the
port field could fail with an IOException, which is weird
behavior for reading a property.
* Fixup test
* Fix another test
---------
Co-authored-by: Jesse Wilson <jwilson@squareup.com>
* Decompose the request line into individual properties
Replace the 'path' property with the URL's encodedPath
property.
Rename the 'requestUrl' property to 'url'.
* Spotless
* Fix up DnsOverHttpsTest
* Fix some test failures
Also remove @ExperimentalOkHttpApi in a few places.
Also rename 'shutdown' to 'close' in MockWebServer
and Dispatcher.
Also rename QueueDispatcher.enqueueResponse() to
QueueDispatcher.enqueue.
Co-authored-by: Jesse Wilson <jwilson@squareup.com>
* Change MockWebServer to use Okio's new Socket interface
This replaces the Stream interface introduced in a recent
alpha release.
* apiDump
* Only buffer once
---------
Co-authored-by: Jesse Wilson <jwilson@squareup.com>
* Finalize the new API for MockResponse
It's a value object with a bunch of fields, and a builder.
* Tunnel then body
---------
Co-authored-by: Jesse Wilson <jwilson@squareup.com>
* TrailersSource, a new public API for HTTP trailers
This doesn't change much.
The new interface replaces a Kotlin lambda that had
similar behavior, though that lambda wasn't specified
as thoroughly.
We now permit calls to Response.trailers() before the
entire response body is consumed. But when such calls are
made the response body is discarded first. This could be
a bit of a surprise to users, especially users who do an
additional layer of buffering over their ResponseBody
because it could yield latent failures.
But I think it's better behavior overall, especially since
it's possible data binding layers might not consume the
entire response body in all cases. For example, a JSON
library might not read to the very end of the response
if it has received a terminating '}' byte.
The riskiest part of this change is when ResponseBodySource
self-reports as complete. Previously it would self-report
as complete when it returned as many bytes as promised
in the Content-Length. With this change it will now only
report itself complete when it receives a definitive EOF
on the stream, signaled by a -1 byte count on a read. This
is because only when the EOF is received can we be sure
that the trailers are received, and we must not unhook
the Exchange from the Call until that happens. The previous
behavior could make Call.cancel() no-op even if we were
blocked waiting on trailers.
* apiDump
* Attempt to get more tests passing
* Don't wait for stream EOF to release the stream
One of our tests caught a situation where we were waiting
for the caller to read the EOF when we didn't need to.
---------
Co-authored-by: Jesse Wilson <jwilson@squareup.com>
* Public API for duplex streams in MockWebServer
I'm not 100% on the name 'Stream' for the source+sink pair. It's
tempting to use 'Socket', though I think that's an implementation name
and this is an abstraction that uses a different implementation.
I've chosen Stream specifically 'cause it's the word used in the
HTTP/2 spec. My biggest gripe with it is that it's bidirectional
in the HTTP/2 spec, but Java InputStream and OutputStream are not
bidirectional.
* Dump APIs for streams
* Don't include a Content-Length header for chunked bodies
* Convert MockWebServerTest to Kotlin (#7596)
* Rename .java to .kt
* Convert Java to Kotlin
* Null isn't special for last-write wins
* Attempt to make NonCompletingRequestBody less flaky
* Create MockResponseBody
We'd previously only ever used Buffer to model the type
of the MockResponse body. This has proven inadequate, particularly
for features like duplex responses.
Most of the complexity in this PR is changing how throttling
and disconnect-during-body work when we don't necessarily have
a Buffer for the response body.
This is a first step, more capability to follow.
* Update API
* We flush fewer times now
* Attempt to make a test less flaky
* Try harder to make the test less flaky
* Switch to a Builder for mockwebserver3.MockResponse
* Migrate lots of tests to MockResponse.Builder
* Improve some code style
* Follow naming conventions in MockResponse.Builder
* Apply side-effects for inTunnel=true
* Update the API
* Implement CONNECT tunnels for HTTP/2 prior knowledge
Closes: https://github.com/square/okhttp/issues/7289
* Update the API spec for MockWebServer
* It is okay for HTTP/2 prior knowledge to send data early
Tests were failing due to an overly-pessimistic 'too much buffering'
exception. I moved the detector to where it's actually needed.
* Change how HTTP 1xx responses work in MockWebServer
Previously this was a SocketPolicy. With this change each
response may carry 0 or more informational responses which
are transmitted before the ultimate response.
* Add a test for multiple 1xx responses
* Update API
