HTTP define diferentes formas de interactuar con el servidor, y hay 4 métodos básicos: GET, POST, PUT y DELETE. El nombre completo de la URL es un descriptor de recursos, podemos pensar en él así: una dirección URL, se usa para describir un recurso en una red, y GET, POST, PUT, DELETE en HTTP corresponde a las cuatro operaciones de comprobar, modificar, añadir y eliminar este recurso. En este punto, deberías tener una comprensión general: GET se usa generalmente para obtener o consultar información de recursos, mientras que POST se usa generalmente para actualizar información de recursos.
1. Según la especificación HTTP, GET se utiliza para la recuperación de información y debe ser seguro e idempotente.
(1). La llamada seguridad significa que la operación se utiliza para obtener información en lugar de modificarla. En otras palabras, las solicitudes GET generalmente no deberían tener efectos secundarios. Es decir, solo obtiene información de recursos, igual que la consulta de bases de datos, y no modifica, ni añadirá datos, ni afectará al estado del recurso.
* Nota: El significado de seguridad aquí solo se refiere a información no modificada.
(2). idempotente significa que múltiples solicitudes a la misma URL deben devolver el mismo resultado.
Sin embargo, en la práctica, las dos regulaciones anteriores no son tan estrictas. Ejemplos de citar artículos de otras personas: Por ejemplo, la portada de un sitio de noticias se actualiza constantemente. Aunque la segunda solicitud devuelve un lote diferente de noticias, la operación sigue considerándose segura e idempotente porque siempre devuelve las noticias actuales. Fundamentalmente, si el objetivo es que cuando un usuario abra un enlace, pueda estar seguro de que el recurso no ha cambiado desde su punto de vista.
2. Según la especificación HTTP, POST representa una solicitud que puede modificar un recurso en el servidor. Siguiendo citando el ejemplo anterior: Noticias fijas Tomemos la web como ejemplo, los lectores deberían publicar sus propios comentarios sobre las noticias, porque los recursos del sitio son diferentes tras enviar el comentario o modificarlos.
Lo anterior analiza aproximadamente algunos de los principios de GET y POST en la especificación HTTP. Sin embargo, muchas personas no siguen la especificación HTTP cuando lo hacen realmente, lo que puede dar lugar a muchas razones para este problema, como:
1. Mucha gente usa GET para actualizar recursos porque necesita ir a FORM para usar POST, lo cual puede ser un poco problemático.
2. La operación de añadir, eliminar, modificar y comprobar recursos puede realizarse realmente mediante GET/POST, sin necesidad de usar PUT y DELETE.
3. Otra es que los primeros diseñadores de frameworks Web MVC no trataban ni diseñaban conscientemente las URLs como recursos abstractos, por lo que un problema serio es que el framework tradicional de Web MVC básicamente solo soporta dos métodos HTTP, GET y POST, pero no soporta métodos PUT y DELETE.
* Una breve explicación de MVC: MVC existía originalmente en el programa de escritorio, M se refiere al modelo de datos, V a la interfaz de usuario y C al controlador. El propósito de usar MVC es separar el código de implementación de M y V, para que el mismo programa pueda usar representaciones diferentes.
Los 3 puntos anteriores suelen describir el estilo antiguo (sin adherirse estrictamente a la especificación HTTP), y con el desarrollo de la arquitectura, ahora existe REST (Representational State Transfer), un nuevo estilo que soporta la especificación HTTP.
Después de hablar del problema principal, veamos la diferencia entre GET y POST respecto al fenómeno superficial:
1. Los datos de la petición GET se adjuntarán a la URL (es decir, los datos se colocan en la cabecera del protocolo HTTP), y a la ? Divide la URL y transmite los datos, y los parámetros se conectan por &, por ejemplo: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Si los datos son letras o números en inglés, envíalos tal cual; si es un espacio, conviértelos a +; si son caracteres chinos/otros, luego cifra directamente la cadena con BASE64 para obtener una muestra como: %E4%BD%A0%E5%A5%BD, donde XX en %XX es el ASCII representado por el símbolo en hexadecimal.
POST coloca los datos enviados en el cuerpo del paquete HTTP.
2. "El máximo de datos enviados por el método GET solo puede ser de 1024 bytes, teóricamente no hay límite para POST, y se puede transferir una gran cantidad de datos, hasta 80KB en IIS4 y 100KB en IIS5"??!
La frase anterior está redirigida de otros artículos, de hecho, es incorrecto e inexacto decir esto:
(1). En primer lugar, "los datos enviados por el método GET solo pueden tener como máximo 1024 bytes", porque GET envía datos a través de URL, por lo que la cantidad de datos que puede enviar GET está directamente relacionada con la longitud de la URL. De hecho, no existe un límite máximo de parámetros para las URLs, y la especificación del protocolo HTTP no limita la longitud de las URLs. Este límite es una limitación impuesta por un navegador y servidor específicos. El límite de longitud de URL de IE es de 2083 bytes (2K+35). Para otros navegadores como Netscape, Firefox, etc., no existe un límite teórico de longitud, y su límite depende del soporte del sistema operativo.
Ten en cuenta que esto limita toda la longitud de la URL, no solo la longitud de tus datos de valor de parámetro. [Véase Ref. 5]
(2). Teóricamente, POST no tiene límite de tamaño, y la especificación del protocolo HTTP no tiene límite de tamaño, y es inexacto decir que "hay un límite de tamaño de 80K/100K para los datos POST", y no hay límite para los datos POST, y es la potencia de procesamiento del manejador del servidor la que juega un papel limitante.
Para los programas ASP, el objeto Request tiene un límite de longitud de datos de 100K al procesar cada campo de formulario. Pero con Request.BinaryRead no hay tal limitación.
A partir de esto, para IIS 6.0, Microsoft ha aumentado las restricciones por razones de seguridad. También debemos prestar atención a:
1). IIS 6.0 por defecto tiene un máximo de 200 KB de datos ASP POST, y el límite es de 100 KB por campo de formulario.
2). El tamaño predeterminado de los archivos de subida de IIS 6.0 es de 4MB.
3). IIS 6.0 por defecto tiene una cabecera máxima de solicitud de 16KB.
Estas limitaciones no estaban disponibles antes de IIS 6.0. [Véase Ref. 5]
Así que los 80K y 100K anteriores pueden ser simplemente los valores por defecto (nota: aún no he confirmado los parámetros de IIS4 e IIS5), pero definitivamente puedes configurarlos tú mismo. Dado que los valores predeterminados de estos parámetros son diferentes en cada versión de IIS, consulte el documento de configuración correspondiente del IIS para más detalles.
3. En ASP, el servidor utiliza Request.QueryString para obtener el parámetro de solicitud GET y Request.Form para obtener el parámetro de solicitud POST. En JSP, usa request.getParameter(\"XXXX\") para obtenerlo, aunque también existe un método request.getQueryString() en jsp, pero es más complicado de usar, por ejemplo: envía un test.jsp?name=hyddd&password=hyddd, y usa request.getQueryString() para obtener :name= hyddd&password=hyddd。 En PHP, puedes usar $_GET y $_POST para obtener datos de GET y POST respectivamente, mientras que $_REQUEST puede obtener datos tanto de solicitudes GET como POST. Cabe destacar que existen peligros ocultos al usar peticiones en JSP y _REQUEST dólares en PHP, que se resumirán en un artículo la próxima vez.
4.POST es más seguro que GET. Nota: La seguridad mencionada aquí no es el mismo concepto que la "seguridad" mencionada en la GET anterior. Por ejemplo, si envías datos a través de GET, tu nombre de usuario y contraseña aparecerán en texto plano en la URL, porque (1) la página de inicio de sesión puede estar almacenada en caché por el navegador, (2) otros verán el historial del navegador, así que otros podrán obtener tu cuenta y contraseña Ataque de falsificación.
En resumen, Get es una petición para solicitar datos al servidor, mientras que Post es una petición para enviar datos al servidor, en FORM, Method por defecto es "GET"; en esencia, GET y POST son mecanismos de envío diferentes, ¡no uno toma y manda uno!
|
Publicado en 6/12/2014 10:54:55
|
|
|
Publicado en 7/12/2014 17:24:18
