Bug: IsAJAX() relies on inconsistent headers

[MGatner]

Newer JavaScript implementations (i.e. fetch) don't set the HTTP_X_REQUESTED_WITH header, making the current implementation of IncomingRequest::isAJAX() unreliable.

So far I have not found a reliable way to distinguish fetch requests, and if this is ultimately the case then isAJAX() should be removed or reworked so it is clear that it is not definitive.

Ref. https://stackoverflow.com/questions/44202593/detect-a-fetch-request-in-php

[MGatner]

A temporary workaround is to add the header onto the fetch call, if you're writing it yourself:

fetch(url, {
    method: "get",
    headers: {
      "Content-Type": "application/json",
      "X-Requested-With": "XMLHttpRequest"
    }

[lonnieezell]

Oh, well that's a giant PITA.

[MGatner]

Right? With so many things moving to "pure" JavaScript fetch is now becoming a standard. I pretty much gave up, looks like there is no way to differentiate fetch calls unless the developer specifies it. I'd be curious to see how other frameworks are dealing with this.

[lonnieezell]

Did a quick search and didn't find any other ways. So I guess the right thing to do here is to update the user guide to tell them it is not reliable, and provide an example for how to send the header along with their requests.

I'm tempted to rip it out altogether, but if they send the header it still works, and still works with "legacy" javascript solutions, like jQuery, etc. so probably not worth destroying yet. And I know people are already using the framework...

[MGatner]

Is it too gross to change it to isXMLHttpRequest()? That makes it clear that it doesn't cover all AJAX requests but it will catch instances with the header set.

[lonnieezell]

I think that's gross yes. :) But I also don't get too caught up on the name, because much of what we do is not "Asynchronous JavaScript and XML" anymore anyway. AJAX has become the umbrella term for that so I think it is still relevant and the most common name developers use.

Oh - and I don't hardly ever use it as an "XMLHttpRequest" either. More a "JSONHttpRequest" :P

[MGatner]

Oh definitely, but I was referring to the header setting. Right now isAJAX() is pretty much if ($headers['X-Requested-With'] == 'XMLHttpRequest') so naming it after what the check actually is would make it clear what it does and doesn't do.

[lonnieezell]

Yeah, I get that. I don't think it's necessary as long as there's a big section in the docs that addresses this.

I think it definitely warrants looking at how others are handling it (if at all), and a little more research before final release.

[jlamim]

I think it's important to have this information in the documentation so that everyone who is already familiar with this new version of the framework can know about this issue related to how the IsAJAX () method works when used with pure JavaScript.

If you wish I can organize the information added here in this issue and insert this information into the IncomingRequest class documentation.

[lonnieezell]

@jlamim that would be great. I think we need the information on its own page, since it seems it would be referenced from a few different places, including Controller Filters, and Routing maybe?

[jlamim]

@lonnieezell when you said "own page" did you mean that it would be better to post to my personal page / blog or the respective method page within the documentation?

If it's a specific page of the documentation, which page do you recommend?

[lonnieezell]

@jlamim I mean we should create a new page in the documentation specifically about AJAX calls that can be referenced from the 3-4 places it should be mentioned.