Cómo modificar las cabeceras de una petición con nginx

Escenario

Hay que migrar una servicio API a una nueva plataforma. Esto implica rehacer el código desde cero y al mismo tiempo respetar todos los endpoints y aceptar las peticiones de los clientes del API tal y como se estaban mandando hasta ahora.

Problema

Las peticiones del cliente vienen mal formadas: se estaban mandado usando el método POST, usando el valor «POST» para la clave «content-type» de la cabecera. «POST» no es un mime type conocido, por lo que el controlador devolvía una respuesta con el código de error 415 (Unsupported Media Type).

Solución

Para descubrir qué tipo de contenido se estaba mandando, primero tuve que añadir ese dato a los registros de servidor web (nginx): De esta manera pude confirmar que el tipo de contenido enviado era «POST»: Como ya he dicho, uno de los requisitos era respetar la manera en la que el cliente mandaba las peticiones, de modo que tuve que apañármelas a nivel de servidor para que, cuando llegara una petición con una cabecera cuya clave content-type fuera igual a «POST», cambiarla por «application/json». Con nginx es sencillo:

Publicaciones Similares

  • Chart.js: cómo cambiar el idioma (locale) dinámicamente

    Escenario Por un lado una aplicación que permite al usuario personalizar el idioma del sitio. Por otro, una gráfica de tipo línea temporal generada con la biblioteca Chart.js, integrada en un módulo de React con react-chartjs-2. Problema Según un comentario de un usuario de Stackoverflow, basta con un require('moment/min/moment-with-locales'); y establecer el valor de la…

  • Instalación certificado raíz Comodo

    Escenario Hemos migrado nuestro repositorio de git a un nuevo servidor y tenemos que actualizar las URLs de los orígenes de nuestros repositorios locales. Problema Cambiamos la url remota del repositorio local de git con el comando git remote set-url y, tras hacer un pull git nos devuelve el siguiente error: fatal: unable to access 'https://git.technoage.es/acme.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Solución Por lo visto nuestra…

  • |

    Cómo ampliar el espacio en disco en 1and1

    Escenario Hemos contratado un servidor dedicado en 1and1 (ubuntu 14.04) y al acceder por ssh constatamos que no disponemos de todo el espacio en disco disponible: $ df -hFilesystem Size Used Avail Use% Mounted onudev 3.9G 4.0K 3.9G 1% /devtmpfs 798M 592K 797M 1% /run/dev/md1 4.0G 990M 3.0G 25% /none 4.0K 0 4.0K 0% /sys/fs/cgroupnone 5.0M 0 5.0M 0% /run/locknone 3.9G 0 3.9G 0% /run/shmnone 100M 0 100M 0% /run/user/dev/mapper/vg00-usr 4.8G 1.3G 3.3G 28% /usr/dev/mapper/vg00-var 4.8G 812M 3.8G 18% /var/dev/mapper/vg00-home 4.8G 10M 4.6G 1% /home Objetivo Aumentar el espacio disponible para dar cabida a nuestros recursos. Solución Nota: sólo aplicable a sistemas linux Primer paso Comprobamos el espacio en disco real: ~$ sudo fdisk -lDisk /dev/sda: 240.1 GB, 240057409536 bytes255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 4096 bytesI/O size (minimum/optimal): 4096 bytes / 4096 bytesDisk identifier: 0x24e3fc12   Device Boot      Start         End      Blocks   Id  System/dev/sda1            2048     8390655     4194304   fd  Linux raid autodetect/dev/sda2         8390656    12584959     2097152   82  Linux swap / Solaris/dev/sda3        12584960   468862127   228138584   fd  Linux raid autodetect Segundo…

  • Despliegue aplicación Spring Boot

    Escenario Queremos desplegar en la nube una aplicación desarrollada con Spring Boot cuyo código está bajo control de versiones. Para este artículo usaremos ubuntu 16.04 y java 8, pero el procedimiento debería ser el mismo con versiones más actuales. Problema Ninguno. Realmente es sencillo desplegar una aplicación de este tipo si se dispone de las…

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *