Aspnetcore: Add missing Request.IsAjaxRequest

[aspnet-hello]

_From @danroth27 on Thursday, April 2, 2015 3:18:15 PM_

Copied from aspnet/mvc#2291.

In order to do something like this, you need the IsAjaxRequest method, which doesn't seem to exist in ASP.NET 5.

Note: I think it's Context.Request now, and not just Request .

@glen-84

_Copied from original issue: aspnet/HttpAbstractions#245_

[aspnet-hello]

_From @Tratcher on Thursday, April 2, 2015 3:25:03 PM_

Like this?
https://github.com/aspnet/Security/blob/775eb5ece452e10a27aa166f52b58a6c0b615d18/src/Microsoft.AspNet.Authentication.Cookies/Notifications/DefaultBehavior.cs#L35

[aspnet-hello]

_From @danroth27 on Thursday, April 2, 2015 10:21:54 PM_

@DamianEdwards I thought this was just a header thing - I'm not familiar with the query string parameter. Presumably we should do whatever the existing ASP.NET implementation does.

[aspnet-hello]

_From @glen-84 on Friday, April 3, 2015 1:47:26 AM_

I haven't seen the query string parameter either, but it may make more sense to swap those blocks and check the header first (micro-optimization).

[aspnet-hello]

_From @justinvp on Thursday, April 9, 2015 4:00:13 PM_

Just curious: is this still worth including in light of the up-and-coming Fetch API (which, I don't believe sets X-Requested-With)?

[aspnet-hello]

_From @glen-84 on Friday, April 10, 2015 3:32:43 AM_

@justinvp,

Even though that's just an experimental technology, the same would probably be true for something like an ES6 module loader, where this header would not exist. So maybe this method is not really needed. Detecting an "AJAX" request might look different in the future (users may send their own header, for example). It's also easy enough to just check the header directly.

@danroth27,

You can close this issue if you like, unless you think that it should be added for BC reasons.

[aspnet-hello]

_From @jchadwick on Sunday, May 31, 2015 7:46:14 PM_

I use it in every one of my projects, however only for this purpose:

if(Request.IsAjaxRequest())
   return Partial();

return View();

In other words, I only use it for views and this is always going to be an XHR making this request.

Perhaps we just need a better/smarter way to do partial view rendering from the same controller action.

...or maybe we already do and I'm not aware of it yet?

[aspnet-hello]

_From @Alxandr on Sunday, May 31, 2015 8:27:14 PM_

Or just create a simple extension method in your project that suits your needs. So it checks in whatever way is required to check, depending on what you do on the client.

[aspnet-hello]

_From @jchadwick on Sunday, May 31, 2015 8:30:21 PM_

Right, of course I can create my own extension method. The same could be said for any extension method in the API...

The point here is that this is existing functionality that is still relevant in some form, even if it doesn't cover every use case.

[aspnet-hello]

_From @Alxandr on Sunday, May 31, 2015 8:34:15 PM_

True, but I argue that if it's going to not be working half of the time depending on what client side framework is used to send the request, it will only cause confusion in the long run.

[aspnet-hello]

_From @jchadwick on Sunday, May 31, 2015 8:37:59 PM_

If that's the case, that's totally fair. I think that would be the reason not to carry it forward.
...If that's the case. :) I personally don't think it is, but I'm willing to be proven wrong.

[aspnet-hello]

_From @Alxandr on Sunday, May 31, 2015 8:38:23 PM_

A lot of users will see a method called IsAjaxRequest and will just expect it to work, without having any idea how ajax requests are detected. And when it doesn't work, it'll be considered a bug, or lead to hours spent by an unfortunate user trying to figure out what he did wrong.

[aspnet-hello]

_From @Alxandr on Sunday, May 31, 2015 8:39:25 PM_

Note: I'm speaking on the assumption that fetch does indeed not set the header.

[aspnet-hello]

_From @Bartmax on Sunday, May 31, 2015 10:08:10 PM_

Semantically speaking, is fetch an AJAX request? I guess that since fetch is not here yet, there can be a IsAjaxRequest method that checks for the header and when the future became the present it should be an easy nuget update, may even not call it Ajax anymore. Either way, I created an issue on their repo so we can gather ideas/thoughts from there.

[aspnet-hello]

_From @glen-84 on Monday, June 1, 2015 1:49:38 AM_

I'm using PJAX now, but it's also a case of checking a header, so I do this in _ViewStart.cshtml:

``` c#
@{
if (Context.Request.Headers["X-PJAX"] == null)
{
Layout = "/Areas/Admin/Layouts/Default.cshtml";
}
else
{
Layout = "/Areas/Admin/Layouts/Pjax.cshtml";
}
}

The contents of `Pjax.cshtml`:

``` html
<div id="pjax-content" data-title="@ViewBag.Title">
    @RenderBody()
    @RenderSection("scripts", required: false)
</div>

Related:

• https://github.com/github/fetch/issues/17
• https://esdiscuss.org/topic/2-questions-about-es6-module-loaders

[aspnet-hello]

_From @Tratcher on Tuesday, June 23, 2015 3:19:19 PM_

@DamianEdwards "Yes, I’ve certainly used it in the past. Previously it was based on a request header that jQuery added, but we should research if that’s still the best approach. If jQuery is really the only framework that adds a header, we could decide that this doesn’t belong in the framework at all and instead we could just document it as a sample, but I’d like to see data before making that call."

[aspnet-hello]

_From @Daniel15 on Friday, August 7, 2015 10:55:28 PM_

Most frameworks set the X-Requested-With header, it's pretty much a de-facto standard. Keep in mind that if you use that request header you need to remember to also send a Vary: X-Requested-With response header, as your response varies depending on the value of that header (otherwise, your AJAX responses can be cached and served when you really wanted a full page load, or vice versa). This is not an issue if you use a querystring parameter. For what it's worth, Facebook uses a querystring parameter to differentiate AJAX requests (__a=1)

@justinvp The Fetch API is not really production-ready yet, notably it lacks the ability to cancel requests and also lacks the ability to receive progress events.

[aspnet-hello]

_From @AlexKeySmith on Thursday, March 3, 2016 7:06:36 AM_

:+1:

The Stackoverlfow question: Where is Request.IsAjaxRequest() in Asp.Net MVC 5? Has got quite a few views

[aspnet-hello]

_From @vanillajonathan on Tuesday, September 5, 2017 2:16:13 AM_

Here is an extension method that can be used.

Extensions\HttpRequestExtensions.cs

using System;
using Microsoft.AspNetCore.Http;

namespace Microsoft.AspNetCore.Mvc
{
    public static class HttpRequestExtensions
    {
        public static bool IsAjaxRequest(this HttpRequest request)
        {
            if (request == null)
            {
                throw new ArgumentNullException(nameof(request));
            }

            return (request.Headers != null) && (request.Headers["X-Requested-With"] == "XMLHttpRequest");
        }
    }
}

[timmi4sa]

This team is like US Congress nothing gets done. Just add the darn method we keep discussing it for over 21 months. jQuery is here to stay - we have 10 junior devs that are confused as heck. A task that used to take 10 seconds in MVC5 now requires every stinking project to "reinvent" the wheel by figuring out 1) where to put the extension, 2) which project-specific namespace to expect it in, 3) or which framework (written by what department) to add to include all the useful missing methods. C-mon, the frameworks purpose is to standardize the interface and let us expect where things are. And what's wrong with adding yet another method with a different suffix in the future (remember Win32 API's CreateFileEx anybody????). Don't plan for the future, you can't predict it. JUST DO IT (nike) Ts, ts, ts.

[slaneyrw]

This is a mandatory part of the server side infrastructure, and we've set this header when using fetch. The server absolutely needs to distinguish between a client-side AJAX request ( whether jQuery, XmlHttpRequest, or fetch ) and a window navigation. We can't send back AuthN redirects on an AJAX request and the fetch API's opaque redirect system is fundamentally broken ( you can't read the redirect location ).\