Je travaille sur une page C # ASP.NET qui redirige normalement vers une URL "fichier:". Cela semble bien fonctionner la plupart du temps, dans la majorité des cas, mais occasionnellement (et, apparemment, toujours sur mon système de test), au lieu d'une redirection vers un fichier, une page contenant le texte "Objet déplacé vers ici" s'affiche. , où "ici" est un lien vers le fichier vers lequel j'essayais de rediriger, mais avec quatre barres obliques après les deux points au lieu de deux (par exemple, "fichier: ////testserver/docs/testdoc.doc")
Cela est normalement accompagné d'un message "System.Threading.ThreadAbortException: le thread a été abandonné".
J'ai cherché une solution ailleurs et découvert des informations intéressantes sur Response.Redirect, qui constituent des exceptions ThreadAbort, mais cela ne semble pas être le problème fondamental. Il me semble que le problème actuel est "l'objet déplacé vers ici". message, ce qui provoque la levée de l'exception.
Quelqu'un a des suggestions pour lesquelles je reçois ça ...?
MODIFIER: J'ai oublié de mentionner que j'utilise Firefox (3.5.7) avec IE Tab. J'allais donc mentionner que, lorsque j'ai pensé que je ferais mieux de l'essayer dans IE, et le tour est joué - cela fonctionne dans IE (7).
Juste pour référence future, une autre raison qui peut expliquer ce problème est que vous effectuez quelque chose comme Response.Redirect (null) ou similaire. J'ai eu une situation où ma variable contenant l'URL était nulle et c'est ce que j'ai obtenu.
Cela peut être causé par la mise de la méthode Response.Redirect()
dans le bloc try-catch
. La solution que j'ai trouvée consistait à mettre fin à la réponse virtuellement en envoyant un en-tête de redirection au client. regarde:
HttpResponse Response = HttpContext.Current.Response;
Response.StatusCode = 301;
Response.StatusDescription = "Moved Permanently";
Response.RedirectLocation = "YourRedirectionUrlHere.aspx";
Response.Flush();
Je viens de rencontrer un cas où cela se produit. Il s'avère que nous avons eu du code qui a effectivement fait:
if (condition)
{
Response.Redirect(page1);
}
Response.Redirect(page2);
De toute évidence, la personne qui a écrit cela (il y a bien longtemps, heureusement) n'a pas compris qu'un Response.Redirect ne met pas fin au fil par défaut.
Je n'ai aucune idée des conséquences de cette opération, mais une trace de violoniste semble indiquer une redirection corrompue. C’est peut-être une coïncidence bien sûr, mais c’est le seul endroit où nous avons été témoins de ce problème.
Une autre raison qui pourrait expliquer ce problème est que vous redirigez une page https vers une page http . Le fait de modifier l'URL de redirection en https: // a également résolu le problème.
Cela a fait le tour pour moi quand j'ai vu ce problème:
[Route("/something/{param}", "GET")]
public class MyRequestArg{
public string param{get;set;}
}
public class MyRequestService
{
public object Get(MyRequestArg request)
{
var url = "http://www.zombo.com";
var myCookieString = "anything is possible!";
var result = new HttpResult
{
StatusCode = HttpStatusCode.Redirect,
Headers = {
{HttpHeaders.Location, url},
{HttpHeaders.SetCookie, myCookieString}
}
};
return result;
}
}
Dans MVC, vous pourriez voir ceci après un RedirectToRoute ().
Si vous utilisez un outil tel que Fiddler, vous devriez voir un problème avec la réponse du serveur. J'ai remarqué une erreur 500.
Dans mon cas, cela était dû à l'ajout d'un objet àSessionqui étaitNOT Serializable.
Utiliser un élément d'ancrage avec runat=server
<a runat="server" ID="anchor1">anything can be here</a>
Dans le code derrière:
if (!ispostback)
anchor1.href="whateveryoulink";
Essaie.
Cela fonctionne mieux que la précédente méthode Status Code=301
.
J'ai résolu ce problème en définissant ma variable de chaîne globale sur static, car mon URL était réinitialisée sur vide lorsque je redirigeais.