Alternative à la chaîne de requête et aux cookies lors de l'envoi de données au serveur ?

Question

J'ai un petit (ou peut-être pas si petit) problème avec certains sites ASP.NET/Castle Monorail pour un produit sur lequel je travaille.Il s'agit d'un système assez ancien (écrit bien avant mon époque) et il utilise des requêtes GET avec une quantité considérable d'informations dans la chaîne de requête.Nous avons récemment rencontré des limitations de longueur de chaîne de requête, et pour la quantité de données que nous devons transférer au serveur, stocker temporairement les données dans un cookie n'est pas non plus plausible (nous avons déjà largement dépassé la limite de 4096 octets par cookie, et nous nous définissons beaucoup de cookies, nous sommes donc probablement proches ou à la limite des cookies par domaine également.)

Je me demande s'il existe des alternatives, outre POST (dans certains cas, le passage à une requête POST peut être possible, mais probablement pas dans tous), qui pourraient résoudre ce problème.J'espère que quelqu'un d'autre ici sur StackOverflow a rencontré des problèmes similaires et a une solution magique (c'est-à-direcompresser les données avec javascript, encoder en base64, transmettre à un seul élément de chaîne de requête ?Je ne sais pas s'il existe des bibliothèques capables de compresser les données avec javascript d'une manière compatible avec les classes de compression intégrées dans .NET 3.5.)

MISE À JOUR:

La solution que j'ai finalement choisie était de POST sur un contrôleur temporaire.Ce contrôleur temporaire a extrait la grande liste de données, l'a collée dans une session partagée (les serveurs de production se trouvent dans une grande batterie de serveurs multi-banques qui n'utilise pas de sessions/IP persistantes) et a effectué un GET sur le contrôleur réel, qui a extrait les données de la session partagée.Ce n'est pas la solution la plus performante, mais elle a résolu le problème.

Answer 1

Il y a plusieurs encodent base64 pour jQuery , mais ne contribue pas parce que Base64 généralement les données plus , pas plus courte.

Selon les données, je regarde d'autres techniques de compression de texte. Wikipédia énumère quelques-uns :

• Contexte Arbre Méthode de pondération (CTW)
• transformer Burrows-Wheeler (tri de blocs de pré-traitement qui rend la compression plus efficace)
• LZ77 (utilisé par DEFLATE)
• LZW

Voici un mise en œuvre LZW Javascript pour .

encodage Huffman est basé sur la fréquence de la lettre, il pourrait ne pas être approprié pour vos données. Vous aurez probablement échapper le résultat pour le rendre URL de sécurité.

Answer 2

Au-delà de passer à POST vos options vont être limitées. Base64 va augmenter la taille des données diminue pas. Vous parlez de compresser les données dans un seul élément de chaîne de requête ... peut-être au lieu que vous pouvez diviser les données en 2 demandes distinctes en utilisant Ajax? Je ne sais pas si cela est possible pour votre situation, cependant.

Answer 3

Je suggère d'utiliser JSON comme format de transfert de données si un tableau comme chaîne de requête est générée comme suit:

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

Ce serait

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

Vous pouvez sssign cette chaîne JSON à une seule variable de lettre comme ci-dessous

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

Quelque chose serait encore mieux la compression et Base64 toute la chaîne de requête. Puisque vous générez la chaîne de requête sur le côté serveur (je suppose que cela, mais même chose peut être fait dans JS en utilisant les mêmes algorithmes comp / de décomp) vous pouvez utiliser l'algorithme de compression intégré avec votre langage de programmation tel que gzip. Après base64 coder les données compressées, oui, il développe un peu, mais pas autant que le codage URL développe.

Answer 4

Je ne me fierais pas trop javascript. Compacter la chaîne de requête serait la première chose naturelle à faire; mais si vous êtes en avance ces limites, vous devriez essayer des séances mentaining. Vous démarrez frais avec des informations d'état par défaut, reflète progressivement l'état sur le serveur dans la session de l'utilisateur avec les données POST fournis, de sorte que vous partitionner toutes ces données dans de nombreux gestionnaires (lire pages).

Answer 5

La réponse du manuel est d'utiliser POST. Pourquoi serait-ce pas possible? La raison pour laquelle le poste a été inventé était à peu près pour contourner les limites de longueur GET.

Une autre possibilité en fonction des détails est d'avoir plusieurs écrans, chacun avec un sous-ensemble des données et stocker les données de chaque sur le serveur et les relier à la fin.

Answer 6

La limitation de la chaîne de requête est-elle sur le client ou sur le serveur ?

Si le problème est simplement que le client n'enverra pas la longue chaîne GET, vous pouvez peut-être POST sur un serveur proxy qui transmettra ensuite la demande en tant que GET.

Answer 7

Est-ce pour contenir des informations d'état entre les pages? Si oui, une option pourrait être d'utiliser un cookie avec sa valeur en tant que telle un GUID:

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

Et stocker le côté serveur des informations de session. La session est identifié de manière unique avec un GUID, il est alors facile de récupérer la grande quantité d'informations directement sur le serveur.

Il suffit alors d'envoyer / récupérer côté client est que l'identifiant de session, ainsi que le client a généré des informations (champs GET / POST).