javascript - headers - Angular $ http está enviando OPCIONES en lugar de PUT/POST

http post angular 5

Question

Estoy tratando de actualizar / insertar datos en una base de datos MySQL a través de un servidor PHP. Estoy construyendo el Front End con AngularJS y usando el servicio $http para comunicarme con la API REST.

Mi configuración se ve así:

Estoy configurando el encabezado a través del $ httpProvider:

 $httpProvider.defaults.withCredentials = true;
 $httpProvider.defaults.headers = {''Content-Type'': ''application/json;charset=utf-8''};

Y la POST-Call se ve así:

   return $http({
      url: url,
      method: "POST",
      data: campaign
    });

La consola de desarrollo en Chrome me muestra esto:

Cuando cambio de POST a PUT, estoy enviando una llamada de OPTIONS en lugar de un PUT. Y el tipo de contenido cambia solo a content-type .

Mi carga útil de solicitud se envía como un objeto:

¿Cómo configuro mi encabezado correctamente?

EDITAR:

El backend de PHP establece algunos encabezados:

   $e->getResponse()
              ->getHeaders()
              ->addHeaderLine(''Access-Control-Allow-Methods'', ''GET, POST, PUT, DELETE, OPTIONS'');

   $e->getResponse()
              ->getHeaders()
              ->addHeaderLine(''Access-Control-Allow-Origin'', ''*'');

¿Hay algo que falta?

Answer 1

No necesita especificar sus encabezados $http manualmente, todo se hace por usted detrás de escena y se configuran automáticamente en application/json para POST tipo POST y PUT . Entonces todo lo que debes hacer es

$http.post(url, data);
$http.put(url, data);

Answer 2

Ok, ya lo solucioné.

¿Cual fue el problema?
El flujo de trabajo de CORS para DELETE, PUT y POST es el siguiente:

Lo que hace es:

1. Verificando qué solicitud se hará
2. Si es POST, PUT o DELETE
3. Primero envía una solicitud de OPCIÓN para verificar si el dominio, desde el cual se envía la solicitud, es el mismo que el del servidor.
4. De lo contrario , quiere que un encabezado de acceso pueda enviar esta solicitud

Importante aquí: una solicitud de OPCIONES no envía credenciales .

Entonces, mi servidor backend rechazó la solicitud PUT.

Solución:
Poniendo esto dentro del archivo .htaccess

RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ blank.php [QSA,L]
Header set Access-Control-Allow-Origin "http://sub.domain:3000"
Header always set Access-Control-Allow-Credentials "true"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"

Después de esto, cree un archivo .php vacío llamado blank.php dentro de la carpeta pública.

EDITAR: Como señaló un comentarista, en lugar de crear un archivo PHP vacío, puede agregar esta regla de reescritura a su archivo .htaccess /;

RewriteRule ^(.*)$ $1 [R=200,L,E=HTTP_ORIGIN:%{HTTP:ORIGIN}]]

Para aclarar:

1. Ya envié el encabezado de control de acceso
2. Lo que resolvió fueron las dos primeras líneas, y
3. Access-Control-Allow-Origin desde el subdominio específico con Puerto

El mejor sitio web que pude encontrar para aprender más sobre CORS .