Solución:
El problema está relacionado con Solicitudes CORS, ver este problema de github
No hay un encabezado ‘Access-Control-Allow-Origin’ presente en el recurso solicitado
significa que 'Access-Control-Allow-Origin' es obligatorio en los encabezados de respuesta.
Angular no recibe ningún código de estado, por eso te da una 0 que se debe a que el navegador no permite xml parser para analizar el response debido a inválido headers.
Necesitas adjuntar correctamente Encabezados CORS para usted error response al igual que success.
Si cloudcms.com no configura el Access-Control-Allow-Origin en la respuesta 401, entonces no puedes hacer mucho. Debe abrir el ticket de soporte correctamente con ellos para confirmar si ese es un comportamiento normal.
javascript en los navegadores (FF, Chrome y Safari) que probé no recibiré ninguna información si se produce un error CORS, que no sea el estado 0. Angular2 no tiene control sobre él.
Creé una prueba simple y obtuve el mismo resultado que el tuyo:
geturl() {
console.log('geturl() clicked');
let headers = new Headers({ 'Content-Type': 'application/xhtml+xml' });
let options = new RequestOptions({ 'headers': headers });
this.http.get(this.url)
.catch((error): any => {
console.log('************* ERROR Response', error);
let errMsg = (error.message) ? error.message :
error.status ? `${error.status} - ${error.statusText}` : 'Web Server error';
return Observable.throw(error);
})
.subscribe(
(i: Response) => { console.log(i); },
(e: any) => { console.log(e); }
);
}
Después de mucho buscar en Google, encontré lo siguiente (https://github.com/angular/angular.js/issues/3336):
lucassp comentó el 19 de agosto de 2013
Encontré el problema por un tiempo, pero olvidé publicar aquí una respuesta. CADA respuesta, incluso el Error 500, debe tener los encabezados CORS adjuntos. Si el servidor no adjunta los encabezados CORS a la respuesta del Error 500, el Objeto XHR no lo analizará, por lo que el Objeto XHR no tendrá ningún cuerpo de respuesta, estado ni ningún otro dato de respuesta dentro.
El resultado del monitor de red de Firefox parece respaldar la razón anterior.
La solicitud de Javascript recibirá una respuesta vacía.
La solicitud de URL simple (copie y pegue el enlace en la barra de direcciones) obtendrá el cuerpo de la respuesta
Javascript usa XHRHttpRequest para la comunicación http.
Cuando llega una respuesta XHR, el navegador procesará el encabezado, por eso verá esos mensajes de red 401. Sin embargo, si la respuesta XHR es de un host diferente, el javascript Y el encabezado de respuesta no contienen encabezado CORS (p. Ej. Access-Control-Allow-Origin: *), el navegador no devolverá ninguna información a la capa XHR. Como resultado, el cuerpo de la respuesta estará completamente vacío sin estado (0).
Probé con FF 48.0.1, Chrome 52.0.2743.116 y Safari 9.1.2, y todos tienen el mismo comportamiento.
Use el monitor de red del navegador para verificar el encabezado de respuesta para aquellos 401 Unauthorized entradas, es muy probable que no haya Access-Control-Allow-Origin encabezado y causando el problema al que se enfrenta. Esto puede ser un error o por diseño del proveedor de servicios.
Access-Control-Allow-Origin es un encabezado http solo de respuesta. Para obtener más información de https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#The_HTTP_response_headers
Trabajo para Cloud CMS. Puedo confirmar que configuramos correctamente los encabezados CORS en las llamadas a la API. Sin embargo, para las respuestas 401, los encabezados no se configuran correctamente. Esto se ha resuelto y la corrección estará disponible en la API pública al final de esta semana.
Por cierto, si usa nuestro controlador javascript https://github.com/gitana/gitana-javascript-driver en lugar de escribir en la API directamente, el flujo de reautorización se maneja automáticamente y no necesita atrapar errores 401 en absoluto.