Usar GET o POST para un formulario de búsqueda

Question

Tengo un par de formularios de búsqueda, 1 con ~ 50 campos y el otro con ~ 100. Normalmente, como dice la especificación HTML, realizo búsquedas utilizando el método GET ya que no se modifican datos. Todavía no me he encontrado con este problema, pero me pregunto si pronto me quedaré sin espacio para URL.

El límite de Internet Explorer es de 2083 caracteres. Otros navegadores, tienen un much higher limit. Estoy ejecutando Apache, por lo que el límite es de alrededor de 4000 caracteres, que IIS tiene 16384 caracteres.

En 100 campos, digamos una longitud promedio de nombre de campo de 10 caracteres, eso ya son 5000 caracteres ... increíble en el formulario de campo 100, no he tenido ningún error todavía. (25% de los campos son seleccionados múltiples, por lo que la longitud del campo es mucho más larga.)

Entonces, me pregunto cuáles son mis opciones. (Acortar los formularios no es una opción.) Aquí mis ideas:

• Usar POST. No me gusta tanto porque, en este momento, los usuarios pueden marcar sus búsquedas y volver a realizarlas más tarde, una característica muy buena.
• Haga que JavaScript recorra el formulario para determinar qué campos son diferentes de los predeterminados, llene otro formulario y envíelo. El usuario, por supuesto, marcará la versión abreviada.

¿Alguna otra idea?

Además, ¿alguien sabe si la longitud es la longitud codificada o simplemente texto sin formato?

Estoy desarrollando en PHP, pero probablemente no haga la diferencia.

Editar: No puedo eliminar ningún campo; No puedo acortar el formulario. Esto es lo que el cliente ha pedido y a menudo usan una variedad de campos, en las diferentes categorías. Sé que es difícil pensar en una forma que se vea bien con tantos campos, pero los usuarios no tienen problemas para entender cómo funciona.

Answer 1

¿Sus usuarios usarán realmente todos los campos 50-100 para realizar sus búsquedas? Si solo usan unos pocos, ¿por qué no PUBLICAR la búsqueda en una página "intermedia", cuyo encabezado() - los redirige a la página de resultados solo con los campos modificados por el usuario en la URL? La página de resultados usaría los valores predeterminados para los campos que no existen en la URL.

Answer 2

Para abordar su pregunta de forma indirecta, si tuviera que rellenar un formulario de 100 campos en una sola página, lo más probable es que cerraré el navegador, suena como una completa usabilidad pesadilla.

Mi respuesta es, si existe el peligro de que esté llegando a un punto cercano a ese límite para normal uso del formulario, probablemente lo estoy haciendo mal.

En orden de preferencia, me

1. Dividir la forma y utilizar alguna retención estado del lado del servidor
2. Cambiar a POST, y luego generar y redirigir a una URL más corta en POST que se resolvió el mismo resultado
3. Abandona;)

Answer 3

Usted mencionó en un comentario que muchos de los campos "están ocultos y se puede abrir como sea necesario".

Si está dispuesto a descartar la degradación elegante, siempre podría agregar y eliminar los campos del formulario, en lugar de simplemente ocultarlos y mostrarlos: el navegador no enviará los que no están incluidos en el formulario .

Esta es una variante de los formularios "Marca y modelo" que utilizan las páginas de seguros en línea, etc. - seleccione la marca, envíe de vuelta al servidor y obtenga la lista de modelos para ese fabricante.

Answer 4

Si no le importa usar javascript, puede hacer que funcione la longitud de la cadena de consulta y si es demasiado larga, cambie a una publicación. Luego, tenga algún tipo de mapeador de url que les permita marcar estas búsquedas publicadas.

Answer 5

Utilice la publicación y si el usuario marca la búsqueda, guárdela en una base de datos y asígnele un token único, luego redirija a la página de búsqueda usando GET y pase el token como parámetro.

TinyURL es un buen ejemplo: le da una URL muy larga, la guarda en una base de datos, le da un identificador único para esa URL y luego puede solicitar la URL larga usando ese identificador.

En PHP sería algo a lo largo de las líneas de:

<?php 
if (isset($_GET['token'])) 
{ 
    $token = addslashes($_GET['token']); 
    $qry = mysql_query("SELECT fields FROM searches WHERE token = '{$token}'"); 
    if ($row = mysql_fetch_assoc($qry)) 
    { 
     performSearch(unserialize($row['fields'])); 
     exit; 
    } 
    showError('Your saved search has been removed because it hasn\'t been used in a while'); 
    exit; 
} 
$fields = addslashes(serialize($_POST)); 
$token = sha1($_SERVER['REMOTE_ADDR'].rand()); 
mysql_query("INSERT INTO searches (token, fields, save_time) Values ('{$token}', '{$fields}', NOW())"); 
header('Location: ?token='.$token); 
exit; 
?> 

y ejecutar un script diaria:

<?php 
mysql_query('DELETE FROM searches WHERE save_time < DATE_ADD(NOW(), INTERVAL -200 DAY)'); 
?> 

Answer 6

Además, ¿alguien sabe si la longitud es la longitud codificada ¿o simplemente texto plano?

Supongo que fue para la longitud codificada. Hice una prueba simple: un área de texto y un botón de enviar a un script PHP simplista.
Cargó la página en IE6, pegó texto en francés en el área de texto, 2000 caracteres. Si presiono el botón de enviar, nada. Tuve que reducir la longitud del texto para poder enviarlo.

En otras palabras, el límite de 2083 caracteres es exactamente la longitud máxima de la URL encontrada en la barra de direcciones después de enviar la solicitud GET.

Me gustaría ir por la solución de JavaScript: al enviar, analizar el formulario, crear un formulario secundario con hidden atributos, y enviar eso.

Algunas estrategias sobre el acortamiento de la salida:

• Como usted señala, ya se puede omitir todos los valores dejados por defecto (sin campo, sin valor).
• Si tiene un formulario como el de Processing forum search, puede agrupar todos los estados de casilla de verificación en una sola variable, por ejemplo. usando la codificación de letras.
• Utilice atributos cortos value (en select por ejemplo).

Nota: si la página de búsqueda en realidad está compuesta de varios formularios independientes, donde los usuarios llenan solo una sección u otra, puede hacer varias formas por separado.
Podría no aplicarse a su caso y podría parecer obvio, pero vale la pena mencionarlo para el registro ...^_^

Answer 7

Uno podría mirar filosóficamente la POST de envío de búsqueda como la creación de una búsqueda guardada (especialmente cuando se busca un objeto tan complejo como el que están haciendo sus usuarios). En este caso, podría aceptar la publicación para la creación de una búsqueda y luego redirigir usando un GET para buscar los resultados de búsqueda apropiados (publicar/redireccionar/obtener).

Esto también les permitiría a los usuarios marcar los resultados de búsqueda (GET) para regresar en cualquier momento para volver a ejecutar la búsqueda.

Answer 8

Get puede tener una ventaja si los resultados de la búsqueda pueden ser compartidos, en caso de solicitud POST si envía el enlace a alguien, esa persona no va a ver los resultados de cualquier búsqueda