Repository navigation
Add X-Requested-With header #16
Description
Hi,
I think it should be nice to have hinclude send and "X-Requested-With" header with the value "XMLHttpRequest"
Most js framework send this header with ajax requests and the server side framework i know (including symfony2 which has support for hinclude) use this header to help detect ajax requests
Thanks
Tom
Activity
mnot commentedon Nov 29, 2012
What is it actually useful for, though?
tkleinhakisa commentedon Jan 3, 2013
Hi
It is usefull for detecting ajax request on the server side
It is used by framework like symfony2 or zf2
if i want some server-side code to be executed only in ajax request there is currently no way to detect it using hinclude
Thanks
Tom
tkleinhakisa commentedon Feb 6, 2013
@mnot Any thoughts ?
see for exemple :
http://symfony.com/doc/master/book/templating.html#asynchronous-content-with-hinclude-js
http://symfony.com/doc/master/book/controller.html#the-request-object
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Request.php#L1423
Thanks
Tom
Zeichen32 commentedon Mar 26, 2013
+1
mnot commentedon Mar 29, 2013
What I'm asking for is the use case for this header - why do you need to know that it's an Ajax request on the server side?
Changing content based upon request headers is inviting problems; e.g.,
http://steveluscher.com/archives/ajax-requests-x-requested-with-headers-and-unexpected-cache-contents
mnot commentedon Mar 29, 2013
Oh, and X-R-W also causes problems with CORS; e.g.,
angular/angular.js#1454
hakisa-jerome commentedon Mar 29, 2013
http://steveluscher.com/archives/ajax-requests-x-requested-with-headers-and-unexpected-cache-contents this one was just a particular bug that had to be handled by the developer.
I still think that checking if the request was made through Ajax or not to render a response in the good format is a good use case. Anyway other use cases may exist.
If you read the bug related to angular/angular.js#1454 (angular/angular.js#1004) you'll see that simply removing X-Requested-With is not the best solution. I think removing it only if it is a cross domain request as in jQuery is a better solution.
Maybe there's just a condition missing in my pull request...
mnot commentedon Apr 6, 2013
Sorry, I'm not convinced. What does "good format" mean here? Are you saying that you just want to change to JSON or XML (for example), or that you want to fundamentally return a different response?
Please give a concrete use case.
hakisa-jerome commentedon Apr 8, 2013
I don't want to discuss anymore, you'll never be convinced and there's no problem with that, I'll just stick with my own solution.
tkleinhakisa commentedon Apr 8, 2013
Simple use case:
I have an action to edit an entity.
In normal GET context (not ajax) i want my action to render a full page, including my layout
In ajax GET context i want to only render the form so i can put it in a modalbox
even rails use this header to check for ajax request (http://apidock.com/rails/ActionController/Request/xml_http_request%3Fhttp://apidock.com/rails/ActionController/Request/xml_http_request%3F) ... don't you think that if all great webframework use it, it is for a reason ?
kingcrunch commentedon May 17, 2013
Another example: Login.
When I call the url directly, it should show the whole login page. When I call it via ajax, it should only return the login form.
gnat42 commentedon Jun 3, 2013
Yeah, I usually use it for this same use case. One URL that returns just the form without the full layout via ajax but full layout without...
J7mbo commentedon Jun 7, 2013
Symfony2 has an isXmlHttpRequest method as a major, often used method of the Request class.
As this method, and other server side frameworks use the X-Request-With header to check for a valid XmlHttpRequest, +1. This would be very useful!
KeKs0r commentedon Jul 18, 2013
+1, I really need this one as well, because on ajax calls I only render the main content, on regular calls I render content and layout. Currently Hinclude renders my whole layout within some modals.
mikemeier commentedon Jul 30, 2013
+1 - cant be that hard to understand why its necessary, isnt it?
11 remaining items
pixeltrix commentedon Aug 29, 2013
In Rails we use it to work around broken
Accept:headers sent by browsers. If*/*is present without theX-Requested-Withheader we'll send HTML by default, whereas if the header is present we'll return what theAccept:header has asked for. jQuery includes*/*by default so without the header you'd have to override the accept header on every ajax request otherwise you'd get HTML back when you asked forapplication/jsonAlso if there's no
Accept:header andX-Requested-Withis present we'll render the JS template by default instead of the HTML. The relevant code is in this module: https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/http/mime_negotiation.rbI believe the general recommendation by Rails core is that
Accept:is broken and it's better to use explicit formats in your urls - if you look at the code linked above you'll see that we give precedence to the:formatparameter over the accept header.rudiedirkx commentedon Aug 29, 2013
I don't know what hinclude is, but still, here's my 2c:
My app uses XRW for its response. If a request was made with Ajax, the response is only the content part, otherwise it's the full page (including menu, header, CSS etc etc). So the server knows to do less, because only the content part (a table or a list) is relevant AND the client will receive only the relevant part. The URLs are always the same though, e.g.:
/reservations/2013-01-01. The Accept header in this case is useless, because it's always text/html. The accept header is useless in other cases too, because a CSV export is just a link and the client can't set a header for that, so you'll need to change the URL or add a query param:/reservations/2013-01-01/export.csvor/reservations/2013-01-01?csv, but now I might be digressing.joe-mojo commentedon Aug 29, 2013
All people here not using Accept header or a different url for partial content don't make RESTful apps and/or API. They are wrong. Like all those people that wrote broken markup/js because 95% of people were using IE6.
Please don't hurt the web, respect standards... and be RESTful.
PS : Not only the X-Requested-With header is "borken" by design, but is now recommended not creating X-* headers. Just sayin'
pixeltrix commentedon Aug 29, 2013
Wow, it must be great to have clients that don't care that their site doesn't work in large proportion of browsers - my clients don't really care whether I respect the standards or not.
The
X-Requested-Withheader at least allows Rails to useAccept:for clients that 'respect' the standards - without it we'd have to turn off content negotiation everywhere and rely on urls with embedded formats.I believe the advice was to not create new headers prefixed with X since there was no point - a bit like browser vendors supporting other browsers' CSS prefixes, making them redundant. Since
X-Requested-Withwas added 8 years ago I think we're good to keep using it 😄mstade commentedon Aug 30, 2013
If Rails recommends the use of a different URL rather than headers, then why not just run with that? It's a little silly to introduce a new, non-standard header in order to hack in support for one that's already available, documented and should do what it says on the tin. If (bad) clients don't respect headers, what's to say X-R-W is in any better position in the future (which, arguably, should be more important than the present.) The unfortunate reality of having to deal with shitty clients doesn't provide justification when there is a well supported solution at hand: URLs. They are cheap, well supported and actually solves the problem. It might not be fancy and shiny, but at least it doesn't smell.
pixeltrix commentedon Aug 30, 2013
Who said it was new? It was added to Rails version 0.12 - it predates the adding of REST support to Rails.
URLs are the preferred way and take precedence over the Accept header but we still support the header - we're opinionated, not dogmatic 😄
It's up to @mnot whether he wants to add the header or not - I'm just providing some context on it's history and usage
mstade commentedon Sep 6, 2013
Fair enough; I obviously used the word "new" too freely, my apologies. The salient point being that using standard and better supported mechanisms is preferable to introducing new ones. (Oops, I guess I did it again.)
:)
peter-gribanov commentedon Aug 8, 2016
+1 I do not think it's right to give a different content (different layout) for a single URL. But we need to be able to distinguish AJAX requests and full requests.
For example, i do not want to content loaded via AJAX was available in full request. For example, without this restriction, you can freely embed content on other sites. Of course, this restriction is easy to get around, but that is no reason not to use it.
bluesmoon commentedon Aug 8, 2016
@peter-gribanov it causes performance problems. Do not do it. Use the standard
Acceptheader instead. See https://www.soasta.com/blog/options-web-performance-with-single-page-applications/ for details.peter-gribanov commentedon Aug 8, 2016
@bluesmoon currently headlines
X-Requested-WithorAcceptare not forcibly sent. When you send the AJAX request,Acceptheader is set to*/*. Do you really think it is right to identify the AJAX request?bluesmoon commentedon Aug 8, 2016
Acceptis the right header. You should not be "identifying AJAX" (ie, transport method), you should be "identifying required content".peter-gribanov commentedon Aug 9, 2016
@bluesmoon no. In this case, the content will be same in both cases, but the call context differs.
Identify call context can only be by headers
X-Requested-WithandReferer. HeaderAcceptindicates that we expect to receive and in both cases it will be atext/htmlbecause the library can load only HTML code.bluesmoon commentedon Aug 9, 2016
If the content is the same then why does it matter what the requesting context is? The whole point of using HTTP is that the requesting context is irrelevant.
peter-gribanov commentedon Aug 9, 2016
@bluesmoon yes, that's right. But i'm interested in the ability to block access to content that is not supposed to show in full request.
bluesmoon commentedon Aug 9, 2016
Then you should use a query string parameter or different URL to distinguish. Your client & server may understand custom HTTP headers, but intermediate proxies will not, which means they might respond with cached copies based on the URL and some of the basic content headers. I've seen intermediate proxies also ignore Cache-control headers (and a smaller number even ignore query strings), so a different URL is really the only way to handle this particular case.