PUBLICACIÓN (HTTP)

HTTP
Persistencia Compresión HTTPS RÁPIDO
Métodos de solicitud
OPCIONES CONSEGUIR CABEZA CORREO PONER BORRAR RASTRO CONECTAR PARCHE
Campos de encabezado
Galleta Etiqueta electrónica Ubicación Referencia HTTP No disponible X-Reenviado-Para
Códigos de estado de respuesta
301 se trasladó de forma permanente 302 encontrados 303 Ver otros 403 Prohibido 404 No encontrado 451 No disponible por razones legales
Métodos de control de acceso de seguridad
Autenticación de acceso básica Autenticación de acceso mediante resumen
Vulnerabilidades de seguridad
Inyección de encabezado HTTP Contrabando de solicitudes HTTP División de la respuesta HTTP Contaminación de parámetros HTTP
en a mi

En informática , POST es un método de solicitud compatible con HTTP que se utiliza en la World Wide Web . Por diseño, el método de solicitud POST solicita que un servidor web acepte los datos incluidos en el cuerpo del mensaje de solicitud, probablemente para almacenarlos. ^[1] Se suele utilizar al cargar un archivo o al enviar un formulario web completo .

Por el contrario, el método de solicitud HTTP GET recupera información del servidor. Como parte de una solicitud GET, se pueden pasar algunos datos dentro de la cadena de consulta de la URL , especificando (por ejemplo) términos de búsqueda, rangos de fechas u otra información que defina la consulta.

Como parte de una solicitud POST, se puede enviar al servidor una cantidad arbitraria de datos de cualquier tipo en el cuerpo del mensaje de solicitud. Un campo de encabezado de campos en la solicitud POST generalmente indica el tipo de medio de Internet del cuerpo del mensaje.

La World Wide Web y el protocolo HTTP se basan en una serie de métodos de solicitud o "verbos", entre los que se incluyen POST y GET, así como PUT, DELETE y varios otros. Los navegadores web normalmente utilizan solo GET y POST, pero las aplicaciones en línea RESTful hacen uso de muchos de los otros. El lugar de POST en el rango de métodos HTTP es enviar una representación de una nueva entidad de datos al servidor para que se almacene como un nuevo subordinado del recurso identificado por el URI . ^[1] Por ejemplo, para el URI , se podría esperar que las solicitudes POST representen nuevos clientes, cada uno incluyendo su nombre, dirección, detalles de contacto, etc. Los primeros diseñadores de sitios web se alejaron de este concepto original de dos maneras importantes. Primero, no hay ninguna razón técnica para que un URI describa textualmente el recurso web subordinado al cual se almacenarán los datos POST. De hecho, a menos que se haga algún esfuerzo, la última parte de un URI probablemente describa la página de procesamiento de la aplicación web y su tecnología, como . En segundo lugar, dada la limitación natural de la mayoría de los navegadores web de usar solo GET o POST, los diseñadores sintieron la necesidad de reutilizar POST para realizar muchas otras tareas de envío y gestión de datos, incluida la alteración de registros existentes y su eliminación.http://example.com/customershttp://example.com/applicationform.php

Los esfuerzos de algunos escritores influyentes para remediar el primer punto comenzaron ya en 1998. ^{[2] [ se necesita una mejor fuente ]} Los marcos de aplicaciones web como Ruby on Rails y otros facilitan a los diseñadores proporcionar a sus usuarios URL semánticas . Con respecto al segundo punto, es posible utilizar scripts del lado del cliente o escribir aplicaciones independientes para hacer uso de los otros métodos HTTP cuando sean relevantes, ^[3] pero fuera de esto, la mayoría de los formularios web que envían o modifican datos del servidor continúan utilizando POST para este propósito.

Esto no quiere decir que cada formulario web deba especificar method="post"en su etiqueta de apertura . Muchos formularios se utilizan para especificar con mayor precisión la recuperación de información del servidor, sin ninguna intención de alterar la base de datos principal. Los formularios de búsqueda, por ejemplo, son ideales para tener method="get"una especificación. ^[4]

Hay ocasiones en las que HTTP GET es menos adecuado incluso para la recuperación de datos. Un ejemplo de esto es cuando se necesita especificar una gran cantidad de datos en la URL. Los navegadores y servidores web pueden tener límites en la longitud de la URL que manejarán sin truncamiento o error. La codificación porcentual de caracteres reservados en URL y cadenas de consulta puede aumentar significativamente su longitud, y mientras que Apache HTTP Server puede manejar hasta 4.000 caracteres en una URL, ^[5] Microsoft Internet Explorer está limitado a 2.048 caracteres en cualquier URL. ^[6] De igual modo, HTTP GET no debe utilizarse cuando se debe enviar información confidencial, como nombres de usuario y contraseñas, junto con otros datos para que se complete la solicitud. Incluso si se utiliza HTTPS , evitando que los datos sean interceptados en tránsito, el historial del navegador y los registros del servidor web probablemente contendrán la URL completa en texto sin formato, que puede quedar expuesta si alguno de los sistemas es pirateado. En estos casos, se debe utilizar HTTP POST. ^[7]

Cuando un navegador web envía una solicitud POST desde un elemento de formulario web , el tipo de medio de Internet predeterminado es " application/x-www-form-urlencoded ". ^[8] Este es un formato para codificar pares clave-valor con claves posiblemente duplicadas. Cada par clave-valor está separado por un carácter '&', y cada clave está separada de su valor por un carácter '='. Tanto las claves como los valores se escapan reemplazando los espacios con el carácter '+' y luego usando la codificación de porcentaje en todos los demás caracteres no alfanuméricos ^[9] .

Por ejemplo, los pares clave-valor

Nombre: Gareth WylieEdad: 24Fórmula: a+b == 21

están codificados como

Nombre=Gareth+Wylie&Edad=24&Fórmula=a%2Bb+%3D%3D+21

A partir de HTML 4.0, los formularios también pueden enviar datos en multipart/form-data como se define en RFC 2388 (consulte también RFC 1867 para obtener una versión experimental anterior definida como una extensión de HTML 2.0 y mencionada en HTML 3.2).

El caso especial de un POST a la misma página a la que pertenece el formulario se conoce como postback .

Según RFC 7231, el método POST no es idempotente , lo que significa que múltiples solicitudes idénticas podrían no tener el mismo efecto que transmitir la solicitud solo una vez. Por lo tanto, POST es adecuado para solicitudes que cambian el estado cada vez que se realizan, por ejemplo, enviar un comentario a una publicación de blog o votar en una encuesta en línea. GET se define como nulopotente , sin efectos secundarios, y las operaciones idempotentes "no tienen efectos secundarios en solicitudes segundas o futuras". ^{[10] [11]} Por esta razón, los rastreadores web como los indexadores de motores de búsqueda normalmente usan los métodos GET y HEAD exclusivamente, para evitar que sus solicitudes automatizadas realicen tales acciones.

Sin embargo, existen razones por las que se utiliza POST incluso para solicitudes idempotentes, en particular si la solicitud es muy larga. Debido a las restricciones en las URL, la cadena de consulta que genera el método GET puede llegar a ser muy larga, especialmente debido a la codificación porcentual . ^[10]

• Definición sencilla de POST
• Verbo POST en la especificación HTTP
• "Implementación de almacenamiento en Google Cloud Platform", Guía de estudio de Google Cloud Certified Associate Cloud Engineer , Wiley, 28 de marzo de 2019, págs. 275-308, doi :10.1002/9781119564409.ch12, ISBN 9781119564409, Número de identificación del sujeto  241576882