Código de estado HTTP 0 - Dominio de error = NSURLErrorDomain?

Estoy trabajando en un proyecto de iOS.

En esta aplicación, estoy descargando imágenes del servidor.

Problema:

Mientras descargo imágenes, obtengo Request Timeout . Según la documentación, el código de estado HTTP del tiempo de espera de la solicitud es 408.

Pero en mi aplicación, obtengo el código de estado HTTP 0con el siguiente error

Error Domain = NSURLErrorDomain Code = -1001 "Se agotó el tiempo de espera de la solicitud". UserInfo = 0xb9af710 {NSErrorFailingURLStringKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg , NSErrorFailingURLKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg , NSLocalizedDescription out = The NSLocalizedDescription out = ., NSUnderlyingError = 0x13846870 "Se agotó el tiempo de espera de la solicitud."}

Durante una búsqueda, a través de Internet, no encontré información sobre el código de estado HTTP 0.

¿Puede alguien explicarme esto?

No hay código de estado HTTP 0. Lo que ve es un 0 devuelto por la API / biblioteca que está utilizando. Tendrá que verificar la documentación para eso.

Un código de estado de 0 en un NSHTTPURLResponseobjeto generalmente significa que no hubo respuesta y puede ocurrir por varias razones. El servidor nunca devolverá un estado de 0 ya que este no es un código de estado HTTP válido.

En su caso, parece que obtiene un código de estado de 0 porque la solicitud se está agotando y 0 es solo el valor predeterminado para la propiedad. El tiempo de espera en sí podría deberse a varias razones, como que el servidor simplemente no responde a tiempo, está bloqueado por un firewall o toda la conexión de red está inactiva. Por lo general, en el caso de este último, el teléfono es lo suficientemente inteligente como para saber que no tiene conexión de red y fallará inmediatamente. Sin embargo, aún fallará con un código de estado aparente de 0.

Tenga en cuenta que en los casos en que el código de estado es 0, el error real se captura en el NSErrorobjeto devuelto , no en el NSHTTPURLResponse.

El estado HTTP 408es bastante poco común en mi experiencia. Yo nunca me he encontrado con uno. Pero aparentemente se usa en los casos en que el cliente necesita mantener una conexión de socket activa con el servidor, y el servidor está esperando que el cliente envíe más datos a través del socket abierto, pero no lo hace en un período de tiempo determinado y el servidor finaliza la conexión con un 408código de estado, que básicamente le dice al cliente "tardó demasiado".

La respuesta fue vacía. La mayoría de los casos, los códigos se mostrarán con 1xx, 2xx, 3xx, 4xx, 5xx.

Lista de códigos de estado HTTP

En iOS SDK Cuando su API llama a los tiempos de espera, obtiene el estado 0 para eso.

Desde mi limitada experiencia, diría que los siguientes dos escenarios podrían causar una respuesta status code: 0, tenga en cuenta; podrían ser más, pero yo sé de esos dos:

• su conexión puede responder lentamente.
• o tal vez el servidor back-end no esté disponible.

la cosa es que status: 0es un poco genérico y podrían haber más casos de uso que desencadenan un cuerpo de respuesta vacío.

El código de estado '0' puede ocurrir por tres razones
1) El Cliente no puede conectarse al servidor
2) El Cliente no puede recibir la respuesta dentro del período de tiempo de espera
3) La Solicitud fue "detenida (abortada)" por el Cliente.

Pero estas tres razones no están estandarizadas

La respuesta HTTP 0 no es una respuesta HTTP estándar. Pero indica que el cliente no pudo conectarse con el servidor y, por lo tanto, se agotó el tiempo de espera.

Tenemos el error:

GET http: //localhost/pathToWebSite/somePage.aspx generó un error http.status: 0

Esa llamada se realiza desde una tarea de Windows que llama a un archivo VBS, por lo que para solucionar el problema, apuntó un navegador a la URL y obtenemos un Error de privacidad:

Tu conexión no es privada

Los atacantes podrían estar intentando robar su información de localhost (por ejemplo, contraseñas, mensajes o tarjetas de crédito). NET :: ERR_CERT_COMMON_NAME_INVALID

Informar automáticamente los detalles de posibles incidentes de seguridad a Google. Política de privacidad Volver a la seguridad Este servidor no pudo probar que es localhost; su certificado de seguridad es de * .ourdomain.com. Esto puede deberse a una configuración incorrecta o un atacante que intercepta su conexión. Aprende más.

Esto se debe a que tenemos un conjunto de reglas de reescritura de URL de IIS para forzar que las conexiones usen https. Esa regla desvía http: // localhost a https: // localhost pero nuestro certificado SSL se basa en un nombre de dominio externo, no localhost, por lo que el error se informa como código de estado 0. Por lo tanto, un error de privacidad podría ser una razón muy oscura. para este código de estado 0.

En nuestro caso, la solución fue agregar una excepción a la regla para localhost y permitir que http: //localhost/pathToWebSite/somePage.aspx use http. Oscuro, sí, pero me encontraré con esto el próximo año y ahora encontraré mi respuesta en una búsqueda en Google.

A veces, el navegador responde al controlador de errores http con un objeto de error, que tiene el estado establecido en 0, incluso si puede ver el estado de error 404, 401, 500, etc.en la red.

Esto podría suceder si su aplicación y API están en dominios diferentes: se aplica el mecanismo CORS. Según CORS, para cada solicitud de API, el navegador envía dos solicitudes:

1. Solicitud de OPCIONES de verificación previa para comprender si la API permite la solicitud de origen / real.
2. cuando la API lo permite (la solicitud de OPTIOS responde con el estado 204 y los encabezados de Access-Control-Allow-Origin correctos) - el navegador envía la siguiente "Solicitud de origen / real".

En la aplicación, estamos manejando la respuesta de error para "Solicitud real / de origen", y si la "solicitud de OPCIONES de verificación previa" falla, el navegador no proporciona el objeto HttpError correcto para el controlador de errores http. Por lo tanto, para obtener el estado correcto de la respuesta http, asegúrese de obtener una respuesta de solicitud de OPCIONES de verificación previa exitosa.

CORS en mi caso.

Una vez tuve esa respuesta en una aplicación de iOS. La solución fue la falta Access-Control-Allow-Origin: *en los encabezados.

Más: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

Esto puede suceder con una respuesta http 401 si usa NSURLConnection.

Consulte NSURLConnection que devuelve el error en lugar de la respuesta para 401

En el tiempo de espera de la puerta, el estado será cero en su devolución de llamada de error.

.error( function( data,status,headers,config){
    console.log(status) 
 }

Códigos de estado HTTP