Ajoutez cette méthode d'extension à votre code:
public static Uri UrlOriginal(this HttpRequestBase request)
{
string hostHeader = request.Headers["host"];
return new Uri(string.Format("{0}://{1}{2}",
request.Url.Scheme,
hostHeader,
request.RawUrl));
}
Et puis vous pouvez l'exécuter sur la RequestContext.HttpContext.Request
propriété.
Il y a un bogue (peut être contourné, voir ci-dessous) dans Asp.Net qui se produit sur les machines qui utilisent des ports autres que le port 80 pour le site Web local (un gros problème si les sites Web internes sont publiés via l'équilibrage de charge sur IP virtuelle et les ports sont utilisés en interne pour les règles de publication), où Asp.Net ajoutera toujours le port sur la AbsoluteUri
propriété - même si la requête d'origine ne l'utilise pas.
Ce code garantit que l'URL renvoyée est toujours égale à l'URL que le navigateur a initialement demandée (y compris le port - car il serait inclus dans l'en-tête de l'hôte) avant tout équilibrage de charge, etc.
Au moins, c'est le cas dans notre environnement (plutôt alambiqué!) :)
S'il y a des procurations géniales entre les deux qui réécrivent l'en-tête de l'hôte, cela ne fonctionnera pas non plus.
Mise à jour du 30 juillet 2013
Comme mentionné par @KevinJones dans les commentaires ci-dessous - le paramètre que je mentionne dans la section suivante a été documenté ici: http://msdn.microsoft.com/en-us/library/hh975440.aspx
Même si je dois dire que je ne pouvais pas le faire fonctionner quand je l'ai essayé - mais cela pourrait simplement être moi qui fais une faute de frappe ou quelque chose.
Mise à jour du 9 juillet 2012
Je suis tombé sur cela il y a un petit moment et je voulais mettre à jour cette réponse, mais je ne l'ai jamais fait. Quand un vote positif est venu sur cette réponse, j'ai pensé que je devais le faire maintenant.
Le «bug» que je mentionne dans Asp.Net peut être contrôlé avec une valeur appSettings apparemment non documentée - appelée 'aspnet:UseHostHeaderForRequest'
- c'est-à-dire:
<appSettings>
<add key="aspnet:UseHostHeaderForRequest" value="true" />
</appSettings>
Je suis tombé sur cela en regardant HttpRequest.Url
dans ILSpy - indiqué par le --->
côté gauche du copier / coller suivant de cette vue ILSpy:
public Uri Url
{
get
{
if (this._url == null && this._wr != null)
{
string text = this.QueryStringText;
if (!string.IsNullOrEmpty(text))
{
text = "?" + HttpEncoder.CollapsePercentUFromStringInternal(text,
this.QueryStringEncoding);
}
---> if (AppSettings.UseHostHeaderForRequestUrl)
{
string knownRequestHeader = this._wr.GetKnownRequestHeader(28);
try
{
if (!string.IsNullOrEmpty(knownRequestHeader))
{
this._url = new Uri(string.Concat(new string[]
{
this._wr.GetProtocol(),
"://",
knownRequestHeader,
this.Path,
text
}));
}
}
catch (UriFormatException)
{ }
}
if (this._url == null) { /* build from server name and port */
...
Personnellement, je ne l'ai pas utilisé - il n'est pas documenté et donc pas garanti de rester - mais il pourrait faire la même chose que je mentionne ci-dessus. Pour augmenter la pertinence des résultats de recherche - et pour reconnaître quelqu'un d'autre qui semble avoir découvert cela - le 'aspnet:UseHostHeaderForRequest'
paramètre a également été mentionné par Nick Aceves sur Twitter