La diferencia entre ir, iniciar sesión, obtener y publicar

La respuesta más común

Lo pensé durante mucho tiempo después de regresar. ¿Qué quería preguntarme? Siempre he sentido que no hay diferencia entre GET y POST excepto por la semántica. Así lo entendí desde que comencé a aprender programación web.

Muchas personas pueden haber adivinado que la respuesta que quiere es:

GET usa URL o Cookie para pasar parámetros. Y POST pone los datos en BODY.

La URL de GET tendrá una longitud limitada y los datos de POST pueden ser muy grandes.

POST es más seguro que GET porque los datos no son visibles en la barra de direcciones.

Pero desafortunadamente, todas estas distinciones están equivocadas. Lo que es aún más desafortunado es que esta respuesta todavía está en la primera página de la búsqueda de Google. Sin embargo, ni siquiera pensé que estas fueran las respuestas, porque en. Mi opinión es que todos están equivocados. Déjame explicarlos uno por uno.

1. GET y POST no tienen nada que ver con cómo se transmiten los datos.

GET y POST están definidos por el protocolo HTTP. En el protocolo HTTP, el método y los datos (URL, cuerpo, encabezado) son dos conceptos ortogonales. Es decir, el método que se utiliza no tiene relación con la forma en que se transmiten los datos en la capa de aplicación.

HTTP no lo requiere. Si el Método son datos POST, se deben colocar en el BODY. No hay ningún requisito si el Método es GET, los datos (parámetros) deben colocarse en la URL y no en el BODY.

Entonces, ¿de dónde viene esta afirmación que tanto circula en Internet? Encontré una descripción similar en el estándar HTML. Esto concuerda con la declaración que circula en Internet. Pero esto es sólo una convención del estándar HTML para el uso del protocolo HTTP. ¿Cómo se puede considerar la diferencia entre GET y POST?

Además, los servidores web modernos admiten solicitudes como GET que contienen BODY. Aunque este tipo de solicitud no se puede realizar desde el navegador, el servidor web actual no solo es utilizado por el navegador, sino que ha excedido por completo el alcance del servidor HTML.

¿De qué sirve saber esto? No quiero explicar, a veces tienes que lastimarte una vez antes de recordar.

2. El protocolo HTTP no tiene restricciones de longitud en GET y POST.

El protocolo HTTP señala claramente que no hay requisitos de longitud para el encabezado y el cuerpo HTTP. Hay dos motivos para la restricción de la longitud de la URL:

Navegador. Se dice que los primeros navegadores limitarían la longitud de la URL. Se dice que IE limita la longitud de la URL a 2048 caracteres (tiene una amplia circulación e innumerables colegas están de acuerdo). Pero lo probé yo mismo, construí una URL de 90K para acceder a live.com a través de IE9 y fue normal. No confíes en nada en Internet, incluso si está en Wikipedia.

Servidor. Cuando la URL es larga, también supone una carga para el servidor procesarla. Originalmente, una sesión no tenía muchos datos. Ahora, si alguien construye maliciosamente varias URL de varios tamaños M y sigue accediendo a su servidor. Obviamente, el número máximo de concurrencias en el servidor disminuirá. Otro método de ataque es decirle al servidor que Content-Length es un número grande y luego solo enviar algunos datos al servidor. Oye, solo espera a que el servidor funcione. Incluso si tiene una configuración de tiempo de espera, este tipo de tiempo de espera de acceso deliberado puede hacer que el servidor se sienta miserable. En vista de esto, la mayoría de los servidores limitarán la longitud de la URL por razones de seguridad y estabilidad. Pero esta restricción es para todas las solicitudes HTTP y no tiene nada que ver con GET y POST.

La seguridad y la inseguridad no tienen nada que ver con GET y POST

Creo que esto es realmente una característica china. Déjenme contarles una breve historia y todos deberían poder entender lo ridícula que es esta afirmación.

Las personas que piensan que los datos POST son más seguros que los datos GET dirán

"Cuidado con los caballeros, no con los villanos; hay muchos novatos en China, así que protéjase contra los novatos". usuarios."

"Humph", no estuve de acuerdo, "Entonces, ¿por qué no dijiste que los parámetros de URL estaban codificados o en Base64? Incluso un novato no puede entenderlo.

”

El hombre replicó: “Codificar es demasiado simple. Un principiante inteligente puede decodificarlo y modificarlo fácilmente”. ”

Me reí y dije: “Se necesitan cincuenta pasos para hacer cien pasos más fáciles, no importa lo inteligente que seas, puedes interceptar el paquete y reenviarlo”. "

El hombre ofreció insidiosamente el artefacto, el derecho final de interpretación, y dijo: "Este no es un novato. ”

Dios mío.

Últimos pensamientos

Solía ​​hacer aplicaciones de escritorio para Windows y no sabía mucho sobre desarrollo web hasta hace más de un año. Después de cambiar al desarrollo del lado del servidor, comencé a entrar en contacto con HTTP (tenga en cuenta que estoy hablando de HTTP, no de HTML. La interfaz abierta del servidor está diseñada en base al concepto REST y el protocolo utilizado es HTTP, pero. el contenido transmitido no es HTML. Este no es el servidor web, sino un servicio web)

Así que mi comprensión de GET y POST se deriva puramente del protocolo HTTP. En pocas palabras, uno se usa para obtener datos y el otro se usa para modificar datos. Consulte el documento RFC para obtener más detalles.

Si una persona está haciendo desarrollo web desde el principio. Es probable que el uso de HTML para el protocolo HTTP sea el único uso razonable del protocolo HTTP. Por lo tanto, he cometido el error de generalizar.

Algunas personas pueden pensar que estoy hablando demasiado. No me gusta la ambigüedad, los límites poco claros, los conceptos poco claros y el “utilismo”. Me da vergüenza que otras personas a las que les gusta hablar de las cosas me ridiculicen.

“Saber es saber, no saber es”. sin saberlo. ”