Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Add this extension method to your code:</p> <pre><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)); } </code></pre> <p>And then you can execute it off the <code>RequestContext.HttpContext.Request</code> property.</p> <p>There is a bug (can be side-stepped, see below) in Asp.Net that arises on machines that use ports other than port 80 for the local website (a big issue if internal web sites are published via load-balancing on virtual IP and ports are used internally for publishing rules) whereby Asp.Net will <em>always</em> add the port on the <code>AbsoluteUri</code> property - even if the original request does not use it.</p> <p>This code ensures that the returned url is always equal to the Url the browser <em>originally</em> requested (including the port - as it would be included in the host header) before any load-balancing etc takes place.</p> <p>At least, it does in our (rather convoluted!) environment :)</p> <p>If there are any funky proxies in between that rewrite the host header, then this won't work either.</p> <p><strong>Update 30th July 2013</strong></p> <p>As mentioned by @KevinJones in comments below - the setting I mention in the next section has been documented here: <a href="http://msdn.microsoft.com/en-us/library/hh975440.aspx" rel="noreferrer">http://msdn.microsoft.com/en-us/library/hh975440.aspx</a></p> <p>Although I have to say I couldn't get it work when I tried it - but that could just be me making a typo or something.</p> <p><strong>Update 9th July 2012</strong></p> <p>I came across this a little while ago, and meant to update this answer, but never did. When an upvote just came in on this answer I thought I should do it now.</p> <p>The 'bug' I mention in Asp.Net can be be controlled with an apparently undocumented appSettings value - called <code>'aspnet:UseHostHeaderForRequest'</code> - i.e:</p> <pre><code>&lt;appSettings&gt; &lt;add key="aspnet:UseHostHeaderForRequest" value="true" /&gt; &lt;/appSettings&gt; </code></pre> <p>I came across this while looking at <code>HttpRequest.Url</code> in ILSpy - indicated by the <code>---&gt;</code> on the left of the following copy/paste from that ILSpy view:</p> <pre><code>public Uri Url { get { if (this._url == null &amp;&amp; this._wr != null) { string text = this.QueryStringText; if (!string.IsNullOrEmpty(text)) { text = "?" + HttpEncoder.CollapsePercentUFromStringInternal(text, this.QueryStringEncoding); } ---&gt; 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 */ ... </code></pre> <p>I personally haven't used it - it's undocumented and so therefore not guaranteed to stick around - however it might do the same thing that I mention above. To increase relevancy in search results - and to acknowledge somebody else who seeems to have discovered this - <a href="http://twitter.com/nickaceves/status/32932099061194752" rel="noreferrer">the <code>'aspnet:UseHostHeaderForRequest'</code> setting has also been mentioned by Nick Aceves on Twitter</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload