-
Notifications
You must be signed in to change notification settings - Fork 670
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
Duplicate network request for images with chunked response #1543
Comments
@Fayth Does OkHttp have the same behaviour for that URL? Coil's |
I haven't used "raw" okhttp much, but from what I tried, there's only one GET request when using this sample request:
Looking through okhttp source, I think the only place where it uses content length in higher-level logic is ensuring there's no body for 204/205 responses. |
Hello, we just ran into this for @Test
fun `chunked response`() = runTestAsync {
val url = server.url(IMAGE).toString()
server.enqueueChunkedImage(IMAGE)
server.enqueueChunkedImage(IMAGE)
val fetcher = newFetcher(url, Options(context, diskCachePolicy = CachePolicy.DISABLED))
fetcher.fetch()
assertEquals(1, server.requestCount)
}
fun MockWebServer.enqueueChunkedImage(image: String) {
val buffer = Buffer()
val context = ApplicationProvider.getApplicationContext<Context>()
context.assets.open(image).source().buffer().readAll(buffer)
val response = MockResponse().setBody(buffer).removeHeader("Content-Length")
enqueue(response)
} I also tried it with current coil/coil-network-core/src/commonMain/kotlin/coil3/network/NetworkFetcher.kt Lines 70 to 71 in e553267
However, as 3.0 is still in alpha, we'd prefer to have a fix in 2.x. I am open to creating a PR if there is a chance to get it merged. |
This is fixed in 2.7.0. |
Describe the bug
Scenario:
Content-Length
header)results in two requests to given url (despite the first one being successful)
To Reproduce
Logs/Screenshots
The cause seems to be the verification in https://github.com/coil-kt/coil/blob/main/coil-base/src/main/java/coil/fetch/HttpUriFetcher.kt#L95 which relies on explicit content length being provided in response. In the scenario above the length isn't known (okhttp reports it as -1)
Version
2.2.2
It might be enough to allow
contentLength() == -1
in the check mentioned above (it seems to fix the problem in my case) or possibly also peeking the response body buffer to make sure it's not emptyThe text was updated successfully, but these errors were encountered: