Obtener VS. CORREO
- 3487
- 292
- María Elena Elizondo
Http CORREO Las solicitudes suministran datos adicionales del cliente (navegador) al servidor en el cuerpo del mensaje. A diferencia de, CONSEGUIR Las solicitudes incluyen todos los datos requeridos en la URL. Los formularios en HTML pueden usar cualquier método especificando Método = "Post" o método = "Get" (predeterminado) en el elemento. El método especificado determina cómo se envían los datos de formulario al servidor. Cuando se obtiene el método, todos los datos de formulario están codificados en la URL, adjunto al acción URL como parámetros de cadena de consulta. Con Post, los datos de formulario aparecen dentro del cuerpo de mensajes de la solicitud HTTP.
Cuadro comparativo
| CONSEGUIR | CORREO | |
|---|---|---|
|
| |
| Historia | Los parámetros permanecen en la historia del navegador porque son parte de la URL | Los parámetros no se guardan en la historia del navegador. |
| Marcado | Puede ser marcado. | No se puede marcar marcado. |
| Comportamiento del botón de retroceso/volver a sumisión | Las solicitudes GET se re-ejecutan, pero no se pueden volver a sumar al servidor si el HTML se almacena en el caché del navegador. | El navegador generalmente alerta al usuario de que los datos deberán volver a ser enviados. |
| Tipo de codificación (atributo de cifrado) | aplicación/x-www-form-urlencoded | multipart/formy-data o aplicación/x-www-form-urlencoded use la codificación multipart para datos binarios. |
| Parámetros | puede enviar pero los datos de los parámetros se limitan a lo que podemos meter en la línea de solicitud (URL). Más seguro para usar menos de 2k de parámetros, algunos servidores manejan hasta 64k | Puede enviar parámetros, incluida la carga de archivos, al servidor. |
| Pirateado | Más fácil de hackear para guiones para niños | Más difícil de hackear |
| Restricciones en el tipo de datos de formulario | Sí, solo los caracteres ASCII permitidos. | Sin restricciones. También se permiten datos binarios. |
| Seguridad | Get es menos seguro en comparación con la publicación porque los datos enviados son parte de la URL. Por lo tanto, se guarda en el historial del navegador y los registros del servidor en texto sin formato. | La publicación es un poco más segura que obtener porque los parámetros no se almacenan en el historial del navegador o en los registros de servidor web. |
| Restricciones en la longitud de los datos de formulario | Sí, dado que los datos de formulario están en la URL y la longitud de la URL está restringida. Un límite de longitud de URL seguro a menudo es de 2048 caracteres, pero varía según el navegador y el servidor web. | Sin restricciones |
| Usabilidad | El método GET no debe usarse al enviar contraseñas u otra información confidencial. | Método de publicación utilizado al enviar contraseñas u otra información confidencial. |
| Visibilidad | El método Get es visible para todos (se mostrará en la barra de direcciones del navegador) y tiene límites en la cantidad de información para enviar. | Las variables del método de publicación no se muestran en la URL. |
| En caché | Se puede almacenar en caché | No almacenado en caché |
Diferencias en la presentación de formulario
La diferencia fundamental entre Método = "Get" y Método = "Post" es que corresponden a diferentes solicitudes HTTP, como se define en las especificaciones HTTP. El proceso de envío para ambos métodos comienza de la misma manera: el navegador construye un conjunto de datos de formulario y luego está codificado de una manera especificada por el cisquero atributo. Para Método = "Publicar el cisquero El atributo puede ser Data multipart/formulario o aplicación/x-www-form-urlencoded, mientras que para Método = "Get", solo aplicación/x-www-form-urlencoded esta permitido. Este conjunto de datos de formulario se transmite luego al servidor.
Para el envío del formulario con método = "Get", el navegador construye una URL tomando el valor de la acción atributo, agregar un ? A él, luego, agregue el conjunto de datos del formulario (codificado usando el tipo de contenido Aplicación/X-WWW-Form-URLEncoded). El navegador luego procesa esta URL como si siguiera un enlace (o como si el usuario hubiera escrito la URL directamente). El navegador divide la URL en partes y reconoce a un host, luego envía a ese host una solicitud con el resto de la URL como argumento. El servidor lo toma desde allí. Tenga en cuenta que este proceso significa que los datos del formulario están restringidos a los códigos ASCII. Se debe tener especial cuidado para codificar y decodificar otros tipos de caracteres al pasarlos a través de la URL en formato ASCII.
Envío de un formulario con método = "post" hace que se envíe una solicitud de publicación, utilizando el valor del acción atributo y un mensaje creado de acuerdo con el tipo de contenido especificado por el cisquero atributo.
Pros y contras
Dado que los datos del formulario se envían como parte de la URL cuando CONSEGUIR se usa --
- Los datos de formulario están restringidos a los códigos ASCII. Se debe tener especial cuidado para codificar y decodificar otros tipos de caracteres al pasarlos a través de la URL en formato ASCII. Por otro lado, se pueden enviar datos binarios, imágenes y otros archivos a través de Método = "Post"
- Todos los datos de formulario completados son visibles en la URL. Además, también se almacena en el historial/registros de navegación web del usuario para el navegador. Estos problemas hacen CONSEGUIR menos seguro.
- Sin embargo, una ventaja de los datos de formulario que se envían como parte de la URL es que uno puede marcar las URL y usarlos directamente y evitar completamente el proceso de repleto de formularios.
- Existe una limitación sobre cuánto formulario se pueden enviar datos porque las longitudes de URL son limitadas.
- Script Kiddies puede exponer más fácilmente las vulnerabilidades en el sistema para piratearlo. Por ejemplo, Citibank fue pirateado cambiando los números de cuenta en la cadena de URL.[1] Por supuesto, los piratas informáticos o desarrolladores web experimentados pueden exponer tales vulnerabilidades incluso si se usa la publicación; es un poco más difícil. En general, el servidor debe sospechar de los datos enviados por el cliente y proteger contra las referencias de objetos directos inseguros.
Diferencias en el procesamiento del lado del servidor
En principio, el procesamiento de los datos de formulario enviados depende de si se envía con Método = "Get" o Método = "Post". Dado que los datos están codificados de diferentes maneras, se necesitan diferentes mecanismos de decodificación. Por lo tanto, en términos generales, cambiar el método puede requerir un cambio en el script que procesa la sumisión. Por ejemplo, cuando se usa la interfaz CGI, el script recibe los datos en una variable de entorno (QueryString) cuando CONSEGUIR se usa. Pero cuando CORREO se usa, los datos de formulario se pasan en la secuencia de entrada estándar (stdin) y el número de bytes a leer viene dado por el encabezado de longitud de contenido.
¿Qué sucede cuando obtenga un conflicto de variables??
En algunos idiomas, como PHP, la información de los parámetros GET y POST, además de estar disponibles por separado, también se combina en una variable de conveniencia E.gramo., $ _ Request en PHP. Si hay un conflicto-i.mi., El mismo nombre de parámetro se usa con diferentes valores en Get y Post-Th-Then, el conflicto se resuelve con ciertas reglas. En el caso de PHP, la precedencia es decidida por el variables_order directiva de configuración. El pedido predeterminado es EGPCS (entorno, get, post, cookie, servidor). Esto significa que la variable en $ _get tiene precedencia más de $ _post, lo que a su vez tiene precedencia más de $ _cookie.
Uso recomendado
Get se recomienda al enviar formularios "ideMpotent", aquellos que no "alteran significativamente el estado del mundo". En otras palabras, formularios que involucran consultas de bases de datos solamente. Otra perspectiva es que varias consultas idempotentes tendrán el mismo efecto que una sola consulta. Si las actualizaciones de la base de datos u otras acciones, como activar correos electrónicos.
Del blog de desarrollador de Dropbox:
Un navegador no sabe exactamente qué hace un formulario HTML en particular, pero si el formulario se envía a través de HTTP Get, el navegador sabe que es seguro volver a intentar automáticamente el envío si hay un error de red. Para los formularios que usan la publicación HTTP, es posible que no sea seguro volver a intentarlo, por lo que el navegador solicita al usuario la confirmación primero.
Una solicitud de "obtener" a menudo es almacenable, mientras que una solicitud de "publicación" difícilmente puede ser. Para los sistemas de consulta, esto puede tener un impacto de eficiencia considerable, especialmente si las cadenas de consulta son simples, ya que los cachés pueden servir a las consultas más frecuentes.
En ciertos casos, usando CORREO se recomienda incluso para consultas ideMpotent:
- Si los datos del formulario contengan caracteres no ASCII (como personajes acentuados), entonces Método = "Get" No es aplicable en principio, aunque puede funcionar en la práctica (principalmente para los caracteres ISO Latin 1).
- Si el conjunto de datos del formulario es grande - Digamos, cientos de personajes, entonces Método = "Get" puede causar problemas prácticos con implementaciones que no pueden manejar esas URL largas.
- Es posible que desee evitar Método = "Get" Para que sea menos visible para los usuarios cómo funciona el formulario, especialmente para hacer campos "ocultos" (entrada tipo = "oculto") más oculto al no aparecer en la URL. Pero incluso si usas campos ocultos con Método = "Post", Todavía aparecerán en el código fuente HTML.
¿Qué pasa con los https??
Actualizado el 15 de mayo de 2015: específicamente cuando se usa HTTPS (HTTP sobre TLS/SSL), publica la oferta más seguridad que obtener?
Esta es una pregunta interesante. Digamos que realiza una solicitud GET a una página web:
Obtener https: // www.ejemplo.com/inicio de sesión.php?usuario = Mickey & Passwd = Mini
Suponiendo que su conexión a Internet se está monitoreando, qué información sobre esta solicitud estará disponible para el Swooper? Si se usa Post, y los datos del usuario y PASSWD se incluyen en las variables POST, será más seguro en el caso de las conexiones HTTPS?
La respuesta es no. Si realiza una solicitud TE GET, solo la siguiente información será conocida por el atacante que monitorea su tráfico web:
- El hecho de que hiciste una conexión HTTPS
- El nombre de host - www.ejemplo.comunicarse
- La longitud total de la solicitud
- La longitud de la respuesta
La parte del camino de la url - yo.mi., La página real solicitada, así como los parámetros de cadena de consulta, están protegidos (encriptados) mientras están "sobre el cable" I.mi., en tránsito en su camino al servidor de destino. La situación es exactamente la misma para las solicitudes de publicación.
El CORREO El método aún conserva una ventaja incluso en el caso de HTTPS, sin embargo,. Los servidores web tienden a registrar toda la URL solicitada en texto sin formato en sus registros de acceso; Entonces, enviar información confidencial a través de obtener no es una buena idea. Esto se aplica independientemente de si se usa HTTP o HTTPS.