Alternativa a la cadena de consulta y cookies cuando el envío de datos al servidor?

Question

Tengo una pequeña (o quizás no tan pequeño) problema con algunos ASP.NET/Castle de Monorraíl de sitios para un producto con el que trabajar.Esto es bastante antiguo sistema (escrito mucho antes de mi tiempo), y utiliza las peticiones GET con una cantidad considerable de información en la cadena de consulta.Recientemente hemos ejecutar en la cadena de consulta de las limitaciones de longitud, y por la cantidad de datos que necesitamos para que el servidor de transferencia, almacenar los datos temporalmente en una cookie no es también plausible (estamos ya bien pasado el 4096 bytes límite por galleta, y nos hemos puesto un montón de galletas, así que estamos cerca de o en el límite de las cookies en cada dominio, así.)

Me pregunto si hay alguna de las alternativas, además de PUBLICAR (en algunos casos, el cambio a una solicitud POST puede ser posible, pero es probable que no en todos), que podría resolver este problema.Estoy esperando que alguien más aquí en StackOverflow ha tenido problemas similares, y tiene algo de mágica solución (es decir,comprimir los datos con javascript, codificar en base64, pasar a una sola cadena de consulta elemento?Pero no estoy seguro si hay alguna de las bibliotecas que puede comprimir los datos con javascript en un modo compatible con la compresión incorporada clases .NET 3.5.)

ACTUALIZACIÓN:

Solución que se me acabó eligiendo era POST a un temporal controlador.Este controlador temporal tiró de la gran lista de datos, atrapado en una Sesión compartida (los servidores de producción se encuentran en un gran multi-banco de la granja de servidores que no hace uso de sticky sessions/IPs), y realizar un GET para el controlador, el que sacó los datos de la Sesión compartida.No la más eficiente solución, pero no solucionó el problema.

Answer 1

Hay varias href="http://plugins2.jquery.com/search/node/base64+type%3Aproject_project" para jQuery , pero que no ayuda porque base 64 hace que en general los datos ya , no más corto.

En función de los datos, me vería en algunas otras técnicas de compresión de texto. Wikipedia se describen algunos :

• Contexto método del árbol de ponderación (CTW)
• Burrows-Wheeler transformar (bloque de procesamiento previo de clasificación que hace la compresión más eficiente)
• LZ77 (utilizado por DEFLATE)
• LZW

He aquí un href="http://www.marklomas.net/ch-egg/articles/lzwjs.htm" rel="nofollow noreferrer"> aplicación .

codificación Huffman se basa en la frecuencia de la carta, por lo que podría no ser apropiada para tu información. Es probable que tenga que escapar el resultado para que sea el URL de fallos.

Answer 2

Más allá de conmutación para publicar sus opciones van a ser limitada. Base 64 va a aumentar el tamaño de los datos no disminuirlo. Usted menciona la compresión de los datos en un solo artículo cadena de consulta ... tal vez se podría dividir los datos en 2 solicitudes separadas utilizando Ajax? No estoy seguro de si eso es viable para su situación, sin embargo.

Answer 3

Yo sugeriría el uso de JSON como la transferencia de datos de formato si una matriz como la de la cadena de consulta se genera de la siguiente manera:

params[]=sth&params[]=sth2&params[]=sth3

Esto sería

{params:['sth1', 'sth2', 'sth3']}

Usted puede sssign esta cadena JSON a una sola carta de la variable, como el de abajo

p={params:['sth1', 'sth2', 'sth3']}

Algo aún mejor sería que la compresión y la codificación Base64 toda la cadena de consulta.Desde generar la cadena de consulta en el lado del servidor(supongo que esto, pero lo mismo puede ser hecho en JS mediante el uso de la misma comp/decomp algoritmos) puede utilizar cualquier builtin algoritmo de compresión con su lenguaje de programación como gzip.Después de la codificación Base64 los datos comprimidos, sí que se expanda un poco, pero no tanto como la codificación url expande.

Answer 4

No me confíe demasiado en Javascript. La compactación de la cadena de consulta sería la primera lo más natural; pero si usted está muy por delante de esos límites, usted debe tratar mentaining sesiones. Que inicie fresca con información de estado por defecto, y luego poco a poco reflejan el estado del servidor en la sesión del usuario con los datos puesto previsto, por lo que la partición de todos esos datos en muchos manipuladores (leer páginas).

Answer 5

La respuesta de libros de texto es utilizar POST. ¿Por qué esto no puede ser posible? La razón por la POST se inventó era más o menos de moverse en los límites de longitud GET.

Otra posibilidad dependiendo de los detalles es tener múltiples pantallas, cada una con un subconjunto de los datos, y almacenar los datos de cada uno en el servidor y conectarlos al final.

Answer 6

¿Es la limitación cadena de consulta en el cliente o el servidor?

Si el problema es que el cliente no enviará la cadena GET larga, tal vez usted puede enviar a un servidor proxy que a su vez reenvía la petición como un GET.

Answer 7

Es esto para mantener información de estado entre las páginas? Si es así, una opción podría ser el uso de una cookie con su valor un GUID como tal:

_SESSIONID=3F2504E0-4F89-11D3-9A0C-0305E82C3301

Y almacenar el lado del servidor la información de sesión. La sesión se identifica de forma única con un GUID, por lo que es entonces fácil de recuperar la gran cantidad de información directamente en el servidor.

Todo lo que se necesita para enviar / recuperar del lado del cliente es que id de sesión, así como la información generada por el cliente (campos GET / POST).