Fresco: La respuesta de error HTTP al cargar la imagen da como resultado una conexión filtrada
Descripción
Noté un montón de líneas de registro como esta en Logcat mientras usaba mi aplicación:
19098-19147/<package> W/OkHttpClient: A connection to <my server> was leaked. Did you forget to close a response body?
Finalmente lo reduje a un solo SimpleDraweeView que lo estaba causando cuando intenté establecer su URI de imagen.
Usando imagepipeline-okhttp3, agregué un interceptor y un cliente OkHTTP para poder inspeccionar lo que estaba sucediendo con la solicitud / respuesta HTTP. Resulta que la respuesta no fue 200, sino un error 401. Esto impidió que la imagen se cargara como se esperaba y también condujo a las líneas de registro anteriores.
Pude corregir este error 401 en particular usando un interceptor para agregar los encabezados de autenticación necesarios que me faltaban. Sin embargo, me preguntaba si hay diferentes errores HTTP en el futuro, ¿existe una forma general de detectar errores de tal manera que no se filtre una conexión?
Reproducción
Establezca un URI de imagen en SimpleDraweeView que dé como resultado una respuesta de código de error HTTP 401.
información adicional
- Versión Fresco: 1.5.0
- imagepipeline-okhttp3 versión: 1.5.0
stephen-workpop
Todos 4 comentarios
¡Gracias por el informe! No usamos OkHttp internamente, por lo que es una prioridad bastante baja para nosotros. ¡No dude en enviar una solicitud de extracción!
foghina
en 7 dic. 2017
@foghina ¿Puedes explicarme cómo Fresco estaba usando OkHttp incluso antes de que incluyera la dependencia imagepipeline-okhttp3? Recibía la línea de registro anterior cuando usaba la configuración predeterminada para Fresco (no usaba la configuración de la tubería de imagen OkHttp). Incluso revisé mi archivo build.gradle y me aseguré de excluir explícitamente OkHttp como una dependencia transitiva en todas las demás dependencias. Luego ejecuté gradle app:dependencies e inspeccioné el árbol de dependencias para asegurarme de que OkHttp no formaba parte de él. De alguna manera, todavía tengo la línea de registro quejándose de una fuga en la conexión OkHttp cuando Fresco cargó la imagen del problema. ¿OkHttp es utilizado internamente por el sistema Android? No veo de qué otra manera podría haber estado en los registros si no lo hubiera incluido como una dependencia y tampoco Fresco. Asumiría que si OkHttp no se incluyera como una dependencia o se estableciera explícitamente en la configuración de Fresco, internamente, Fresco solo usaría el cliente HTTP Apache o HttpURLConnection, que está integrado en el propio Android, en su lugar.
stephen-workpop
en 7 dic. 2017
Oh, aquí hay un tweet del propio Jake Wharton que dice que OkHttp es, de hecho, parte del sistema a partir de Android v4.4: https://twitter.com/JakeWharton/status/482563299511250944
Supongo que así es como se implementa HttpUrlConnection.
stephen-workpop
en 7 dic. 2017
Oh dulce. No tenia idea 😅
foghina
en 8 dic. 2017
Temas relacionados
sungerk
·
3Comentarios
ykostova
·
3Comentarios
836154942
·
3Comentarios
satyarths
·
3Comentarios
cococool
·
4Comentarios
Comentario más útil
Oh, aquí hay un tweet del propio Jake Wharton que dice que OkHttp es, de hecho, parte del sistema a partir de Android v4.4: https://twitter.com/JakeWharton/status/482563299511250944
Supongo que así es como se implementa HttpUrlConnection.