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

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

все это отлично работает, но я должен передать текущий, полный 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>
311
asp.net asp.net-mvc c# razor

8 ответов

можно использовать Request.RawUrl, Request.Url.OriginalString, Request.Url.ToString() или Request.Url.AbsoluteUri.

471

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

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 года

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

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

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

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

I лично я не использовал его - он недокументирован и поэтому не гарантирует, что останется - однако он может сделать то же самое, что я упоминал выше. Чтобы повысить релевантность результатов поиска - и признать кого - то еще, кто видит, что обнаружил это -the 'aspnet:UseHostHeaderForRequest' настройка также была упомянута ником Aceves в Twitter

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

должно работать отлично, особенно если вы хотите только относительный Uri (но сохраняя querystrings)

9

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

@Request.Url.GetLeftPart(UriPartial.Path)

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

8

мой любимый...

Url.Content(Request.Url.PathAndQuery)

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

Url.Action()
3

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

Request.Url.AbsoluteUri.ToString()

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

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

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

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

0

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

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