Request.Url.Host vs Request.Url.Authority

Question

J'ai hérité d'une application web ASP.NET écrite en C#. Dans de nombreuses pages du site, le nom d'hôte est récupéré à l'aide de :

BaseHost = Request.Url.Host;

Comme j'utilise Visual Studio 2012 Express et le serveur IIS Express local installé, il semble que je sois bloqué avec un numéro de port ajouté au nom d'hôte (localhost) lorsque je débogue/exécute localement. Le code ci-dessus n'entraîne pas l'inclusion du numéro de port et, en tant que tel, brise les liens générés par le code (liens d'éléments de menu, redirections, etc).

Je vois que je peux résoudre le problème en changeant le code en :

BaseHost = Request.Url.Authority;

Cela semble régler le problème en incluant le port lorsque je fonctionne localement (localhost:4652) et lorsqu'il est publié sur mon serveur d'essai (development.mysite.com).

Ma question : Est-ce que c'est mal vu ? Y a-t-il un moment ou une situation où cela va causer des problèmes sur mon site ? Il semble beaucoup plus facile de remplacer rapidement toutes ces instances. J'ai envisagé d'écrire une petite routine pour ajouter : with Request.Url.Port mais il semble plus facile d'utiliser Request.Url.Authority . Trop facile peut-être...

J'ai essayé de rechercher ma question en ligne et sur MSDN, mais je ne vois pas de réponse.

Answer 1

Selon le MSDN Authority inclut le numéro de port tandis que Host ne le fait pas. Un autre aspect est que Authority échappe les caractères réservés si nécessaire.

Sans connaître votre application, il est difficile de dire si c'est une bonne idée, mais en général, je pense que cela ne va rien casser... alors allez-y...

Une autre option consiste à exécuter l'application IIS au lieu d'IIS Express...

Answer 2

Mon problème est qu'il ajoute TOUJOURS le port, même lorsqu'il n'est pas nécessaire. Par exemple, dans un environnement de serveur de production derrière un pare-feu sur une paire de serveurs web à charge équilibrée, il a continué à mettre le port du pare-feu en place, mais cela a entraîné la rupture de l'URL parce que le port était lié à un serveur web spécifique dans la ferme de serveurs qui n'aurait pas été mappé correctement à travers le pare-feu. Je serais donc très prudent avec cette méthode si vous l'utilisez sur plusieurs serveurs. Elle a causé un problème de rupture avec notre application et nous avons dû revenir à l'utilisation de Url.Host. De plus, le numéro de port des URL de la production web était bizarre.