¿Hay alguna diferencia entre los parámetros en una URL y <form method = "get">?

Question

Ahora, sé una diferencia entre los parámetros en una URL y un parámetro POST: algunos navegadores pueden portarse mal si la URL es demasiado larga, por lo que no es una buena idea rellenar cientos de parámetros en una URL, incluso si tu aplicación puede responder a una solicitud GET

Por el bien de la discusión, supongamos la siguiente aplicación web: un usuario puede ingresar una serie de (posiblemente cientos de) coordenadas X, Y. El servidor los traza en un gráfico, que se devuelve como una imagen.

Esto es claramente un ejemplo de idempotent operation, por lo que, de acuerdo con HTTP spec, se recomienda implementar como una operación GET. Sin embargo, no puede compilar una URL con todos los parámetros, ya que será demasiado larga. ¿Puede un < forma método = "obtener" > manejar tantos parámetros?

También he oído que < form method = "get" > es completamente equivalente a colocar parámetros en una URL? Ahora, ¿eso es cierto para algunos navegadores o para todo el protocolo HTTP? ¿Hay una longitud máxima para una solicitud?

Answer 1

La especificación HTTP no establece limitaciones, pero los navegadores y los servidores sí. Ver here para detalles.

El navegador creará una URL larga si el método está configurado para OBTENER un formulario, por lo que se aplican las limitaciones anteriores.

Answer 2

Lo que su navegador realmente hace es crear una url realmente larga desde las entradas del formulario. Por lo tanto, no habrá diferencia entre una URL y forma Method = "GET". Cualquiera de los dos dará lugar a que se cargue la misma URL.

Answer 3

También he oído que < form method = "get" > es completamente equivalente a colocar parámetros en una URL?

eso es cierto, aquí es el correspondiente RFC section

¿Hay una longitud máxima de una solicitud?

El spec dice "El protocolo HTTP no pone ningún límite a priori en la longitud de un URI".

Sin embargo Internet Explorer 6 tiene un límite de 2.083 caracteres. Otros navegadores permiten más caracteres, pero si va por esa ruta, básicamente tendrá que diseñar para ie6

Answer 4

form method = get VOLVERÁ a poner toda la entrada del formulario en la URL.

Es cierto que los navegadores tienen una longitud máxima para la URL. Cambia de navegadores a navegadores, y seguramente de la versión de navegadores a la versión de navegadores.

Si puede, le recomendaría usar POST para su formulario.

HTH

Answer 5

GET y url? Nombre = valor & ... son la misma cosa, como el navegador más que convierte una forma GET a una URL antes de enviar la solicitud.

La longitud máxima de la URL se determina en el navegador y el nivel del servidor, por lo que, para un navegador/servidor determinado, es la menor de las dos.

This post tiene una buena lista de longitudes máx actuales para las direcciones URL

Answer 6

Ésta no es una respuesta a su pregunta sobre GET y POST, pero en una situación como la que describes en muchas ocasiones es más fácil de almacenar el más complejo datos en el servidor y asociarlo con un ID de sesión o una cuenta de usuario en lugar de ponerlo en la URL cada vez. Luego puede usar solo el identificador de esa sesión en una cookie o como un parámetro url para recuperar la imagen.

Eso también puede ayudarlo a almacenar en caché las imágenes solicitadas para que no tenga que realizar el trabajo de regenerarlas cada vez que un usuario desee volver a mirar un gráfico en particular.

Answer 7

No, un servidor no puede ver la diferencia entre poner parámetros en una URL y usar un FORMULARIO con un método GET. Entonces, si una URL dada con parámetros sería demasiado larga, usar un FORMULARIO con un método GET no ayudará.

POST o GET debe elegirse principalmente por su semántica. GET es para acciones "seguras". Es decir, los usuarios no deben responsabilizarse de una operación realizada por una solicitud GET. El método POST se usa para operaciones de las que el usuario es responsable.

Es muy frustrante, por ejemplo, cuando una función de búsqueda usa POST. Un usuario no espera que una consulta simple altere ningún estado importante del sistema — que esperan que sea una operación "segura".

Por otro lado, existen muchas vulnerabilidades porque las operaciones inseguras son accesibles a través de solicitudes GET, así como de POST. Esto contribuye a vulnerabilidades como XSRF donde un atacante simplemente necesita obtener una URL maliciosa "src" en una etiqueta IMG en un sitio legítimo.

Para su caso de uso, Ajax puede ser una solución adecuada. Puede hacer una solicitud GET para cada punto seleccionado, almacenarlos en una sesión en el servidor. Cuando el usuario termina de ingresar puntos, una solicitud GET final recupera el producto final.

Answer 8

El HTTP specification no requiere explícitamente colocar parámetros de una solicitud GET en el URI. Sería legal enviar un cuerpo de mensaje en una solicitud GET como formularios usando POST do.

Sin embargo, los navegadores implementan formularios GET de esta manera por una muy buena razón: Almacenamiento en caché. Se espera que las solicitudes GET se procesen en el servidor sin efectos secundarios. Por lo tanto, las respuestas a las solicitudes GET pueden almacenarse en caché. Esta opción de mejora del rendimiento se pierde instantáneamente si comienza a usar cuerpos de mensaje en las solicitudes GET.

Si va a diseñar un API de gráfico, es posible que desee echar un vistazo a Google. Ya ofrecen una muy buena para el público. Incluso si solo es para aprender cómo empacar la mayor cantidad posible de información en parametros de URI, vale la pena verla.