Why Request.QueryString["ReturnUrl"] returning NULL even if it is present in the URL?

Question

(This is a more narrow question)

In my asp.net MVC action, I am looking if the ReturnUrl value is in the URL.

My Url looks like this:

http://localhost:56112/user/login?ReturnUrl=/user/settings

In my action, I am looking if that querystring value exists, and it is returning NULL?? How can this be?

The code:

if(Request.QueryString["ReturnUrl"] != null)
{

}

Tracing through the application, it is just skipping the if statement's body i.e. it is NULL.

How can this be explained?

Update

In the controller that checks if the user has logged in, I have a ActionFilter that looks like:

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        base.OnActionExecuting(filterContext);
        // some stuff
        string loginUrl = FormsAuthentication.LoginUrl + "/user/settings;

         context.Response.Redirect(loginUrl);
    }

Answer 1

Try debugging the code - you should be able to see in the debugger the entire list of QueryString parameters, so you can see if you miss-spelt it.

Answer 2

Just ran into a similar issue myself.

Request.RawUrl is correct, the url submitted to the browser is missing the QueryString. Check the View Source for the page, and verify the url on the action attribute of your form element. You'll likely find the QueryString is missing.

What's probably happening is that you're using an overload of @Html.BeginForm that takes the routeValues parameter. Using any overload with "routeValues" will generate a new routing URL and strip any querystring parameters. In my case, I wanted to add the enctype attribute and the only overload requires routeValues to be specified. I suppose it's an oversight in MVC 3.

However, you can still write your own form tag the old-fashioned way. Looking at the source code for MVC 3, it appears that the base overload for Html.BeginForm uses Request.RawUrl.

Try the following:

<form action="@Request.RawUrl" method="post" enctype="multipart/form-data">

Answer 3

I encountered this problem myself and had some difficulty identifying the most optimal solution, so I thought I'd add my brief experience to the conversation.

In debug mode, I scrolled down through all of the properties of the Request; in my case, I found the QueryString value I was seeking in HttpContext.Request.UrlReferrer.Query. The reason for this seems to be that I had clicked on an Html.ActionLink from the page that owned that QueryString value, and that pushed me to an MVC ActionResult handler -- which is technically treated as a separate page (with its own newly defined HttpContext), even though it doesn't represent as such on the URL in the browser while you're debugging.

Further research seems to suggest that Microsoft's preferred solution to this issue is to just pass your value down the chain when you call the handler... but the syntax for making that happen is perhaps not as clear as it should be. In lieu of that, parsing your value from the UrlReferrer seems to work just fine, even if it takes one or two extra lines of code to reach your value. For example, the most basic case scenario with a single value passed on the QueryString could look something like this:

String query = HttpContext.Request.UrlReferrer.Query;
String myValue = query.Split('=')[1];