2010-11-18 22 views
2

Pour toutes les réponses redirigées IBM Websphere ajoute automatiquement en-tête comme ci-dessous:Comment éviter le blocage des cookies d'en-tête IBM websphere ajoutant automatiquement

Cache-control: no-cache="set-cookie, set-cookie2" 

Cet en-tête affecte les navigateurs IE et ne se les cookies au large. L'en-tête est ajouté pour les réponses de redirection (code 302) sans aucun contenu. Ce comportement bloque le travail de session normal de l'application. Encore une fois, cette en-tête a un effet sur IE seulement, tous les autres navigateurs semblent l'ignorer et continuer à traiter les cookies.

Répondre

2

Le champ d'en-tête général Cache-Control est utilisé pour spécifier les directives qui DOIVENT être respectées par tous les mécanismes de mise en cache le long de la chaîne de requête/réponse. Les directives spécifient un comportement destiné à empêcher les caches d'interférer de manière négative avec la demande ou la réponse. Ces directives remplacent généralement les algorithmes de mise en cache par défaut. Les directives de cache sont unidirectionnelles dans la mesure où la présence d'une directive dans une requête n'implique pas que la même directive doit être donnée dans la réponse.

Si la directive no-cache spécifie un ou plusieurs noms de champs, un cache PEUT utiliser la réponse pour satisfaire une demande ultérieure, sous réserve de toute autre restriction de mise en cache. Cependant, les noms de champs spécifiés NE DOIVENT PAS être envoyés dans la réponse à une demande subséquente sans une revalidation réussie avec le serveur d'origine. Cela permet à un serveur d'origine d'empêcher la réutilisation de certains champs d'en-tête dans une réponse, tout en permettant la mise en cache du reste de la réponse.

(S'il vous plaît voir rfc2616 à 14.9 et 14.9.1)

Qu'est-ce no-cache = "set cookie, set-cookie2" fait est qu'il dit chaque serveur proxy en amont de ne pas mettre en cache et peut-être envoyer de nouveau les cookies (c'est-à-dire les cookies liés à l'authentification) par erreur à des clients autres que ceux prévus. Vous essayez probablement de (reverse) proxy quelque chose à partir d'un serveur d'applications, et ne voient pas les cookies dans le navigateur, car votre configuration force ou permet au serveur frontal de mettre en cache et de ré-servir le contenu lui-même. Les navigateurs et les procurations déposent le cookie à la demande en faisant cela.

Ce qui devrait être fait est que le serveur d'application devrait répondre avec la directive de plain-no-cache sans n'importe quels en-têtes définis. Ce serait clair parce que, dans un sens, la ressource qui donne 302 est destinée à être privée.

Malheureusement, IBM WebSphere est une grande famille de produits et la réalisation de ces configurations dépend du produit. Si cet en-tête provient de l'intérieur d'un produit IBM, vous devriez probablement ouvrir un PMR. Vous pouvez également écrire un Server Filter pour manipuler les en-têtes à l'extérieur. Si c'est votre application qui est en question, supprimez simplement l'impression des en-têtes (set-cookie et set-cookie2) de votre code mais laissez la partie no-cache.