Vs Server.Transfer Response.Redirect

Question

Quelle est la différence entre Server.Transfer et Response.Redirect ?

• Quels sont les avantages et les inconvénients de chacun?
• Quand l'un est-il approprié par rapport à l'autre?
• Quand ne convient-on pas?

Answer 1

Response.Redirect envoie simplement un message (HTTP 302) . vers le navigateur.

Server.Transfer se produit sans que le navigateur sache rien, le navigateur demande une page, mais le serveur renvoie le contenu d'un autre.

Answer 2

Response.Redirect () vous renvoie à une nouvelle page, met à jour la barre d'adresse et l'ajoute à l'historique du navigateur. Sur votre navigateur, vous pouvez cliquer en arrière.

Server.Transfer () ne modifie pas la barre d'adresse. Vous ne pouvez pas riposter.

J'utilise Server.Transfer () lorsque je ne veux pas que l'utilisateur voie où je vais. Parfois, sur un " chargement " type de page.

Sinon, j'utiliserai toujours Response.Redirect () .

Answer 3

Pour être bref: Response.Redirect indique simplement au navigateur de visiter une autre page. Server.Transfer permet de réduire le nombre de requêtes du serveur, de conserver l'URL identique et, moyennant un petit bogue, de transférer la chaîne de requête et les variables de formulaire.

Quelque chose que j'ai trouvé et avec lequel je suis d'accord ( source ):

  

Server.Transfer est similaire en ce sens qu'il envoie l'utilisateur à une autre page.   avec une instruction telle que Server.Transfer ("WebForm2.aspx") . cependant,   la déclaration présente un certain nombre d'avantages et d'inconvénients.

     

Tout d'abord, transfert vers une autre page à l'aide de Server.Transfer   conserve les ressources du serveur. Au lieu de dire au navigateur de   redirige, cela change simplement le " focus " sur le serveur Web et   transfère la demande. Cela signifie que vous n'obtenez pas autant de HTTP   demandes qui arrivent, ce qui allège donc la pression sur votre   Serveur Web et accélère l’exécution de vos applications.

     

Mais attention, car le & transfert; transfert " processus peut travailler que sur ceux   sites en cours d'exécution sur le serveur; vous ne pouvez pas utiliser Server.Transfer pour envoyer   l'utilisateur sur un site externe. Seul Response.Redirect peut le faire.

     

Deuxièmement, Server.Transfer conserve l'URL d'origine dans le navigateur.   Cela peut vraiment aider à rationaliser les techniques de saisie de données, bien que cela puisse   créer de la confusion lors du débogage.

     

Ce n'est pas tout: la méthode Server.Transfer a également une seconde   paramètre & # 8212; "preserveForm". Si vous définissez ceci sur True , utilisez une instruction   tel que Server.Transfer (" WebForm2.aspx " ;, True) , la requête existante   chaîne et toutes les variables de formulaire seront toujours disponibles pour la page que vous   sont transférés vers.

     

Par exemple, si votre WebForm1.aspx a un contrôle TextBox appelé   TextBox1 et vous avez transféré à WebForm2.aspx avec le preserveForm   paramètre défini sur True, vous pourrez récupérer la valeur du   page d'origine contrôle TextBox par référencement    Request.Form ("TextBox1") .

Answer 4

Response.Redirect () doit être utilisé lorsque:

• nous voulons rediriger la demande vers des pages HTML simples sur notre serveur ou vers un autre serveur Web
• nous ne nous soucions pas de provoquer des allers-retours supplémentaires sur le serveur à chaque demande
• il n'est pas nécessaire de conserver la chaîne de requête et les variables de formulaire de la demande d'origine
• nous voulons que nos utilisateurs puissent voir la nouvelle URL redirigée vers laquelle il est redirigé dans son navigateur (et pouvoir l'ajouter aux favoris si nécessaire)

Server.Transfer () doit être utilisé lorsque:

• nous voulons transférer la demande de page en cours vers une autre page .aspx sur le même serveur
• nous voulons préserver les ressources du serveur et éviter les allers-retours inutiles au serveur
• nous voulons préserver la chaîne de requête et les variables de formulaire (éventuellement)
• nous n'avons pas besoin d'indiquer l'URL réelle où nous avons redirigé la demande dans le navigateur Web des utilisateurs

Answer 5

Response.Redirect redirige la page vers une autre page après que la première page soit arrivée au client. Le client connaît donc la redirection.

Server.Transfer quitte l'exécution en cours de la page. Le client ne connaît pas la redirection. Il vous permet de transférer la chaîne de requête et les variables de formulaire.

Cela dépend donc de vos besoins pour choisir le meilleur.

Answer 6

" response.redirect " et " server.transfer " aide à transférer l'utilisateur d'une page à une autre pendant l'exécution de la page. Mais la façon dont ils effectuent ce transfert / redirection est très différente.

Au cas où vous seriez un mec visuel et aimeriez voir une démonstration plutôt que de la théorie, je suggérerais de voir la vidéo ci-dessous sur Facebook qui explique la différence de manière plus démonstrative.

https://www.facebook.com/photo.php?v=762186150488997

La principale différence entre eux est de savoir qui effectue le transfert. Dans " response.redirect " le transfert est effectué par le navigateur lorsque vous êtes dans " server.transfer " le serveur le fait. Essayons de comprendre cette affirmation de manière plus détaillée.

Dans "Server.Transfer" Voici le déroulement du transfert: -

1. L’utilisateur envoie une demande à une page ASP.NET. Dans la figure ci-dessous, la demande est envoyée à " WebForm1 " et nous aimerions accéder à "Webform2".

2. Le serveur commence à exécuter "Webform1". et le cycle de vie de la page commence. Mais avant que le cycle de vie complet de la page ne soit terminé, Server.transfer & # 8221; arrive à "WebForm2".

3. "Webform2" l’objet page est créé, le cycle de vie complet de la page est exécuté et la réponse HTML en sortie est ensuite envoyée au navigateur.

Pendant que vous êtes dans "Response.Redirect" Voici la séquence d'événements pour la navigation: -

1.Le client (navigateur) envoie une demande à une page. Dans la figure ci-dessous, la demande est envoyée à " WebForm1 " et nous aimerions accéder à "Webform2".

2. Cycle de vie de "Webform1" commence à exécuter. Mais entre les étapes du cycle de vie "Response.Redirect" se passe.

3.Maintenant que le serveur effectue une redirection, il envoie une commande HTTP 302 au navigateur. Cette commande indique au navigateur qu'il doit initier une requête GET pour "Webform2.aspx". page.

4.Browser interprète la commande 302 et envoie une demande GET pour "Webform2.aspx".

En d'autres termes, "Server.Transfer". est exécuté par le serveur alors que "Response.Redirect " est exécuté par le navigateur. " Response.Redirect " a besoin de deux demandes pour rediriger la page.

Quand utiliser " Server.Transfer " et quand utiliser " Response.Redirect " ?

Utilisez " Server.Transfer " lorsque vous souhaitez parcourir des pages qui résident sur le même serveur, utilisez " Response.Redirect " lorsque vous souhaitez naviguer entre des pages situées sur différents serveurs et domaines.

Vous trouverez ci-dessous un tableau récapitulatif indiquant les différences et le scénario à utiliser.

Answer 7

La beauté de Server.Transfer, c’est ce que vous pouvez en faire:

TextBox myTxt = (TextBox)this.Page.PreviousPage.FindControl("TextBoxID");

Vous pouvez obtenir n'importe quoi de votre page précédente en utilisant la méthode ci-dessus tant que vous utilisez Server.Transfer mais pas Response.Redirect

Answer 8

Outre le commentaire de ScarletGarden, vous devez également prendre en compte l'impact des moteurs de recherche et de votre redirection. Cette page a-t-elle été déplacée de façon permanente? Temporairement? Cela fait une différence.

voir: Response.Redirect contre "301 déplacé de façon permanente" :

  

Nous avons tous utilisé Response.Redirect sur   une fois ou une autre. C'est le rapide   et un moyen facile de faire pointer les visiteurs   dans la bonne direction s'ils en quelque sorte   se retrouver au mauvais endroit. Mais avez-vous   savoir que Response.Redirect envoie un message   Code d'état de la réponse HTTP de " 302   Trouvé " quand tu pourrais vraiment vouloir   envoyer " 301 déplacé de façon permanente "?

     

La distinction semble petite, mais dans   certains cas, il peut effectivement faire un   grande différence. Par exemple, si vous   utiliser un " 301 déplacé de façon permanente " réponse   code, la plupart des moteurs de recherche supprimeront   le lien obsolète de leur index et   remplacez-le par le nouveau. Si vous   utiliser "302 trouvés", ils continueront   revenir à l'ancienne page ...

Answer 9

Le transfert s'effectue entièrement côté serveur. La barre d'adresse du client reste constante. Une certaine complexité du transfert de contexte entre les demandes. Le vidage et le redémarrage des gestionnaires de pages peuvent être coûteux, alors effectuez votre transfert tôt dans le processus, par exemple. dans un HttpModule pendant BeginRequest. Lisez attentivement la documentation MSDN, testez et comprenez les nouvelles valeurs de HttpContext.Request, en particulier dans les scénarios de post-publication. Nous utilisons généralement Server.Transfer pour les scénarios d'erreur.

Redirect termine la demande avec un statut 302 et une réponse aller-retour côté client avec et mange en interne une exception (perfor-mance du serveur mineur - dépend du nombre de fois que vous en faites par jour). Le client navigue ensuite vers la nouvelle adresse. Barre d'adresse du navigateur & amp; mises à jour de l'historique, etc. Le client paie le coût d'un aller-retour supplémentaire - le coût varie en fonction de la latence. Dans notre entreprise, nous redirigeons beaucoup , nous avons écrit notre propre module pour éviter le coût des exceptions.

Answer 10

Response.Redirect est plus coûteux, car il ajoute un déplacement supplémentaire au serveur pour déterminer où aller.

Server.Transfer est plus efficace mais il peut être un peu déroutant pour l'utilisateur puisque l'URL ne change pas physiquement.

D'après mon expérience, la différence de performances n'a pas été suffisamment significative pour utiliser cette dernière approche

Answer 11

Il existe de nombreuses différences, comme spécifié ci-dessus. En dehors de tout, il y a encore une différence. Response.Redirect () peut être utilisé pour rediriger l'utilisateur vers une page ne faisant pas partie de l'application, mais Server.Transfer () ne peut être utilisé que pour rediriger l'utilisateur application.

//This will work.
Response.Redirect("http://www.google.com");

//This will not work.
Server.Transfer("http://www.google.com");

Answer 12

Server.Transfer ne modifie pas l'URL dans le navigateur client. Par conséquent, le navigateur ne sait pas que vous avez changé pour un autre gestionnaire côté serveur. Response.Redirect indique au navigateur de passer à une autre page afin que l'URL de la barre de titre change.

Server.Transfer est légèrement plus rapide puisqu'il évite un aller-retour vers le serveur, mais le non changement de l'URL peut être bon ou mauvais pour vous, selon ce que vous essayez de faire.

Answer 13

Response.Redirect: indique au navigateur que la page demandée peut être trouvée à un nouvel emplacement. Le navigateur lance ensuite une autre demande à la nouvelle page en chargeant son contenu dans le navigateur. Cela entraîne deux demandes du navigateur.

Server.Transfer: Il transfère l'exécution de la première page à la deuxième page du serveur. En ce qui concerne le client du navigateur, il a fait une demande et la page initiale est celle qui répond avec le contenu. L'avantage de cette approche est un trajet aller-retour de moins vers le serveur à partir du navigateur client. En outre, toutes les variables de formulaire et paramètres de chaîne de requête publiés sont également disponibles sur la deuxième page.

Answer 14

Juste plus de détails sur Transfer (), c'est en fait Server.Execute () + Response.End (), son code source est ci-dessous (à partir de Mono / .net 4.0):

public void Transfer (string path, bool preserveForm)
{
    this.Execute (path, null, preserveForm, true);
    this.context.Response.End ();
}

et pour Execute (), ce qu'il faut exécuter est le gestionnaire du chemin donné, voir

  

ASP.NET ne vérifie pas que l'utilisateur actuel est autorisé à afficher la ressource fournie par la méthode Execute . Bien que la logique d'autorisation et d'authentification ASP.NET s'exécute avant l'appel du gestionnaire de ressources d'origine, ASP.NET appelle directement le gestionnaire indiqué par la méthode Execute et ne réexécute pas la logique d'authentification et d'autorisation pour la nouvelle ressource. Si la stratégie de sécurité de votre application requiert que les clients disposent des autorisations appropriées pour accéder à la ressource, l’application doit forcer la réautorisation ou fournir un mécanisme de contrôle d’accès personnalisé.

     

Vous pouvez forcer la réautorisation en utilisant la méthode Redirect au lieu de la méthode Exécuter . Redirect effectue une redirection côté client dans laquelle le navigateur demande la nouvelle ressource. Comme cette redirection est une nouvelle demande entrant dans le système, elle est soumise à toute la logique d'authentification et d'autorisation de la stratégie de sécurité Internet Information Services (IIS) et ASP.NET.

     

- à partir de MSDN

Answer 15

Response.Redirect implique un aller-retour supplémentaire et met à jour la barre d'adresse.

Server.Transfer ne provoque pas la modification de la barre d'adresse, le serveur répond à la requête avec le contenu d'une autre page

par exemple

Response.Redirect: -

1. Sur le client, le navigateur demande une page http: //InitiallyRequestedPage.aspx
2. Sur le serveur, la réponse à la demande est 302 en passant l'adresse de redirection http: //AnotherPage.aspx .
3. Sur le client, le navigateur envoie une deuxième demande à l'adresse http: //AnotherPage.aspx .
4. Sur le serveur, le contenu de http: //AnotherPage.aspx

Server.Transfer: -

1. Sur le navigateur du client, une page est demandée http: //InitiallyRequestedPage.aspx
2. Sur le serveur Server.Transfer sur http: //AnotherPage.aspx
3. Sur le serveur, la réponse à la demande de http: //InitiallyRequestedPage.aspx est renvoyée http: //AnotherPage.aspx

Response.Redirect

Avantages: - RESTful - Cela change la barre d'adresse, l'adresse peut être utilisée pour enregistrer les changements d'état entre les requêtes.

Contre: - Lent - Il y a un aller-retour supplémentaire entre le client et le serveur. Cela peut être coûteux lorsqu'il existe une latence importante entre le client et le serveur.

Server.Transfer

Avantages: - Rapide.

Contre: - Etat perdu - Si vous utilisez Server.Transfer pour modifier l'état de l'application en réponse aux envois postérieurs, si la page est ensuite rechargée, cet état sera perdu, car la barre d'adresse sera la même que celle de la première fois. demande.

Answer 16

Response.Redirect Response.Redirect () vous enverra vers une nouvelle page, mettra à jour la barre d'adresse et l'ajoutera à l'historique du navigateur. Sur votre navigateur, vous pouvez cliquer en arrière. Il redirige la demande vers des pages HTML simples sur notre serveur ou vers un autre serveur Web. Cela provoque des allers-retours supplémentaires vers le serveur à chaque demande. Il ne conserve pas la chaîne de requête et les variables de formulaire de la demande initiale. Il permet de voir la nouvelle URL redirigée là où elle est redirigée dans le navigateur (et de la marquer si cela est nécessaire). Réponse. La redirection envoie simplement un message au navigateur (HTTP 302).

Server.Transfer Server.Transfer () ne change pas la barre d’adresse, nous ne pouvons pas revenir en arrière. Nous devons utiliser Server.Transfer () quand il / elle ne veut pas que l’utilisateur voie où il va. Parfois sur un " chargement " taper la page. Il transfère la demande de page en cours vers une autre page .aspx sur le même serveur. Il préserve les ressources du serveur et évite les allers-retours inutiles au serveur. Il préserve la chaîne de requête et les variables de formulaire (facultatif). Il n'affiche pas la véritable URL à laquelle il redirige la demande dans le navigateur Web de l'utilisateur. Server.Transfer se passe sans que le navigateur sache rien, le navigateur demande une page, mais le serveur renvoie le contenu d'un autre.