Solicitud HTTP de Angular enviada como OPCIONES en lugar de POST

Tenemos la mejor solución que hemos encontrado por todo internet. Nosotros deseamos que te resulte útil y si puedes aportar algo que nos pueda ayudar a crecer hazlo con libertad.

Solución:

los OPTIONS la petición se llama así solicitud previa al vueloque es parte de Intercambio de recursos de origen cruzado (CORS). Los navegadores lo usan para verificar si se permite una solicitud de un dominio en particular como sigue:

1. El navegador quiere enviar una solicitud, digamos un POST solicitud con el application/json tipo de contenido
2. Así que primero, envía el antes del vueloOPTIONS solicitud
3. Si el servidor responde con una respuesta de estado que no es 2XX, el navegador no enviará la solicitud real (porque ahora sabe que sería rechazada de todos modos)
4. Si el navegador tiene un HTTP 200 OK respuesta a la solicitud previa al vuelo, envía la solicitud real, POST en tu caso

---

Teoría

Solicitudes simples

navegadores no son enviando el antes del vuelo solicitudes en algunos casos, esos son los llamados solicitudes simples y se utilizan en las siguientes condiciones:

• Uno de los métodos permitidos:
  • GET
  • HEAD
  • POST
• Además de los encabezados establecidos automáticamente por el agente de usuario (por ejemplo, Conexión, Agente de usuario, etc.), los únicos encabezados que se pueden configurar manualmente son los siguientes:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (pero tenga en cuenta los requisitos adicionales a continuación)
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
• Los únicos valores permitidos para el encabezado Content-Type son:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain
• No hay detectores de eventos registrados en ningún XMLHttpRequestUpload objeto utilizado en la solicitud; a estos se accede mediante el XMLHttpRequest.upload propiedad.
• No ReadableStream objeto se utiliza en la solicitud.

Dichas solicitudes se envían directamente y el servidor simplemente procesa correctamente la solicitud o responde con un error en caso de que no coincida con las reglas de CORS. En cualquier caso, la respuesta contendrá los encabezados CORS Access-Control-Allow-*.

Solicitudes comprobadas previamente

navegadores están enviando el antes del vuelo solicitudes si la solicitud real no cumple con los petición sencilla condiciones, la mayoría de las veces:

• tipos de contenido personalizado como application/xml o application/jsonetc., se utilizan
• el método de solicitud es diferente a GET, HEAD o POST
• los POST el método es de otro tipo de contenido que application/x-www-form-urlencoded, multipart/form-data o text/plain

Necesitas asegúrese de que la respuesta a la antes del vuelo solicitud tiene lo siguiente attributes:

• código de estado HTTP exitoso, es decir 200 OK
• encabezamiento Access-Control-Allow-Origin: * (un comodín * permite una solicitud de cualquier dominio, puede usar cualquier dominio específico para restringir el acceso aquí, por supuesto)

Desde el otro lado, el servidor puede rechazar la solicitud CORS simplemente enviando una respuesta a la antes del vuelo solicitud con lo siguiente attributes:

• código HTTP sin éxito (es decir, que no sea 2XX)
• éxito código HTTP (p. ej. 200 OK), pero sin ningún encabezado CORS (es decir, Access-Control-Allow-*)

Consulte la documentación en Mozilla Developer Network o, por ejemplo, el tutorial CORS de HTML5Rocks para obtener más detalles.

---

TL; DR respuesta

Entonces, en su caso, el encabezado adecuado está presente, solo tiene que Asegúrate que antes del vuelo el código de estado HTTP de la respuesta es 200 OK o alguna otra exitosa (2XX).

Me encontré con un problema muy similar al escribir una aplicación Angular 2, que usa un servidor NODE para la API.

Como estoy desarrollando en mi máquina local, seguí teniendo problemas con el encabezado de origen cruzado, cuando intentaba publicar en la API desde mi aplicación Angular.

La configuración de los encabezados (en el servidor de nodos) como se muestra a continuación funcionó para las solicitudes GET, pero mis solicitudes PUT seguían publicando objetos vacíos en la base de datos.

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT');
header('Access-Control-Allow-Headers: X-Requested-With, Content-Type, 
Origin, Authorization, Accept, Client-Security-Token, Accept-
Encoding, X-Auth-Token, content-type');

Después de leer la publicación de Dawid Ferenczy, me di cuenta de que la solicitud PREFLIGHT estaba enviando datos en blanco a mi servidor, y es por eso que las entradas de mi base de datos estaban vacías, así que agregué esta línea en el servidor NODE JS:

  if (req.method == "OPTIONS")
    
        res.writeHead(200, "Content-Type": "application/json");
        res.end();
    

Entonces, ahora mi servidor ignora la solicitud PREFLIGHT (y devuelve el estado 200, para que el navegador sepa que todo está bien …) y de esa manera, la solicitud real puede pasar y ¡obtengo datos reales publicados en mi base de datos!

Sólo hay que poner

if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') 
header("HTTP/1.1 200 ");
exit;

al comienzo de su aplicación del lado del servidor y debería estar bien.

Tienes la opción de añadir valor a nuestra información participando con tu veteranía en los comentarios.

---

---

Utiliza Nuestro Buscador