Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read the response even if writing the request fails #6295

Merged
merged 1 commit into from
Oct 2, 2020

Conversation

swankjesse
Copy link
Member

@swankjesse swankjesse commented Oct 2, 2020

Closes: #1001

@@ -20,6 +20,7 @@ import java.net.ProtocolException
import okhttp3.Interceptor
import okhttp3.Response
import okhttp3.internal.EMPTY_RESPONSE
import okhttp3.internal.http2.ConnectionShutdownException
import okio.buffer
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the diffs on this file are worth viewing in 'ignore whitespace' mode because there’s a lot of indentation change

return response
} catch (e: IOException) {
if (sendRequestException != null) {
sendRequestException.addSuppressed(e)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

.build())

call.execute().use { response ->
assertThat(response.body!!.string()).isEqualTo("abc")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice!

@@ -1118,7 +1118,7 @@ private void writeChunk(BufferedSink sink) throws IOException {
assertThat(listener.recordedEventTypes()).containsExactly(
"CallStart", "ProxySelectStart", "ProxySelectEnd", "DnsStart", "DnsEnd", "ConnectStart",
"ConnectEnd", "ConnectionAcquired", "RequestHeadersStart", "RequestHeadersEnd",
"RequestBodyStart", "RequestFailed", "ConnectionReleased", "CallFailed");
"RequestBodyStart", "RequestFailed", "ResponseFailed", "ConnectionReleased", "CallFailed");
Copy link
Collaborator

@yschimke yschimke Oct 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have a test for this where it does successfully read the response? That is, even though server didn't read the request?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, the new test case includes that.

expectedEvents += "RequestHeadersStart"
expectedEvents += "RequestHeadersEnd"
expectedEvents += "RequestBodyStart"
expectedEvents += "RequestFailed"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe a trailing comment here highlighting that the important part is we read the response headers and body even on error.

@bessbd
Copy link

bessbd commented Oct 5, 2020

I've just verified this fix E2E in a project that uses okhttp. Thank you, @swankjesse

@ricellis
Copy link

We've been waiting for this for quite a long time, Is there any chance of a 4.x release that includes this fix?

@swankjesse
Copy link
Member Author

@ricellis 5.0.0-alpha.3 is out as of yesterday and it has it. I don't think we'll backport to 4.x because it's a riskier change. (We're tracking one regression related to internet disconnects.)

@ricellis
Copy link

I don't think we'll backport to 4.x because it's a riskier change.

Ah that's a shame because we missed 3.x to 4.x for the same reason once before, guess this fix has unlucky timing!

Thank you for the update.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Handling of early 403 FORBIDDEN with Connection: close whilst streaming
5 participants