En una solicitud HTTP GET , los parámetros se envían como una cadena de consulta :
http://example.com/page ? parameter = value & also = another
En una solicitud HTTP POST , los parámetros no se envían junto con el URI.
¿Dónde están los valores? En el encabezado de la solicitud? En el cuerpo de la solicitud? Cómo se ve?
Respuestas:
Los valores se envían en el cuerpo de la solicitud, en el formato que especifica 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 usa el mismo formato que la cadena de consulta:
parameter=value&also=another
Cuando usa una carga de archivo en el formulario, usa la multipart/form-datacodificación, que tiene un formato diferente. Es más complicado, pero generalmente no es necesario que te importe cómo se ve, así que no mostraré un ejemplo, pero puede ser bueno saber que existe.
multipart/form-datao si está a cargo de la construcción de la solicitud, cambiar el tipo de contenido application/jsony pegar el texto json en el cuerpo http directamente
El contenido se coloca después de los encabezados HTTP. El formato de una POST HTTP es tener los encabezados HTTP, seguidos de una línea en blanco, seguida del 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
Puede ver esto usando una herramienta como Fiddler , que puede usar para ver la carga de solicitud y respuesta HTTP sin procesar que se envía a través del cable.
application/x-www-form-urlencoded, que no siempre es el caso.
Fromencabezado allí?
Fromencabezado. OMI está ahí arriba con el código de estado 418 HTTP.
Respuesta corta: en las 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-urlencodedo multipart/form-data. Los lenguajes de programación o marcos que han sido diseñados para manejar las peticiones web por lo general hacer "la cosa correcta ™" con tales peticiones y le proporcionará un acceso fácil a los valores decodificados fácilmente (como $_REQUESTo $_POSTen PHP, o cgi.FieldStorage(), flask.request.formen Python).
Ahora pasemos un poco, lo que puede ayudar a entender la diferencia;)
La diferencia entre GETy las POSTsolicitudes 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.
Al ejecutar una GETsolicitud, 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 de ?. Esto es parte de la sintaxis de URI .
Por lo tanto, desde el punto de vista del código de su aplicación (la parte que recibe la solicitud), deberá inspeccionar la parte de consulta URI para obtener acceso a estos valores.
Tenga en cuenta que las claves y los valores son parte del URI. Los navegadores pueden imponer un límite en la longitud de URI. El estándar HTTP establece que no hay límite. Pero en el momento de escribir estas líneas, la mayoría de los navegadores no limitan los URI (no tengo valores específicos). GETlas solicitudes nunca deben usarse para enviar nueva información al servidor. Especialmente no documentos más grandes. Ahí es donde debes usar POSTo PUT.
Al ejecutar una POSTsolicitud, el cliente está enviando un nuevo documento al host remoto. Por lo tanto, una cadena de consulta no tiene sentido (semánticamente). Es por eso que no tiene acceso a ellos en su código de aplicación.
POSTes un poco más complejo (y mucho más flexible):
Al recibir una solicitud POST, siempre debe esperar una "carga útil" o, en términos HTTP: un cuerpo de mensaje . El cuerpo del mensaje en sí mismo es bastante inútil, ya que no hay un formato estándar (por lo que puedo decir. ¿Tal vez aplicación / octeto-flujo?). El formato del cuerpo está definido por el Content-Typeencabezado. Cuando se usa un FORMelemento HTML con method="POST", esto suele ser application/x-www-form-urlencoded. Otro tipo muy común es multipart / form-data si usa cargas de archivos. Pero podría ser cualquier cosa , desde text/plain, más application/jsono incluso una costumbre application/octet-stream.
En cualquier caso, si se realiza una POSTsolicitud con una Content-Typeque no puede ser manejada por la aplicación, debe devolver un 415código de estado .
La mayoría de los lenguajes de programación (y / o marcos web) ofrecen una forma de descodificar / codificar el cuerpo del mensaje de / a los tipos más comunes (como application/x-www-form-urlencoded, multipart/form-datao application/json). Entonces eso es fácil. Los tipos personalizados requieren potencialmente un poco más de trabajo.
Usando un documento codificado estándar de formulario HTML como ejemplo, la aplicación debe realizar los siguientes pasos:
Content-Typecampo415código de estadoUna vez más, 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 415error. Ningún marco puede predecir qué tipos de contenido elige admitir y / o no admitir su aplicación. Esto depende de ti.
Una PUTsolicitud se maneja de la misma manera que una POSTsolicitud. La gran diferencia es que POSTse supone que una solicitud permite que el servidor decida cómo (y si es que lo hace) crear un nuevo recurso. Históricamente (a partir del ahora obsoleto RFC2616 fue crear un nuevo recurso como "subordinado" (hijo) del URI al que se envió la solicitud).
En PUTcambio, se supone que una solicitud "deposita" un recurso exactamente en ese URI y con exactamente ese contenido. Ni mas ni menos. La idea es que el cliente sea responsable de crear el recurso completo antes de "PONERLO". El servidor debe aceptar que tal y como está en la URL dada.
Como consecuencia, una POSTsolicitud generalmente no se usa para reemplazar un recurso existente. Una PUTsolicitud puede crear y reemplazar.
También hay " parámetros de ruta " que se pueden usar para enviar datos adicionales al control remoto, pero son tan poco comunes que no voy a entrar en demasiados detalles aquí. Pero, como referencia, aquí hay un extracto del RFC:
Además de los segmentos de puntos en las rutas jerárquicas, la sintaxis genérica considera que un segmento de ruta es opaco. Las aplicaciones que producen URI a menudo usan los caracteres reservados permitidos en un segmento para delimitar subcomponentes específicos del esquema o del controlador de referencia. Por ejemplo, los caracteres reservados con punto y coma (";") e igual ("=") a menudo se usan para delimitar parámetros y valores de parámetros aplicables a ese segmento. El carácter reservado con coma (",") se utiliza 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 pueden definirse por una semántica específica del esquema,
PUTsección, verás que es idempotente. POSTen contraste puede, por definición, no ser. POSTsiempre creará un nuevo recurso. PUTserá, si existe un recurso idéntico reemplazarlo. Entonces, si llamas POST10 veces, crearás 10 recursos. Si llama PUT10 veces, (quizás) creará solo una. Eso responde tu pregunta?
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 publicados.
Content-Lengthsupone que debe estar 29aquí? Esa es la longitud real de la cuerda username=zurfyx&pass=password.
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 claves pueden ser duplicadas. Cada par clave-valor está separado por un &carácter, y cada clave está separada de su valor por un =carácter.
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.
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, consulte las especificaciones .
?por ejemplo?
application/x-www-form-urlencoded, que no siempre es el caso.
Algunos de los servicios web requieren que coloque los datos y metadatos de la solicitud por separado. Por ejemplo, una función remota puede esperar que la cadena de metadatos firmada 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 utilizando un único Content-Typeque es una "instrucción de análisis" para un servidor web.
Tenga en cuenta: HTTP / 1.1 está envuelto con el #32(espacio) a la izquierda y con #10(Avance de línea) a la derecha.
/user/johny /?user=johnes meramente semántica (HTTP realmente no da un tratamiento especial a las cadenas de consulta), por lo que considero que esto es razonablemente esperado. Pero, ¿qué quieres decir con "envuelto por el espacio a la izquierda"? No hay espacios antes del método HTTP. ¿Te refieres a la línea en blanco para el cuerpo de la publicación?
...Ym04y HTTP/1.1en el código anterior. Entonces, un QueryString simplemente reside entre el verbo y la versión del protocolo.
?misma manera que lo hacemos con las GETsolicitudes.
En primer lugar, diferenciemos entre GETyPOST
Obtener: es la HTTPsolicitud predeterminada que se realiza al servidor y se utiliza para recuperar los datos del servidor y la cadena de consulta que viene después ?de a URIse utiliza para recuperar un recurso único.
este es el formato
GET /someweb.asp?data=value HTTP/1.0
Aquí data=valueestá el valor de cadena de consulta pasado.
POST: se utiliza para enviar datos al servidor de forma segura, por lo que cualquier cosa que se necesite, este es el formato de una POSTsolicitud
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é publicar en GET?
En GETel valor que se envía a los servidores generalmente se agrega a la URL base en la cadena de consulta, ahora hay 2 consecuencias de esto
GETsolicitudes se guardan en el historial del navegador con los parámetros. Por lo tanto, sus contraseñas permanecen sin cifrar en el historial del navegador. Este era un problema real para Facebook en aquellos días.URIpuede durar. Si se envían demasiados parámetros, es posible que reciba414 Error - URI too long En caso de una solicitud posterior, sus datos de los campos se agregan al cuerpo. La longitud de los parámetros de solicitud se calcula y se agrega al encabezado para la longitud del contenido y no se agregan datos importantes directamente a la URL.
Puede utilizar la sección de red de Herramientas para desarrolladores de Google para ver información básica sobre cómo se realizan las solicitudes a los servidores.
y siempre se puede añadir más valores en el Request Headerscomo Cache-Control, Origin, Accept.
HTTPSconexión, no HTTP. HTTPScifra tanto el URL(incluidos los parámetros de consulta) como el Request Body, cuando no HTTPcifra ni protege ninguno. El problema descrito proviene del hecho de que muchos navegadores almacenan el URIs(incluido URLs) en sus bases de datos de historial (generalmente no encriptado). Por lo tanto, use solo el Request Body+ HTTPSpara cualquier cosa sensible.
multipart/form-data. Sin embargo, para aquellos interesados, aquí hay una pregunta al respecto .