빌드중인 블로그에서 Facebook 댓글 플러그인을 사용하고 있습니다. 페이지에서 참조되는 페이스 북 자바 스크립트로 해석되는 일부 FBXML 태그가 있습니다.
이 모든 것이 잘 작동하지만 현재 정규화 된 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.
Request.Url.ToString()또는 Request.Url.AbsoluteUri?
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속성에서 실행할 수 있습니다 .
로컬 웹 사이트에 포트 80 이외의 포트를 사용하는 컴퓨터에서 발생하는 버그 (아래 단계 참조, 아래 참조)가 있습니다 (내부 웹 사이트가 가상 IP에서로드 밸런싱을 통해 게시되는 경우 큰 문제) 포트는 내부적으로 규칙을 게시하는 데 사용됩니다. 따라서 Asp.Net은 AbsoluteUri원래 요청 에서 포트를 사용하지 않더라도 항상 포트를 속성 에 추가 합니다.
이 코드는 로드 밸런싱 등이 발생하기 전에 반환 된 URL이 브라우저가 원래 요청한 URL (호스트 헤더에 포함 된 포트 포함) 과 항상 동일한 지 확인합니다 .
적어도, 그것은 (우리보다 복잡한) 환경에서 않습니다 :)
호스트 헤더를 다시 쓰는 사이에 펑키 프록시가 있으면 작동하지 않습니다.
2013 년 7 월 30 일 업데이트
아래 주석에서 @KevinJones가 언급했듯이 다음 섹션에서 언급 한 설정은 여기에 설명되어 있습니다. http://msdn.microsoft.com/en-us/library/hh975440.aspx
나는 그것을 시도했을 때 그것을 작동시킬 수 없다고 말해야하지만-오타 나 무언가를 만드는 것이 될 수 있습니다.
2012 년 7 월 9 일 업데이트
나는 얼마 전에 이것을 보았고이 답변을 업데이트하려고했지만 결코하지 않았습니다. upvote가 방금이 답변에 왔을 때 나는 지금해야한다고 생각했다.
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 */
...나는 개인적으로 그것을 사용하지 않았습니다-그것은 문서화되지 않았고 따라서 붙어 있다고 보장하지는 않습니다-그러나 위에서 언급 한 것과 똑같은 일을 할 수 있습니다. 검색 결과의 관련성을 높이고이를 발견 한 것으로 보이는 다른 사람을 인정하기 위해 'aspnet:UseHostHeaderForRequest'설정은 트위터의 Nick Aceves에 의해 언급되었습니다.
나도 페이스 북의 이유로 이것을 찾고 있었고 지금까지 주어진 답변 중 어느 것도 필요하거나 너무 복잡하지 않았습니다.
@Request.Url.GetLeftPart(UriPartial.Path)쿼리 문자열을 "없이"전체 프로토콜, 호스트 및 경로를 가져옵니다. 기본 80 이외의 것을 사용하는 경우 포트도 포함합니다.
다른 답변에서 언급되지 않은 한 가지 사례는 여러 위치에서 참조 될 경우 대소 문자 구분입니다 (원래 질문에는 없지만이 질문이 많은 유사한 검색에 나타남에 따라 고려할 가치가 있음) ). 다른 답변을 바탕으로 처음에 다음이 효과가 있음을 알았습니다.
Request.Url.AbsoluteUri.ToString()
그러나 더 신뢰할 수 있도록 다음과 같이되었습니다.
Request.Url.AbsoluteUri.ToString().ToLower()
그런 다음 내 요구 사항 (사이트에 액세스하는 도메인 이름 확인 및 관련 내용 표시) :
Request.Url.AbsoluteUri.ToString().ToLower().Contains("xxxx")