Как получить URL текущей страницы в MVC 3

Я использую плагин комментариев Facebook в блоге, который я строю. У него есть некоторые теги FBXML, которые интерпретируются JavaScript-кодом Facebook, на который есть ссылки на странице.

Все это прекрасно работает, но я должен передать текущий полный URL-адрес к плагину.

<div style="width: 900px; margin: auto;">
    <div id="fb-root"></div>
    <fb:comments href="URL HERE" num_posts="10" width="900"></fb:comments>
</div>

Каков наилучший способ получить URL текущей страницы? URL запроса.

Решение

Вот окончательный код моего решения:

<fb:comments href="@Request.Url.AbsoluteUri" num_posts="15" width="900"></fb:comments>

Вы могли бы использовать Request.RawUrl, Request.Url.OriginalString, Request.Url.ToString()или Request.Url.AbsoluteUri.

Добавьте этот метод расширения в ваш код:

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));
}

И тогда вы можете выполнить его за пределами RequestContext.HttpContext.Requestсобственности.

В Asp.Net существует ошибка (ее можно обойти, см. Ниже), которая возникает на компьютерах, которые используют порты, отличные от порта 80, для локального веб-сайта (большая проблема, если внутренние веб-сайты публикуются с помощью балансировки нагрузки на виртуальном IP-адресе и порты используются внутренне для правил публикации), благодаря чему Asp.Net всегда добавляет порт в AbsoluteUriсвойстве - даже если исходный запрос не использует его.

Этот код гарантирует, что возвращаемый URL-адрес всегда будет равен URL-адресу, который первоначально запрашивал браузер (включая порт - как он будет включен в заголовок хоста), прежде чем произойдет какое-либо распределение нагрузки и т. Д.

По крайней мере, в нашей (довольно запутанной!) Среде :)

Если между ними есть какие-нибудь фанки прокси, которые переписывают заголовок хоста, то это тоже не сработает.

Обновление 30 июля 2013

Как упомянуто @KevinJones в комментариях ниже - настройка, о которой я упоминаю в следующем разделе, была задокументирована здесь: http://msdn.microsoft.com/en-us/library/hh975440.aspx

Хотя я должен сказать, что не смог заставить его работать, когда попробовал - но это может быть просто я сделал опечатку или что-то в этом роде.

Обновление 9 июля 2012

Я столкнулся с этим некоторое время назад, и хотел обновить этот ответ, но никогда не делал. Когда на этот ответ пришло возражение, я подумал, что должен сделать это сейчас.

«Ошибка», которую я упоминаю в Asp.Net, может управляться явно недокументированным значением appSettings - называемым 'aspnet:UseHostHeaderForRequest'- то есть:

<appSettings>
  <add key="aspnet:UseHostHeaderForRequest" value="true" />
</appSettings>

Я сталкивался с этим, просматривая HttpRequest.UrlILSpy - на это указывает --->слева в следующей копии / вставке из этого представления 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 */
       ...

Лично я не использовал его - он не имеет документов и поэтому не гарантированно останется здесь, однако он может сделать то же самое, что я упомянул выше. Для повышения релевантности в результатах поиска - и признать , кто - то другой seeems, что обнаружил это - установка также упоминается Ник Aceves на Twitter'aspnet:UseHostHeaderForRequest'

public static string GetCurrentWebsiteRoot()
{
    return HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Authority);
}

Request.Url.PathAndQuery

должно работать идеально, особенно если вам нужен только относительный Uri (но с сохранением строк запроса)

Я тоже искал это по причинам Facebook, и ни один из ответов, приведенных до сих пор, не работал должным образом или был слишком сложным.

@Request.Url.GetLeftPart(UriPartial.Path)

Получает полный протокол, хост и путь "без" строки запроса. Также включает порт, если вы используете что-то, отличное от 80 по умолчанию.

Мое любимое...

Url.Content(Request.Url.PathAndQuery)

или просто...

Url.Action()

Одна вещь, которая не упоминается в других ответах, это чувствительность к регистру, если на нее будут ссылаться в нескольких местах (чего нет в исходном вопросе, но стоит принять во внимание, так как этот вопрос появляется во многих похожих поисках ). Основываясь на других ответах, я обнаружил, что изначально сработало для меня:

Request.Url.AbsoluteUri.ToString()

Но чтобы быть более надежным, это стало:

Request.Url.AbsoluteUri.ToString().ToLower()

И затем для моих требований (проверка, с какого доменного имени осуществляется доступ к сайту и показ соответствующего контента):

Request.Url.AbsoluteUri.ToString().ToLower().Contains("xxxx")

Для меня проблема была, когда я пытался получить доступ HTTPContextв конструкторе контроллера, пока HTTPContextеще не готов. При перемещении внутри метода Index это работало:

var uri = new Uri(Request.Url.AbsoluteUri);
url = uri.Scheme + "://" + uri.Host + "/";enter code here

Случай (стиль одной страницы) для истории браузера

HttpContext.Request.UrlReferrer