Pregunta ¿Cómo se envían los parámetros en una solicitud HTTP POST?


En un HTTP OBTENER solicitud, los parámetros se envían como cadena de consulta:

http://example.com/page? parameter = value & also = another

En un HTTP ENVIAR solicitud, los parámetros no se envían junto con el URI.

¿Dónde están los valores? En el encabezado de solicitud? En el cuerpo de solicitud? Cómo se ve?


1165
2018-01-27 19:19


origen


Respuestas:


Los valores se envían en el cuerpo de la solicitud, en el formato especificado por el tipo de contenido.

Por lo general, el tipo de contenido es application/x-www-form-urlencoded, por lo que el cuerpo de la solicitud utiliza el mismo formato que la cadena de consulta:

parameter=value&also=another

Cuando utiliza una carga de archivo en el formulario, utiliza el multipart/form-data codificación en cambio, que tiene un formato diferente. Es más complicado, pero por lo general no es necesario que le importe lo que parece, así que no mostraré un ejemplo, pero puede ser bueno saber que existe.


962
2018-01-27 19:32



El contenido se coloca después de los encabezados HTTP. El formato de un HTTP POST es tener los encabezados HTTP, seguidos de una línea en blanco, seguidos por el cuerpo de la solicitud. Las variables POST se almacenan como pares clave-valor en el cuerpo.

Puede ver esto en el contenido sin formato de una Publicación HTTP, que se muestra a continuación:

POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

home=Cosby&favorite+flavor=flies

Puedes ver esto usando una herramienta como Violinista, que puede usar para ver las cargas de solicitud y respuesta HTTP sin procesar enviadas a través del cable.


349
2018-01-27 19:21



Respuesta corta: en solicitudes POST, los valores se envían en el "cuerpo" de la solicitud. Con los formularios web, lo más probable es que se envíen con un tipo de medio de application/x-www-form-urlencoded o multipart/form-data. Los lenguajes de programación o los marcos que se han diseñado para manejar solicitudes web generalmente hacen "Lo correcto" con tales solicitudes y le proporcionan un fácil acceso a los valores fácilmente decodificados (como $_REQUEST o $_POST en PHP, o cgi.FieldStorage(), flask.request.form en Python).


Ahora vamos a desviarnos un poco, lo que puede ayudar a entender la diferencia;)

La diferencia entre GET y POST las solicitudes son en gran medida semánticas. También se "usan" de manera diferente, lo que explica la diferencia en cómo se pasan los valores.

OBTENER (sección relevante de RFC)

Al ejecutar una GET solicitud, le pide al servidor una, o un conjunto de entidades. Para permitir que el cliente filtre el resultado, puede usar la llamada "cadena de consulta" de la URL. La cadena de consulta es la parte después del ?. Esto es parte del Sintaxis de URI.

Entonces, desde el punto de vista de su código de aplicación (la parte que recibe la solicitud), deberá inspeccionar la parte de la consulta de URI para obtener acceso a estos valores.

Tenga en cuenta que las claves y los valores son parte del URI. Navegadores mayo imponer un límite en la longitud del URI. El estándar HTTP establece que no hay límite. Pero en el momento de escribir esto, la mayoría de los navegadores hacer limite los URI (no tengo valores específicos). GET las solicitudes deben Nunca ser utilizado para enviar nueva información al servidor. Especialmente no documentos más grandes. Ahí es donde deberías usar POST o PUT.

POST (sección relevante de RFC)

Al ejecutar una POST solicitud, el cliente está enviando un nuevo documento al host remoto. Entonces, un consulta la cadena no tiene sentido (semánticamente). Por eso no tienes acceso a ellos en tu código de aplicación.

POST es un poco más complejo (y camino mas flexible):

Al recibir una solicitud POST, siempre debe esperar una "carga útil" o, en términos HTTP: a Cuerpo del mensaje. El cuerpo del mensaje en sí mismo es bastante inútil, ya que no hay estándar (por lo que puedo decir. ¿Tal vez application / octet-stream?) formato. El formato del cuerpo está definido por el Content-Type encabezamiento. Cuando usas un HTML FORM elemento con method="POST", esto es usualmente application/x-www-form-urlencoded. Otro tipo muy común es multipart / form-data si usas cargas de archivos Pero podría ser cualquier cosa, que van desde text/plain, encima application/json o incluso una costumbre application/octet-stream.

En cualquier caso, si POST la solicitud se realiza con un Content-Type que no puede ser manejado por la aplicación, debe devolver un 415 código de estado.

La mayoría de los lenguajes de programación (y / o web-frameworks) ofrecen una forma de des / codificar el cuerpo del mensaje desde / hasta los tipos más comunes (como application/x-www-form-urlencoded, multipart/form-data o application/json) Entonces eso es fácil. Los tipos personalizados requieren potencialmente un poco más de trabajo.

Usando un documento codificado con formato HTML estándar como ejemplo, la aplicación debe realizar los siguientes pasos:

  1. Leer el Content-Type campo
  2. Si el valor no es uno de los tipos de medios admitidos, devuelva una respuesta con un 415 código de estado
  3. de lo contrario, decodifique los valores del cuerpo del mensaje.

Nuevamente, los lenguajes como PHP o los marcos web para otros lenguajes populares probablemente lo manejarán por usted. La excepción a esto es el 415 error. Ningún marco puede predecir qué tipos de contenido su aplicación elige para admitir y / o no admitir. Esto depende de ti.

PONER (sección relevante de RFC)

UN PUT solicitud se maneja prácticamente de la misma manera que una POST solicitud. La gran diferencia es que POST Se supone que la solicitud permite que el servidor decida cómo (y si lo hace) crea un nuevo recurso. Históricamente (desde el ahora obsoleto RFC2616 fue crear un nuevo recurso como un "subordinado" (hijo) del URI al que se envió la solicitud).

UN PUT En cambio, se supone que la solicitud "deposita" un recurso exactamente a ese URI, y con exactamente ese contenido. Ni mas ni menos. La idea es que el cliente es responsable de crear el completar recurso antes de "PUTting". El servidor debería aceptarlo como es en la URL dada

Como consecuencia, una POST solicitud generalmente no se usa para reemplazar un recurso existente. UN PUT solicitud puede hacer ambos crear y reemplazar.

Nota al margen

También hay "parámetros de ruta"que se puede usar para enviar datos adicionales al control remoto, pero son tan poco comunes que no entraré en demasiados detalles aquí. Pero, como referencia, aquí hay un extracto del RFC:

Aparte de los segmentos de punto en las rutas jerárquicas, se considera un segmento de ruta   opaco por la sintaxis genérica. Las aplicaciones que producen URI a menudo usan   caracteres reservados permitidos en un segmento para delimitar esquema específico o   subcomponentes específicos del manejador de dereference. Por ejemplo, el punto y coma (";")   y equals ("=") los caracteres reservados a menudo se usan para delimitar parámetros y   valores de parámetros aplicables a ese segmento. La coma (",") reservada   el personaje se usa a menudo para fines similares. Por ejemplo, un productor de URI   podría usar un segmento como "nombre; v = 1.1" para indicar una referencia a la versión   1.1 de "nombre", mientras que otro podría usar un segmento como "nombre, 1.1" para   indicar lo mismo. Los tipos de parámetros se pueden definir por esquema específico   semántica, pero en la mayoría de los casos la sintaxis de un parámetro es específica del   implementación del algoritmo de desreferenciación de URI.


287
2017-11-03 15:54



No puede escribirlo directamente en la barra de URL del navegador.

Puede ver cómo se envían los datos POST en Internet con Live HTTP Headers por ejemplo. El resultado será algo así

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

En donde dice

Content-Length: 30
    username=zurfyx&pass=password

serán los valores de publicación.


48
2018-01-27 19:29



El tipo de medio predeterminado en una solicitud POST es application/x-www-form-urlencoded. Este es un formato para codificar pares clave-valor. Las llaves pueden ser duplicadas. Cada par clave-valor está separado por un & carácter, y cada clave está separada de su valor por un = personaje.

Por ejemplo:

Name: John Smith
Grade: 19

Está codificado como:

Name=John+Smith&Grade=19

Esto se coloca en el cuerpo de la solicitud después de los encabezados HTTP.


18
2018-06-16 05:33



Los valores de formulario en HTTP POST se envían en el cuerpo de la solicitud, en el mismo formato que la cadena de consulta.

Para más información, vea el especulación.


13
2018-01-27 19:20



Algunos de los servicios web requieren que realice una solicitud datos y metadata por separado. Por ejemplo, una función remota puede esperar que la cadena de metadatos firmados se incluya en un URI, mientras que los datos se publican en un cuerpo HTTP.

La solicitud POST puede verse semánticamente así:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

Este enfoque combina lógicamente QueryString y Body-Post usando un solo Content-Type que es una "instrucción de análisis" para un servidor web.

Tenga en cuenta: HTTP / 1.1 es envuelto con el #32 (espacio) a la izquierda y con #10 (Avance de línea) a la derecha.


13
2017-07-31 14:01



Antes que nada, diferenciemos GET y POST 

Obtener: Es el predeterminado HTTP solicitud que se realiza en el servidor y se utiliza para recuperar los datos del servidor y la cadena de consulta que viene después ? en un URI se usa para recuperar un recurso único.

este es el formato

GET /someweb.asp?data=value HTTP/1.0

aquí data=value es el valor de cadena de consulta pasado.

ENVIAR: Se usa para enviar datos al servidor de forma segura para que todo lo que se necesite, este es el formato de un POST solicitud

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

¿Por qué POST sobre GET?

En GET el valor que se envía a los servidores generalmente se anexa a la URL base en la cadena de consulta, esto hace que sus datos puedan ser pirateados (esto fue un problema en días para Facebook donde sus credenciales estuvieron expuestas) es por eso que POSTse usa para enviar datos al servidor que usó Request Body para enviar sus datos al servidor que es más seguro porque oculta sus datos además obtiene sus datos de los campos calcula la longitud de los mismos y los agrega a la header para content-length y no se anexan datos importantes directamente a la URL

ahora que su solicitud está segura, cualquier valor que se envíe al servidor se puede enviar en el Request Body como su nombre lo indica, contendrá los datos que el usuario quería enviar (y se envía en el URL Encoded formato) y el Request Headers mantendrá segura la Solicitud al comparar los valores en Request Body con el Request Headers

Puede usar la sección de red de Google Developer Tools para ver información básica sobre cómo se realizan las solicitudes a los servidores.

y siempre puedes agregar más valores en tu Request Headers me gusta Cache-Control , Origin , Accept.


0
2017-07-19 07:04